www.pengutronix.de/en/Pengutronix e.K.2024-03-18T14:34:14.875043+00:00python-feedgentag:www.pengutronix.de,2024-01-19:/2024-01-19-usb-sd-mux-now-reads-sd-card-info-registers.htmlUSB-SD-Mux now reads SD Card registers2024-01-19T17:22:50+01:00Chris Fiege<div class="section" id="usb-sd-mux-now-reads-sd-card-registers">
<p>The USB-SD-Mux is designed to make life easier for embedded software engineers by automating the transfer of an SD
card between a host PC (deploying a new software image to the SD card) and an embedded Linux device.
Since we have introduced this device into our Embedded Linux development workflow back in 2019 we have probably
written thousands of SD card images with it.
Now the <tt class="docutils literal">usbsdmux</tt> software controlling the device has gained a new feature:
It can now read and decode a few SD card information registers.
This makes it possible to gain more insight into the capabilities of the used SD card - especially while developing
on low-level software and drivers interfacing with the SD card.</p>
<div class="ptx-sidebar">
<div class="title">
Release 24.01
<div class="corner"></div>
</div>
<div class="body">
<p>GitHub <a class="reference external" href="https://github.com/linux-automation/usbsdmux/releases/tag/24.01">release page</a>,
Pypi <a class="reference external" href="https://pypi.org/project/usbsdmux/24.01">page</a></p>
</div>
</div>
<p>Once the SD card is switched to <code>host</code> the new <code>info</code> command reads the
<code>SCR</code> (SD Card Configuration Register),
<code>CID</code> (Card Identification Register) and
<code>CSD_20</code> (Card Specific Data) register.</p>
<p>To make post-processing easier, there is also a <code>--json</code> switch that formats the output
machine readable.</p>
<p>In action the output looks something like this:
(For a full example of the output scroll to the end of this post.)</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>usbsdmux<span class="w"> </span>/dev/usb-sd-mux/id-00035.00008<span class="w"> </span>info
SCR<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span><span class="m">0235848700000000</span>
<span class="w"> </span><span class="o">(</span>...<span class="o">)</span>
CID<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span>9f5449202020202010830258e5017600
<span class="w"> </span>MID:<span class="w"> </span>Manufacturer<span class="w"> </span>ID
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b10011111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x9f</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">159</span>
<span class="w"> </span>enum:<span class="w"> </span>Kingston<span class="w"> </span>SD
<span class="w"> </span><span class="o">(</span>...<span class="o">)</span>
<span class="w"> </span>PSN:<span class="w"> </span>Product<span class="w"> </span>serial<span class="w"> </span>number
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b10000011000000100101100011100101</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x830258e5</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">2197969125</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">2197969125</span>
<span class="w"> </span>MDT_Y:<span class="w"> </span>Manufacturing<span class="w"> </span>date<span class="w"> </span><span class="o">(</span>year<span class="o">)</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00010111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x17</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">23</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">2023</span>
<span class="w"> </span>MDT_M:<span class="w"> </span>Manufacturing<span class="w"> </span>date<span class="w"> </span><span class="o">(</span>month<span class="o">)</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0110</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x6</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">6</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">7</span>
<span class="w"> </span><span class="o">(</span>...<span class="o">)</span>
CSD_20<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span>400e0032db79000074197f800a400000
<span class="w"> </span><span class="o">(</span>...<span class="o">)</span>
<span class="w"> </span>TRAN_SPEED:<span class="w"> </span>max.<span class="w"> </span>data<span class="w"> </span>transfer<span class="w"> </span>rate
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00110010</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x32</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">50</span>
<span class="w"> </span>decoded:<span class="w"> </span><span class="o">(</span><span class="m">2</span>.5,<span class="w"> </span><span class="s1">'10Mbit/s'</span><span class="o">)</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">25000000</span>.0<span class="w"> </span>bit/s
</pre></div>
</div>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1763x1498" href="https://www.pengutronix.de/media/blog/2024/2024-01-19_usb-sd-mux-now-reads-sd-card-info-registers/usb-sd-mux.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2024/2024-01-19_usb-sd-mux-now-reads-sd-card-info-registers/usb-sd-mux.thumb.e27639e4237ddbb50ef9cbf0bde19734.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The USB-SD-Mux</p>
</figcaption>
</figure>
</div><p>To implement this feature Jan first implemented
<a class="reference external" href="https://github.com/linux-automation/usbsdmux/pull/58">reading SD Card registers</a> from our card reader.
To archive this the tool uses vendor specific SCSI commands implemented by the card reader on the USB-SD-Mux.</p>
<p>Next Jan implemented
<a class="reference external" href="https://github.com/linux-automation/usbsdmux/pull/62">register decoding</a>.</p>
<p>Out of curiosity we we grabbed some SD cards we had lying around:</p>
<ul class="simple">
<li>SD Cards from well-known brands tend to carry (potentially) individual serial numbers.
Also the <code>Manufacturer</code> and <code>Product Name</code> fields are often set.</li>
<li>We have also found two no-name SD Cards (purchased at the same time and that totally look the same from the outside)
contain widely different values in the <code>CID</code> register.
Also one of these cards had a serial number far below <cite>10.000</cite>.
But it's still unclear to us what that means.</li>
</ul>
<p>We will probably write a statistics post at some point in the future 😀.</p>
<div class="section" id="statistics-via-mqtt">
<h3>Statistics via MQTT</h3>
<p>Next we want to automate the collection of SD Card information and statistics in our lab.
Therefore we will add an (optional) MQTT client to the USB-SD-Mux tool.
This way we hope to get more insight into details like:</p>
<ul class="simple">
<li>What cards are used.</li>
<li>How manufacturers fill the fields in the <code>CID</code> register (e.g. <code>product name</code>, <code>serial number</code>).</li>
<li>How much data is written to a card over it's lifetime.</li>
</ul>
<p>We are currently implementing this feature and will add it to the USB-SD-Mux tool once it is ready.</p>
</div>
<div class="section" id="complete-list-of-decoded-register-values">
<h3>Complete list of decoded register values</h3>
<p>Finally, here is the complete output of the <code>info</code> command:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>usbsdmux<span class="w"> </span>/dev/usb-sd-mux/id-00035.00008<span class="w"> </span>info
SCR<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span><span class="m">0235848700000000</span>
<span class="w"> </span>SCR_STRUCTURE:<span class="w"> </span>SCR<span class="w"> </span>Structure
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>enum:<span class="w"> </span><span class="m">1</span>.0
<span class="w"> </span>SD_SPEC:<span class="w"> </span>SD<span class="w"> </span>Memory<span class="w"> </span>Card<span class="w"> </span>-<span class="w"> </span>Spec.<span class="w"> </span>Version
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0010</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x2</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">2</span>
<span class="w"> </span>enum:<span class="w"> </span><span class="m">2</span>.00<span class="w"> </span>or<span class="w"> </span><span class="m">3</span>.0X
<span class="w"> </span>DATA_STAT_AFTER_ERASE:<span class="w"> </span>data<span class="w"> </span>status<span class="w"> </span>after<span class="w"> </span>erase
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>SD_SECURITY:<span class="w"> </span>CPRM<span class="w"> </span>Security<span class="w"> </span>Support
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b011</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x3</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">3</span>
<span class="w"> </span>enum:<span class="w"> </span>SDHC<span class="w"> </span>Card<span class="w"> </span><span class="o">(</span>Security<span class="w"> </span>Version<span class="w"> </span><span class="m">2</span>.00<span class="o">)</span>
<span class="w"> </span>SD_BUS_WIDTHS:<span class="w"> </span>DAT<span class="w"> </span>Bus<span class="w"> </span>widths<span class="w"> </span>supported
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0101</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x5</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">5</span>
<span class="w"> </span>bits:<span class="w"> </span><span class="m">1</span><span class="w"> </span>bit,<span class="w"> </span><span class="m">4</span><span class="w"> </span>bit
<span class="w"> </span>SD_SPEC3:<span class="w"> </span>Spec.<span class="w"> </span>Version<span class="w"> </span><span class="m">3</span>.00<span class="w"> </span>or<span class="w"> </span>higher
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b1</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x1</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">1</span>
<span class="w"> </span>EX_SECURITY:<span class="w"> </span>Extended<span class="w"> </span>Security<span class="w"> </span>Support
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>RESERVED
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b100100001</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x121</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">289</span>
<span class="w"> </span>CMD_SUPPORT:<span class="w"> </span>Command<span class="w"> </span>Support<span class="w"> </span>bits
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b11</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x3</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">3</span>
<span class="w"> </span>bits:<span class="w"> </span>Speed<span class="w"> </span>Class<span class="w"> </span>Control<span class="w"> </span><span class="o">(</span>CMD20<span class="o">)</span>,<span class="w"> </span>Set<span class="w"> </span>Block<span class="w"> </span>Count<span class="w"> </span><span class="o">(</span>CMD23<span class="o">)</span>
<span class="w"> </span>RESERVED_MFG
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00000000000000000000000000000000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
CID<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span>9f5449202020202010830258e5017600
<span class="w"> </span>MID:<span class="w"> </span>Manufacturer<span class="w"> </span>ID
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b10011111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x9f</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">159</span>
<span class="w"> </span>enum:<span class="w"> </span>Kingston<span class="w"> </span>SD
<span class="w"> </span>OID:<span class="w"> </span>OEM/Application<span class="w"> </span>ID
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0101010001001001</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x5449</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">21577</span>
<span class="w"> </span>value:<span class="w"> </span>TI
<span class="w"> </span>PNM:<span class="w"> </span>Product<span class="w"> </span>name
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0010000000100000001000000010000000100000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x2020202020</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">137977929760</span>
<span class="w"> </span>value:
<span class="w"> </span>PRV:<span class="w"> </span>Product<span class="w"> </span>revision
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00010000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x10</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">16</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">1</span>.0
<span class="w"> </span>PSN:<span class="w"> </span>Product<span class="w"> </span>serial<span class="w"> </span>number
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b10000011000000100101100011100101</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x830258e5</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">2197969125</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">2197969125</span>
<span class="w"> </span>RESERVED
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>MDT_Y:<span class="w"> </span>Manufacturing<span class="w"> </span>date<span class="w"> </span><span class="o">(</span>year<span class="o">)</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00010111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x17</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">23</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">2023</span>
<span class="w"> </span>MDT_M:<span class="w"> </span>Manufacturing<span class="w"> </span>date<span class="w"> </span><span class="o">(</span>month<span class="o">)</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0110</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x6</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">6</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">7</span>
<span class="w"> </span>CRC:<span class="w"> </span>CRC7<span class="w"> </span>checksum
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>NU1:<span class="w"> </span>not<span class="w"> </span>used,<span class="w"> </span>always<span class="w"> </span><span class="m">1</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
CSD_20<span class="w"> </span>Register<span class="w"> </span>Value:<span class="w"> </span>400e0032db79000074197f800a400000
<span class="w"> </span>CSD_STRUCTURE:<span class="w"> </span>CSD<span class="w"> </span>structure
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b01</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x1</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">1</span>
<span class="w"> </span>enum:<span class="w"> </span><span class="m">2</span>.0
<span class="w"> </span>TAAC:<span class="w"> </span>data<span class="w"> </span><span class="nb">read</span><span class="w"> </span>access-time-1
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00001110</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0xe</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">14</span>
<span class="w"> </span>decoded:<span class="w"> </span><span class="o">(</span><span class="m">1</span>.0,<span class="w"> </span><span class="s1">'1ms'</span><span class="o">)</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">1000000</span>.0<span class="w"> </span>ns
<span class="w"> </span>NSAC:<span class="w"> </span>data<span class="w"> </span><span class="nb">read</span><span class="w"> </span>access-time-2
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00000000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">0</span><span class="w"> </span>CLK<span class="w"> </span>cycles
<span class="w"> </span>TRAN_SPEED:<span class="w"> </span>max.<span class="w"> </span>data<span class="w"> </span>transfer<span class="w"> </span>rate
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b00110010</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x32</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">50</span>
<span class="w"> </span>decoded:<span class="w"> </span><span class="o">(</span><span class="m">2</span>.5,<span class="w"> </span><span class="s1">'10Mbit/s'</span><span class="o">)</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">25000000</span>.0<span class="w"> </span>bit/s
<span class="w"> </span>CCC:<span class="w"> </span>card<span class="w"> </span><span class="nb">command</span><span class="w"> </span>classes
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b110110110111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0xdb7</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">3511</span>
<span class="w"> </span>bits:<span class="w"> </span><span class="m">0</span>,<span class="w"> </span><span class="m">1</span>,<span class="w"> </span><span class="m">2</span>,<span class="w"> </span><span class="m">4</span>,<span class="w"> </span><span class="m">5</span>,<span class="w"> </span><span class="m">7</span>,<span class="w"> </span><span class="m">8</span>,<span class="w"> </span><span class="m">10</span>,<span class="w"> </span><span class="m">11</span>
<span class="w"> </span>READ_BL_LEN:<span class="w"> </span>max.<span class="w"> </span><span class="nb">read</span><span class="w"> </span>data<span class="w"> </span>block<span class="w"> </span>length
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b1001</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x9</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">9</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">512</span><span class="w"> </span>bytes
<span class="w"> </span>READ_BL_PARTIAL:<span class="w"> </span>partial<span class="w"> </span>blocks<span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="nb">read</span><span class="w"> </span>allowed
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>WRITE_BLK_MISALIGN:<span class="w"> </span>write<span class="w"> </span>block<span class="w"> </span>misalignment<span class="w"> </span>allowed
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>READ_BLK_MISALIGN:<span class="w"> </span><span class="nb">read</span><span class="w"> </span>block<span class="w"> </span>misalignment<span class="w"> </span>allowed
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>DSR_IMP:<span class="w"> </span>driver<span class="w"> </span>stage<span class="w"> </span>register<span class="w"> </span>implemented
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>C_SIZE:<span class="w"> </span>device<span class="w"> </span>size
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000000111010000011001</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x7419</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">29721</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">15582887936</span><span class="w"> </span>bytes
<span class="w"> </span>ERASE_BLK_EN:<span class="w"> </span>erase<span class="w"> </span>single<span class="w"> </span>block<span class="w"> </span><span class="nb">enable</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b1</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x1</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">1</span>
<span class="w"> </span>value:<span class="w"> </span>True
<span class="w"> </span>SECTOR_SIZE:<span class="w"> </span>erase<span class="w"> </span>sector<span class="w"> </span>size
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b1111111</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x7f</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">127</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">128</span><span class="w"> </span>write<span class="w"> </span>blocks
<span class="w"> </span>WP_GRP_SIZE:<span class="w"> </span>write<span class="w"> </span>protect<span class="w"> </span>group<span class="w"> </span>size
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">1</span><span class="w"> </span>erase<span class="w"> </span>sectors
<span class="w"> </span>WP_GRP_ENABLE:<span class="w"> </span>write<span class="w"> </span>protect<span class="w"> </span>group<span class="w"> </span><span class="nb">enable</span>
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>R2W_FACTOR:<span class="w"> </span>write<span class="w"> </span>speed<span class="w"> </span>factor
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b010</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x2</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">2</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">4</span><span class="w"> </span>multiples<span class="w"> </span>of<span class="w"> </span><span class="nb">read</span><span class="w"> </span>access<span class="w"> </span><span class="nb">time</span>
<span class="w"> </span>WRITE_BL_LEN:<span class="w"> </span>max.<span class="w"> </span>write<span class="w"> </span>data<span class="w"> </span>block<span class="w"> </span>length
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b1001</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x9</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">9</span>
<span class="w"> </span>value:<span class="w"> </span><span class="m">512</span><span class="w"> </span>bytes
<span class="w"> </span>WRITE_BL_PARTIAL:<span class="w"> </span>partial<span class="w"> </span>blocks<span class="w"> </span><span class="k">for</span><span class="w"> </span>write<span class="w"> </span>allowed
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>FILE_FORMAT_GRP:<span class="w"> </span>file<span class="w"> </span>format<span class="w"> </span>group
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>COPY:<span class="w"> </span>copy<span class="w"> </span>flag
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>PERM_WRITE_PROTECT:<span class="w"> </span>permanent<span class="w"> </span>write<span class="w"> </span>protection
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>TMP_WRITE_PROTECT:<span class="w"> </span>temporary<span class="w"> </span>write<span class="w"> </span>protection
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>value:<span class="w"> </span>False
<span class="w"> </span>FILE_FORMAT:<span class="w"> </span>file<span class="w"> </span>format
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
<span class="w"> </span>enum:<span class="w"> </span>Hard<span class="w"> </span>disk-like<span class="w"> </span>file<span class="w"> </span>system<span class="w"> </span>with<span class="w"> </span>partition<span class="w"> </span>table
<span class="w"> </span>CRC
<span class="w"> </span>raw:<span class="w"> </span><span class="nv">0b0000000</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="nv">0x0</span><span class="w"> </span><span class="o">==</span><span class="w"> </span><span class="m">0</span>
</pre></div>
</div></div>
</div>
<p>The USB-SD-Mux is designed to make life easier for embedded software engineers by automating the transfer of an SD
card between a host PC (deploying a new software image to the SD card) and an embedded Linux device.
Since we have introduced this device into our Embedded Linux development workflow back in 2019 we have probably
written thousands of SD card images with it.
Now the <tt class="docutils literal">usbsdmux</tt> software controlling the device has gained a new feature:
It can now read and decode a few SD card information registers.
This makes it possible to gain more insight into the capabilities of the used SD card - especially while developing
on low-level software and drivers interfacing with the SD card.</p>2024-01-19T17:22:50+01:00tag:www.pengutronix.de,2024-01-09:/2024-01-04-rueckblick-auf-2023-3.htmlPengutronix 2023: A Year in Review - Part III2024-01-09T10:00:00+01:00Enrico JörnsLeonard Göhrs<div class="section" id="pengutronix-2023-a-year-in-review-part-iii">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x855" href="https://www.pengutronix.de/media/images/blog/happy_new_year.jpg" itemprop="contentUrl">
<img alt="colorful fireworks against a black background" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/happy_new_year.thumb.6e73876b8cd6ec22b20777a9cb54a441.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the third and final part of our retrospective series, we look at our sister
company <em>Linux Automation GmbH</em>, which, in addition to moving into new premises,
has used the year to bring the long-awaited <em>LXA TAC</em> (Test Automation
Controller) closer to market maturity despite all adversities. The colleagues
provide a brief review and insight into this, as well as into current further
developments of existing products.</p>
<p>Last but not least, our podcast series "Kernel-Panic: Board on Fire" that began
last year has turned out to be a complete success, which we would like to
briefly overview again at the conclusion of the retrospective.</p>
<div class="section" id="hardware-developments">
<h3>Hardware Developments</h3>
<p>Linux Automation GmbH, Pengutronix's hardware subsidiary, was also not idle in
2023.
There is new hardware in our <a href="https://shop.linux-automation.com/">shop</a>
and products that we can look forward to in 2024.</p>
<div class="section" id="candlelight-fd">
<h4>CandleLight FD</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1024" href="https://www.pengutronix.de/media/blog/2024/2024-01-04_rueckblick-auf-2023/candlelightfd-dsub.jpg" itemprop="contentUrl">
<img alt="Candelight FD board with USB-C and D-Sub-9 connector" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2024/2024-01-04_rueckblick-auf-2023/candlelightfd-dsub.thumb.31b3008a09ed5f1dbfdafb95c1f65b15.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>For several years now, we have been manufacturing and selling
<a href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00-en">CandleLight</a>
open hardware USB-CAN adapters in our shop.
Except for <a href="https://github.com/linux-automation/candleLight/">a few tweaks</a>,
this is the design of
<a href="https://github.com/HubertD/candleLight">HubertD auf GitHub</a>.
Thanks again for that!</p>
<p>Since this year, we have also made our first real own contribution to the
USB-CAN adapter world: the
<a href="https://shop.linux-automation.com/candlelight-fd-en">candleLight FD</a>!</p>
<p>The candleLight FD is a modernized version of the candleLight, with CAN FD and
USB-C connection. Like the candleLight, the candleLight FD is also
<a href="https://github.com/linux-automation/candleLightFD">open hardware</a>.</p>
</div>
<div class="section" id="lxa-tac">
<h4>LXA TAC</h4>
<p>A project that we keep teasing at trade fairs and on the Internet is the LXA
TAC, a Linux computer as a development tool for other Linux computers. The
much-feared EMC test and the even more feared part shortage have massively
delayed our planned launch, but both hurdles have now been overcome and the
first TACs have already gone to external testers.</p>
<p>Soon, the first TACs should also go on sale in our shop.</p>
<p>This year, we also published the Yocto project with which LXA TAC images and
bundles can be generated. So if you want to contribute before the sale day, you
can do so in the meta-lxatac project.</p>
</div>
<div class="section" id="usb-sd-mux-fast">
<h4>USB-SD-Mux Fast</h4>
<p>If you have been closely following the release notes of the USB-SD-Mux control
software, you will have seen it: we are working on a new generation of the
USB-SD-Mux, the USB-SD-Mux Fast.</p>
<p>The USB-SD-Mux Fast contains a new switch for the data lines of the SD card,
thus allowing faster cards to be used in some devices.</p>
<p>USB-C has also been introduced here, and there are two new digital outputs that
can be used to control, for example, the boot mode and reset of a device under
test.</p>
<p>We are still doing extensive internal testing of the USB-SD-Mux Fast, but it
should be available in our shop in the not-too-distant future.</p>
</div>
</div>
<div class="section" id="podcast-kerne-panic-board-on-fire">
<h3>Podcast: Kerne Panic - Board on Fire</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="591x591" href="https://www.pengutronix.de/media/images/blog/podcast.png" itemprop="contentUrl">
<img alt="Pengutronix Podcast logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/podcast.thumb.941e5c7ea39d61a2409897e105225b35.png"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>In the second (and first 'actual') year of our podcast <em>Kernel Panic - Board on
Fire</em>, Leonard gathered around the imaginary campfire with a total of six
colleagues in succession, letting them share more stories about Linux and
tricky bug-hunting tales.</p>
<p>Note that the Podcast is available in German language only.</p>
<ul>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-01-24-kernel-panic-board-on-fire-003-ein-rennen-um-nanosekunden.html">Episode #003</a>: <em>Ein Rennen um Nanosekunden</em> with Michael Grzeschik</p>
<p>About the tricky troubleshooting with tracing, disassembler, and the like to get to the bottom of a sporadically failing USB controller.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-05-24-kernel-panic-board-on-fire-004-optee-und-trustzone.html">Episode #004</a>: <em>OP-TEE und TrustZone - Geheimnisträger in der CPU</em> with Rouven Czerwinski</p>
<p>About OP-TEE and ARM TrustZone, how both are connected and, for example, can be used for storing cryptographic keys.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-06-24-kernel-panic-board-on-fire-005-time-sensitive-networking.html">Episode #005</a>: <em>Time Sensitive Networking - Was wann wo wieso?</em> with Johannes Zink</p>
<p>About the basics of Time Sensitive Networking (TSN) and the Precision Time Protocol (PTP) and the diverse possible applications.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-07-24-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten.html">Episode #006</a>: <em>Der Browser im Fahrkartenautomaten</em> with Bastian Krause</p>
<p>About the use of web technologies for GUIs on embedded devices, different browser engines and ways to test web applications.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-08-24-kernel-panic-board-on-fire-007-der-weg-zum-offenen-grafiktreiber.html">Episode #007</a>: <em>GPU und nu? Der Weg zum offenen Grafiktreiber</em> with Lucas Stach</p>
<p>About the background and origins of open source GPU drivers such as <em>Etnaviv</em> and <em>Nouveau</em> in the Linux kernel and their basic functionality.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/en/blog/2023-09-24-kernel-panic-board-on-fire-008-aus-dem-takt.html">Episode #008</a>: <em>Aus dem Takt - Das Doppelpack Clock-Glitches</em> mit Ahmad Fatoum</p>
<p>About the generation and distribution of clocks in SoCs and what can go wrong.</p>
</li>
</ul>
</div>
<div class="section" id="thank-you">
<h3>Thank You!</h3>
<p>At the end of this series, we would like to thank all customers, developers,
maintainers, bug reporters, interested parties, hackers, and penguins for the
valuable technical and human exchange in 2023 and look forward to an exciting
year with you in 2024!</p>
</div>
</div><p>In the third and final part of our retrospective series, we look at our sister
company <em>Linux Automation GmbH</em>, which, in addition to moving into new premises,
has used the year to bring the long-awaited <em>LXA TAC</em> (Test Automation
Controller) closer to market maturity despite all adversities. The colleagues
provide a brief review and insight into this, as well as into current further
developments of existing products.</p>2024-01-09T10:00:00+01:00tag:www.pengutronix.de,2024-01-08:/2024-01-04-rueckblick-auf-2023-2.htmlPengutronix 2023: A Year in Review - Part II2024-01-08T12:00:00+01:00Enrico JörnsMarie MannMichael TretterLeonard Göhrs<div class="section" id="pengutronix-2023-a-year-in-review-part-ii">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x855" href="https://www.pengutronix.de/media/images/blog/happy_new_year.jpg" itemprop="contentUrl">
<img alt="colorful fireworks against a black background" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/happy_new_year.thumb.6e73876b8cd6ec22b20777a9cb54a441.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the second part of our review, we will focus, among other things, on the
work of our <strong>graphics and multimedia team</strong>, which again covers the entire
Linux stack, from the kernel to mesa to <em>Pipwire</em>, <em>Weston</em> and <em>Webkit</em> has
accommodated a whole range of bug fixes, extensions and adjustments to cover
the requirements of a wide range of customer projects.</p>
<p>In addition to developing patches, contact with the community and keeping up
with the latest topics relating to 'Embedded Linux' are of course also a matter
for us as a service provider.
That's why we were present again at numerous <strong>conferences and events</strong>,
sometimes just as participants, but mostly with our own lectures on current
topics, which we list again as an overview in this part.</p>
<div class="section" id="graphics-multimedia">
<h3>Graphics & Multimedia</h3>
<p>Besides the GPU kernel driver etnaviv and the 3D graphics library mesa, for
which we also brought various optimizations and bug fixes this year, there were
several other exciting projects in the video and audio area that Pengutronix
employees contributed to and that we will briefly introduce below.</p>
<div class="section" id="pipewire">
<h4>PipeWire</h4>
<p>PipeWire is used in various projects as it allows relatively easy sharing of
video streams between applications. For example, one application can display a
camera image on the screen while another encodes and records the same image.</p>
<p>We made many small bug fixes in PipeWire for these use cases. Among other
things, we repaired the JPEG support in pipewiresink and the loading of
<tt class="docutils literal">videotestsrc</tt>.</p>
<p>This contributes to PipeWire's suitability for routing video streams in
addition to audio streams.</p>
</div>
<div class="section" id="gstreamer">
<h4>GStreamer</h4>
<p>At the GStreamer Conference 2023, we introduced the uvcsink element we
developed. This element allows operating a UVC gadget (essentially the camera
side of a USB camera) with a GStreamer pipeline. You just need to configure the
appropriate formats and start a pipeline that sends video data from any source
to a uvcsink. Then you can receive the video stream on another computer as if
it were a normal USB camera.</p>
<p>Besides, we also fixed many small errors in GStreamer that occur in the special
use cases of our customers and that no one had thought of before.</p>
</div>
<div class="section" id="webkit">
<h4>WebKit</h4>
<p>In embedded Linux systems, browsers are increasingly used for UI display.
Perfectly suited for this is WPE (<a class="reference external" href="https://wpewebkit.org/">https://wpewebkit.org/</a>) - a WebKit port
focused on embedded.</p>
<p>The obvious input method is a touch display. We have made several improvements
upstream in processing touch events:</p>
<ul class="simple">
<li>"Do not skip generic touch event handling for axis event gesturing" (<a href="https://github.com/WebKit/WebKit/pull/6550">WebKit PR #6550</a>)</li>
<li>"Do not generate click event for long touch presses" (<a href="https://github.com/WebKit/WebKit/pull/6627">WebKit PR #6627</a>)</li>
<li>"Make TouchPoint ID unique" (<a href="https://github.com/WebKit/WebKit/pull/9599">WebKit PR #9599</a>)</li>
</ul>
<p>The <a href="https://www.w3.org/TR/pointerevents/">Pointer Event API</a> allows
maximum flexibility, e.g., in interpreting gestures. Until now, support for
touch events was missing here.
We were able to bring this <a href="https://github.com/WebKit/WebKit/pull/9688">API as a new feature upstream</a>.</p>
<p>All patches are included in the current <a href="https://wpewebkit.org/release/">stable release 2.42</a>.</p>
</div>
<div class="section" id="weston">
<h4>Weston</h4>
<p>In November, Weston 13 was released, containing many new features that we
developed. With Multi-Backend Support and GL-Renderer Support for VNC and
PipeWire, which we developed, use cases where the screen output should be
simultaneously available on the network are now much more efficient and easier
to configure.</p>
<p>A more detailed overview of the new features of Weston 13 can be found in the
blog post <a href="https://www.pengutronix.de/en/blog/2023-12-01.html">What's New in Weston 13?</a>.</p>
</div>
</div>
<div class="section" id="talks-and-events">
<h3>Talks and Events</h3>
<p>At Pengutronix this year we are looking forward to the release of
lecture recordings on our YouTube channel were not recorded and instead we
presented at numerous local events.
Thanks to the professional work of many community events, the majority of the
lectures are available on various platforms to watch on cold winter days.</p>
<p>In <strong>February</strong> we were at <a href="https://archive.fosdem.org/2023/">FOSDEM</a> in Brussels,</p>
<ul class="simple">
<li><a href="https://archive.fosdem.org/2023/schedule/event/sth_to_hide/">"Having Something To Hide: Trusted Key Storage in Linux"</a> by Ahmad Fatoum</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/delta_like_ota_streaming/">"Delta-like Streaming of (encrypted) OTA Updates for RAUC"</a> by Enrico Jörns</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/network_time_sensitive/">"So you want to build a deterministic networking system: A gentle introduction to Time Sensitive Networking"</a> by Johannes Zink</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/barebox/">"barebox, the bootloader for Linux kernel developers"</a> vom Marco Felsch</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/om_chromium/">"Modern Camera Handling in Chromium: Implementing Camera Access with xdg-desktop-portal and PipeWire in Chromium"</a> by Michael Olbrich</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/fpga_bitstreams/">"Building FPGA Bitstreams with Open-Source Tools"</a> by Michael Tretter</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/pwm/">"Pulse-Width-Modulation (PWM) is easy, isn't it? Turning it off and on again"</a> by Uwe Kleine-König</li>
</ul>
<p>at the <a href="https://pretalx.com/openembedded-workshop-2023/talk/3C8MFF/">OpenEmbedded Workshop</a> in Brussels:</p>
<ul class="simple">
<li><a href="https://pretalx.com/openembedded-workshop-2023/talk/3C8MFF/">"unified key access and code signing in oe-core"</a> by Jan Lübbe</li>
</ul>
<p>In <strong>March</strong> at the <a href="https://chemnitzer.linux-tage.de/2023/en/">CLT</a> in Chemnitz (talks only in German):</p>
<ul class="simple">
<li><a href="https://media.ccc.de/v/clt23-188-einfache-vpns-mit-wireguard">"Einfache VPNs mit Wireguard"</a> by Rouven Czerwinski</li>
<li><a href="https://media.ccc.de/v/clt23-193-der-linux-kernel-entwicklungs-workflow">"Der Linux Kernel Entwicklungs-Workflow"</a> by Rouven Czerwinski</li>
<li><a href="https://media.ccc.de/v/clt23-102-mach-es-einfach-nutze-vim">"Vim - Mach es einfach!"</a> by Marie Mann</li>
<li><a href="https://media.ccc.de/v/clt23-212-linux-systeme-automatisiert-auf-echter-hardware-testen">"Linux-Systeme automatisiert auf echter Hardware testen"</a> by Chris Fiege</li>
<li><a href="https://media.ccc.de/v/clt23-228-heimspiel-fur-deine-daten-die-einfache-cloud-von-zu-hause">"Heimspiel für deine Daten: Die (einfache) Cloud von zu Hause"</a> by Holger Assmann</li>
<li><a href="https://media.ccc.de/v/clt23-251-wenn-gerate-an-baumen-wachsen-linux-device-tree-portierung">"Wenn Geräte an Bäumen wachsen: Linux Device-Tree Portierung"</a> by Ahmad Fatoum</li>
<li><a href="https://media.ccc.de/v/clt23-265-ssh-das-schweizer-taschenmesser-furs-netzwerk">"SSH - Schweizer Taschenmesser fürs Netzwerk"</a> by Björn Lässig</li>
<li><a href="https://media.ccc.de/v/clt23-174-kameras-in-chromium-mit-pipewire-und-xdg-desktop-portal">"Kameras in Chromium mit PipeWire und xdg-desktop-portal"</a> by Michael Olbrich</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1470x828" href="https://www.pengutronix.de/media/blog/2024/2024-01-04_rueckblick-auf-2023/embedded_world_2023.jpg" itemprop="contentUrl">
<img alt="Pengutronix booth at the Embedded World" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2024/2024-01-04_rueckblick-auf-2023/embedded_world_2023.thumb.9f8c3bbb8bfb2d52fb2dd1dd59514df5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Directly following this, we were present with a booth at the <a href="https://www.embedded-world.de/">Embedded World</a> in
Nuremberg, together with our sister company <em>Linux Automation GmbH</em>.
There, we presented our demos on open-source FPGA tooling, open-source graphics
on the Rockchip RK3568, 3D acceleration with WPE WebKit, OTA field updates, hardware
test automation, and T1L Ethernet, and had many interesting conversations.</p>
<p>In <strong>June</strong> at the <a href="https://events.linuxfoundation.org/archive/2023/embedded-open-source-summit/">EOSS</a> in Prague, Czech Republic:</p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=IsT_29qJz7c">"Low level Ethernet specific magic for embedded devices"</a> by Oleksij Rempel</li>
<li><a href="https://youtube.com/watch?v=poVrAdBdOeM">"Do the Time Warp - The Rocky Horror PTP Show: Verification of Network Time Synchronization in the Real World"</a> by Johannes Zink</li>
<li><a href="https://youtube.com/watch?v=LzleI6t29fM">"Why are GPUs (not) fast - a trip through the driver stack"</a> by Lucas Stach</li>
<li><a href="https://www.youtube.com/watch?v=-nnipak67t8">"Yocto DevDay: Quick Development Cycles with NFS-Root: A Prototype Tool"</a> by Enrico Jörns</li>
</ul>
<p>In <strong>July</strong> at the Bosch-OSS-Day in Stuttgart:</p>
<ul class="simple">
<li>"Community Collaboration Patterns: Addressing Risk and Complexity" by Jan Lübbe</li>
<li>"From Vulnerable to Vigilant: A 10+ Year Roadmap for Embedded Software Maintenance" by Jan Lübbe</li>
<li>"Exploring RAUC: A Flexible Building Block for Embedded Linux Updates" by Rouven Czerwinski</li>
</ul>
<p>In <strong>September</strong> at the <a href="https://all-systems-go.io">All Systems Go</a> in Berlin,</p>
<ul class="simple">
<li><a href="https://media.ccc.de/v/all-systems-go-2023-213-exploring-rauc-a-flexible-building-block-for-image-based-updates">"Exploring RAUC: A Flexible Building Block for Embedded Linux Updates"</a> von Rouven Czerwinski</li>
</ul>
<p>at the <a href="https://gstreamer.freedesktop.org/conference/2023/">gStreamer Conference</a> in A Coruña, Spain,</p>
<ul class="simple">
<li>"Building your own USB camera with GStreamer" by Michael Grzeschik</li>
</ul>
<p>at the <a href="https://events.weka-fachmedien.de/tsna-conference/home/">TSNA</a> in Ludwigsburg,</p>
<ul class="simple">
<li>"… If You Try Sometime You’ll Find You Get What You Need - Streaming Media Over TSN Finally Made Easy by Going Mainline?" by Johannes Zink</li>
</ul>
<p>and at the <a href="https://embedded-recipes.org/2023/">Embedded Recipes</a> in Paris, France.</p>
<ul class="simple">
<li><a href="https://youtube.com/watch?v=ViaLmrrMhqk">"One Image to Rule Them All: Portably Handling Hardware Variants"</a> by Ahmad Fatoum</li>
</ul>
<p>In <strong>October</strong> at the <a href="https://indico.freedesktop.org/event/4/">XDC</a> in A Coruña, Spain:</p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=QhGJL4nKfAg">"Wayland Shells for Embedded Systems"</a> by Michael Tretter</li>
</ul>
<p>In <strong>December</strong> at the <a href="https://ese-kongress.de">ESE-Kongress</a> in Sindelfingen:</p>
<ul class="simple">
<li>"Build-Systeme für die effiziente Embedded-Linux-Entwicklung" by Bastian Krause</li>
</ul>
<p>In addition, we used the
<a href="https://ep2023.europython.eu">Euro Python</a>, the
<a href="https://kernel-recipes.org/en/2023/">Kernel Recipes</a>, and the
<a href="https://programm.froscon.org/2023/">FrOSCon</a> as opportunities to meet
and exchange ideas with developers from the community.</p>
</div>
</div>
<p>In the second part of our review, we will focus, among other things, on the
work of our <strong>graphics and multimedia team</strong>, which again covers the entire
Linux stack, from the kernel to mesa to <em>Pipwire</em>, <em>Weston</em> and <em>Webkit</em> has
accommodated a whole range of bug fixes, extensions and adjustments to cover
the requirements of a wide range of customer projects.</p>2024-01-08T12:00:00+01:00tag:www.pengutronix.de,2024-01-05:/2024-01-04-rueckblick-auf-2023.htmlPengutronix 2023: A Year in Review - Part I2024-01-05T22:00:00+01:00Enrico JörnsJan LübbeLeonard GöhrsAhmad Fatoum<div class="section" id="pengutronix-2023-a-year-in-review-part-i">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x855" href="https://www.pengutronix.de/media/images/blog/happy_new_year.jpg" itemprop="contentUrl">
<img alt="colorful fireworks against a black background" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/happy_new_year.thumb.6e73876b8cd6ec22b20777a9cb54a441.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another exciting yet challenging year has passed.
We are a year closer to the Y2038 problem, OpenSSL 1.1.1 is finally history,
kernel v4.14 from 2017 will finally be discontinued in four weeks, upcoming LTS
kernels will only be supported for two years.
The relevance of Linux, not just in embedded systems, is soaring.
Simultaneously, the European (Open Source) software world faces necessary but
challenging transformations, heralded by the upcoming Cyber Resilience Act.</p>
<p>A good opportunity to pause for a moment in this hustle and bustle, reflect and
look back on the past year 2023 and what it has given us as Pengutronix.</p>
<p>We start the first part of our year in review with an overview of our main
contributions to open source projects, most notably the Linux Kernel, into
which the majority of development hours for various projects continue to flow.
But also projects like <em>Barebox</em>, <em>RAUC</em>, or <em>labgrid</em>, which are primarily
maintained by Pengutronix developers, have received groundbreaking innovations
or extensions that we would like to briefly discuss.</p>
<p>In the two following parts of this series, we will then look back on our
activities in the field of <em>graphics and multimedia</em>, as well as the developments
of our hardware company <em>Linux Automation GmbH</em>.</p>
<div class="section" id="contributions-to-the-linux-kernel">
<h3>Contributions to the Linux Kernel</h3>
<p>In 2023, 17 developers from our team introduced about 2500 changes to over 4000
files in the kernel, covering a wide range of topics. These included minor
spelling corrections, major cross-subsystem clean-up operations, bug fixes,
cleanups, simplifications, drivers for previously unsupported hardware
components, and additions to device trees for new and supported hardware.</p>
<p>For instance, Oleksij Rempel expanded the DSA driver for the widely used
Microchip "KSZ" switches to support
<a class="reference external" href="https://lore.kernel.org/all/20231026051051.2316937-1-o.rempel@pengutronix.de/">Wake on LAN (WoL)</a>
and
<a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7-rc8&id=002841be134e60994a34b510eebf5f091d0cd6c6">Access Control Lists</a></p>
<p>At the end of the year, our colleague Uwe Kleine-König took over the
maintenance of the PWM subsystem from long-time maintainer Thierry Reding and
will be responsible for it after the upcoming 6.7 release.</p>
</div>
<div class="section" id="barebox-bootloader">
<h3>Barebox Bootloader</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/images/blog/barebox.svg" itemprop="contentUrl">
<img alt="barebox Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/barebox.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>Barebox Bootloader saw a continuation of the monthly release cycle in 2023 with
1677 changes from 53 contributors, including 19 from Pengutronix. Highlights
include:</p>
<ul class="simple">
<li>Support for new SoCs:
<a class="reference external" href="https://lore.barebox.org/barebox/20230504081745.305841-1-s.hauer@pengutronix.de/">Rockchip RK3588</a>,
<a class="reference external" href="https://lore.barebox.org/barebox/20231110125800.1901232-1-s.hauer@pengutronix.de/">NXP i.MX93</a>, and
<a class="reference external" href="https://lore.barebox.org/barebox/7b035953-f359-f616-9d90-df37da1890a1@pengutronix.de/">TI AM62x</a></li>
<li>New and revised drivers, including DSA drivers for more
<a class="reference external" href="https://lore.barebox.org/barebox/20230111132956.1153359-1-a.fatoum@pengutronix.de/">Microchip</a> and
<a class="reference external" href="https://lore.barebox.org/barebox/20230116134501.2006391-1-a.fatoum@pengutronix.de/">Realtek</a> Ethernet switches,
a higher speed mode for
<a class="reference external" href="https://lore.barebox.org/barebox/20230417164255.1070012-1-a.fatoum@pengutronix.de/">eMMCs</a>, and
initial support for <a class="reference external" href="https://lore.barebox.org/barebox/20230621090329.2652672-1-a.fatoum@pengutronix.de/">USB Type-C</a></li>
<li>True <a class="reference external" href="https://lore.barebox.org/barebox/20230303092131.3063587-1-s.hauer@pengutronix.de/">multiplatform support</a>:
allowing Barebox to support various processor families in the same build,
such as i.MX8M, AM62x, and RK3568</li>
<li>Improvements in Secure Boot, including verified boot (HAB) for i.MX8M, now
<a class="reference external" href="https://lore.barebox.org/barebox/20231017145131.3069283-1-m.felsch@pengutronix.de/">configurable</a>
via Kconfig, and the evaluation of signed unlock tokens in Barebox using
<a class="reference external" href="https://lore.barebox.org/barebox/20231023143122.1760217-1-a.fatoum@pengutronix.de/">JSON Web Tokens</a>.</li>
<li>Stack protector support has been added for
<a class="reference external" href="https://lore.barebox.org/barebox/20230911150900.3584523-4-a.fatoum@pengutronix.de/">detecting and reporting</a>
stack corruption</li>
</ul>
<p>The likely highlights of the v2024.01.0 release include <a class="reference external" href="https://lore.barebox.org/barebox/20231127064947.2207726-1-a.fatoum@pengutronix.de/">expanded</a>
support for the STM32MP13 and
<a class="reference external" href="https://lore.barebox.org/barebox/20231127063559.2205776-1-a.fatoum@pengutronix.de/">bidirectional communication</a>
with OP-TEE for controlling TrustZone-exclusive clocks.</p>
</div>
<div class="section" id="rauc">
<h3>RAUC</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/images/blog/rauc.svg" itemprop="contentUrl">
<img alt="RAUC Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/rauc.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>For RAUC, the open-source embedded Linux updater, three feature releases were
published this year:</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-03-07-rauc-v1-9-released.html">v1.9 in March</a>
added a new InspectBundle D-Bus API for querying detailed information about a
bundle, supporting both local bundle files and URLs on an HTTPS server.</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-07-01-rauc-v1-10-released.html">v1.10 in June</a>
brought more granular progress messages during installation and the ability to
provide additional system information to "handlers."</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-07-01-rauc-v1-10-released.html">v1.11 in December</a>
enabled sending additional headers to the HTTPS update server (e.g., device
serial number, type, variant) and configurable event logs for long-term
traceability of software installations on a device.</p>
<p>Besides new features, we improved CI using sanitizers and integrated RAUC into
OSS-Fuzz. After adding meson as a new build system in the v1.9 release,
autotools were removed in the current v1.11 release. Last but not least, the
<a href="https://rauc.readthedocs.io/">documentation</a> was further improved.
Many thanks to everyone who contributed to RAUC!</p>
</div>
<div class="section" id="labgrid">
<h3>Labgrid</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/images/blog/labgrid.svg" itemprop="contentUrl">
<img alt="labgrid Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/labgrid.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>Labgrid, the hardware control framework, saw its most visible change this year
in the form of <a href="https://github.com/labgrid-project/labgrid/pull/1155">new logging</a>.
This makes the nested steps, such as those a test
suite must perform to provision a board, much more traceable.
Not only the output has been improved, but also the input via labgrid-client is
now easier thanks to <a href="https://github.com/labgrid-project/labgrid/pull/1055">Bash completion</a>.
This also includes specifying resource names, as they now support all relevant
subcommands.
Places with multiple resources of the same type can now be easily used via
labgrid-client.
In addition to the usual mix of smaller features and fixes, the list of
<a href="https://labgrid.readthedocs.io/en/latest/configuration.html#drivers">drivers</a> and
<a href="https://labgrid.readthedocs.io/en/latest/configuration.html#resources">resources</a>
is steadily growing.</p>
<p>Internally, we have switched to a new, <a href="https://github.com/labgrid-project/labgrid/pull/1077">date-based versioning scheme</a>, which better suits the
project's continuous development than the previous semantic versioning.
Also internal, but hopefully noticeable, is the separation of Coordinator and
Client/Library/Pytest-Plugin/Exporter during installation.
This brings simpler dependency management.
Due to the simpler installation, labgrid can now be used even better, for
example, as a library.</p>
</div>
<div class="section" id="openembedded-yocto">
<h3>OpenEmbedded & Yocto</h3>
<p>After presenting our approach for the uniform use of signature keys on hardware
tokens at the OE Workshop right after FOSDEM, the necessary code was included
in the <a href="https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/classes/signing.bbclass">meta-openembedded layer</a>.</p>
<p>In oe-core, in addition to version bumps, typo fixes, and documentation
adjustments to the <tt class="docutils literal"><span class="pre">Upstream-Status</span></tt> field of patches, we also brought some
initial clean-up work to the test code around oe-selftest upstream. These are
part of our efforts to make barebox available as a bootloader in oe-core to the
community.</p>
<p>In total, we contributed 22 patches to meta-oe this year. In oe-core, there
were almost 42, twice as many, but unfortunately still fewer than we would like
according to our own standards. This point will definitely be on the list of
good resolutions for 2024.</p>
</div>
<div class="section" id="ptxdist">
<h3>PTXdist</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/images/blog/ptxdist.svg" itemprop="contentUrl">
<img alt="PTXdist Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/images/blog/ptxdist.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>The compiler wrapper in PTXdist has become stricter this year, now filtering
all accesses to paths outside the BSP build directory. This change enhances the
build system's independence from the host system, leading to greater
reproducibility of build artifacts.</p>
<p>In macros for building Python packages, there is now support for projects using
pyproject.toml instead of setup.py, reflecting the recent standard shift in
Python packaging. Support for Rust software with Cargo as a build system has
also been expanded. For embedded devices typically in the field for over 10
years, Y2K38 compatibility for processing timestamps beyond 2038 is crucial. In
conjunction with the OSELAS.Toolchain 2023.07.0, the glibc version 2.37 now
offers support for this.</p>
<p>The majority of changes in PTXdist, as in previous years, focused on updating
software versions and packaging new software.</p>
</div>
<div class="section" id="distrokit">
<h3>DistroKit</h3>
<p>DistroKit has seen three new releases this year, introducing many updated
software versions, bug fixes, and some new features to our PTXdist reference
distribution <a href="https://www.pengutronix.de/en/software/distrokit.html">DistroKit</a>.</p>
<p>A significant portion of the patches revolved around integrating our update
framework RAUC on <a href="https://lore.distrokit.org/distrokit/20230828085804.293762-1-rhi@pengutronix.de/">v7a and v8a platform boards</a>.
This includes mechanics for creating a
<a href="https://lore.distrokit.org/distrokit/20231213144750.1899431-1-rhi@pengutronix.de/">data partition</a>
at runtime, independent of system partitions.
Minor additions now allow booting a system via
<a href="https://lore.distrokit.org/distrokit/20230502080646.94539-3-jbe@pengutronix.de/#Z31doc:testing.rst">Android's Fastboot protocol</a>
instead of from an SD card, or using a single Barebox recipe for
<a href="https://lore.distrokit.org/distrokit/20230531114744.3281270-1-a.fatoum@pengutronix.de/">all boards on the v8a platform</a>.
The <a href="https://lore.distrokit.org/distrokit/20230710050324.3004120-5-o.rempel@pengutronix.de/">Microchip SAMA5D3 EDS board</a>
is a newly supported platform.</p>
</div>
<div class="section" id="umpf-universal-magic-patch-functionator">
<h3>umpf - Universal Magic Patch Functionator</h3>
<p>Strong tools are the backbone of productive development work as they avoid
tedious tasks and careless errors. This is also true for our patch management
for customer BSPs. Where Git reaches its limits in juggling many long-standing
feature branches, our internally used tool umpf comes into play; it is used for
managing and merging Git-based topic branches, especially in complex and
long-maintained projects like our customer kernel repositories.</p>
<p>This year, in line with our open source and mainline-first strategy, we decided
to release this tool as open-source software, allowing not only knowledgeable
customers but also the interested community to benefit from it.</p>
<p>In our blog post <a href="https://www.pengutronix.de/en/blog/2023-08-29.html">umpf - Git on a New Level</a>,
we provide a deeper insight into the functionality and use of umpf.</p>
</div>
</div>
<p>Another exciting yet challenging year has passed.
We are a year closer to the Y2038 problem, OpenSSL 1.1.1 is finally history,
kernel v4.14 from 2017 will finally be discontinued in four weeks, upcoming LTS
kernels will only be supported for two years.
The relevance of Linux, not just in embedded systems, is soaring.
Simultaneously, the European (Open Source) software world faces necessary but
challenging transformations, heralded by the upcoming Cyber Resilience Act.</p>2024-01-05T22:00:00+01:00tag:www.pengutronix.de,2023-12-22:/2023-12-22-rauc-v1-11-released.htmlRAUC v1.11 Released2023-12-22T12:00:00+01:00Enrico Jörns<div class="section" id="rauc-v1-11-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.11 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.11">release page</a></p>
</div>
</div>
<p>Ho Ho ho! As the year's progress bar approaches 99%, another update is
already completed: RAUC v1.11 is here!</p>
<p>We have collected some noteworthy changes over the last five months
since v1.10.
The initial version of a new event-logging framework allows you to keep track
of your device's update and redundancy boot history in dedicated log files.
With extending the capabilities of sending device information upon HTTP
requests, RAUC extends its portfolio regarding network-based OTA update
support.
Automatic creation of symlinks to active slots, options for excluding images
from bundle conversion, and fuzzing support are just a few others changes to
note.</p>
<p>By the end of the year, it is also time to say goodbye to a companion of many
years: Autotools support in RAUC is taking its well-deserved retirement.
From now on, Meson, which was introduced in RAUC v1.9, will be the sole build
system for RAUC.</p>
<div class="section" id="installation-history-new-event-logging">
<h3>Installation History - New Event Logging</h3>
<p>One of the most notable additions in v1.11 is probably the new installation
history and event logging which has paved its way into mainline since the last
release by introducing several smaller new features.
The changes introduced mainly focused on clarifying relations and states in the
update life-cycle and fix inconsistencies in that context.</p>
<p>With this release, the slot status file was extended: It can now also serve as
storage location for global information that is not slot-specific.
This first user of this is the new <em>boot detection</em> which works by persisting
the system's <tt class="docutils literal">boot_id</tt> and compare it with the current one.
Another addition in slot status file handling is that the <tt class="docutils literal">status</tt> field was
extended to consistently show the actual slot update status and now has
<tt class="docutils literal">pending</tt> and <tt class="docutils literal">failed</tt> state.</p>
<p>The primary purpose of the new framework is to provide configurable log file
writing of relevant update- and redundancy boot-related events over the life
time of a device.
This information is meant to better answer common OTA update-related
questions like:</p>
<ul class="simple">
<li>Was the update <em>X</em> ever installed on this particular device?</li>
<li>After installing update <em>Y</em> a month ago, did the device boot successfully
into that?</li>
<li>Has there ever been an update failure?</li>
</ul>
<p>While some of this information could be obtained from the normal RAUC service
log already, the messages so far lacked well structuring and consistency, and,
with a device lifetime of years in mind, they were hard to filter and archive.</p>
<p>The new dedicated "event" messages make use of Glib's structured logging
capabilities, have distinct identifiers, and are used both for the service log
as well as for the configurable log files.
They consist of a readable text message combined with fields for additional
context information.</p>
<p>Soon, the journal messages will be enriched with <a class="reference external" href="https://www.freedesktop.org/wiki/Software/systemd/catalog/">journald
message catalog</a>
information, allowing users to obtain more details and possible guidance from
the systemd journal output.</p>
<div class="row"><div class="col-md-8"><p>Loggers can be defined in the <tt class="docutils literal">system.conf</tt> by creating a
<tt class="docutils literal"><span class="pre">[log.<name>]</span></tt> section and specifying a log <tt class="docutils literal">filename</tt> .
The log file will be created in the configured <tt class="docutils literal"><span class="pre">data-directory</span></tt> by
default.
Optional configuration items are the output format and event types to be
logged.
Loggers also support file rotation to limit the maximum amount of storage
space consumed over the device lifetime.</p>
<p>Events currently logged are installation start/end/failure, individual
slot writes, good/bad/active marking, boots and service restart.</p>
<p>Available output formats are a human-readable one with details, a short
one with only the message line, and a JSON output to support further
processing.</p>
<div class="clearfix"></div></div><div class="col-md-4"><p>Full-featured configuration example:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[log.install-log]</span>
<span class="na">filename</span><span class="o">=</span><span class="s">install.log</span>
<span class="na">events</span><span class="o">=</span><span class="s">install</span><span class="c1">;boot</span>
<span class="na">output-format</span><span class="o">=</span><span class="s">short</span>
<span class="na">max-size</span><span class="o">=</span><span class="s">1M</span>
<span class="na">max-files</span><span class="o">=</span><span class="s">5</span>
</pre></div>
</div><div class="clearfix"></div></div></div><p>Refer to the <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#installation-history-and-event-logging">RAUC documentation</a>
for more details on the framework and its configuration options.</p>
<p>An example log of the (default) human-readable verbose logger (without event type
filtering) looks as follows:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>2023-12-20T11:32:15Z: Booted into rootfs.0 (A)
boot ID: 55304525-445b-45b2-95e3-71d6646ca437
bundle hash: unknown
2023-12-20T11:32:16Z: Marked slot rootfs.0 good
2023-12-20T11:32:33Z: Service restarted
2023-12-20T11:33:56Z: Installation 871dbf94 started
transaction ID: 871dbf94-75cf-4a6a-b3de-6b81d2013d9e
2023-12-20T11:33:56Z: Marked slot rootfs.1 bad
2023-12-20T11:33:56Z: Updating slot efi.0
2023-12-20T11:34:17Z: Updating slot rootfs.1
2023-12-20T11:35:05Z: Marked slot rootfs.1 active
bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
bootname: B
2023-12-20T11:35:06Z: Installation 871dbf94 succeeded
bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
bundle version: 1.0
transaction ID: 871dbf94-75cf-4a6a-b3de-6b81d2013d9e
2023-12-20T11:35:50Z: Booted into rootfs.1 (B)
boot ID: 3850cffb-2eca-4960-b682-ec95bd5a222c
bundle hash: ee3f0b6649cd1425efe69c3947f7c5e862ce0e3f91cb4d36904a1e99c2bff110
2023-12-20T11:35:51Z: Marked slot rootfs.1 good
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We don’t consider the details of the new log events fixed yet, so
please use them as a preview and for testing.</p>
</div>
</div>
<div class="section" id="http-header-information">
<h3>HTTP Header Information</h3>
<p>RAUC becomes more and more relevant in the context of (semi-)automatic
network-based OTA roll-outs where devices fetch their updates from a server.
With its built-in <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#http-streaming">HTTP(S) streaming capabilities</a>,
RAUC already made a leap forward towards securely supporting network downloads
without the need for intermediate services.</p>
<p>This is sufficient for simple externally triggered bundle downloads from a
fixed location, but use cases like automated downloads, update roll-out
scheduling, device/fleet monitoring, etc. often require more information about
the system and more logic within the client.</p>
<p>When using dedicated deployment servers with control APIs, these
tasks clearly belong to an external service (like <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a> for <a class="reference external" href="https://eclipse.dev/hawkbit/">hawkBit</a>).
However, for many cases, a simple HTTP server with a minimum of backend
handling would be sufficient.</p>
<p>As the first step towards supporting the <a class="reference external" href="https://github.com/rauc/rauc/issues/1114">simple update server use-case</a> in RAUC, we identified the ability
to send additional information about the device to the server.
For this, RAUC v1.11 now comes with configurable and <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#additional-http-header-information">extendable HTTP header
information support</a>.</p>
<div class="row"><div class="col-md-6"><p>The set of headers to be sent can be set in the <tt class="docutils literal">system.conf</tt>
<tt class="docutils literal">[streaming]</tt> section option <tt class="docutils literal"><span class="pre">send-headers</span></tt>:</p>
<div class="clearfix"></div></div><div class="col-md-6"><div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[streaming]</span>
<span class="na">...</span>
<span class="na">send-headers</span><span class="o">=</span><span class="s">boot-id</span><span class="c1">;transaction-id,uptime</span>
</pre></div>
</div><div class="clearfix"></div></div></div><div class="row"><div class="col-md-6"><p>Additional details can be provided using the <tt class="docutils literal"><span class="pre">system-info</span></tt> handler:</p>
<div class="clearfix"></div></div><div class="col-md-6"><div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[handlers]</span>
<span class="na">system-info</span><span class="o">=</span><span class="s">example-script.sh</span>
</pre></div>
</div><div class="clearfix"></div></div></div><div class="row"><div class="col-md-6"><p>The script <tt class="docutils literal"><span class="pre">example-script.sh</span></tt> can write variables prefixed with
<tt class="docutils literal">RAUC_HTTP_</tt> to stdout that will be forwarded as HTTP headers:</p>
<div class="clearfix"></div></div><div class="col-md-6"><div class="code-block">
<div class="highlight"><pre><span></span><span class="ch">#!/bin/sh</span>
<span class="nb">echo</span><span class="w"> </span><span class="s2">"RAUC_HTTP_MAC=</span><span class="k">$(</span>cat<span class="w"> </span>/sys/class/net/eth0/address<span class="k">)</span><span class="s2">"</span>
</pre></div>
</div><div class="clearfix"></div></div></div><p>An example GET request would then look as follows:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="nf">GET</span> <span class="nn">/test/good-verity-bundle.raucb</span> <span class="kr">HTTP</span><span class="o">/</span><span class="m">1.1</span>
<span class="na">Host</span><span class="o">:</span> <span class="l">localhost:8081</span>
<span class="na">Range</span><span class="o">:</span> <span class="l">bytes=0-3</span>
<span class="na">User-Agent</span><span class="o">:</span> <span class="l">rauc/v1.11</span>
<span class="na">Accept</span><span class="o">:</span> <span class="l">*/*</span>
<span class="na">RAUC-Boot-ID</span><span class="o">:</span> <span class="l">70b30259-817a-4f11-89bb-ae99d22b4b11</span>
<span class="na">RAUC-Transaction-ID</span><span class="o">:</span> <span class="l">9c18267e-36ff-4672-ac0d-19f639ca1910</span>
<span class="na">RAUC-Uptime</span><span class="o">:</span> <span class="l">19.83</span>
<span class="na">RAUC-MAC</span><span class="o">:</span> <span class="l">00:b0:d0:63:c2:26</span>
</pre></div>
</div><p>It is then up to the update server to either just log this information for
later or to use them for custom purposes.</p>
</div>
<div class="section" id="links-for-active-slot-devices">
<h3>Links for Active Slot Devices</h3>
<p>For some use cases it can be required to know or access the currently active
slots from RAUC's perspective.
While this information so far could only be retrieved by parsing the output of
<tt class="docutils literal">rauc status</tt> or its D-Bus call pendant, both meant additional effort.</p>
<p>RAUC v1.11 introduces a simple solution for this: the automatic creation of
symbolic links to the active slot devices under <tt class="docutils literal">/run/rauc/slots/active</tt>.
The symlinks are named after the corresponding slot class.</p>
</div>
<div class="section" id="ignore-images-during-casync-conversion">
<h3>Ignore Images During (casync) Conversion</h3>
<p>People that wanted to use RAUC's <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#rauc-casync-support">casync support</a>
instead of the new built-in streaming, sometimes ran into a problem: <tt class="docutils literal">rauc
convert</tt> unconditionally converted <em>all</em> images from the conventional
bundle to casync index files.
However, some slot/storage types simply (like raw NAND) cannot be written with
casync.</p>
<p>With this release we have introduced the new <tt class="docutils literal"><span class="pre">--ignore-image</span></tt> option to
exclude certain slots from the conversion.
For example, to exclude the <tt class="docutils literal">bootloader</tt> slot class, use</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="go">rauc convert --ignore-image=bootloader input-bundle.raucb mixed-casync-bundle.raucb</span>
</pre></div>
</div></div>
<div class="section" id="further-notable-changes">
<h3>Further Notable Changes</h3>
<p>RAUC now has a simple mechanism for detecting changes to its config file during
service runtime.
Just like e.g. systemd, it now warns (in the journal/service log) if the
config file was changed but you forgot to restart the RAUC service which turned
out to be a common pitfall over the years.</p>
<p>For the <tt class="docutils literal">rauc resign</tt> and <tt class="docutils literal">rauc <span class="pre">replace-signature</span></tt> commands, support for
encrypted bundles was implemented.</p>
<p>This release also comes with a fuzzing support.
Initially contributed by René Fischer, it was extended and adapted to the needs of the
<a class="reference external" href="https://github.com/google/oss-fuzz">OSS-Fuzz</a> project where RAUC is
<a class="reference external" href="https://oss-fuzz-build-logs.storage.googleapis.com/index.html#rauc">monitored</a> since
then.</p>
<p>Parts of the documentation received a little makeover.
Both the generated HTML
documentation as well as the man pages can now be installed by meson and thus
can be made available in distros as offline documentation.</p>
<p>For a comprehensive list of changes in v1.11, see the official <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-11-released-dec-20-2023">changelog</a>.</p>
</div>
<div class="section" id="outlook">
<h3>Outlook</h3>
<p>For those wanting to update applications, data files, containers, etc.
that are separate from the root file system, the <a class="reference external" href="https://github.com/rauc/rauc/pull/1301">pull-request #1301</a> gives a preview of the ongoing work
to implement the RAUC <a class="reference external" href="https://github.com/rauc/rauc/issues/969">Concept Issue #969</a> for <em>Artifact Updates</em>.
Stay tuned for one of the most significant extensions RAUC has received recently.</p>
</div>
<div class="section" id="thank-you">
<h3>Thank You!</h3>
<p>Contributions to this release came from Angelo Compagnucci, Roland Hieber,
Zygmunt Krynicki, David Runge, Emil Velikov, Hans Christian Lonstad, René
Fischer, Stephan Wurm, Thomas Kilian, Ulrich Ölmann, and Uwe Kleine-König.</p>
<p>Thanks to you and to all RAUC contributors for effort you put in discussing
ideas, reporting and reproducing bugs, and especially for contributing fixes
and features over the last year.
We wish you Happy Holidays and a successful version bump to 2024!</p>
</div>
</div>
<p>Ho Ho ho! As the year's progress bar approaches 99%, another update is
already completed: RAUC v1.11 is here!</p>2023-12-22T12:00:00+01:00tag:www.pengutronix.de,2023-12-01:/2023-12-01.htmlWhat's new in Weston 13?2023-12-01T00:00:00+01:00Michael TretterPhilipp Zabel<div class="section" id="what-s-new-in-weston-13">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="117x150" href="https://www.pengutronix.de/media/blog/2023/2023-12-01_weston-13/wayland.png" itemprop="contentUrl">
<img alt="Wayland Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-12-01_weston-13/wayland.thumb.c413adce0a728213494a75aa496a379c.png"/>
</a><figcaption itemprop="caption description" style="
width: 117px;
"></figcaption>
</figure>
</div><p>Last Tuesday, <a href="https://lists.freedesktop.org/archives/wayland-devel/2023-November/043326.html">Weston 13.0</a>
has been released. The release contains several new features that have
been developed and mainlined for our embedded systems' use cases. In
this blog post, we would like to explain the new features relevant for
us — multi-backend, OpenGL renderer for the PipeWire and VNC backends
and overlapping outputs — and outline why those are important for
embedded usecases.</p>
<!-- TODO Ein Bild der 4-Video-Demo mit Fernwartung über VNC. -->
<div class="section" id="new-features">
<h3>New Features</h3>
<p>With the <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/578">Multi-Backend</a>
feature, it is now possible to have an additional remote-control- or
streaming feature for a system where Weston controls the output on a
locally connected display. Up to now, Weston was restricted by the fact
that only one backend could be active at the same time, and thus only
outputs of one type (i.e. DRM or VNC) were available. Now with the multi
backend, this restriction is gone and Weston can now create outputs of
different types, so for example we can now operate a DRM, VNC and
PipeWire output in one system in parallel. For many embedded systems
with networking, a remote-control operation is a welcome feature.</p>
<p>Embedded hardware is still performance constrained, so hardware
accelerated rendering stays important. Up to now, the VNC and PipeWire
backend could only be used with the Pixman software renderer. Starting
with Weston 13, these backends can also make use of the
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1106">OpenGL accelerated renderer</a>.
In Weston, a renderer can be shared for all backends, so this does also
allow to continue using the GL renderer for the DRM backend when a
PipeWire or VNC output is added. Therefore, drawing operations can be
performed on the GPU instead of the CPU and hardware ressources can be
utilized in a more efficient way.</p>
<p>The support of <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1291">overlapping outputs</a>
has interesting effects for our usual use cases. First of all, hardware
planes can now be also used for windows being displayed on multiple
outputs. Hardware planes partially make it possible to combine multiple
windows on the display output path, thus leading to more ressource
availability on the GPU. Secondly, it is now possible to display the
same desktop content on multiple outputs. Before this change, damage
tracking constraints made it necessary to separate outputs completely,
which in turn lead to workarounds to show a window both on DRM and VNC.</p>
</div>
<div class="section" id="upcoming-work">
<h3>Upcoming Work</h3>
<p>Even with those features now being in mainline, we won't run out of work
soon. The following features to improve performance and configuability
of Weston for embedded systems are now planned.</p>
<p>There is already a merge request for <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366">DMABUF-support for the
PipeWire backend</a>.
With this feature, Weston can hand over GL rendered frames directly to
PipeWire and, without a copy, further on to hardware accelerated JPEG-
or H.264 encoders. This makes it possible to get rid of unnecessary
copies of large buffers, resulting in better performance for streaming
and recording.</p>
<p>A similar optimization would be desirable for the VNC backend; this will
need more work in Neat VNC.</p>
<p>Another issue is that currently the config options for multiple outputs
are quite constrained. We are missing a feature to position outputs on
the desktop and configure their size, both by configuration (similar to
the clone mode) and programatically, with a plugin. The programmatic
part could be combined with a <a href="https://www.youtube.com/watch?v=qK2Emqp9t0g&t=14244s">hypothetic window management
infrastructure</a>.
It is also desired to create and remove the VNC and PipeWire outputs on
runtime.</p>
<p>Nevertheless, Weston continues to prove being a great Wayland compositor
for embedded systems. It makes sense to update your own systems to
Wayland 13.</p>
</div>
</div>
<p>Last Tuesday, <a href="https://lists.freedesktop.org/archives/wayland-devel/2023-November/043326.html">Weston 13.0</a>
has been released. The release contains several new features that have
been developed and mainlined for our embedded systems' use cases. In
this blog post, we would like to explain the new features relevant for
us — multi-backend, OpenGL renderer for the PipeWire and VNC backends
and overlapping outputs — and outline why those are important for
embedded usecases.</p>2023-12-01T00:00:00+01:00tag:www.pengutronix.de,2023-09-24:/2023-09-24-kernel-panic-board-on-fire-008-aus-dem-takt.html[Podcast] Kernel Panic - Board on Fire ~~> #008: Aus dem Takt - Das Doppelpack Clock-Glitches2023-09-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-008-aus-dem-takt-das-doppelpack-clock-glitches">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#008: Aus dem Takt - Das Doppelpack Clock-Glitches", "summary": "Ahmad und Leonard reden dar\u00fcber warum es in System on a Chips so viele Clocks und Takte gibt und was mit ihnen so schief gehen kann.", "publicationDate": "2023-09-24T10:10:10+00:00", "duration": "01:05:05", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-09-24-kernel-panic-board-on-fire-008-aus-dem-takt.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/008_pll_glitches.mp3", "size": 48084764, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/008_pll_glitches.mp3", "size": 48084764, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge reden Ahmad und Leonard über Takte / Clocks in Prozessoren.
Darüber warum es so viele gibt, wie sie erzeugt und im Chip verteilt werden und
darüber, was dabei eigentlich so schief gehen kann.</p>
<p>Dabei berühren wir Themen wie PLLs (Phase Locked Loops), Clock Trees, Gates
und Muxes, die Takte im System erzeugen und verteilen und Glitches, die beim
Umschalten der Taktquellen passieren können.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1920x1080" href="https://www.pengutronix.de/media/blog/2023/2023-09-24_kernel-panic-board-on-fire-008-aus-dem-takt/title_bauchbinde.jpg" itemprop="contentUrl">
<img alt="Portrait von Leonard und Ahmad nebeneinander vor einer mit Efeu überwachsenen Wand. Beide tragen ein schwarzes T-Shirt." itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-09-24_kernel-panic-board-on-fire-008-aus-dem-takt/title_bauchbinde.thumb.1b46c031e0b7f6e95c988c9b20114745.jpg"/>
</a><figcaption itemprop="caption description" style="
"><p>Leonard und Ahmad</p>
</figcaption>
</figure>
</div></div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Einleitende warme Worte. Ahmad ist zwar nicht das erste Mal im Podcast,
trotzdem stellen wir ihn, mich (Leonard), den Podcast und das Drumherum
nochmal etwas vor.
Nach vier Techweek-Folgen, in denen jeweils frei über ein Thema getratscht
würde wollen wir jetzt wieder zurück zu den Software-Schauergeschichten.
Deshalb reden wir in dieser Folge über zwei Themen, die mit der Erzeugung
und Verteilung von Taktsignalen im System zusammenhängen und wie sie schief
gehen kann.</dd>
<dt>05:45</dt>
<dd>Was ist ein Takt in einem Prozessor und warum gibt es mittlerweile oftmals
ganz viele verschiedene Takte?
Wie werden diese verschiedenen Takte aus einer Eingangsfrequenz abgeleitet?</dd>
<dt>15:45</dt>
<dd>Wie erzeugt eine PLL (Phase Locked Loop) aus einer niedrigen Eingangsfrequenz
eine höhere Ausgangsfrequenz und wie verwendet man sie in der Praxis?</dd>
<dt>22:15</dt>
<dd>Was sind Clock-Glitches, wie können sie durch Umkonfigurieren des Clock-Trees
passieren und welche Probleme können sie hervorrufen?</dd>
<dt>27:15</dt>
<dd>In der ersten Geschichte aus der Praxis wurden durch einen Designfehler im
Chip bei eigentlich zulässigen Schaltvorgängen Clock-Glitches erzeugt,
die eine Einheit im Prozessor quasi für einen Zyklus übertaktet haben.
Um das zu verhindern müssen Workarounds implementiert werden.</dd>
<dt>35:45</dt>
<dd>Zwischen den Geschichten reden wir etwas über die Probleme,
die im Allgemeinen beim Umschalten von Clocks im laufenden System auftreten
können und wie man um sie herum arbeitet.</dd>
<dt>38:30</dt>
<dd>In der zweiten Geschichte geht es um eine andere Art Clock-Glitch,
bei der manchmal Taktpulse auf eine etwas längere Zeit gestreckt werden,
wodurch andere Chips im System aus dem Tritt geraten.</dd>
<dt>58:25</dt>
<dd>Als kleines Bonus-Thema reden wir noch darüber wie die PLLs ganz bewusst
ein "schlechtes" Taktsignal erzeugen können um Störabstrahlungen des
Gesamtsystems zu verringern.</dd>
<dt>63:20</dt>
<dd>Abschluss der Folge.</dd>
</dl>
</div><p>In dieser Folge reden Ahmad und Leonard über Takte / Clocks in Prozessoren.
Darüber warum es so viele gibt, wie sie erzeugt und im Chip verteilt werden und
darüber, was dabei eigentlich so schief gehen kann.</p>2023-09-24T10:10:10+01:00tag:www.pengutronix.de,2023-08-29:/2023-08-29.htmlumpf - Git on a New Level2023-08-29T00:00:00+01:00Holger AssmannMichael Olbrich<div class="section" id="umpf-git-on-a-new-level">
<div class="ptx-sidebar">
<div class="title">
Mainline First
<div class="corner"></div>
</div>
<div class="body">
<blockquote>
Our <a href="https://github.com/pengutronix/umpf/blob/master/README.rst">Github-Repository</a>
provides the source code and a comprehensive documentation for <strong>umpf</strong>.</blockquote>
</div>
</div>
<p>Modern software development is commonly accompanied by a <a href="https://git-scm.com/">version control
system like Git</a> in order to have changes to the source
code being documented in a traceable manner. Furthermore, any version state should
be easily reproducible at any time. However, for work on complex projects such as
the BSP ("Board Support Package") of an embedded system with its multiple
development aspects, the simple stacking of the individual changes on top of
each other does not scale.</p>
<p>Oftentimes, different functionalities for a BSP are developed in parallel based
on a common version state. Then there might be back ports to be
integrated, and specific work intended for upstream has to be managed separately.
This separation is commonly handled by introducing individual Git branches.</p>
<p>However, this model becomes complicated once the subsequent merging of more than
two branches is due - e.g. in order to be able to test the entire project, or to
publish a release. Manual merging of the individual branches is as
time-consuming as it is error-prone and it collides with the short test cycles
of iterative development models.</p>
<div class="section" id="merging-branches-reasonably">
<h3>Merging Branches Reasonably</h3>
<p>To simplify this last mentioned step and to be able to generate a reproducible
patch stack from a selection of topic branches, we have developed the
<strong>Universal Magic Patch Functionator (umpf)</strong> as an open source extension for
the local Git installation.</p>
<p>With <em>umpf</em>, a linear patch series can be generated within the regular Git
infrastructure and across multiple Git branches ("topic branches"), with their
individual dependencies being preserved at the same time.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/idea.svg" itemprop="contentUrl">
<img alt="The Idea Behind umpf" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/idea.svg" style="
width: 90%;
"/>
</a><figcaption itemprop="caption description" style="
"><p>umpf combines several parallel topic branches into a serialized patch
stack. By referencing the respective HEADs, the underlying branches
can always be restored to their state at the time of tagging.</p>
</figcaption>
</figure>
</div><p>This series of commits is described by a regular Git tag, which is supplemented
by <em>umpf</em> with references to the contained topic branches. Such a <em>utag</em> thus
combines several properties:</p>
<ul class="simple">
<li>The marker includes a timestap, which makes it <strong>uniquely referable</strong>.</li>
<li>A <strong>linear patch stack</strong> can be exported as a series.</li>
<li>The state of the underlying branches is preserved at the time of the <em>umpf</em>.
Later changes of a branch (e.g. force pushes after bug fixes) have no
influence on the resulting <em>utag</em>. Consequently, the actual development state
at the time of tagging can be <strong>easily retraced and restored</strong>.</li>
<li>By archiving the contained branches, their dependencies among each other can
be traced with <strong>normal Git tooling</strong>.</li>
<li>The project type is recognized heuristically and a suitable timestamp gets
integrated - for example as EXTRAVERSION in a Makefile. This allows for a
<strong>clear identification</strong> later, even of the already compiled and delivered
software.</li>
</ul>
<p>The generating of an <em>utag</em> and its linear patch series is relatively
straight-forward and only requires an existing Git project. <em>umpf</em> itself is a
bash script and uses the regular tools that Git provides. Therefore, tags and
merges generated by <em>umpf</em> can later be processed by any normal Git
installation. An <em>utag</em> is therefore also regularly added to the existing
repository via <code>git push</code> and can be re-called again via <code>git
checkout</code>.</p>
<p>In order to create an <em>utag</em>, <em>umpf</em> needs three parameters, which can either be
provided by using a <em>useries</em> text file, or by calling <code>umpf init</code>:</p>
<ul class="simple">
<li><strong>base</strong>: The starting point on which the subsequent patch series is to be
built. The <em>umpf-base</em> is usually an upstream commit, such as a release tag
(e.g. for Linux: "v6.3").</li>
<li><strong>name</strong>: The actual name of the <em>umpf</em>, which later also becomes part of the
<em>utag</em>. It is recommended to derive it from the <em>base</em>, e.g.
"6.3/release-name".</li>
<li><strong>topic</strong>: The actual Git branches (topic branches) are each preceded by
<code># umpf-topic:</code>. They should themselves be built on the <em>base</em> commit to
avoid complications. It is therefore recommended to re-base branches with a
different starting point than the <em>umpf-base</em> first.</li>
</ul>
</div>
<div class="section" id="backport-integration">
<h3>Backport Integration</h3>
<p>Especially when working with upstream projects, it happens frequently that
bug fixes or functional enhancements provided by third parties have to be
integrated. The strength of <em>umpf</em> is that such changes can be maintained in a
separate branch and thus do not interfere with your own work on the project.</p>
<p>However, this branch integration by <em>umpf</em> only works reliably when the underlying
basis is comparable: Topic branches for <code>v5.15</code> and <code>v5.16</code>, for
example, can usually be processed together by <em>umpf</em> without any problems.
On the other hand, a further branch based e.g. on <code>v6.2</code>, will lead to
complications during <em>umpfing</em> due to the extensive differences in the
overall code.</p>
<p>In order to integrate bugfixes and other backports, it is thus recommended to
re-base those within their own topic branch on the <em>umpf-base</em> first.</p>
</div>
<div class="section" id="handling-merge-conflicts">
<h3>Handling Merge Conflicts</h3>
<div class="ptx-sidebar">
<div class="title">
Git Performance
<div class="corner"></div>
</div>
<div class="body">
<blockquote>
Extensive Git projects like the Linux kernel require a lot of computing
power in order to handle the huge amount of commits. However, the
performance can be increased by utilizing
<a href="https://git-scm.com/docs/git-commit-graph">git commit-graph</a>.</blockquote>
</div>
</div>
<p><em>umpf</em> cannot resolve merge conflicts on its own. Manual conflict resolution
during <em>umpfing</em> is possible and sometimes unavoidable, e.g. when working with
device trees, but it should be kept to a minimum.</p>
<p>However, the solutions to individual conflicts can be recorded by using
<a href="https://git-scm.com/book/en/v2/Git-Tools-Rerere">git-rerere</a>, which
automatically resolves known conflicts in case of recurrence. The branches to be
integrated should nevertheless have already been restructured and cleaned up
appropriately prior to an <em>umpf</em>.</p>
</div>
<div class="section" id="generating-a-linear-series">
<h3>Generating a Linear Series</h3>
<p>A <em>useries</em> created as described above can now be used to derive an <em>utag</em> and
thus unify all registered development branches into a common release tag:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/epic-project<span class="w"> </span>$<span class="w"> </span>cat<span class="w"> </span>./useries
<span class="c1"># umpf-base: v6.3</span>
<span class="c1"># umpf-name: 6.3/special-customer-release</span>
<span class="c1"># umpf-topic: v6.3/topic/bugfix-branch</span>
<span class="c1"># umpf-topic: v6.3/topic/more-fixes</span>
<span class="c1"># umpf-end</span>
</pre></div>
</div><div class="code-block">
<div class="highlight"><pre><span></span>~/epic-project<span class="w"> </span>$<span class="w"> </span>umpf<span class="w"> </span>tag<span class="w"> </span>./useries
</pre></div>
</div><p><em>umpf</em> will now stack all branches in the order they are mentioned in the
<em>useries</em> onto the specified <em>umpf-base</em>. An autosquash is also performed so
that fixup commits are resolved and do not end up in the final patchstack.</p>
<p>An example of how such an <em>utag</em> is represented in Git can be seen in the
figure below. This is a so-called <strong>qualified umpf</strong>, since it contains all the
necessary information for complete reconstruction:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/umpf_complete_compact.svg" itemprop="contentUrl">
<img alt="Complete umpf" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/umpf_complete_compact.svg" style="
width: 100%;
"/>
</a><figcaption itemprop="caption description" style="
"><p>A "qualified" <em>umpf</em> tag (<em>utag</em>) as seen by Git.</p>
</figcaption>
</figure>
</div><ul class="simple">
<li><strong>umpf-base</strong>: The base commit, commonly an upstream tag.</li>
<li><strong>Patch Stack</strong>: Commits of the topic branches stacked on the <em>umpf-base</em>. The
order of the branches is the same as they were passed to <em>umpf</em>.</li>
<li><strong>References</strong>: The state of the integrated branches at the time of the
<em>umpf</em>. This state is referenced in the <em>utag</em>'s commit via the branches'
HEADs and thus preserved. Consequently, even a subsequent change to a branch
has no effect if the <em>utag</em> is checked out again at a later time. The
referencing also causes the
<a href="https://git-scm.com/docs/git-gc">Git Garbage Collection</a> to leave the
supposedly orphaned branch states in the repository. This way, that very
constellation represented by the <em>utag</em> can be re-visited at any point in the
future.</li>
<li><strong>utag</strong>: A regular Git tag containing references to the underlying branches
and their latest commit IDs (HEADs) at the time of <em>umpfing</em>.</li>
<li><strong>Release Tag</strong>: Another regular Git tag. This has to be referenced for
generating a patch series. The commit may perform a modification to the
project code in order to include a timestamp.</li>
</ul>
<p>The final export of the patch stack can be done with the <code>umpf format-patch</code>
command. The export can be varied with parameters: An appended <code>-bb</code>
creates a patch series compatible to Yocto projects, <code>-p</code> specifies the
target path, and with <code>-u</code> the overwriting of an already
existing series can be initiated. Further hints are provided by <code>umpf
--help</code>.</p>
</div>
<div class="section" id="umerge">
<h3><em>umerge</em></h3>
<p>Instead of an <em>utag</em>, we can also build an <em>umerge</em> without an existing
<em>useries</em> step by step by calling <code>umpf merge</code> and manually inserting the
individual topic branches. To do this, first use to use <code>git
checkout</code> in order to switch to the desired <em>umpf-base</em> and then use
<code>umpf merge</code> to load the desired branches:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/epic-project<span class="w"> </span>$<span class="w"> </span>git<span class="w"> </span>checkout<span class="w"> </span>v6.3
~/epic-project<span class="w"> </span>$<span class="w"> </span>umpf<span class="w"> </span>merge<span class="w"> </span>v6.3/topic/bugfix-branch
umpf:<span class="w"> </span>merging<span class="w"> </span><span class="s1">'v6.3/topic/bugfix-branch'</span>...
<span class="o">[</span>...<span class="o">]</span>
~/epic-project<span class="w"> </span>$<span class="w"> </span>umpf<span class="w"> </span>merge<span class="w"> </span>v6.3/topic/more-fixes
umpf:<span class="w"> </span>merging<span class="w"> </span><span class="s1">'v6.3/topic/more-fixes'</span>...
<span class="o">[</span>...<span class="o">]</span>
</pre></div>
</div><p>This merging of multiple branches is similar to an <em>Octopus Merge</em>, which can be
used in Git for the simultaneous merging of more than two branches. Unlike Git,
but like with an <em>utag</em> however, the origin of the added commits is preserved by
an <code>umpf merge</code>: The underlying branches are referenced in their state at
the time of the <em>umerge</em> by an additional entry in the commit message of the
merge. This allows the origin of the individual commits - i.e. the original
names of their branches as well as their history - to be traced at any time.</p>
<p>A <em>umerge</em> can also be created directly from a <em>useries</em> file by calling
<code>umpf build ./useries</code></p>
<p>An <em>umerge</em> is particularly suitable for iterative development, in which all
topic branches of a project are required - e.g. for hardware-related kernel
development. Additional changes to the source code can then be simply put on top
of the <em>umerge</em> and be tested. Afterwards, by calling <code>umpf distribute</code>,
the newly created patches can be interactively assigned to one of the original
branches and will become integrated there by <em>umpf</em> directly.</p>
<p><code>umpf distribute</code> can also be used if the commits were not stacked on an
<em>umerge</em>, but on an <em>utag</em> instead.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/umerge.svg" itemprop="contentUrl">
<img alt="*umpf* Stacking Feature" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-29_introducing-umpf/umerge.svg" style="
width: 100%;
"/>
</a><figcaption itemprop="caption description" style="
"><p>Dependencies between the topic branches of a single <em>useries</em> can be
realized with <em>umerge</em>.</p>
</figcaption>
</figure>
</div><p>Furthermore, <em>umerges</em> can also be used directly in projects if there are
dependencies between the individual topic branches. Through the <em>Stacking
Feature</em> of <em>umpf</em>, the branch based on an <em>umerge</em> will be regularly integrated
into the linearized sequence of commits during subsequent processing. It should
be noted that the entry of the branch in question in the <em>useries</em> file must not
be inserted before the branches on which it depends; the order of naming is
decisive here.</p>
<p>Since the <em>umerge</em> preserves the state of the base branches the new branch relies
on, subsequent work on those bases will logically not be carried over to an
already existing <em>umerge</em>. This can lead to conflicts when a new <em>utag</em> shall
be generated with an older <em>umerge</em> included. In such a case, changes done to the
base branches must not affect direct dependencies of the dependent branch.</p>
</div>
</div>
<div class="section" id="why-we-are-umpfing">
<h2>Why We Are <em>umpfing</em></h2>
<p>At Pengutronix, we have specialized in Embedded Linux, and are thus mainly
working on the Linux kernel and associated projects. As part of our "mainline
first" strategy, we bring the functionalities developed in our projects into the
official upstream channels as early as possible. While this comes with many
long-term benefits - such as ensuring the high quality standard of our code
through community review - it also means that the resulting patches must not only
work when directly integrated into our BSPs, but must also meet the fluctuating
upstream situation. This requires a clean separation of the respective topic
branch from the rest of the project.</p>
<p>The impetus for the development of <em>umpf</em> ultimately came from our work on
driver development for embedded systems: Today, modern SoCs cover an incredibly
broad spectrum of implementations and functionalities; at the same time,
SoC components of identical design (so-called "intellectual property cores"
or "IP cores") are often used in a modular manner - even by different
manufacturers. Consequently, we have built up specific driver branches
that can be used across several of our integration projects without further
adaptation needed.</p>
<p>Working directly on the Linux kernel with its hundreds of branches and its
continuous upstream development is of course a prime example of how extensive a
project managed with Git can become. But even much smaller projects can benefit
from automation aids like <em>umpf</em> once more than one branch is used.</p>
<p>Although an extension like our <strong>Universal Magic Patch Functionator</strong> might at
some point have limitations when it comes to the actual possible complexity a Git
repository can get to, <em>umpf</em> has nevertheless successfully enabled us for years
to manage a whole range of different patch stacks for a large number of projects
and to keep the general versioning effort relatively low in this regard.</p>
<p>We have now decided to <a href="https://github.com/pengutronix/umpf/">make this tool available</a> under MIT license to the open source
community - and as always, we look forward to you participation!</p>
</div>
<p>Modern software development is commonly accompanied by a <a href="https://git-scm.com/">version control
system like Git</a> in order to have changes to the source
code being documented in a traceable manner. Furthermore, any version state should
be easily reproducible at any time. However, for work on complex projects such as
the BSP ("Board Support Package") of an embedded system with its multiple
development aspects, the simple stacking of the individual changes on top of
each other does not scale.</p>2023-08-29T00:00:00+01:00tag:www.pengutronix.de,2023-08-24:/2023-08-24-kernel-panic-board-on-fire-007-der-weg-zum-offenen-grafiktreiber.html[Podcast] Kernel Panic - Board on Fire ~~> #007: GPU und nu? Der Weg zum offenen Grafiktreiber2023-08-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-007-gpu-und-nu-der-weg-zum-offenen-grafiktreiber">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#007: GPU und nu? Der Weg zum offenen Grafiktreiber", "summary": "Lucas und Leonard reden \u00fcber Grafikkarten, -treiber und warum sich Leute die M\u00fche machen offene Treiber f\u00fcr sie zu schreiben", "publicationDate": "2023-08-24T10:10:10+00:00", "duration": "01:00:42", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-08-24-kernel-panic-board-on-fire-007-der-weg-zum-offenen-grafiktreiber.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/007_etnaviv.mp3", "size": 49998596, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/007_etnaviv.mp3", "size": 49998596, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge erzählt Lucas Stach uns wie er in die Entwicklung der offenen
Grafiktreiber Nouveau und Etnaviv hineingeraten ist und was so ein
Grafiktreiber eigentlich tut.
Wir reden darüber warum Grafikkarten überhaupt Software ausführen und wie
diese Software von der Anwendung bis in die Grafikkarte kommt.</p>
<p>Diese Folge ist die letzte in der Techweek vorproduzierte Folge, deshalb kann
es bei der Veröffentlichung der nächsten Folge zu Verspätungen kommen.
Wir haben aber schon Ideen für weitere Folgen, früher oder später geht es also
bestimmt weiter.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd><p class="first">Einleitende warme Worte. Was macht das Pengutronix Grafikteam so im
Allgemeinen und Lucas im Speziellen?</p>
<p class="last">Die Antwort ist natürlich wie immer „alles!”, nur mit etwas anderem Fokus
als andere Teams es machen.</p>
</dd>
<dt>03:30</dt>
<dd>Lucas erzählt wie er eigentlich dazu gekommen ist Grafiktreiber unter Linux
zu schreiben. Nämlich von der ganz anderen Seite her, indem er als Hobby
Spiele unter Windows programmiert hat und darüber immer weiter in die Materie
programmierbarer Shader-Einheiten eingestiegen ist.
Damals passierte diese Programmierung noch direkt im Assembler der jeweiligen
Grafikeinheit anstatt sie aus einer high level Sprache wie GLSL zu erzeugen.</dd>
<dt>06:20</dt>
<dd>Was ist überhaupt ein Shader und wie werden aus Befehlen für die
Grafikeinheit Pixel auf dem Bildschirm?</dd>
<dt>07:45</dt>
<dd>Der Weg von Spielen unter Windows zu Grafiktreibern unter Linux.
Das Nouveau-Projekt, das einen freien Treiber für NVIDIA-Grafikkarten
programmiert, war gerade so weit, dass es erste sichtbare Ergebnisse gab.
Die perfekte Gelegenheit also mal wieder in die low level Grafikentwicklung
einzusteigen und dort mit zu arbeiten.</dd>
<dt>10:45</dt>
<dd>Wie funktionieren Grafiktreiber? Es gibt eine Kernel-Komponente,
die aber mehr oder weniger nur Kommandos einer Komponente im Userspace
durchreicht.
Das ist sowohl bei offenen Treibern als auch bei den closed-source
Treibern von z.B. NVIDIA, so.
Das ermöglicht ein Reverse-Engineering des Verhalten des closed-source
Treibers indem man z.B. auf der Userspace-Seite des Treibers den Auftrag
gibt etwas bestimmtes zu zeichnen und dann auf der anderen Seite die an die
Grafikeinheit übergebenen Befehle anschaut.</dd>
<dt>14:00</dt>
<dd>Eine Tangente darüber wie sichergestellt wird, dass Programme, die die
Grafikeinheit nicht den Speicher anderer Programme auslesen und so z.B.
Informationen extrahieren.</dd>
<dt>15:15</dt>
<dd>Zurück zum eigentlichen Thema mit einer kurzen Zusammenfassung des Gehörten.</dd>
<dt>19:50</dt>
<dd>Warum brauchte es zur Entwicklung von Nouveau eigentlich Reverse-Engineering?
Gibt es denn keine Dokumentation für die Grafikeinheiten? Nein, gibt es nicht.</dd>
<dt>21:20</dt>
<dd>Der Übergang von Nouveau in der Freizeit programmieren zu beruflich Etnaviv
mitentwickeln.</dd>
<dt>23:00</dt>
<dd>Mit dem Aufkommen von Touch-Bedienung wurde auch im Embedded-Bereich Grafik
relevant. Deshalb wurde in den i.MX6 von Freescale (heute NXP) eine vergleichbar
performante Grafikeinheit eingebaut.
Diese ließ sich aber nur per closed-source Treiber ansprechen.
Für Industriekunden mit langen Produktlaufzeiten ist so ein closed-source
Treiber ein großes Risiko, weil Updates jederzeit eingestellt werden können.
Deshalb gab es damals der Auftrag den freien Etnaviv Treiber für diese Hardware
in einen nutzbaren Zustand zu bringen.</dd>
<dt>33:45</dt>
<dd>Eine kleine Erläuterung was das Mesa-Projekt tut. Es stellt eine gemeinsame
Basis für Grafiktreiber da, damit nur noch die wirklich hardwarespezifischen
Teile der Treiber jeweils neu implementiert werden müssen.
Gemeinsame Teile sind z.B. die Bereitstellung der OpenGL und Vulkan API und
State Machines oder das Kompilieren und Optimieren von Shader-Programmen in
eine <em>Intermediate Representation</em>.
Die tatsächliche Umsetzung in Befehle für die Grafikeinheit ist dann
hardwarespezifisch.</dd>
<dt>37:00</dt>
<dd><p class="first">Wie sieht der Maschinencode, der auf einer Grafikeinheit ausgeführt wird,
eigentlich aus? Wie muss man sich die parallele Ausführung auf vielen
Shader Cores vorstellen?</p>
<p class="last">Shader-Programme sind aus Sicht eines Pixels geschrieben und dadurch massiv
parallel ausführbar. Aus Sicht der Anwendung ist die Art <em>wie</em> schlussendlich
parallelisiert wird ziemlich egal.
Tatsächlich kann es in vielen Fällen sogar dem Treiber egal sein, da die GPU
selbst entscheidet was wann wie auf welchem Core ausgeführt wird.</p>
</dd>
<dt>40:00</dt>
<dd>Kleiner Umweg über PCI und PCI-Express. Über PCI-Express angebundene
Grafikkarten können per DMA selbstständig Daten aus dem Arbeitsspeicher der
CPU anfragen und in ihren eigenen Speicher übertragen.</dd>
<dt>48:00</dt>
<dd>Ein bisschen Lagerfeuergeschichte. Auf einer bestimmten Hardware war die
Grafikeinheit sehr instabil und es wurden immer mehr Workarounds in die
Treiber eingebaut. Schlussendlich stellte sich heraus, dass ein Teil der
GPU aus Versehen übertaktet wurde.</dd>
<dt>56:30</dt>
<dd>Neuerdings finden auch in Embedded-SoCs Beschleunigereinheiten für neuronale
Netze Einzug. In manchen Fällen sind das einfach Erweiterungen für bestehende
Grafikeinheiten, an die Einheiten für größere Matrixmultiplikationen angebaut
werden.</dd>
<dt>59:45</dt>
<dd>Abschließende Worte</dd>
</dl>
</div><p>In dieser Folge erzählt Lucas Stach uns wie er in die Entwicklung der offenen
Grafiktreiber Nouveau und Etnaviv hineingeraten ist und was so ein
Grafiktreiber eigentlich tut.
Wir reden darüber warum Grafikkarten überhaupt Software ausführen und wie
diese Software von der Anwendung bis in die Grafikkarte kommt.</p>2023-08-24T10:10:10+01:00tag:www.pengutronix.de,2023-08-17:/2023-08-17-candlelight-fd-open-hardware-usb-to-can-fd-interface.htmlcandleLight FD - Open Hardware USB-to-CAN-FD interface2023-08-17T17:01:02+01:00Chris Fiege<div class="section" id="candlelight-fd-open-hardware-usb-to-can-fd-interface">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2010x2010" href="https://www.pengutronix.de/media/blog/2023/2023-08-18_candlelight-fd-open-hardware-usb-to-can-fd-interface/candlelightfd-dsub.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-18_candlelight-fd-open-hardware-usb-to-can-fd-interface/candlelightfd-dsub.thumb.65ceac43a61367f2f9f85bc534d030f3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"></figcaption>
</figure>
</div><p>This week <a class="reference external" href="https://linux-automation.com">Linux Automation</a> has released a CAN-FD version of the
low-cost USB-to-CAN interface <a class="reference external" href="https://www.linux-automation.com/en/products/candlelight.html">candleLight</a>:
the <a class="reference external" href="https://linux-automation.com/en/products/candlelight-fd.html">candleLight FD</a>.
And as the candleLight the candleLight FD is Open Hardware.
Check the KiCad project <a class="reference external" href="https://github.com/linux-automation/candleLightFD">on Github</a>.</p>
<p>With CAN-FD the effective data rate and maximum packet length on the bus can be increased.
CAN only supports a data rate of up to 1MBit/s for the frame's header and data part.
With CAN-FD the data part of the frame can be send with a higher data rate.
While the maximum duration of the frame stays the same, more data is transmitted.</p>
<p>Don't know what to do with a candleLight FD?
Marc has written a
<a href="https://www.pengutronix.de/en/blog/2022-02-17-first-steps-using-the-candlelight.html">blog post about candump, cansend and similar tools</a>.
And Leonard made a <a href="https://www.youtube.com/watch?v=JqTBzDN7VOk">video</a> where he demonstrates how to
reverse-engineer a CAN-based protocol using the candleLight and Wireshark.</p>
<div class="section" id="what-s-new">
<h3>What's new</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1695x1695" href="https://www.pengutronix.de/media/blog/2023/2023-08-18_candlelight-fd-open-hardware-usb-to-can-fd-interface/candlelightfd.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-18_candlelight-fd-open-hardware-usb-to-can-fd-interface/candlelightfd.thumb.73a691e3dac21c5904fe7cf7d63a0cf2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"></figcaption>
</figure>
</div><p>To be honest: compared to <a class="reference external" href="https://github.com/HubertD/candleLight">HubertD's candleLight</a> not that much has
changed.
The candleLight already checks all boxes.
So Linux Automation only made slight changes.
Here is what's actually new:</p>
<ul class="simple">
<li>It now uses a ST STM32G0B1CBT CPU.
This is an entry-level microcontroller with USB and CAN-FD.</li>
<li>The Micro-USB socket has been swapped for an USB-C socket.</li>
<li>The candleLight FD has two pins which allow connecting the +12V pin on the D-SUB9 connector.
This way, devices on the CAN-Bus can be supplied without the need for a separate injector - if soldering
cables to your CAN interface is OK for you.</li>
</ul>
<p>Interestingly, the CAN transceiver on the candleLight is already CAN-FD capable.
Thus in the candleLightFD we still use the NXP TJA1051T3.</p>
</div>
<div class="section" id="software">
<h3>Software</h3>
<p>The <cite>gs_usb</cite> driver <a class="reference external" href="https://lore.kernel.org/all/20220309124132.291861-16-mkl@pengutronix.de/">got support for CAN-FD</a>
back in 5.18.
So on any Linux system with a somewhat recent kernel, the CAN-FD on the candleLight FD will work out-of-the-box.
After connecting your candleLight FD via USB a new device will appear:</p>
<pre class="code literal-block">
[72781.472163] usb 5-1: new full-speed USB device number 5 using xhci_hcd
[72781.645516] usb 5-1: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[72781.645522] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[72781.645524] usb 5-1: Product: candleLightFD gs_usb
[72781.645526] usb 5-1: Manufacturer: candleLightFD
[72781.645527] usb 5-1: SerialNumber: 003400205841500B20373233
[72781.656517] gs_usb 5-1:1.0: Configuring for 1 interfaces
</pre>
<p>Additionally a <cite>can0</cite> network device will appear.
This can be configured using <cite>ip</cite>:</p>
<pre class="code shell literal-block">
$<span class="whitespace"> </span>ip<span class="whitespace"> </span>link<span class="whitespace"> </span><span class="name builtin">set</span><span class="whitespace"> </span>can0<span class="whitespace"> </span>up<span class="whitespace"> </span><span class="name builtin">type</span><span class="whitespace"> </span>can<span class="whitespace"> </span>bitrate<span class="whitespace"> </span><span class="literal number">200000</span><span class="whitespace"> </span>dbitrate<span class="whitespace"> </span><span class="literal number">2000000</span><span class="whitespace"> </span>fd<span class="whitespace"> </span>on
</pre>
<p>This will enable CAN-FD mode, set a data part speed of 2MBit/s and bring the device up.
Other parameters like <em>sampling point</em>, <em>sjw</em>, <em>dswj</em> and so forth will be set to (hopefully) sane defaults.
(Note: When combining CAN interfaces with different base clocks or CAN cores these values sometimes need additional
tweaking.)</p>
<p>Alternatively, with <em>systemd</em> we can use <em>systemd-networkd</em> to bring up the CAN interface after it appeared.
For example:</p>
<pre class="code shell literal-block">
$<span class="whitespace"> </span>cat<span class="whitespace"> </span>/etc/systemd/network/90-candlelight.network<span class="whitespace">
</span><span class="operator">[</span>Match<span class="operator">]</span><span class="whitespace">
</span><span class="name variable">Property</span><span class="operator">=</span><span class="name variable">ID_VENDOR_ID</span><span class="operator">=</span>1d50<span class="whitespace"> </span><span class="name variable">ID_MODEL_ID</span><span class="operator">=</span>606f<span class="whitespace">
</span><span class="operator">[</span>CAN<span class="operator">]</span><span class="whitespace">
</span><span class="name variable">BitRate</span><span class="operator">=</span><span class="literal number">200000</span><span class="whitespace">
</span><span class="name variable">DataBitRate</span><span class="operator">=</span><span class="literal number">2000000</span><span class="whitespace">
</span><span class="name variable">FDMode</span><span class="operator">=</span>True<span class="whitespace">
</span><span class="name variable">RestartSec</span><span class="operator">=</span>100ms
</pre>
<p>Take a look at the
<a class="reference external" href="https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BCAN%5D%20Section%20Options">systemd network [CAN] section documentation</a>
for more details on what can be configured here.
For classical CAN we already took a deep dive into <em>systemd-networkd</em> and CAN in
<a href="https://www.pengutronix.de/en/blog/2022-02-04-initializing-can-interfaces-with-systemd-networkd.html">this blog post</a>.</p>
</div>
</div><p>This week <a class="reference external" href="https://linux-automation.com">Linux Automation</a> has released a CAN-FD version of the
low-cost USB-to-CAN interface <a class="reference external" href="https://www.linux-automation.com/en/products/candlelight.html">candleLight</a>:
the <a class="reference external" href="https://linux-automation.com/en/products/candlelight-fd.html">candleLight FD</a>.
And as the candleLight the candleLight FD is Open Hardware.
Check the KiCad project <a class="reference external" href="https://github.com/linux-automation/candleLightFD">on Github</a>.</p>2023-08-17T17:01:02+01:00tag:www.pengutronix.de,2023-08-07:/2023-08-07-lxa-t1l-beagle-play.htmlLXA USB-T1L ❤️ Beagle Play: Exploring Single Wire Ethernet2023-08-07T15:45:10+01:00Chris Fiege<div class="section" id="lxa-usb-t1l-beagle-play-exploring-single-wire-ethernet">
<p>It seems everybody is talking about Single Pair Ethernet (SPE) these days.
So we want to follow the trend and do the same :-)
SPE is a class of Ethernet transmission standards that uses just a single pair of twisted pair cable for data
transmission.
There are multiple SPE variants spanning maximum data rates from a hand full MBit/s
to multiple GBit/s and cable lengths from a hand full of meters to kilometers.
The most interesting ones from our embedded-centric point of view are 10Base-T1L (point-to-point, up to 1 km),
10Base-T1S (multidrop, approx. 10 m) and 100Base-T1 (point-to-point, 15 m).
The new <a class="reference external" href="https://beagleboard.org/play">Beagle Play</a> comes with a 10Base-T1L PHY.
This makes it a great peer to experiment with our
<a class="reference external" href="https://www.linux-automation.com/en/products/usb-t1l.html">Linux Automation USB-T1L</a>.
In this post we will explore the possibilities of 10Base-T1L on a recent Linux system.</p>
<p>The <a class="reference external" href="https://www.ieee802.org/3/cg/public/adhoc/10BASE-T1L%20Clause%20164%20Rev.%20D.pdf">10Base-T1L standard</a>
defines a <em>point-to-point</em> connection between two stations using a shielded twisted pair cable up to 1000 m in length.
The standard defines the <em>PHY</em>-layer, so MAC- and all higher layers are shared with <em>normal</em> Ethernet.
10Base-T1L is designed with the industrial automation market in mind and is intended to replace 4..20 mA analog interfaces as well
as low-speed field-busses.
Currently PHYs are available from <a class="reference external" href="https://www.analog.com/en/products/adin1110.html">Analog Devices</a> and
<a class="reference external" href="https://www.ti.com/product/DP83TD510E">Texas Instruments</a>.</p>
<div class="section" id="linux-support-for-10base-t1l">
<h3>Linux Support for 10Base-T1L</h3>
<p><a class="reference external" href="https://lore.kernel.org/lkml/20221205132102.2941732-1-o.rempel@pengutronix.de/">Oleksij Rempel contributed</a>
support for the
<a class="reference external" href="https://www.linux-automation.com/en/products/usb-t1l.html">Linux Automation USB-T1L</a> to Linux back in 6.1.
Using this or a newer version allows us to <em>plug and play</em> the device like any other USB-to-Ethernet dongle.
Linux has full access to the registers of the PHY,
so <cite>ethtool -S <t1l-interface></cite> will show some additional 10Base-T1L statistics provided by the PHY.</p>
<p>The Beagle Play comes with Debian Bullseye and an (ancient) Linux 5.10 kernel pre-installed but is batteries included
to use the 10Base-T1L PHY on the board.</p>
<p>Further details like <em>master</em> and <em>slave</em> on a 10Base-T1L are of no concern for this setup:
The defaults inside the PHYs are chosen in way that they are plug-and-play.</p>
</div>
<div class="section" id="testing-environment">
<h3>Testing Environment</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1112" href="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/basic_setup.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/basic_setup.thumb.8f5c7b6921233484e2e8b159a9a89b8f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>The basic setup on my desk.</p>
</figcaption>
</figure>
</div>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1605" href="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/tiny_cable.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/tiny_cable.thumb.4a3d4d4d18f23a0a0f9efc4caef1e0e5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>The short black cable between the Beagle Play and the USB-T1L serves as the "known good" link.</p>
</figcaption>
</figure>
</div><p>The basic setup for this blog post consists of the following parts:</p>
<ul class="simple">
<li>Beagle Play as 10Base-T1L remote station</li>
<li>A serial console connection to control the Beagle Play</li>
<li>LXA USB-T1L as 10Base-T1L Ethernet dongle</li>
<li>LXA Test Automation Controller (LXA TAC) as host for the USB-T1L and to terminate the serial console
to the Beagle Play</li>
<li>A tiny cable for the 10Base-T1L link (We will use a longer cable later!)</li>
</ul>
<p>The cable used for 10Base-T1L in this setup is actually not complying to the specification:
Instead of a high-quality shielded twisted pair cable (for example a <em>FieldBus Type A</em> cable)
we only use an unshielded not-twisted telephone-style cable.
But: the cable is so short that probably even
<a class="reference external" href="https://www.revk.uk/2017/12/its-official-adsl-works-over-wet-string.html">two wet strings</a> would do.</p>
<p>The Linux Automation Test Automation Controller
(<a class="reference external" href="https://www.linux-automation.com/en/products/lxa-tac.html">LXA TAC</a>) is used for two jobs in this setup.</p>
<p>First: Provide remote access to the serial console on the Beagle Play using
<a class="reference external" href="https://labgrid.readthedocs.io/en/latest/">labgrid</a>.</p>
<p>Second: Provide a Linux system with a recent (6.4) kernel for easy use of the USB-T1L Ethernet dongle.
On the LXA TAC <em>network manager</em> brings up all newly connected network interfaces.
For the sake of simplicity the 10Base-T1L interface (<cite>eth0</cite>) is bridged onto the upstream Ethernet connection.
This way the Beagle Play can access all the network services the TAC has access to,
like the DHCP server serving our <em>lab network</em>.</p>
<p>On the Beagle Play no services takes care of configuring the 10Base-T1L network interface, so we'll need to add
a <em>systemd network</em>-file to configure the interface on boot:</p>
<pre class="code literal-block">
root@BeaglePlay:~# cat /etc/systemd/network/eth1.network
[Match]
Name=eth1
Type=ether
[Link]
RequiredForOnline=yes
[Network]
DHCP=ipv4
</pre>
</div>
<div class="section" id="plugging-it-together">
<h3>Plugging it together</h3>
<p>After all preparations have been done we can simply plug the 10Base-T1L link together and we are ready to go!
The following snippet shows the state of the 10Base-T1L phy-level link:
We have a full duplex 10 MBit/s link using 10baseT1L.
The signal quality indicator (<cite>SQI</cite>) is only reported on the USB-T1L with a recent kernel.
The SQI reports 7 out of 7 - as expected with such a short cable.</p>
<pre class="code shell literal-block">
root@lxatac-00013:~<span class="whitespace"> </span>ethtool<span class="whitespace"> </span>eth0<span class="whitespace">
</span>Settings<span class="whitespace"> </span><span class="keyword">for</span><span class="whitespace"> </span>eth0:<span class="whitespace">
</span>Supported<span class="whitespace"> </span>ports:<span class="whitespace"> </span><span class="operator">[</span><span class="whitespace"> </span><span class="operator">]</span><span class="whitespace">
</span>Supported<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Supported<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace"> </span>Receive-only<span class="whitespace">
</span>Supports<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Supported<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace"> </span>Receive-only<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>No<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Speed:<span class="whitespace"> </span>10Mb/s<span class="whitespace">
</span>Duplex:<span class="whitespace"> </span>Full<span class="whitespace">
</span>Auto-negotiation:<span class="whitespace"> </span>on<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>cfg:<span class="whitespace"> </span>preferred<span class="whitespace"> </span>slave<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>status:<span class="whitespace"> </span>unknown<span class="whitespace">
</span>Port:<span class="whitespace"> </span>Twisted<span class="whitespace"> </span>Pair<span class="whitespace">
</span>PHYAD:<span class="whitespace"> </span><span class="literal number">1</span><span class="whitespace">
</span>Transceiver:<span class="whitespace"> </span>external<span class="whitespace">
</span>MDI-X:<span class="whitespace"> </span>Unknown<span class="whitespace">
</span>Supports<span class="whitespace"> </span>Wake-on:<span class="whitespace"> </span>pg<span class="whitespace">
</span>Wake-on:<span class="whitespace"> </span>p<span class="whitespace">
</span>Current<span class="whitespace"> </span>message<span class="whitespace"> </span>level:<span class="whitespace"> </span>0x00000007<span class="whitespace"> </span><span class="operator">(</span><span class="literal number">7</span><span class="operator">)</span><span class="whitespace">
</span>drv<span class="whitespace"> </span>probe<span class="whitespace"> </span>link<span class="whitespace">
</span>Link<span class="whitespace"> </span>detected:<span class="whitespace"> </span>yes<span class="whitespace">
</span>SQI:<span class="whitespace"> </span><span class="literal number">7</span>/7
</pre>
<p>On the Beagle Play <cite>ethtool</cite> does not report the <cite>SQI</cite>.
But otherwise all relevant metrics are reported:</p>
<pre class="code shell literal-block">
root@BeaglePlay:~#<span class="whitespace"> </span>ethtool<span class="whitespace"> </span>eth1<span class="whitespace">
</span>Settings<span class="whitespace"> </span><span class="keyword">for</span><span class="whitespace"> </span>eth1:<span class="whitespace">
</span>Supported<span class="whitespace"> </span>ports:<span class="whitespace"> </span><span class="operator">[</span><span class="whitespace"> </span><span class="operator">]</span><span class="whitespace">
</span>Supported<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Supported<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace">
</span>Supports<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Supported<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace"> </span>Receive-only<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Speed:<span class="whitespace"> </span>10Mb/s<span class="whitespace">
</span>Duplex:<span class="whitespace"> </span>Full<span class="whitespace">
</span>Auto-negotiation:<span class="whitespace"> </span>on<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>cfg:<span class="whitespace"> </span>preferred<span class="whitespace"> </span>slave<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>status:<span class="whitespace"> </span>unknown<span class="whitespace">
</span>Port:<span class="whitespace"> </span>Twisted<span class="whitespace"> </span>Pair<span class="whitespace">
</span>PHYAD:<span class="whitespace"> </span><span class="literal number">1</span><span class="whitespace">
</span>Transceiver:<span class="whitespace"> </span>external<span class="whitespace">
</span>MDI-X:<span class="whitespace"> </span>Unknown<span class="whitespace">
</span>Supports<span class="whitespace"> </span>Wake-on:<span class="whitespace"> </span>d<span class="whitespace">
</span>Wake-on:<span class="whitespace"> </span>d<span class="whitespace">
</span>Current<span class="whitespace"> </span>message<span class="whitespace"> </span>level:<span class="whitespace"> </span>0x000020f7<span class="whitespace"> </span><span class="operator">(</span><span class="literal number">8439</span><span class="operator">)</span><span class="whitespace">
</span>drv<span class="whitespace"> </span>probe<span class="whitespace"> </span>link<span class="whitespace"> </span>ifdown<span class="whitespace"> </span>ifup<span class="whitespace"> </span>rx_err<span class="whitespace"> </span>tx_err<span class="whitespace"> </span>hw<span class="whitespace">
</span>Link<span class="whitespace"> </span>detected:<span class="whitespace"> </span>yes
</pre>
<p>And does the link work? Let's try to ping our <em>lab network</em> default gateway from the Beagle Play.
If this works it would mean Ethernet frames are transferred from the Beagle Play to the LXA TAC via a 10Base-T1L link
and from there over a gigabit link to our infrastructure.</p>
<asciinema-player poster="npt:0:01" preload="True" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/ip_config.cast">
</asciinema-player><p>Nice! What about bandwidth? We'll test throughput from the Beagle Play to the LXA TAC using <cite>iperf3</cite>.
So in this test only the 10Base-T1L link is tested.</p>
<asciinema-player poster="npt:0:01" preload="True" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/iperf.cast">
</asciinema-player><p>As expected, we achieve around 9.0 to 9.5 MBit/s full-duplex throughput in this setup.</p>
</div>
<div class="section" id="using-a-long-cable">
<h3>Using a long cable</h3>
<p>The next logical step is to increase the cable length and find out how far we can push 10Base-T1L.
Since we dont' have a compliant cable available in our lab we are going to improvise …
Let's use CAT6 / CAT7 S/FTP Ethernet cable instead.
A S/FTP cable contains four pairs of individually shielded twisted pair cables.
So 1m of S/FTP cable actually gives us 4 m of cable pairs to use in our experiment!</p>
<p>To connect the individual pairs two
<a class="reference external" href="https://www.linux-automation.com/en/products/lxa-tools.html">Linux Automation RJ45-Matrix</a> boards are used as
breakouts for the RJ45-connectors.
The jumper cables are connected in such way that they actually use the twisted pairs inside the S/FTP cable.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_1.thumb.1f33d154dd72013ec188ef41aa6e7b48.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>On the near end the pair in (1,2) is connected to the USB-T1L, the pair in (3,6) is looped back to (4,5),
the pair in (7,8) goes to the Begale Play.
Ethernet TIA-568 pin assignments are fun!
(The second side of the RJ45-Matrix boards is not used in this setup.)</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_2.thumb.ef0beb5ff001a914d389408f9b96c8cd.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>On the far end the pair in (1,2) is looped back to (3,6) and the pair in (4,5) is looped back to (7,8).
This way all four twisted pairs in the cable are used.
(The second side of the RJ45-Matrix boards is not used in this setup.)</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x2425" href="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/rj45_3.thumb.13b7271e34448d022d3e260d4ad8133b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The full setup with 5x 20 m of cable and receptacle-receptacle connectors between the cables.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>By daisy-chaining all 20 m cables from our lab a total cable length of 400 m is achieved.
With this less-than-ideal cable the SQI drops to 5/7:</p>
<pre class="code shell literal-block">
root@lxatac-00013:~<span class="whitespace"> </span>ethtool<span class="whitespace"> </span>eth0<span class="whitespace">
</span>Settings<span class="whitespace"> </span><span class="keyword">for</span><span class="whitespace"> </span>eth0:<span class="whitespace">
</span>Supported<span class="whitespace"> </span>ports:<span class="whitespace"> </span><span class="operator">[</span><span class="whitespace"> </span><span class="operator">]</span><span class="whitespace">
</span>Supported<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Supported<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace"> </span>Receive-only<span class="whitespace">
</span>Supports<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Supported<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>Symmetric<span class="whitespace"> </span>Receive-only<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>link<span class="whitespace"> </span>modes:<span class="whitespace"> </span>10baseT1L/Full<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>pause<span class="whitespace"> </span>frame<span class="whitespace"> </span>use:<span class="whitespace"> </span>No<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>auto-negotiation:<span class="whitespace"> </span>Yes<span class="whitespace">
</span>Link<span class="whitespace"> </span>partner<span class="whitespace"> </span>advertised<span class="whitespace"> </span>FEC<span class="whitespace"> </span>modes:<span class="whitespace"> </span>Not<span class="whitespace"> </span>reported<span class="whitespace">
</span>Speed:<span class="whitespace"> </span>10Mb/s<span class="whitespace">
</span>Duplex:<span class="whitespace"> </span>Full<span class="whitespace">
</span>Auto-negotiation:<span class="whitespace"> </span>on<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>cfg:<span class="whitespace"> </span>preferred<span class="whitespace"> </span>slave<span class="whitespace">
</span>master-slave<span class="whitespace"> </span>status:<span class="whitespace"> </span>unknown<span class="whitespace">
</span>Port:<span class="whitespace"> </span>Twisted<span class="whitespace"> </span>Pair<span class="whitespace">
</span>PHYAD:<span class="whitespace"> </span><span class="literal number">1</span><span class="whitespace">
</span>Transceiver:<span class="whitespace"> </span>external<span class="whitespace">
</span>MDI-X:<span class="whitespace"> </span>Unknown<span class="whitespace">
</span>Supports<span class="whitespace"> </span>Wake-on:<span class="whitespace"> </span>pg<span class="whitespace">
</span>Wake-on:<span class="whitespace"> </span>p<span class="whitespace">
</span>Current<span class="whitespace"> </span>message<span class="whitespace"> </span>level:<span class="whitespace"> </span>0x00000007<span class="whitespace"> </span><span class="operator">(</span><span class="literal number">7</span><span class="operator">)</span><span class="whitespace">
</span>drv<span class="whitespace"> </span>probe<span class="whitespace"> </span>link<span class="whitespace">
</span>Link<span class="whitespace"> </span>detected:<span class="whitespace"> </span>yes<span class="whitespace">
</span>SQI:<span class="whitespace"> </span><span class="literal number">5</span>/7
</pre>
<p>We can now repeat the full-duplex throughput measurement using <cite>iperf3</cite>:</p>
<asciinema-player poster="npt:0:01" preload="True" src="https://www.pengutronix.de/media/blog/2023/2023-08-07_lxa-t1l-beagle-play/iperf_rj45.cast">
</asciinema-player><p>As expected the throughput stays around 9.5 MBit/s.</p>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
<p>While the hardware-ecosystem around Single Pair Ethernet with 10Base-T1L is still evolving,
the software side (at least for basic features) under Linux is already quite usable.</p>
<p>There is still some unused potential however, as the 10Base-T1L standard defines more complex functions
like advanced link diagnostics that require the assistance of the remote station.
Such feature could come in handy when debugging issues in, for example, an industrial setting.</p>
<p>Are you interested in using 10Base-T1l in your Linux based product?
Then feel free to <a href="https://www.pengutronix.de/en/company/about.html">contact us</a> for commercial support!</p>
</div>
</div><p>It seems everybody is talking about Single Pair Ethernet (SPE) these days.
So we want to follow the trend and do the same :-)
SPE is a class of Ethernet transmission standards that uses just a single pair of twisted pair cable for data
transmission.
There are multiple SPE variants spanning maximum data rates from a hand full MBit/s
to multiple GBit/s and cable lengths from a hand full of meters to kilometers.
The most interesting ones from our embedded-centric point of view are 10Base-T1L (point-to-point, up to 1 km),
10Base-T1S (multidrop, approx. 10 m) and 100Base-T1 (point-to-point, 15 m).
The new <a class="reference external" href="https://beagleboard.org/play">Beagle Play</a> comes with a 10Base-T1L PHY.
This makes it a great peer to experiment with our
<a class="reference external" href="https://www.linux-automation.com/en/products/usb-t1l.html">Linux Automation USB-T1L</a>.
In this post we will explore the possibilities of 10Base-T1L on a recent Linux system.</p>2023-08-07T15:45:10+01:00tag:www.pengutronix.de,2023-08-04:/2023-08-04-froscon-2023.htmlFrOSCon 20232023-08-04T10:03:07+01:00Marie Mann<div class="section" id="froscon-2023">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1412x380" href="https://www.pengutronix.de/media/blog/2023/2023-08-04_froscon-2023/FrOSCon-Logo-rgb-dark-blue-endorse-below.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-08-04_froscon-2023/FrOSCon-Logo-rgb-dark-blue-endorse-below.thumb.1a3a73e99518a6098ef4a03f31f9fa21.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In a few hours, the 18th <a class="reference external" href="https://froscon.org/">FrOSCon</a>
will begin at the Bonn-Rhein-Sieg University of Applied Sciences.
Pengutronix will be there again with a small team.
At one of the partner booths we will show some of our activities in the open
source community.
We will bring our <a class="reference external" href="https://www.youtube.com/watch?v=FCdkBli2kJ4">labgrid demonstrator</a>
and the <a class="reference external" href="https://video.fosdem.org/2023/UD2.120%20(Chavanne)/fpga_bitstreams.webm">FPGA demo</a>.</p>
<p>We are looking forward to seeing familiar and new faces and to many interesting
conversations!</p>
</div>
<p>In a few hours, the 18th <a class="reference external" href="https://froscon.org/">FrOSCon</a>
will begin at the Bonn-Rhein-Sieg University of Applied Sciences.
Pengutronix will be there again with a small team.
At one of the partner booths we will show some of our activities in the open
source community.
We will bring our <a class="reference external" href="https://www.youtube.com/watch?v=FCdkBli2kJ4">labgrid demonstrator</a>
and the <a class="reference external" href="https://video.fosdem.org/2023/UD2.120%20(Chavanne)/fpga_bitstreams.webm">FPGA demo</a>.</p>2023-08-04T10:03:07+01:00tag:www.pengutronix.de,2023-07-24:/2023-07-24-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten.html[Podcast] Kernel Panic - Board on Fire ~~> #006: Der Browser im Fahrkartenautomaten - Webtechnologie trifft Embedded-GUIs2023-07-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten-webtechnologie-trifft-embedded-guis">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#006: Der Browser im Fahrkartenautomaten - Webtechnologie trifft Embedded-GUIs", "summary": "Basti und Leonard reden in dieser Folge \u00fcber Webbrowser auf Embedded-Ger\u00e4ten und ihre Vor- und Nachteile.", "publicationDate": "2023-07-24T10:10:10+00:00", "duration": "00:53:48", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-07-24-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/006_der_browser_im_fahrkartenautomaten.mp3", "size": 47815844, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/006_der_browser_im_fahrkartenautomaten.mp3", "size": 47815844, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge erzählt Bastian Krause uns warum man öfter als man vielleicht
denkt Webbrowser auf Embeddedgeräten vorfindet und was die verwendeten Browser
von normalen Desktopbrowsern unterscheidet.
Außerdem reden wir über Browserengines im Allgemeinen und auch ein bisschen
über automatisiertes Testing von Webapplikationen.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Einleitende warme Worte. Bastian erzählt was er im Integrationsteam so macht
und wie das Zusammenstellen von Board Support Packages (BSPs) und Images für
Embeddedgeräte so funktioniert.</dd>
<dt>09:00</dt>
<dd><p class="first">Übergang zum Thema Browser auf Embeddedgeräten und warum sie als Alternative
zu klassischen GUI-Toolkits wie z.B. QT verwendet werden.</p>
<p class="last">Ressourcenverbrauch ist kein so großes Problem mehr wie es einmal war und
für Webentwicklung sind EntwicklerInnen leichter zu bekommen als für native
Anwendungen mit QT.</p>
</dd>
<dt>12:30</dt>
<dd><p class="first">Wenn Browser zum Anzeigen von Anwendungen auf Embeddedgeräten so verbreitet
sind, warum sehe ich dann nirgendwo browsertypische Bedienelemente auf
Automaten?</p>
<p>Weil der Browser in einem abgespecktem Kiosk-Modus läuft, in dem keine
Bedienelemente angezeigt werden.</p>
<p class="last">In manchen Fällen, wie z.B. Smart-TVs, kommen aber auch normale Browser mit
Bedienelementen zum Einsatz.</p>
</dd>
<dt>15:00</dt>
<dd><p class="first">Das Thema Browserengines.</p>
<p class="last">Engines sind so komplex geworden, dass z.B. Microsoft und Opera die
Entwicklung ihrer eigenen Engine aufgegeben haben.
Stattdessen gibt es jetzt noch die großen Engines WebKit (Safari), Blink
(Chrome, Chromium, Edge, Opera …) (ein WebKit Fork) und Gecko (Firefox).</p>
</dd>
<dt>26:00</dt>
<dd><p class="first">Als Teil des WebKit-Projekts gibt es verschiedene Ports - Anpassungen der
Engine und des Drumherums auf verschiedene Hardwareplatformen.
Darunter ist z.B. eine für die Sony Playstation aber auch eine mit dem
Namen "Web Platform for Embedded" (WPE).</p>
<p class="last">WPE is auf typische Embedded-Usecases optimiert, also niedriger
Ressourcenverbrauch, größtmögliches Auslagern von Berechnungen für z.B.
Videodekodierung an Hardwareeinheiten, auf Embedded-Geräten vertretene
Input-/Output-Möglichkeiten ….</p>
</dd>
<dt>38:30</dt>
<dd>Schwenk zu einem anderen Thema - automatisiertes Testing von Webanwendungen
per Selenium und WebDriver.</dd>
<dt>44:00</dt>
<dd>Wie funktionieren Code-Contributions bei einem Riesenprojekt wie WebKit?
Das kommt darauf an welchen Teil des Codes die Änderungen betreffen.
Für die Ports z.B. gibt es verschiedene Maintainer in verschiedenen Firmen.</dd>
<dt>52:30</dt>
<dd>Abschluss und Verabschiedung.</dd>
</dl>
</div><p>In dieser Folge erzählt Bastian Krause uns warum man öfter als man vielleicht
denkt Webbrowser auf Embeddedgeräten vorfindet und was die verwendeten Browser
von normalen Desktopbrowsern unterscheidet.
Außerdem reden wir über Browserengines im Allgemeinen und auch ein bisschen
über automatisiertes Testing von Webapplikationen.</p>2023-07-24T10:10:10+01:00tag:www.pengutronix.de,2023-07-17:/2023-07-17-embedded-linux-conference-europe-2023-our-recommendations.htmlEmbedded Linux Conference Europe 2023: Our Recommendations2023-07-17T08:00:00+01:00Chris FiegeRoland HieberJohannes ZinkMichael Tretter<div class="section" id="embedded-linux-conference-europe-2023-our-recommendations">
<div class="ptx-sidebar">
<div class="title">
Our contributions
<div class="corner"></div>
</div>
<div class="body">
<p>You can find our contributions in this <a href="https://www.pengutronix.de/en/blog/2023-06-27-elce-2023-ptx.html">blog post</a>.</p>
</div>
</div>
<p>Last month Pengutronix was present at the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">Embedded Open Source Summit (EOSS)</a>
in Prague.
Thanks to all to all speakers for sharing your knowledge!
In this blog post we want to shine a spotlight at a few talks that we found especially interesting.
(Links to recordings will be added once the recordings are available.)</p>
<div class="section" id="chris-suggestion-testing-and-remote-access-to-embedded-system-dpi-lvds-display-output-marek-vasut">
<h3>Chris' Suggestion: Testing and Remote Access to Embedded System DPI/LVDS Display Output (Marek Vasut)</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x771" href="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/veggie.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/veggie.thumb.09344e7d5a8007955d54bd04a67c5dda.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 199px;
"><p>During the whole event there was a constant supply of snacks and cold and warm beverages</p>
</figcaption>
</figure>
</div><p><a class="reference external" href="https://eoss2023.sched.com/event/1LcOL/testing-and-remote-access-to-embedded-system-dpilvds-display-output-marek-vasut?iframe=no">Schedule</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=ncnM8K6A1l4">Recording</a></p>
<p>In his talk Marek presented a way to capture the raw data of parallel display outputs and visualize the result.
This allows easy debugging of the resulting output at the end of the complete chain.</p>
<p>The cool thing about his method is, that he does not need expensive or specialized hardware to do so.
This solution incorporates the USB 3 version of a well-known parallel-to-USB buffered interface,
that has been used with <a class="reference external" href="https://sigrok.org/wiki/Fx2lafw">Sigrok</a> as a logic analyzer for quite some time.
He is using the
<a class="reference external" href="https://www.infineon.com/cms/en/product/universal-serial-bus/usb-peripheral-controllers-for-superspeed/ez-usb-fx3-usb-5gbps-peripheral-controller/">Cypress FX3 USB controller</a>
together with the already existing <a class="reference external" href="https://github.com/zeldin/fx3lafw">fx3lafw</a> Open Source firmware.</p>
<p>Marek used the FX3 dev-kit as a platform and added a interface PCB to his device under test (DUT).
The interface mechanically adapts the connector on the DUT to the connector on the dev-kit
and has no active parts.
After some firmware modifications (fx3lafw samples <em>free-running</em>, but the parallel display signal has a synchronous
clock signal) he was able to capture the raw data stream coming from the DUT.
This also includes blanking areas, H-sync and V-sync signals.</p>
<p>In the end Marek was able to capture frames and visualize them.</p>
<p>A capture device for parallel video output was missing our toolkit for development and automated testing.
It's great to see that all the building blocks are already there.
I will try to build these setup myself once I am back at the office.</p>
</div>
<div class="section" id="roland-s-suggestion-accelerated-mainline-linux-development-ahead-of-soc-availability-bryan-brattlof-praneeth-bajjuri">
<h3>Roland's Suggestion: Accelerated Mainline Linux Development Ahead of SoC Availability (Bryan Brattlof & Praneeth Bajjuri)</h3>
<p><a class="reference external" href="https://eoss2023.sched.com/event/1LcOO/accelerated-mainline-linux-development-ahead-of-soc-availability-bryan-brattlof-praneeth-bajjuri-texas-instruments">Schedule</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=5BGhRNxIevg">Recording</a></p>
<p>Although their colleague Praneeth Bajjuri could not make it to the conference,
Bryan Brattlof of Texas Instruments gave a good overview how the design and
driver development process works for new SoCs.</p>
<p>They showed that the development process of a modern SoC is not at all
straight-forward, and instead software and hardware development are heavily
intertwined, which results in fast development cycles.
With the different steps in the design process from the initial idea over
hardware design and validation, to tapeout at the manufacturer, they are able to
react to feedback by internal as well as external community members like
business people, system developers and architects, and experts for the different
Linux kernel subsystems.
This way the SoC vendor can address past pain points and get a feeling whether a
new SoC will be maintainable in mainline Linux at all.</p>
<p>Of course, the advantage of having kernel developers in-house makes it possible
for TI to work with internal pre-release versions of new SoC designs, and
develop preliminary driver support for new hardware units and the surrounding
hardware ecosystem (e.g. PMICs) while the design is still being validated.
Until hardware availability, the new systems are emulated in software based on
Verilog and SystemC models, which is fairly slow (as Bryan put it, "You find
other things to do after you hit that Run button"), but still, this approach
allows them to find errors quite fast, and the turnaround for a bug fix can be
measured in days or even hours rather than weeks.</p>
<p>In the Q&A, I was positively surprised that TI seems to have moved to a
"upstream first" approach.
When asked about how they persuaded the management, Bryan emphasised that they
realised that the "downstream BSP" approach was not feasible for long-term
platform support.
They learned from that past mistake and decided to work with upstream directly
instead, which gives them the advantage of feedback, support, and maintenance of
the wider Kernel community.
At last they want happy customers after all… :-)</p>
</div>
<div class="section" id="johannes-suggestion-muse-mtd-in-userspace-or-how-to-extend-fuse-for-fun-and-profit-richard-weinberger">
<h3>Johannes' Suggestion: MUSE: MTD in Userspace, or How to Extend FUSE for Fun and Profit (Richard Weinberger)</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="766x1024" href="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/stickers.jpeg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/stickers.thumb.96f7868323c673313200262fa7080f9b.jpeg"/>
</a><figcaption itemprop="caption description" style="
width: 112px;
"><p>Pengutronix Technical Showcase during the Booth Crawl</p>
</figcaption>
</figure>
</div><p><a class="reference external" href="https://eoss2023.sched.com/event/1LcO3/muse-mtd-in-userspace-or-how-to-extend-fuse-for-fun-and-profit-richard-weinberger-sigma-star-gmbh">Schedule</a>,
<a class="reference external" href="https://youtu.be/Ou1Wex_Dxu8">Recording</a>
In his position as MTD subsystem maintainer Richard not only spends a significant amount
of time improving NAND drivers and filesystems, but also investigating NAND images.</p>
<p>NAND flash is prone to bits flipping now and then, which requires error correction to be implemented
in NAND filesystems. Debugging with real-world NAND dumps can be quite painful, since
looking at raw dumps in a hex editor is still somewhat state-of-the art.</p>
<p>In his talk Richard pointed out that the existing in-kernel NAND-flash simulators <em>mtdram</em>,
<em>block2mtd</em> and <em>nandsim</em> besides <em>qemu virt</em> have been a good pathway for implementing and testing
especially error correction code and for bringing the MTD framework in good shape, but they
often do not simulate flash wear and are not very flexible with respect to fault injection and fuzzing.</p>
<p>When a colleague of Richard's mentioned <em>cuse</em> (character device in userspace) Richard was
immediately hooked and thought about if <em>cuse</em> or the closely related fuse (filesystem in userspace)
could be used for writing a new and more in-depth MTD simulator, for which he started writing <em>MUSE</em> (MTD in userspace).
Richard soon found that he only needed to add some minor additions with under 1k LOC in the kernel
to the already existing fuse implementation for simulating bad block handling and could quite
easily plug MTD filesystems on top of a fuse MTD simulator.</p>
<p>He now aims to have full record/replay options for using realworld NAND dumps, recording single steps of
error correction for better analysis, fuzzing, fault injection and supporting multiple formats of raw NAND dumps.</p>
<p>Richard still wants to experiment with his implementation, but announced that he will upstream his work
once he figured out a stable set of required operations for the FUSE device in order to support the MTD simulation.
He presented the internal structures and how FUSE works, as it uses a rather unique setup where the kernel is a client
to the userspace server part with the kernel making requests which are answered by the userspace.
At the Moment Richard is experimenting with using the <em>libfuse</em> low-level API in rust, while his original
implementation has been written in C.</p>
<p>At the end of his talk, he also pointed out that this could possibly be (mis)used for userspace MTD drivers,
though this is strongly discouraged, not only will this approach exhibit a performance penalty but also have some
security implications is calling for lots of other havoc.</p>
<p>I really enjoyed this talk, as it shows a creative use of already existing infrastructure for solving real-world problems,
I am curious if we will see similar FUSE-based approaches for tackling issues in other fields in our customer projects soon.</p>
</div>
<div class="section" id="michael-s-suggestion-how-much-is-tracing-measuring-the-overhead-caused-by-the-tracing-infrastructure-andreas-klinger">
<h3>Michael's Suggestion: How Much Is Tracing? Measuring the Overhead Caused by the Tracing Infrastructure (Andreas Klinger)</h3>
<p><a class="reference external" href="https://eoss2023.sched.com/event/1LcQu/how-much-is-tracing-measuring-the-overhead-caused-by-the-tracing-infrastructure-andreas-klinger-it-klinger">Schedule</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=oUWWGuvU4BE">Recording</a></p>
<p>Andreas reports on his investigation of the performance overhead of different
tracing mechanisms. He uses a test setup consisting of a BeagleBone Black with
custom Linux driver to toggle a GPIO and an oscilloscope to measure the pulse
width of the GPIO. Enabling and configuring different tracing mechanisms in
this test setup and observing the effects on the GPIO pulse width, allows to
draw conclusions about the overhead of the different mechanisms.</p>
<p>While developing actual products, we already experienced that the tracing
mechanisms, even though they are highly optimized and should have very little
overhead if they are enabled at compile time, but disabled at runtime, don't
come for free. Seeing the confirmation and actual measurements of this
performance overhead is very insightful, as tracing is a very valuable
debugging tool and one may prefer to keep it enabled in production systems.</p>
<p>Steven Rostedt, who is the maintainer of the tracing infrastructure, showed a
lot of interest in the measurement results. This further underlines the
relevance of Andreas' work. Hopefully, this work may result in further
optimization of the tracing infrastructure or at least in some guidelines which
tracing options may be kept enabled at what cost in production systems.</p>
</div>
<div class="section" id="elce-booth-crawl">
<h3>ELCE Booth Crawl</h3>
<p>During the Onsite Attendee Reception the Embedded Linux (Micro-) Conference (ELCE) gives projects and companies the
chance to present their projects with a tabletop demo.
The booth crawl is always another good opportunity to get in touch with the community.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="576x1024" href="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/fpga.jpeg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/fpga.thumb.2f4d36647700db95662a0302dbba0d32.jpeg"/>
</a><figcaption itemprop="caption description" style="
width: 84px;
"><p>Michael introducing the FPGA demo</p>
</figcaption>
</figure>
</div><p>Penugtronix used this chance to present two of our tabletop demos:</p>
<p>Our <strong>Open Source FPGA Demo</strong> shows that with an Open Source toolchain, RISC-V soft-core, build system and some
IP-cores it is possible to build complete systems.</p>
<p>Our <strong>Labgrid Demo</strong> showcases how easy it is to run tests on real hardware using
<a class="reference external" href="https://github.com/labgrid-project/labgrid">labgrid</a> and the
<a class="reference external" href="https://www.linux-automation.com/en/products/lxa-tac.html">Linux Automation Test Automation Controller</a>.</p>
<p>Labgrid is a Python-based Open Source board control library.
It allows you to interactively control embedded devices on your desk - or at a remote location.
It also has a strong focus on automation:
You can either use it as a library in your scripts or as a pytest plugin.
This way, you can run tests on real hardware that feel like pure software testing.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x1836" href="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/cfi_has_labgrid.jpeg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-07-03_embedded-linux-conference-europe-2023-our-recommendations/cfi_has_labgrid.thumb.8db2eeb9bba21823f9da96bfb0235226.jpeg"/>
</a><figcaption itemprop="caption description" style="
width: 266px;
"><p>Holger and Chris introduce labgrid and the LXA TAC</p>
</figcaption>
</figure>
</div><p>The Test Automation Controller (TAC) (designed by our spin-off <a class="reference external" href="https://www.linux-automation.com/en/">Linux Automation</a>)
connects the physical world to labgrid.
It provides interfaces such as an UART, a power switch with voltage and current measurement, USB host and device
ports and general purpose I/Os.</p>
<p>The test controller can be powered using Power over Ethernet (PoE) and has an integrated Ethernet switch.
This means, that in most cases, you only have two connections to your test setup:
power for your device under test and Power over Ethernet for the Test Automation Controller.
The device runs Linux based on Yocto.
The <a class="reference external" href="https://github.com/linux-automation/meta-lxatac/">Yocto layer</a> is already available under MIT license.
The device will most likely be available in autumn 2023.</p>
<p>In this demonstration we run a few tests on the device under test (DUT), in this case,
a Beagle Bone with a separate motor board.
At the beginning of a test-run, labgrid switches the device off and provisions the newest software image on
the SD-Card using the USB-SD-Mux.
Afterwards, the DUT is powered on and labgrid interrupts the boot process to run a first test inside the bootloader.
Then, the boot process is resumed and labgrid takes control over the Linux shell.</p>
<p>In the shell, the main functionality of this device is tested:
We want to spin the disk at a given speed.
By slowing the disk down manually, we can let the tests fail intentionally.
In a real-world scenario these results would now be collected by the test runner and some engineer would have to
investigate what has happened.
But in our demonstrator the process simply starts over again.</p>
</div>
</div><p>Last month Pengutronix was present at the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">Embedded Open Source Summit (EOSS)</a>
in Prague.
Thanks to all to all speakers for sharing your knowledge!
In this blog post we want to shine a spotlight at a few talks that we found especially interesting.
(Links to recordings will be added once the recordings are available.)</p>2023-07-17T08:00:00+01:00tag:www.pengutronix.de,2023-07-01:/2023-07-01-rauc-v1-10-released.htmlRAUC v1.10 Released2023-07-01T18:00:22+01:00Enrico Jörns<div class="section" id="rauc-v1-10-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.10 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.10">release page</a></p>
</div>
</div>
<p>Just in time for the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">EOSS 2023</a>
in Prague, we have released v1.10 of RAUC.
Just-in-time means the release was actually finalized by Jan Lübbe in the
train to Prague (like I finally wrote the majority of this blog post on the
train back).</p>
<p>So what is in the release?
Besides some minor memory leak fixes, smaller improvements, and bugfixes, we have
also made progress.
And this is meant literally, as you will see below.
Other useful features introduced are <em>transaction UUIDs</em>, meta-data printout
for <tt class="docutils literal">rauc info</tt>, a new JSON output format, and some more.</p>
<p>A notable bug fixed with this release relates to mount point detection which
had a logical issue and thus, in some scenarios could have prevented detecting
some external mount points reliably.
See <a class="reference external" href="https://github.com/rauc/rauc/pull/1105">#1105</a> for more information.</p>
<p>As always, the topics in this blog post are cherry-picked from the
changes that actually happened.
Refer to the full changes listed on the release page for a more comprehensive
overview.</p>
<div class="section" id="progress-handling-rework">
<h3>Progress Handling Rework</h3>
<p>From a user perspective, probably the most notable change with v1.10 is
the progress handling, which is now more realistic
and fine-grained.</p>
<p>Historically, the progress information in RAUC, emitted by either the D-Bus
<tt class="docutils literal">Progress</tt> property or shown by CLI when calling <tt class="docutils literal">rauc install <span class="pre">--progress</span></tt>,
was badly distributed.
This means that actual image copying started at 80%, while everything before was
just some checks and verification.</p>
<p>This has never been a realistic distribution of the actual duration for each
task, but has become much worse with the introduction of the 'verity' format
which made the initial verification happen quite quickly.
As a result (depending on the actual write speeds etc.), the progress bar
had reached 80% after completing ~10% of the installation job.</p>
<div class="row"><div class="col-md-7"><p>With v1.10, we have now added support for weighting substeps, which allowed us to
redistribute the actual progress without having to change much of the current
progress update calls.
As a result, RAUC will now start coping images at 40% progress.</p>
<p>But, the more notable and often requested feature is of course the support for
fine-grained progress, meaning that RAUC will emit evenly distributed progress
steps <em>during</em> image installation.
Especially when updating a slot takes a long time, this should significantly improve
the user experience.</p>
<p>Thanks to the initial work done by Lars Poeschel who submitted this as a
PR in November 2021, we have been able to add some missing puzzle
pieces and have fine-grained progress working in RAUC in time for a
demo for the Pengutronix booth at Embedded World 2023.</p>
<p>Fine-grained progress currently works for non-adaptive installations of
block images and archives.</p>
<div class="clearfix"></div></div><div class="col-md-5">
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/u8L4DSOT_ow"></iframe>
</div>
<div class="clearfix"></div></div></div></div>
<div class="section" id="improvements-of-rauc-info">
<h3>Improvements of <tt class="docutils literal">rauc info</tt></h3>
<div class="row"><div class="col-md-4"><p>The 'rauc info' command, meant to show information about a bundle, received some
improvements and new features.</p>
<p>When using the default output format for <tt class="docutils literal">rauc info</tt>, all sizes
are now also printed in shorter human-readable form with the original
per-byte-information, e.g. <tt class="docutils literal">14,7 MB (14.659.412 Bytes)</tt>.</p>
<p>As promised in the blog post for v1.9, the support of custom metadata
manifest information is now almost completed by adding it
to the <tt class="docutils literal">InspectBundle()</tt> D-Bus method and
to all <tt class="docutils literal">rauc info</tt> output formats.</p>
<p>With <tt class="docutils literal"><span class="pre">json-2</span></tt>, we introduced a new output format that uses
the same structure as the <tt class="docutils literal">InspectBundle()</tt> method.</p>
<div class="clearfix"></div></div><div class="col-md-8"><div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>rauc<span class="w"> </span>info<span class="w"> </span>--output-format<span class="o">=</span>json-2<span class="w"> </span>test/good-adaptive-meta-bundle.raucb
<span class="o">{</span>
<span class="w"> </span><span class="s2">"update"</span><span class="w"> </span>:<span class="w"> </span><span class="o">{</span>
<span class="w"> </span><span class="s2">"version"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"2023.03-1"</span>,
<span class="w"> </span><span class="s2">"compatible"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"Test Config"</span>
<span class="w"> </span><span class="o">}</span>,
<span class="w"> </span><span class="s2">"images"</span><span class="w"> </span>:<span class="w"> </span><span class="o">[</span>
<span class="w"> </span><span class="o">{</span>
<span class="w"> </span><span class="s2">"slot-class"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"rootfs"</span>,
<span class="w"> </span><span class="s2">"filename"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"rootfs.img"</span>,
<span class="w"> </span><span class="s2">"checksum"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"101a4fc5c369a5c89a51a61bcbacedc90[...]"</span>,
<span class="w"> </span><span class="s2">"size"</span><span class="w"> </span>:<span class="w"> </span><span class="m">8192</span>,
<span class="w"> </span><span class="s2">"hooks"</span><span class="w"> </span>:<span class="w"> </span><span class="o">[]</span>
<span class="w"> </span><span class="o">}</span>,
<span class="w"> </span><span class="o">]</span>,
<span class="w"> </span><span class="s2">"manifest-hash"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"4f471ebf24aeb566fad623c1084cd448[...]"</span>,
<span class="w"> </span><span class="o">[</span>...<span class="o">]</span>
<span class="w"> </span><span class="s2">"meta"</span><span class="w"> </span>:<span class="w"> </span><span class="o">{</span>
<span class="w"> </span><span class="s2">"update"</span><span class="w"> </span>:<span class="w"> </span><span class="o">{</span>
<span class="w"> </span><span class="s2">"poll"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"86400"</span>
<span class="w"> </span><span class="o">}</span>,
<span class="w"> </span><span class="s2">"version"</span><span class="w"> </span>:<span class="w"> </span><span class="o">{</span>
<span class="w"> </span><span class="s2">"channel"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"beta"</span>,
<span class="w"> </span><span class="s2">"release-notes"</span><span class="w"> </span>:<span class="w"> </span><span class="s2">"https://example.com/release-notes"</span>
<span class="w"> </span><span class="o">}</span>
<span class="w"> </span><span class="o">}</span>
<span class="o">}</span>
</pre></div>
</div><div class="clearfix"></div></div></div></div>
<div class="section" id="introduction-of-transaction-uuids">
<h3>Introduction of Transaction UUIDs</h3>
<p>With v1.10, another element for better tracking of the life-cycle
of an installation was added to RAUC: The (installation) transaction UUID.</p>
<p>While the <em>manifest hash</em>, introduced with RAUC v1.9, allowed us to
unambiguously tell which exact bundle was installed, one aim of the transaction
UUID is to tell which exact installation invocations led to the current
state of the system.
Further plans are to use this information for tracking the installation
procedure beyond just the basic slot writing and allows a user to know if an
installation actually resulted in the expected system being booted, etc.</p>
<p>For this, RAUC generates a new UUID when starting an installation.
Alternatively, D-Bus callers can provide their own ID here, e.g. for update
servers that already have a concept of an ID per installation.</p>
<p>Currently, RAUC prints the transaction UUID in the logs, writes it to the
slot status file(s) and shows it in the <tt class="docutils literal">rauc status <span class="pre">--detailed</span></tt> output and
in the corresponding D-Bus API.</p>
</div>
<div class="section" id="sealing-the-leak">
<h3>Sealing the Leak</h3>
<p>Triggered by a <a class="reference external" href="https://github.com/rauc/rauc/pull/1119">community contribution</a> fixing a memory leak
that was revealed by using the libfuzzer and the address sanitizer capabilities of
the compiler, we added a new <tt class="docutils literal">sanitzier</tt> action <a class="reference external" href="https://github.com/rauc/rauc/blob/master/.github/workflows/sanitizers.yml">workflow</a>
to the GitHub CI.</p>
<p>Enabling address sanitizer checking for test cases required a number of memory leaks to be
fixed in the test cases itself, but in the end also revealed
some remaining memory leaks in RAUC itself.</p>
<p>While most unit tests now run with address sanitizer enabled, some still need to
be done.
However, the new checks already help to detect memory leaks and other
regressions in RAUC.</p>
</div>
<div class="section" id="meson-support">
<h3>Meson Support</h3>
<p>Meson support was introduced with RAUC v1.9 to replace the ancient autotools.
They were kept in parallel with autotools for this release to simplify migration.</p>
<p>We have then agreed on keeping both even in the v1.10 release.
Not only to have a longer grace period, but also since we still had some smaller
issues that were fixed now, like a dependency issue for test builds, a wrong
file mode for the <tt class="docutils literal"><span class="pre">rauc-service.sh</span></tt> wrapper, and finally we missed installing
our fine man page.</p>
<p>In the next release, autotools support will likely be
dropped, thus package maintainers who haven't migrated to Meson yet should
consider it.</p>
<p>Luckily, by the time of writing, most have already migrated anyway.
Buildroot did it with the v1.9 migration (thanks to Heiko Thiery), same for
meta-rauc, and for PTXdist I prepared a patch just yesterday.</p>
</div>
<div class="section" id="outlook-http-header-customization">
<h3>Outlook: HTTP Header Customization</h3>
<p>As outlined in concept <a class="reference external" href="https://github.com/rauc/rauc/issues/1114">#1114</a>,
we have plans to improve support for simple update servers by
optionally providing some information about the system state to the server
in the first HTTP request's headers.
The server can then use this for more detailed logging or even for making
simple decisions based on the data.</p>
<p>With v1.10, some other preparations made into RAUC: The so-far quite limited
<tt class="docutils literal"><span class="pre">system-info</span></tt> handler was extended to return custom system
information as environment-like variables.
Specially named variables are then planned to be exposed via HTTP headers, too.
The actual header implementation is already available in PR
<a class="reference external" href="https://github.com/rauc/rauc/pull/1152">#1152</a>.</p>
</div>
<div class="section" id="thanks">
<h3>Thanks</h3>
<p>Many thanks again to all contributors of the v1.10 release: Christian Hitz,
Christian Hohnstaedt, Christian Meusel, Enrico Jörns, Jan Lübbe, Lars Poeschel,
René Fischer, Stefan Wahren, Ulrich Ölmann, b4yuan</p>
</div>
</div><p>Just in time for the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">EOSS 2023</a>
in Prague, we have released v1.10 of RAUC.
Just-in-time means the release was actually finalized by Jan Lübbe in the
train to Prague (like I finally wrote the majority of this blog post on the
train back).</p>2023-07-01T18:00:22+01:00tag:www.pengutronix.de,2023-06-27:/2023-06-27-elce-2023-ptx.htmlEmbedded Linux Conference Europe 2023: Our Contributions2023-06-27T22:00:00+01:00Chris Fiege<div class="section" id="embedded-linux-conference-europe-2023-our-contributions">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2840x3920" href="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/ptx_badge.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/ptx_badge.thumb.7cda021075c89adcdec64cddec5fa542.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 108px;
"></figcaption>
</figure>
</div><p>This year the Embedded Linux Conference Europe (ELCE) is back in Prague!
Pengutronix, again, is on a <em>field trip</em> with 15 colleges to attend the conference.
The ELCE is one of the big conferences where the Embedded Linux Community meets during the year.
This time the ELCE is part of the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">Embedded Open Source Summit (EOSS)</a>:
a new conference with only embedded topics and without cloud- or crypto-tracks.</p>
<p>In this blog post we showcase the talks our colleagues will present at the ELCE.
(Links to recordings will be added once the recordings are available.)</p>
<div class="section" id="oleksij-rempel-braiding-wires-into-the-linux-network-stack-recent-work-on-embedded-networking">
<h3>Oleksij Rempel: Braiding Wires Into the Linux Network Stack - Recent Work on Embedded Networking</h3>
<div class="ptx-sidebar">
<div class="title">
Links for this talk
<div class="corner"></div>
</div>
<div class="body">
<p><strong>Oleksij Rempel</strong>,
Wednesday, June 28 • 16:05 - 16:45,
<a class="reference external" href="https://eoss2023.sched.com/event/1LcO6/braiding-wires-into-the-linux-network-stack-recent-work-on-embedded-networking-oleksij-rempel-pengutronix-ek">Schedule and Slides</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=IsT_29qJz7c">Recording</a></p>
</div>
</div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="512x512" href="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/ore.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/ore.thumb.1fe6573087d38bb3077a88b7e51edcde.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"><p>Oleksij Rempel</p>
</figcaption>
</figure>
</div><p>Over the last few months, Oleksij Remepel has spent some time extending the Linux kernel's network infrastructure
for embedded use cases - this includes, industrial, medical and automotive devices.
As usual, any driver development starts from the basics and goes to advanced topics.
The driver developer starts with the default hardware settings and makes them work.
For example, with a Gigabit Ethernet controller, the first use case is a 1000BaseT full duplex link.
While this works for most applications, some embedded use cases have special requirements.
This talk will look into topics like: Energy Efficient Ethernet (EEE), Single Pair Ethernet (SPE),
diagnostics and many more.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/IsT_29qJz7c"></iframe>
</div>
</div>
<div class="section" id="lucas-stach-why-are-gpus-not-fast-a-trip-through-the-driver-stack">
<h3>Lucas Stach: Why Are GPUs (Not) Fast - A Trip Through the Driver Stack</h3>
<div class="ptx-sidebar">
<div class="title">
Links for this talk
<div class="corner"></div>
</div>
<div class="body">
<p><strong>Lucas Stach</strong>,
Thursday, June 29 • 14:10 - 14:50,
<a class="reference external" href="https://eoss2023.sched.com/event/1LcPA/why-are-gpus-not-fast-a-trip-through-the-driver-stack-lucas-stach-pengutronix">Schedule and Slides</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=LzleI6t29fM">Recording</a></p>
</div>
</div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="512x512" href="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/lst.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/lst.thumb.86b9123dcfc1538fd636bfc8d67570df.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"><p>Lucas Stach</p>
</figcaption>
</figure>
</div><p>GPUs are often called accelerators and everybody tells us that they are supposed to make all things graphical
go really fast.
So why do they sometimes fall short of expectations and is there something we can do about it?
This talk will first give a brief introduction to GPU hardware and how it differs from the traditional CPU.
It will then work its way up through the different parts of the GPU driver stack until reaching the user visible
APIs like EGL, OpenGL and Vulkan.
The audience will gain a basic understanding on how the GPU hardware and drivers work and how to best utilize them both.
Understanding the driver stack below the sometimes very abstract user APIs will help attendees of this
talk to avoid performance pitfalls and utilize more of the acceleration potential when writing applications
using the GPU.
They will also gain a understanding how the graphics stack ties into the greater Linux ecosystem.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/LzleI6t29fM"></iframe>
</div>
</div>
<div class="section" id="johannes-zink-do-the-time-warp-the-rocky-horror-ptp-show-verification-of-network-time-synchronization-in-the-real-world">
<h3>Johannes Zink: Do the Time Warp – the Rocky Horror PTP Show: Verification of Network Time Synchronization in the Real World</h3>
<div class="ptx-sidebar">
<div class="title">
Links for this talk
<div class="corner"></div>
</div>
<div class="body">
<p><strong>Johannes Zink</strong>,
Friday, June 30 • 14:00 - 14:40,
<a class="reference external" href="https://eoss2023.sched.com/event/1LcQl/do-the-time-warp-the-rocky-horror-ptp-show-verification-of-network-time-synchronization-in-the-real-world-johannes-zink-pengutronix-ek">Schedule and Slides</a>,
<a class="reference external" href="https://www.youtube.com/watch?v=poVrAdBdOeM">Recording</a></p>
</div>
</div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="512x512" href="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/jzi.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-27_elce-2023-ptx/jzi.thumb.dd970eac2d3e135b50caba9e4ecb411f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"><p>Johannes Zink</p>
</figcaption>
</figure>
</div><p>Many realtime network applications require tight time synchronizations between the different nodes in a network.
The Precision Time Protocol PTP can provide clock synchronization down to the nanosecond range.
In order to achieve such tight synchronization, hardware timestamping of PTP packets is used, for which the
Linux kernel provides the kernel PTP hardwareclock infrastructure, while linuxptp implements the PTP protocol
stack in userspace.
Proper configuration of the components involved and the setup of the PTP daemons and hardware can be a difficult task,
because even minor configuration issues have a huge impact on the overall performance.
After a short introduction into PTP and synchronization of PTP hardware clocks, this talk introduces different
methods for measuring clock synchronization and compares their advantages and disadvantages.
Using examples from real world projects, this talk will show common pitfalls when starting to set up new
PTP projects and how to avoid them. Last but not least, this talk will show misleading software debug outputs,
time jumping back and forth, and many more fun effects you can encounter when setting up PTP in your network
for the first time and how to debug these issues.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/poVrAdBdOeM"></iframe>
</div>
</div>
</div>
<p>This year the Embedded Linux Conference Europe (ELCE) is back in Prague!
Pengutronix, again, is on a <em>field trip</em> with 15 colleges to attend the conference.
The ELCE is one of the big conferences where the Embedded Linux Community meets during the year.
This time the ELCE is part of the
<a class="reference external" href="https://events.linuxfoundation.org/embedded-open-source-summit/">Embedded Open Source Summit (EOSS)</a>:
a new conference with only embedded topics and without cloud- or crypto-tracks.</p>2023-06-27T22:00:00+01:00tag:www.pengutronix.de,2023-06-24:/2023-06-24-kernel-panic-board-on-fire-005-time-sensitive-networking.html[Podcast] Kernel Panic - Board on Fire ~~> #005: Time Sensitive Networking - Was wann wo wieso?2023-06-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-005-time-sensitive-networking-was-wann-wo-wieso">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#005: Time Sensitive Networking - Was wann wo wieso?", "summary": "Johannes Zink und Leonard reden in dieser Folge \u00fcber Time Sensitive Networking und warum Industrieanlagen und B\u00fchnentechnik eigentlich eine Menge gemeinsam haben.", "publicationDate": "2023-06-24T10:10:10+00:00", "duration": "01:19:23", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-06-24-kernel-panic-board-on-fire-005-time-sensitive-networking.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/005_time_sensitive_networking.mp3", "size": 69755468, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/005_time_sensitive_networking.mp3", "size": 69755468, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge erzählt Johannes Zink uns was was Time Sensitive Networking
(TSN) und das Precision Time Protocol (PTP) sind und warum sie zum Beispiel für
Industrieanlagen und Bühnentechnik so wichtig sind.</p>
<p>TSN ist eine Gruppe von Standards, die eine deterministischere Übertragung von
Daten über das gewohnte Ethernet-Protokoll erlauben, um z.B. Audiodaten
aussetzerfrei über ein Netzwerk zu übertragen oder Steuerkommandos verlässlich
an Aktoren in Industrieanlagen zu schicken.</p>
<p>Ein besonders interessanter Standard aus dieser Gruppe ist PTP, das Precision
Time Protocol, das eine bis auf wenige Nanosekunden genaue Zeitsynchronisation
über Ethernet-Verbindungen ermöglicht.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Johannes stellt sich und das Thema vor und es gibt ein paar einleitende warme
Worte.
Es werden Abkürzungen wie TSN und PTP geklärt und grob abgesteckt warum
Zeitsynchronisation überhaupt nötig ist.</dd>
<dt>07:00</dt>
<dd>Grobes Abstecken in welchen Fällen eine Synchronisation der Frequenz zwischen
Geräten ausreicht (z.B. Audio/Video Liveübertragung),
in welchen Fällen eine lokale Zeitsynchronisation innerhalb eines Netzes
ausreicht (z.B. Motorsteuerung in Industrieanlagen) und in welchen Fällen
eine absolute Zeitsynchronisation auf globaler Größenordnung notwendig ist
(eher Spezialfälle).</dd>
<dt>14:30</dt>
<dd><p class="first">Wie entscheiden Teilnehmer eines PTP-Netzes darüber welche ihrer Uhren als
Zeitgeber für das Netz verwendet werden soll?</p>
<p class="last">Dafür gibt es einen Algorithmus, der z.B. eine GPS-Referenz höher bewertet
als einen lokalen Quarzoszillator und so den besten Knoten als Zeitbasis
auswählt.</p>
</dd>
<dt>19:30</dt>
<dd><p class="first">Wie übertragen PTP-Knoten ihre aktuelle Uhrzeit nanosekundengenau?</p>
<p class="last">Im üblichen Fall sendet PTP zwei Pakete ab um die aktuelle Zeit an einem
Knoten mitzuteilen.
Zuerst ein mehr oder weniger leeres Ping-Paket, bei dem der Knoten selbst in
Hardware ganz genau den Zeitpunkt bestimmt in dem das Paket auf die Leitung
gegangen ist und im Nachgang ein Paket in dem der Zeitstempel des ersten
Pakets steht.</p>
</dd>
<dt>25:00</dt>
<dd><p class="first">Wie wird die Laufzeit der Pakete auf der Leitung kompensiert?</p>
<p class="last">Es werden bidirektional Ankunfts- und Absendezeiten ausgetauscht und unter
der Annahme, dass die Laufzeit in beide Richtungen symmetrisch ist, kann
sie herausgerechnet werden.</p>
</dd>
<dt>26:30</dt>
<dd><p class="first">Was passiert wenn eine Verbindung nicht direkt Punkt-zu-Punkt ist und z.B.
ein Switch zwischen den Parteien zufällige Verzögerungen einfügt?
Oder was wenn die Laufzeiten in Hin- und Rückrichtung eben nicht symmetrisch
sind?</p>
<p class="last">TL;DR: It depends.</p>
</dd>
<dt>36:15</dt>
<dd>Vergleich von PTP (sehr genau, in der Regel nur in einem lokalen Netz mit
speziellen PTP-fähigen Geräten) und NTP (meist gut genug, über das Internet
und mit gewöhnlicher Hardware).</dd>
<dt>38:15</dt>
<dd>Anwendungen: Audio-/Videoübertragung, Sensoren und Aktoren in Industrieanlagen,
Automotive, Avionik, Stromnetze …</dd>
<dt>50:15</dt>
<dd><p class="first">Übergang von PTP zum Determinismus-Anteil von TSN.</p>
<p class="last">Bei einer Live-Audioübertragung sollen Daten z.B. verlässlich und mit
konstanter Laufzeit vom Sender zum Empfänger fließen.
Bei normalem "best effort" Ethernet ist das nicht immer erfüllbar.
Der älteste Ansatz dazu ist Prioritäten zu definieren um zwischen wichtigen
und weniger wichtigen Daten zu unterscheiden.
Das Prioritätskonzept erfordert aber viel Konfigurationsaufwand und stößt
schnell an seine Grenzen.</p>
</dd>
<dt>56:00</dt>
<dd>Eine Alternative zu Prioritäten ist es feste Bandbreiten zwischen Partnern
im Voraus zu reservieren.</dd>
<dt>72:00</dt>
<dd>Exkursion zu anderen TSN-Erweiterungen, Traffic Shapern und dem
Standardisierungsprozess.</dd>
<dt>74:00</dt>
<dd>Bogen schließen, zusammenfassen und abschließende warme Worte loswerden.</dd>
</dl>
</div><p>In dieser Folge erzählt Johannes Zink uns was was Time Sensitive Networking
(TSN) und das Precision Time Protocol (PTP) sind und warum sie zum Beispiel für
Industrieanlagen und Bühnentechnik so wichtig sind.</p>2023-06-24T10:10:10+01:00tag:www.pengutronix.de,2023-06-13:/2023-06-13-djangocon-europe-2023.htmlDjangoCon Europe 20232023-06-13T10:00:00+01:00Meike Reichle<div class="section" id="djangocon-europe-2023">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4032x3024" href="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/castle.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/castle.thumb.682152f045d0ffd72dd03ebbe05997f4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Edinburgh Castle</p>
</figcaption>
</figure>
</div><p>Django is Pengutronix' framework of choice for internal applications that handle our business processes.
These internal tools are also a great opportunity to try out current developments in the Django universe.</p>
<p>More than enough reason to also pay the Django community a visit
at this year's DjangoCon Europe took place in Edinburgh, Scotland.
The by now well established community conference offered three days of talks,
covering a wide variety of aspects of Django development,
followed by two days of Django project coding sprints.</p>
<p>Some talks that we found especially interesting were for instance
Wilhelm Klopp’s great <a href="https://pretalx.com/djangocon-europe-2023/talk/YJQ8HR/">overview on testing and testing utilities</a>
and Dawn Wages’ excellent <a href="https://pretalx.com/djangocon-europe-2023/talk/DJF7SF/">talk on different types of Open Source project contributors</a>,
how to best motivate and integrate them
and what general themes contribute to a healthy Open Source community project.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3024x3024" href="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/pony.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/pony.thumb.70c6baa8ac8f0d09785eee5118080e1a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The Django Pony meets its Scottish cousin</p>
</figcaption>
</figure>
</div><p>There were also several presentations on especially inspiring applications of the Django framework,
such as on <a href="https://www.aura.radio/">AURA</a>, an <a href="https://pretalx.com/djangocon-europe-2023/talk/9MBQEB/">auto-scheduling tool for free radios</a>
or on scaling up a Django app to such an extent,
that it could be used to run the <a href="https://pretalx.com/djangocon-europe-2023/talk/PYFUGF/">back-end of a WhatsApp based pandemic information and health service</a>,
serving almost 15 Million users all across South Africa.</p>
<p>Established topics such as performance improvement and query optimisation have gained new significance
in light of aspects such as green computing.
This was well illustrated by Andrew Aikman, who gave an <a href="https://pretalx.com/djangocon-europe-2023/talk/PXBRGK/">extensive overview on the subject</a>,
talking about everything from query optimisation to efficient kettle usage!</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3024x4032" href="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/talk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-06-13_djangocon-europe-2023/talk.thumb.6194b6079b753c1458ec068bdab48554.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The main auditorium</p>
</figcaption>
</figure>
</div><p>Carlton Gibson presented a very promising new project called <a href="https://pypi.org/project/neapolitan/">neapolitan</a> („better than vanilla“)
for <a href="https://pretalx.com/djangocon-europe-2023/talk/P9M8BL/">quickly bootstrapping CRUD oriented Django projects</a></p>
<p>Special mention also to Daniele Procida’s talk on <a href="https://pretalx.com/djangocon-europe-2023/talk/KFGC7M/">The programmer’s imagination</a>,
which offered a most entertaining perspective on the general disenchantment of computer use and the emergence of “servile” design and objects.</p>
<p>Big thanks to the conference's organising team and volunteers for an all around great conference!</p>
<p>If you're interested in attending a DjangoCon yourself, <a href="https://2024.djangocon.eu/">next year's DjangoCon</a> is taking place in Vigo, Italy.</p>
</div>
<p>Django is Pengutronix' framework of choice for internal applications that handle our business processes.
These internal tools are also a great opportunity to try out current developments in the Django universe.</p>2023-06-13T10:00:00+01:00tag:www.pengutronix.de,2023-05-24:/2023-05-24-kernel-panic-board-on-fire-004-optee-und-trustzone.html[Podcast] Kernel Panic - Board on Fire ~~> #004: OP-TEE und TrustZone - Geheimnisträger in der CPU2023-05-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-004-op-tee-und-trustzone-geheimnistrager-in-der-cpu">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#004: OP-TEE und TrustZone - Geheimnistr\u00e4ger in der CPU", "summary": "Rouven Czerwinski und Leonard reden in dieser Folge \u00fcber OP-TEE und TrustZone und dar\u00fcber wie beides zusammen arbeitet um auf ARM-Prozessoren Geheimnisse zu speichern", "publicationDate": "2023-05-24T10:10:10+00:00", "duration": "00:46:10", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-05-24-kernel-panic-board-on-fire-004-optee-und-trustzone.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/004_optee-und-trustzone.mp3", "size": 49610468, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/004_optee-und-trustzone.mp3", "size": 49610468, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge erzählt Rouven Czerwinski uns was
<a class="reference external" href="https://optee.readthedocs.io/en/latest/general/about.html">OP-TEE</a>
ist, was es mit ARM TrustZone zu tun hat und wie beides zusammen arbeitet
um Geheimnisse in einem Prozessor abzulegen.</p>
<p>Geheimnisse können in diesem Fall zum Beispiel kryptographische Schlüssel sein,
mit denen sich ein Embedded-Gerät gegenüber einem Server authentifiziert.</p>
<p>Diese Folge ist die erste von vier Techweek-Folgen in denen wir eine Pause von
den Schauergeschichten machen und stattdessen frei über ein interessantes Thema
tratschen.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Vorstellung und einleitende warme Worte.
Diese Folge wird eine von vier Techweek-Folgen, also während der Pengutronix
Techweek aufgenommenen Folgen.
Zur Techweek nimmt sich die ganze Firma eine Woche Zeit um sich mit
interessanten technischen Themen, abseits der üblichen Kundenarbeit, zu
befassen.</dd>
<dt>02:00</dt>
<dd>Rouven erzählt von den Projekten an denen er bisher gearbeitet hat.
Das heißt von Embedded-Development-Automatisierung mit labgrid über
Software-Security mit OP-TEE bis zu seiner aktuellen Spezialisierung als
Grafikentwickler.</dd>
<dt>10:30</dt>
<dd>Was ist OP-TEE, wo kommt es zum Einsatz und warum will man es benutzen?
Ein Einsatzzweck ist es eine sichere Ablage für kryptographisches
Schlüsselmaterial zu haben, bei dem der Private Key niemals das Gerät
verlassen soll.
Das ist z.B. relevant wenn ein Gerät, das irgendwo im Feld steht,
sich gegenüber einem Cloud-Backend authentifizieren soll.</dd>
<dt>13:00</dt>
<dd>Ist das nicht auch was ein TPM (Trusted Platform Module) erreichen soll?
Ungefähr. TPMs kommen aus dem x86 Desktop/Laptop/Server-Umfeld und OP-TEE
aus dem ARM und Embedded-Umfeld.
TPMs sind in der Regel separate Chips, während OP-TEE das TrustZone Feature
von ARM CPUs nutzt, um auf dem selben Prozessor zu laufen wie das eigentliche
Betriebssystem und die Anwendungssoftware.</dd>
<dt>15:00</dt>
<dd>Wann "läuft" OP-TEE? TL;DR: Wenn es aufgerufen wird.
Neben OP-TEE und z.B. einem Linux läuft auf der CPU auch noch ein Secure
Monitor, der OP-TEE und Linux jeweils Bereiche des Speichers zuweist und
Möglichkeiten bereitstellt damit OP-TEE und Linux kommunizieren können.
Im normalen Betrieb sind dann OP-TEE und Linux gleichzeitig im Speicher
geladen und Linux kann über den Secure Monitor Funktionen im OP-TEE aufrufen.</dd>
<dt>23:00</dt>
<dd>Wie speichert OP-TEE geheimes Material wie z.B. Schlüssel obwohl im SoC
(System on Chip) kaum Speicher (flüchtig und permanent) zur Verfügung steht?
Es muss nur ein kryptographischer Schlüssel im SoC selbst gespeichert werden
mit dem Daten verschlüsselt werden bevor sie z.B. auf eine eMMC ausgelagert
werden.</dd>
<dt>25:00</dt>
<dd>Wie das Ablegen der Schlüssel passiert ist hardwareabhängig.
Auf NXP i.MX Prozessoren muss man wenn man OP-TEE nutzen möchte auch
Secure Boot/Verified Boot nutzen.
Dazu wird ein Hashwert eines Public Keys in den Fuses des Prozessors
abgelegt und es werden nur Bootloader gestartet, die mit diesem Public
Key signiert sind.</dd>
<dt>29:30</dt>
<dd>Warum überhaupt OP-TEE wenn man doch sowieso Secure Boot macht und damit
auch sicherstellen kann, dass nur ein signiertes Linux gestartet wird?
Weil Linux ein sehr großes Softwareprojekt ist und deshalb eher
Sicherheitslücken enthält als das vergleichsweise kleine OP-TEE.</dd>
<dt>31:00</dt>
<dd>Wie verhindert OP-TEE, dass geheime Daten den Prozessor verlassen, z.B. beim
Schreiben in den externen RAM?
Soweit möglich wird interner SRAM verwendet. Wird mehr Speicher benötigt
werden nicht mehr genutzte Bereiche aus dem SRAM verschlüsselt und in den
externen RAM ausgelagert.</dd>
<dt>35:30</dt>
<dd>Die Datenleitungen zum externen RAM sind nicht die einzige Möglichkeiten
Daten des OP-TEE auszulesen. Es ist auch wichtig Peripherieeinheiten wie der
Grafikeinheit eines SoCs, der JTAG Debug-Einheit oder den DMA-Einheiten den
Zugriff auf OP-TEE-Speicher zu verbieten.
Wie das passiert ist (mal wieder) hardwareabhängig.
Ob die Einstellungen auch funktionieren muss man ausgiebig testen.</dd>
<dt>44:00</dt>
<dd>Verweis auf Talks und anderes Online-Material und Outro.</dd>
</dl>
</div><p>In dieser Folge erzählt Rouven Czerwinski uns was
<a class="reference external" href="https://optee.readthedocs.io/en/latest/general/about.html">OP-TEE</a>
ist, was es mit ARM TrustZone zu tun hat und wie beides zusammen arbeitet
um Geheimnisse in einem Prozessor abzulegen.</p>2023-05-24T10:10:10+01:00tag:www.pengutronix.de,2023-03-14:/2023-03-14-pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again.htmlPulse Width Modulation (PWM) is easy, isn't it? - Turning it off and on again2023-03-14T10:00:00+01:00Johannes Zink<div class="section" id="pulse-width-modulation-pwm-is-easy-isn-t-it-turning-it-off-and-on-again">
<p>Part of Uwe Kleine-König's work at Pengutronix is to review PWM
(Pulse Width Modulation) drivers.
In addition, he also sometimes refactors existing drivers
and the Linux kernel <a href="https://docs.kernel.org/driver-api/pwm.html">PWM subsystem</a>
in general.</p>
<p>Since Uwe has seen lots of PWM drivers, he decided to give a talk at the
<a href="https://fosdem.org/2023/schedule/event/pwm/">2023 FOSDEM</a> in Brussels
where he explained what PWM is,
how the use-cases influence the kernel PWM subsystem's design,
gave advice to driver authors and
showed common pitfalls.</p>
<p>This blog post summarizes the knowledge Uwe shared in his talk
as a starting point for new driver authors (and users of existing drivers).</p>
<div class="section" id="how-to-toggle-pins-automatically-fast">
<h3>How to toggle pins automatically (fast)</h3>
<p>Pulse Width Modulation, or PWM for short,
refers to a periodic square wave signal and is used for applications such as</p>
<ul class="simple">
<li>dimming (or blinking) LEDs</li>
<li>driving display backlights at a controllable brightness level</li>
<li>controlling motor speeds (e.g. a fan)</li>
<li>remote controls</li>
</ul>
<p>Of course, you could theoretically toggle GPIOs in software as fast as possible to generate a PWM
signal,
but for most applications,
this would not only cause quite some CPU load,
but also introduce quite some unwanted jitter in the PWM signal due to interruptions of the task
performing the toggling by higher priority tasks.</p>
<p>Instead, most SoCs have dedicated hardware units,
which basically increment a counter at each tick of a clock source
and drive outputs based on the counter value.
Once a preconfigured counter value is reached,
a pin is automatically switched on,
without any additional software interaction.
When another preconfigured value is reached,
the pin is automatically switched off,
the counter is cleared and everything automatically starts all over again.</p>
</div>
<div class="section" id="how-shall-i-compare-thee-to-another-pwm">
<h3>How shall I compare thee to another PWM</h3>
<p>Since a PWM is,
in a nutshell,
just a square wave signal,
we can describe it with only a few properties:</p>
<ul class="simple">
<li><tt class="docutils literal">period</tt> [ns], i.e. the time between rising edges</li>
<li><tt class="docutils literal">duty_cycle</tt> [ns], i.e. active time in a period</li>
<li><tt class="docutils literal">polarity</tt> (normal or inverted)</li>
<li><tt class="docutils literal">enable</tt> / <tt class="docutils literal">disable</tt></li>
</ul>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/abstract_pwm.svg" itemprop="contentUrl">
<img alt="Abstract PWM" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/abstract_pwm.svg" style="
width: 700px;
"/>
</a><figcaption itemprop="caption description" style="
"><p>An abstract PWM signal</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>For some use cases it can be useful to set an inverted <tt class="docutils literal">polarity</tt>, which
swaps the active and inactive level. For example, this is useful for a
backlight that has a higher brightness for lower duty cycles.</p>
<p>When a PWM is enabled, the square wave waveform is generated,
when it is disabled, the waveform generation is stopped.</p>
</div>
<div class="section" id="kernel-view-on-a-pwm">
<h3>Kernel view on a PWM</h3>
<p>If a driver in the Linux kernel is a PWM consumer,
i.e. it needs to parameterize a PWM,
the previous description of a PWM signal is used to pass the request to the PWM
device driver,
which in turn has to calculate and write the corresponding values to the PWM
hardware.</p>
<p>The <a href="https://docs.kernel.org/driver-api/pwm.html">PWM Subsystem</a>
bundles the properties in a structure, which is called the <tt class="docutils literal">pwm_state</tt>.
As <tt class="docutils literal">period</tt>s and <tt class="docutils literal">duty_cycle</tt>s tend to be rather short and kernel
interfaces tend to be built around integer numbers, nanoseconds (<tt class="docutils literal">[ns]</tt>)
are used as units of time:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">struct</span><span class="w"> </span><span class="nc">pwm_state</span><span class="w"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">u64</span><span class="w"> </span><span class="n">period</span><span class="p">;</span><span class="w"> </span><span class="c1">// [ns]</span>
<span class="w"> </span><span class="n">u64</span><span class="w"> </span><span class="n">duty_cycle</span><span class="p">;</span><span class="w"> </span><span class="c1">// [ns]</span>
<span class="w"> </span><span class="k">enum</span><span class="w"> </span><span class="n">pwm_polarity</span><span class="w"> </span><span class="n">polarity</span><span class="p">;</span>
<span class="w"> </span><span class="kt">bool</span><span class="w"> </span><span class="n">enabled</span>
<span class="w"> </span><span class="p">...</span>
<span class="p">}</span>
</pre></div>
</div><p>This structure is then passed to or returned by the API functions</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="p">...</span>
<span class="kt">int</span><span class="w"> </span><span class="p">(</span><span class="o">*</span><span class="n">apply</span><span class="p">)(</span><span class="k">struct</span><span class="w"> </span><span class="nc">pwm_device</span><span class="w"> </span><span class="o">*</span><span class="n">pwm</span><span class="p">,</span><span class="w"> </span><span class="k">const</span><span class="w"> </span><span class="k">struct</span><span class="w"> </span><span class="nc">pwm_state</span><span class="w"> </span><span class="o">*</span><span class="n">state</span><span class="p">);</span>
<span class="kt">int</span><span class="w"> </span><span class="p">(</span><span class="o">*</span><span class="n">get_state</span><span class="p">)(</span><span class="k">struct</span><span class="w"> </span><span class="nc">pwm_device</span><span class="w"> </span><span class="o">*</span><span class="n">pwm</span><span class="p">,</span><span class="w"> </span><span class="k">struct</span><span class="w"> </span><span class="nc">pwm_state</span><span class="w"> </span><span class="o">*</span><span class="n">state</span><span class="p">);</span>
<span class="p">...</span>
</pre></div>
</div><p>of a PWM device driver.</p>
<p>When calling its <tt class="docutils literal">.apply()</tt> function, the PWM device driver will calculate the
required register values from the <tt class="docutils literal">pwm_state</tt> properties and write them to
the hardware.</p>
<p>The <tt class="docutils literal">.get_state()</tt> callback does the exact opposite of <tt class="docutils literal">.apply()</tt>:
it reads out the hardware registers and recalculates a <tt class="docutils literal">pwm_state</tt> from the
actual hardware values.</p>
</div>
<div class="section" id="dealing-with-hardware-is-hard">
<h3>Dealing with hardware is... hard</h3>
<p>In an ideal world, the hardware would configure the requested output exactly
and reading it back with
<tt class="docutils literal">.get_state()</tt> would then yield an exact copy of the state passed to <tt class="docutils literal">.apply()</tt>.</p>
<p>In reality,
the hardware often cannot be configured to the exact values requested when
setting a state,
thus calling <tt class="docutils literal">.get_state()</tt> will return a different state from the last values set
with <tt class="docutils literal">.apply()</tt>.</p>
<p>This has a multitude of reasons, some of which Uwe explained in his talk.</p>
<div class="section" id="accuracy-of-values-in-api-and-in-hardware">
<h4>Accuracy of values in API and in hardware</h4>
<p>The hardware counter can only count integer multiples of the time quantum <tt class="docutils literal">q</tt>
of the clock driving it.
The quantum <tt class="docutils literal">q</tt> is the period length of the clock (i.e. the time between two rising edges) and represents
the smallest amount of time that can be adjusted.</p>
<p>Let us for example assume, that we drive our PWM hardware with a 13333 kHz clock.
The quantum <tt class="docutils literal">q</tt> for this clock therefore is 75.001875... ns.</p>
<p>If a PWM consumer now requests a period of 30000 ns,
the driver must select the multiple of the quantum <tt class="docutils literal">q</tt> which best approximates the requested value.
For our example,
this would be either 399 <tt class="docutils literal">q</tt> (= 29925.748 ns) or
400 <tt class="docutils literal">q</tt> (= 30000.750 ns).</p>
<p>So no matter which of the two settings the driver chooses
it will introduce a small,
but inevitable error.</p>
<p>Of course, this principle applies to the duty cycle calculation in the same way.</p>
</div>
<div class="section" id="time-vs-frequency">
<h4>Time vs. frequency</h4>
<p>While for blinking or dimming LEDs,
the exact frequency of the PWM is not of much interest,
some applications such as motor control
require a PWM's frequency to be set as precisely as possible.
Other applications,
such as transmitters for infrared remote controls,
rather require the timing of the PWM to be as precise as possible.</p>
<p>In some corner cases, the rounding strategy determines
which of the requirements is met more precisely.</p>
<p>Assume again an input clock of 13333 kHz,
which gives a quantum <tt class="docutils literal">q</tt> of 75.001875... ns.
As duty cycle and period are multiples of <tt class="docutils literal">q</tt>,
a requested frequency of 1161587 Hz (period = 860.891 ns)
can be approximated by either 11 <tt class="docutils literal">q</tt> or 12 <tt class="docutils literal">q</tt>.</p>
<p>If optimizing for a closer match on the period,
i.e. optimizing for time,
11 <tt class="docutils literal">q</tt> is the better match at 825.021 ns (-35.871 ns off) than
12 <tt class="docutils literal">q</tt> at 900.023 ns (+39.131 ns off).</p>
<p>If optimizing for frequency,
1 / 11 <tt class="docutils literal">q</tt> is the worse match at 1212090.909 Hz (+50503.909 Hz off),
since
1 / 12 <tt class="docutils literal">q</tt> provides the better match at 1111083.333 Hz (-50503.667 Hz off).</p>
<p>As usually the driver author does not know the PWM consumer's requirements,
it is considered best practice to always round down period values,
as this gives at least a consistent behaviour over different drivers.</p>
<p>To further improve the situation for PWM consumers,
Uwe suggests to introduce a new <tt class="docutils literal">.round_state()</tt> callback.
<tt class="docutils literal">.round_state()</tt> would take a state,
calculate which register values would be written in a real <tt class="docutils literal">.apply()</tt> call,
and instead of actually applying the state to the hardware (as <tt class="docutils literal">.apply()</tt> would),
hands the values back to the calculations implemented in <tt class="docutils literal">.get_state()</tt>.</p>
<p>This way, PWM consumers can determine what the actual result of an <tt class="docutils literal">.apply()</tt> call
would be for a given state, which allows them to determine the request that
fits their needs as closely as possible.</p>
</div>
<div class="section" id="precision-of-integer-math">
<h4>Precision of integer math</h4>
<p>As the values in a <tt class="docutils literal">struct pwm_state</tt> are integer values,
special attention has to be paid to the order in which
mathematical operations are executed.</p>
<p>Assume a requested period of 30000 ns, where the driver has
to calculate its period steps as</p>
<p><tt class="docutils literal">period_steps = clkrate / NSEC_PER_SEC * period</tt></p>
<p>If the division is executed as the first operation,
its result will round to 0, and no matter what period is requested,
<tt class="docutils literal">period_steps</tt> will always be 0.</p>
<p>While in this case it is rather obvious that the division needs
to be the last operation executed,
most occurrences in real world drivers are a lot more subtle.</p>
<p>As a general rule of thumb: always divide in the last step,
and only divide once.</p>
<p>Another issue arises from the fact that the clock framework
reports clock rates in Hz rounded to an integer value.</p>
</div>
<div class="section" id="state-transitions">
<h4>State transitions</h4>
<p>When configuring the hardware for a new <tt class="docutils literal">struct pwm_state</tt> by
calling the driver's <tt class="docutils literal">.apply()</tt> function,
the different hardware implementations of PWMs on different SoCs exhibit
a vast set of different behaviours, such as</p>
<ul class="simple">
<li>applying the new state after the current period is finished<ul>
<li>provides a pretty signal</li>
<li>new signal is applied delayed, depending on current position in period and period duration</li>
<li>the apply function may either block or return while the old state is still active</li>
</ul>
</li>
</ul>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/apply_new_state_after_old_period_finished.svg" itemprop="contentUrl">
<img alt="Apply new state after current period has finished" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/apply_new_state_after_old_period_finished.svg" style="
width: 700px;
"/>
</a><figcaption itemprop="caption description" style="
"><p>Calling <tt class="docutils literal">.apply()</tt> at * but finishing current period before applying</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><ul class="simple">
<li>immediately starting a new period with the new values<ul>
<li>causes glitches in the signal</li>
<li>new setting active when <tt class="docutils literal">.apply()</tt> returns</li>
</ul>
</li>
</ul>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/apply_new_state_immediately.svg" itemprop="contentUrl">
<img alt="Apply new state immediately" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-14-03_pulse-width-modulation-is-easy-isn-t-it-turning-it-off-and-on-again/apply_new_state_immediately.svg" style="
width: 700px;
"/>
</a><figcaption itemprop="caption description" style="
"><p>Applying a new state immediately</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><ul class="simple">
<li>mixed settings<ul>
<li>e.g. one cycle with the new period, but with the old duty cycle</li>
<li>usually sensitive to runtime timing behaviour</li>
</ul>
</li>
<li>hardware must be disabled for reconfiguration<ul>
<li>during the reconfiguration, the PWM level is hardware specific</li>
</ul>
</li>
</ul>
</div>
<div class="section" id="further-hardware-limitations">
<h4>Further hardware limitations</h4>
<p>Some hardware implementations cannot output a <tt class="docutils literal">duty_cycle</tt> of 0 or
a <tt class="docutils literal">duty_cycle = period</tt>, i.e. outputting a constant high or low signal.</p>
<p>There is hardware that only supports a fixed <tt class="docutils literal">period</tt>,
on some SoCs multiple PWM units share a common period as they connect to a common counter.</p>
<p>As some hardware has write-only registers for configuring the PWM units,
their drivers do not support <tt class="docutils literal">.get_state()</tt>.</p>
<p>For more hardware limitations, just check the Linux kernel yourself:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>sed<span class="w"> </span>-rn<span class="w"> </span><span class="s1">'/Limitations:/,/\*\/?$/p'</span><span class="w"> </span>drivers/pwm/*.c
</pre></div>
</div></div>
</div>
<div class="section" id="switch-it-off-and-off-again-how-not-to-shut-off-a-pwm">
<h3>Switch it off and off again: how (not) to shut off a PWM</h3>
<p>Most developers assume that for configuring a PWM to generate a
fixed low signal level at the output you can simply</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="n">pwm_get_state</span><span class="p">(</span><span class="n">mypwm</span><span class="p">,</span><span class="w"> </span><span class="o">&</span><span class="n">state</span><span class="p">);</span>
<span class="n">state</span><span class="p">.</span><span class="n">enabled</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">false</span><span class="p">;</span><span class="w"> </span><span class="c1">// <---- Wrong !</span>
<span class="n">state</span><span class="p">.</span><span class="n">duty_cycle</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span>
<span class="n">pwm_state_apply</span><span class="p">(</span><span class="n">mypwm</span><span class="p">,</span><span class="w"> </span><span class="o">&</span><span class="n">state</span><span class="p">);</span>
</pre></div>
</div><p>while this will in most cases generate the intended signal, in some cases it won't.</p>
<p>There are hardware implementations that don't emit the inactive level when disabled, some</p>
<ul class="simple">
<li>freeze the output level at the current output pin state (depending on the current position in the cycle); or</li>
<li>set the output in a high impedance state;</li>
<li>set a (fixed) constant low or a constant high signal at the output thus ignoring the configured polarity;</li>
<li>going to the new output level immediately or after having completed the current period.</li>
</ul>
<p>Instead, setting the <tt class="docutils literal">duty_cycle</tt> to 0 will produce the desired fixed output level
(at least for hardware that allows setting a <tt class="docutils literal">duty_cycle</tt> of <tt class="docutils literal">0</tt>):</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="n">pwm_get_state</span><span class="p">(</span><span class="n">mypwm</span><span class="p">,</span><span class="w"> </span><span class="o">&</span><span class="n">state</span><span class="p">);</span>
<span class="n">state</span><span class="p">.</span><span class="n">enabled</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="nb">true</span><span class="p">;</span>
<span class="n">state</span><span class="p">.</span><span class="n">duty_cycle</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="p">;</span>
<span class="n">pwm_state_apply</span><span class="p">(</span><span class="n">mypwm</span><span class="p">,</span><span class="w"> </span><span class="o">&</span><span class="n">state</span><span class="p">);</span>
</pre></div>
</div><p>As this is a state change nevertheless,
the hardware-specific behaviour for setting the new state
as described in the last section applies.</p>
</div>
<div class="section" id="advice-to-driver-authors">
<h3>Advice to driver authors</h3>
<p>At the end of his talk,
Uwe gave some advice to driver authors.</p>
<p>Besides the already mentioned advice to always round down,
and to do divisions as the last step in a chain of calculations,
Uwe suggests to:</p>
<ul class="simple">
<li>enable the <cite>PWM_STATE</cite> kernel option during tests.
This debugging feature compares the HW state before and after a call to <cite>.apply()</cite> and complains
if either the old state was a better match for the request than the new state,
or if the new state is determined using unexpected rounding.</li>
<li>properly document the hardware's properties,</li>
<li>properly document state transition behaviour as 'Limitations',</li>
<li>link to the hardware manual, which simplifies reviews.</li>
</ul>
<p>Title Image by PiccoloNamek, <a href="http://creativecommons.org/licenses/by-sa/3.0/">CC BY-SA 3.0</a>, via <a href="https://commons.wikimedia.org/wiki/File:RBG-LED.jpg">Wikimedia Commons</a></p>
</div>
</div><p>Part of Uwe Kleine-König's work at Pengutronix is to review PWM
(Pulse Width Modulation) drivers.
In addition, he also sometimes refactors existing drivers
and the Linux kernel <a href="https://docs.kernel.org/driver-api/pwm.html">PWM subsystem</a>
in general.</p>2023-03-14T10:00:00+01:00tag:www.pengutronix.de,2023-03-07:/2023-03-07-rauc-v1-9-released.htmlRAUC v1.9 Released2023-03-07T12:00:22+01:00Enrico Jörns<div class="section" id="rauc-v1-9-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.9 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.9">release page</a></p>
</div>
</div>
<p>"Getting things off the ground" could be the motto for the v1.9 release of
RAUC.
The support for custom metadata in the manifest got a step further,
a new, more flexible, D-Bus API for bundle inspection paved the way for obtaining
more detailed information, and a new manifest hash marks the first of
several planned changes for configurable event logging.
However, one of the most invasive changes happened under the hood:
We have started the transition from autotools to meson as a build system.</p>
<p>For more details on what happened in the 121 (non-merge) commits since v1.8,
read below.</p>
<div class="section" id="custom-meta-data-in-manifest">
<h3>Custom Meta-Data in Manifest</h3>
<p>Beside the mandatory <tt class="docutils literal">compatible</tt>, a RAUC bundle manifest provides a few
pre-defined fields that are not interpreted by RAUC and that you can fill with
your own information, such as <tt class="docutils literal">version</tt>, <tt class="docutils literal">description</tt>, or <tt class="docutils literal">build</tt>.</p>
<p>While these fields are sufficient for many common use cases, there are also
cases where more (structured) meta-data should be included in the bundle.
This meta-data could be used on the target for filtering installations,
displaying additional release information to the user, etc.</p>
<p>As announced in the previous release blog post, RAUC has now
gained basic support for defining custom <tt class="docutils literal"><span class="pre">[meta.<section>]</span></tt> sections in the manifest.
For now, these are just parsed and stored by RAUC.
The plan for the next release is to expose them via <tt class="docutils literal">rauc info</tt> and the
new <tt class="docutils literal">InspectBundle</tt> D-Bus method described below.</p>
<p>A bundle can have multiple <tt class="docutils literal"><span class="pre">[meta.<section>]</span></tt> sections for different purposes.
The <tt class="docutils literal"><section></tt> name can be chosen freely and each meta section can contain a
number of key-values, e.g.:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[update]</span>
<span class="na">compatible</span><span class="o">=</span><span class="s">My Product</span>
<span class="na">description</span><span class="o">=</span><span class="s">Some verbose text</span>
<span class="na">version</span><span class="o">=</span><span class="s">2023.03.1</span>
<span class="na">...</span>
<span class="k">[meta.pengutronix]</span>
<span class="na">location</span><span class="o">=</span><span class="s">Hildesheim</span>
<span class="na">release-notes</span><span class="o">=</span><span class="s">https://example.com/release-nodes-2023.03.1</span>
<span class="na">release-channel</span><span class="o">=</span><span class="s">beta</span>
<span class="k">[meta.vendor]</span>
<span class="na">key</span><span class="o">=</span><span class="s">value</span>
</pre></div>
</div></div>
<div class="section" id="new-inspectbundle-d-bus-api">
<h3>New InspectBundle D-Bus API</h3>
<p>A D-BUS API method in RAUC which has always been quite limited in
functionality is the <tt class="docutils literal">Info</tt> method.
It was aimed to provide the functionality a <tt class="docutils literal">rauc info</tt> call has, but just
took the bundle path as argument and returned the compatible and the version.
This was neither suitable for inspecting remote bundles on HTTP servers with
authentication nor did it allow to return any more information about the
bundle.</p>
<p>Initiated by Stefan Ursella, a new <tt class="docutils literal">InspectBundle</tt> D-Bus method is introduced
in this release.
Similar to the <tt class="docutils literal">InstallBundle</tt> method, this allows passing additional input
arguments as a dictionary (<tt class="docutils literal">a{sv}</tt> in D-Bus type syntax).
It then returns bundle information as a (nested) dictionary.</p>
<p>While for now the returned values are only the <tt class="docutils literal">compatible</tt>, the <tt class="docutils literal">version</tt>,
the <tt class="docutils literal">description</tt> and the <tt class="docutils literal">build</tt>, this is already more information than
the old method provided.</p>
<p>In following releases, it will be extended to return the same information as a
<tt class="docutils literal">rauc info</tt> call, including the custom meta-data described above.</p>
<p>If you want to give the method a try, you can use <tt class="docutils literal">busctl</tt> for a test query:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>busctl<span class="w"> </span>call<span class="w"> </span>de.pengutronix.rauc<span class="w"> </span>/<span class="w"> </span>de.pengutronix.rauc.Installer<span class="w"> </span>InspectBundle<span class="w"> </span>sa<span class="o">{</span>sv<span class="o">}</span><span class="w"> </span><span class="s2">"<bundle-path>/<bundle-url>"</span><span class="w"> </span><span class="m">0</span>
a<span class="o">{</span>sv<span class="o">}</span><span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="s2">"update"</span><span class="w"> </span>v<span class="w"> </span>a<span class="o">{</span>sv<span class="o">}</span><span class="w"> </span><span class="m">4</span><span class="w"> </span><span class="s2">"version"</span><span class="w"> </span>s<span class="w"> </span><span class="s2">"1.0"</span><span class="w"> </span><span class="s2">"compatible"</span><span class="w"> </span>s<span class="w"> </span><span class="s2">"qemu86-64 demo platform"</span><span class="w"> </span><span class="s2">"build"</span><span class="w"> </span>s<span class="w"> </span><span class="s2">"20230306231217"</span><span class="w"> </span><span class="s2">"description"</span><span class="w"> </span>s<span class="w"> </span><span class="s2">"qemu-demo-bundle version 1.0-r0"</span>
</pre></div>
</div></div>
<div class="section" id="manifest-hash">
<h3>Manifest Hash</h3>
<p>Surprisingly, answering the question if a specific bundle is actually the one
installed on a system was not straight-forward so far.
The slot status information saved on the target contained the checksums of the
images installed as well as some manifest information such as version or build
ID.
None of these fully described the bundle's manifest and content, though.</p>
<p>This gap was closed by introducing the <em>manifest hash</em>.
The manifest hash is defined as the (SHA-256) hash calculated over the
manifest.
This hash securely identifies all the manifest fields and, since (for 'verity'
bundles) the verity hash is also part of the manifest, it also identifies the
entire bundle contents.</p>
<p>To actually allow using the manifest hash for identifying bundles, it is
printed when using <tt class="docutils literal">rauc info</tt>, saved in RAUC'S slot status file, and is
exposed via <tt class="docutils literal">rauc status <span class="pre">--detailed</span></tt> and the <tt class="docutils literal">GetSlotStatus</tt> D-Bus method.</p>
<div class="row"><div class="col-sm-6">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="846x445" href="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-info-manifest-hash.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-info-manifest-hash.thumb.9b5bbeefd412eb3bb6d4f612902eb7dd.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>The manifest hash displayed in <tt class="docutils literal">rauc info</tt></p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div><div class="col-sm-6">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="872x598" href="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-status-manifest-hash.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-status-manifest-hash.thumb.32048914c47180a49018574317c59e20.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>The manifest hash displayed in <tt class="docutils literal">rauc status <span class="pre">--detailed</span></tt></p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div></div><p>The manifest hash is the first simple enhancement in a number of planned
features aimed to allow better tracing of RAUC installations on the target.
Some more details are described in
<a class="reference external" href="https://github.com/rauc/rauc/issues/1070">issue #1040</a>.</p>
</div>
<div class="section" id="configurable-boot-attempts-for-barebox">
<h3>Configurable Boot Attempts (for Barebox)</h3>
<p>With <tt class="docutils literal"><span class="pre">boot-attempts</span></tt>, RAUC allows configuring the reset attempts value
written to the bootloader's attempts variable in case of a 'mark good'.
So far, this was supported for the U-Boot backend only.
This release now adds support to configure reset attempts for barebox, too:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[system]</span>
<span class="na">...</span>
<span class="na">bootloader</span><span class="o">=</span><span class="s">barebox</span>
<span class="na">boot-attempts</span><span class="o">=</span><span class="s">5</span>
<span class="na">boot-attempts-primary</span><span class="o">=</span><span class="s">10</span>
</pre></div>
</div><p>A patient user, who had their boot-attempts configured to a value >= 10, might
have run into the issue that some U-Boot environment variables were still
erroneously handled as decimal numbers.
Thanks to Christian Meusel, this if fixed now.</p>
</div>
<div class="section" id="target-vs-host-tool-usage-enhancements">
<h3>Target vs Host Tool Usage Enhancements</h3>
<p>The RAUC binary can be used as both a host tool (for bundle generation) and a
target tool (for installation).
This has its advantages, but is not always clearly separated and may cause some
confusion.</p>
<p>A long-standing message that caused confused, e.g. when calling <tt class="docutils literal">rauc bundle</tt>
from within a container, was:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rauc-Message: 04:13:16.008: Failed to resolve realpath for '/dev/mapper/vg01-root'
</pre></div>
</div><p>This was printed as the RAUC startup routines attempted to find out where we
the system was booted from.
While this step is necessary on the target, it's useless on the development host.
Finally, with <a class="reference external" href="https://github.com/rauc/rauc/pull/1059">#1059</a>, a clearer
separation of host- and target-related setup handling made this message
disappear and also paved the way for other enhancements.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="814x571" href="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-help-host-target.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-03-07_rauc-v1-9-released/rauc-help-host-target.thumb.5a5f86d5d09a000c22ec0604a8f09e1b.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Output of <tt class="docutils literal">rauc <span class="pre">--help</span></tt> configured with <tt class="docutils literal"><span class="pre">-Dcreate=off</span></tt></p>
</figcaption>
</figure>
</div><p>With v1.9, the separation of host and target tool usage is now also reflected
in the output of <tt class="docutils literal">rauc <span class="pre">--help</span></tt> that now has a distinct section for
target-related subcommands as <tt class="docutils literal">service</tt> or <tt class="docutils literal">install</tt>.</p>
<p>The ongoing process of removing the subcommand-specific options from the
global argument list continued as well:
The <tt class="docutils literal"><span class="pre">--intermediate</span></tt> option is now enabled for signing subcommands only.
Some previous changes in this area were reflected in the man page, as well.</p>
</div>
<div class="section" id="meson-build-system-support">
<h3>Meson Build System Support</h3>
<p>Over the years we have encountered several pitfalls, inconveniences and over-
complicated handling with the autotools build system, especially when
generating release artifacts.
The plan to switch to a state-of-the art build system has now finally been
realized with the switch to the <em>meson</em> build system.</p>
<p>To simplify the transition for users, we have decided to keep autotools support
for this release and to drop it in 1.10, unless there are good reasons to keep
it for longer.</p>
<p>For those building RAUC from source manually, this requires a bit of
muscle-memory reconfiguration:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>meson<span class="w"> </span>setup<span class="w"> </span>build
$<span class="w"> </span><span class="nb">cd</span><span class="w"> </span>build
$<span class="w"> </span>meson<span class="w"> </span>compile
</pre></div>
</div><p>(For all others, this change will probably not visible).</p>
<p>One of the benefits of using meson is that the available build configuration
options are now clearly visible and documented in <a class="reference external" href="https://github.com/rauc/rauc/blob/master/meson_options.txt">meson_options.txt</a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As the tar archive generated by meson does not contain a configure
script, you may need to run autogen.sh to generate it.
To simplify the migration, we also provide a -autotools archive variant
which is generated using autotool's make dist (and does not contain the
meson build support).</p>
</div>
</div>
<div class="section" id="documentation-and-ecosystem">
<h3>Documentation and Ecosystem</h3>
<ul class="simple">
<li>Since the question about bundle compatibility comes up from time to time, we
have added a <a class="reference external" href="https://rauc.readthedocs.io/en/latest/faq.html#is-the-rauc-bundle-format-forwards-backwards-compatible">FAQ entry</a>
describing our understanding and approach.</li>
<li>RAUC is used by several Open Source community projects that can serve as
an example or starting point.
To point new users into the right direction, we have added some of them
(such as <a class="reference external" href="https://github.com/rauc/meta-rauc-community">meta-rauc-community</a> for OpenEmbeeded/Yocto or
<a class="reference external" href="https://github.com/cdsteinkuehler/br2rauc">br2rauc</a> for Buildroot) to the
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/examples.html#example-integrations">example integrations</a>
section in the documentation.
If we have overlook anything here, please feel free to add it.</li>
<li>Those who submitted an issue since v1.8 might have already noticed:
We added GitHub issue templates to better guide users to open an issue or to
use <a class="reference external" href="https://github.com/rauc/rauc/discussions">discussions</a> depending on
the case.
Also, for pull request we have added a template with some hints on which
information the PR description should contain.</li>
</ul>
</div>
<div class="section" id="thanks">
<h3>Thanks</h3>
<p>Thanks go out to all those who raised questions, inspired new features, gave
others insight into their use-cases, opened issues or PRs, or contributed to
the project in any other form.</p>
<p>A special shout-out to all that directly contributed patches to this release:
Christian Meusel, Enrico Jörns, Jan Lübbe, Jung-Te Hsieh, Stefan Ursella,
Ulrich Ölmann, and Uwe Kleine-König</p>
</div>
</div><p>"Getting things off the ground" could be the motto for the v1.9 release of
RAUC.
The support for custom metadata in the manifest got a step further,
a new, more flexible, D-Bus API for bundle inspection paved the way for obtaining
more detailed information, and a new manifest hash marks the first of
several planned changes for configurable event logging.
However, one of the most invasive changes happened under the hood:
We have started the transition from autotools to meson as a build system.</p>2023-03-07T12:00:22+01:00tag:www.pengutronix.de,2023-02-10:/2023-02-10-chemnitzer-linux-tage-2023.htmlChemnitzer Linux-Tage 20232023-02-10T14:29:12+01:00Robert Schwebel<div class="section" id="chemnitzer-linux-tage-2023">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="197x70" href="https://www.pengutronix.de/media/blog/2023/2023-02-10_chemnitzer-linux-tage-2023/logo_de.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-02-10_chemnitzer-linux-tage-2023/logo_de.thumb.fc38c2bb2c99cb4dfa64e73461f0a322.png"/>
</a><figcaption itemprop="caption description" style="
width: 422px;
"></figcaption>
</figure>
</div><p>After the Corona break, the Chemnitzer Linux-Tage will actully take
place in real life again, and the Pengutronix team will have eight (!)
talks there.</p>
<p>On the first glance this is a bit strange, as the Linux Tage are not
directly a conference about or "core topics", about Embedded Linux and
its use in the industry. But everyone who has been in Chemnitz before
knows the "spirit" of the event, organized by many, many volunteers,
with a lot of engagement and many, many spare time hours. We actually
<em>love</em> the event and are there for many years. And, last but not least,
it is always a good opportunity to meet with community people or even
possible future employees. In the end, we always search vor people who
"live" Open Source, are experienced in the kernel and want to work on
Linux not only in their spare time.</p>
<p>Our team does not only consist of kernel developers, and so our talks
cover many diffeent topics; in the end, we don't only use Linux on our
embedded customer hardware, but everywhere in our daytime business.</p>
<ul class="simple">
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/102">Mach es einfach: Nutze Vim!</a> (Marie Mann, Assistentant of the CEO)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/174">Kameras in Chromium mit PipeWire und xdg-desktop-portal</a> (Michael Olbrich, Graphics Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/188">Einfache VPNs mit Wireguard</a> (Rouven Czerwinski, Kernel Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/193">Der Linux Kernel Entwicklungs-Workflow</a> (Rouven Czerwinski, Kernel Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/265">SSH – Das Schweizer Taschenmesser fürs Netzwerk</a> (Björn Lässig, Admin Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/251">Wenn Geräte an Bäumen wachsen: Linux-Device-Tree-Portierung</a> (Ahmad Fatoum, Kernel Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/228">Heimspiel für deine Daten: Die (einfache) Cloud von zu Hause</a> (Holger Assmann, Integration Team)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/212">Linux-Systeme automatisiert auf echter Hardware testen</a> (Chris Fiege, Hardware Team)</li>
</ul>
<p>We are looking forward to seeing you in Chemnitz!</p>
</div>
<p>After the Corona break, the Chemnitzer Linux-Tage will actully take
place in real life again, and the Pengutronix team will have eight (!)
talks there.</p>2023-02-10T14:29:12+01:00tag:www.pengutronix.de,2023-02-03:/2023-02-03-fosdem-2023.htmlFOSDEM 20232023-02-03T13:56:03+01:00Robert Schwebel<div class="section" id="fosdem-2023">
<p>The Pengutronix team is on it's way to FOSDEM in Brussels! We are looking
forward to many interesting discussions with developers of different open
source software components - be it the Linux kernel, Debian, KiDAC, FreeCAD etc
...</p>
<p>This year, our team has 8 talks at the conference!</p>
<div class="section" id="our-talks-at-fosdem">
<h3>Our Talks at FOSDEM</h3>
<ul>
<li><div class="first line-block">
<div class="line">Ahmad Fatoum:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/sth_to_hide/">Having Something To Hide - Trusted Key Storage in Linux</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Uwe Kleine-König:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/pwm/">Pulse-Width-Modulation (PWM) is easy, isn't it? Turning it off and on again</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Michael Olbrich:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/om_chromium/">Modern Camera Handling in Chromium - Implementing Camera Access with xdg-desktop-portal and PipeWire</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Michael Tretter:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/fpga_bitstreams/">Building FPGA Bitstreams with Open-Source Tools</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Johannes Zink:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/network_time_sensitive/">So you want to build a deterministic networking system - A gentle introduction to Time Sensitive Networking</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Marco Felsch:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/barebox/">barebox, the bootloader for Linux kernel developers</a></div>
</div>
</li>
<li><div class="first line-block">
<div class="line">Enrico Jörns:</div>
<div class="line"><a class="reference external" href="https://fosdem.org/2023/schedule/event/delta_like_ota_streaming/">Delta-like Streaming of (encrypted) OTA Updates for RAUC</a></div>
</div>
</li>
</ul>
</div>
<div class="section" id="at-oe-workshop">
<h3>At OE Workshop</h3>
<ul>
<li><div class="first line-block">
<div class="line">Jan Lübbe:</div>
<div class="line"><a class="reference external" href="https://pretalx.com/openembedded-workshop-2023/speaker/8XBL9U/">Unified Key Access and Code Signing in oe-core</a></div>
</div>
</li>
</ul>
<p>We are lookiing forward to many new contacts!</p>
</div>
</div>
<p>The Pengutronix team is on it's way to FOSDEM in Brussels! We are looking
forward to many interesting discussions with developers of different open
source software components - be it the Linux kernel, Debian, KiDAC, FreeCAD etc
...</p>2023-02-03T13:56:03+01:00tag:www.pengutronix.de,2023-01-30:/2023-01-30-yes-we-can-add-new-features.htmlYes we CAN... add new features2023-01-30T16:23:42+01:00Marc Kleine-BuddeJohannes Zink<div class="section" id="yes-we-can-add-new-features">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2096x2096" href="https://www.pengutronix.de/media/blog/2023/2023-01-17_yes-we-can-add-new-features/candlelight.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-01-17_yes-we-can-add-new-features/candlelight.thumb.70932251756e635f7a6fff4b5cc32ad5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Have you ever experienced an otherwise fine product that
is missing <em>just</em> the one feature you need for your application?</p>
<p>This is what happened when community member John Whittington debugged a CAN bus with
<a href="https://github.com/tuna-f1sh/entree">his own fork</a> of the original
CandleLight Hardware design.
He found that <tt class="docutils literal">candump <span class="pre">-H</span> <span class="pre">-t</span> a</tt> only shows zeros in the hardware timestamp field,
even though the firmware supports timestamping and opened an issue on
<a href="https://github.com/candle-usb/candleLight_fw/issues/100#issue-1341306351">github</a>.
While with conventional closed source products,
this is the point where this story would end,
for an open source project, this is where a journey starts.
So let us have a look on how the firmware and driver of the open hardware project
<a href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00">CandleLight</a>
got hardware timestamping support in a joint effort of community members.</p>
<div class="section" id="some-stuffed-bits-of-history">
<h3>Some stuffed bits of history</h3>
<p>As for all good tales, the CandleLight's story begins quite some time ago.
On Christmas Eve in 2013 (no, I am not kidding you) the first patch to support an
USB-CAN adapter built by the company Geschwister Schneider UG was <a href="https://lore.kernel.org/all/1387913385.3479.5.camel@blackbox">posted
on the Linux-CAN mailing list</a>.
When Hubert Denkmair <a href="https://lore.kernel.org/all/5702C9C9.3050706@xor.wtf">asked in 2016 on the linux-can mailinglist</a>
for an open protocol for USB CAN adapters, Max Schneider himself
<a href="https://lore.kernel.org/all/1459948981.31599.15.camel@schneidersoft.net/">suggested</a>
to use the Geschwister Schneider implementation as a template and just extract
the protocol definition from the existing driver and build a compatible device.
Hubert Denkmair <a href="https://lore.kernel.org/all/a70ea0015a9c896afdfa7be4e7fa1bff@xor.wtf/">was hooked</a> and later published his
<a href="https://github.com/HubertD/candleLight">hardware design</a>
under the CERN Open Hardware License v1.2 and
<a href="https://github.com/candle-usb/candleLight_fw">firmware</a>
under MIT License on Github.
Over the years, several forks of the original design and the original firmware
were added and modified, some featuring different micro-controllers,
adding multichannel support or using USB-C.</p>
</div>
<div class="section" id="hardware-timestamping">
<h3>Hardware Timestamping</h3>
<p>For precise measurements of the timing behavior on a bus or for running
timing protocols on a bus,
it is very important to know the <em>exact</em> point in time when a packet
(or frame, as they are called in the CAN-universe) is transmitted or received.
Most modern Ethernet interfaces and some CAN controllers have this feature,
as it is also used to increase the precision of timing protocols such as the
<a href="https://en.wikipedia.org/wiki/Precision_Time_Protocol">Precision Time Protocol PTP</a>
on Ethernet or the
<a href="https://en.wikipedia.org/wiki/CANopen#Synchronization_Object_(SYNC)_protocol">SYNC protocol</a>
on CANopen.
This requires the hardware handling the packets to do this measurement as close
to the hardware as possible, to minimize jitter in the measurement.
The most common method to achieve this is to have a constantly running hardware
counter, which is latched into a register on the Receive- or
Transmit-complete-interrupt by hardware.</p>
<p>To achieve the lowest possible jitter this latching should be implemented
as a feature of the CAN hardware itself and be sampled at a known point
in the CAN frame.
Sadly the micro-controller in the CandleLight does not support this kind of
extra-low-latency hardware timestamping on its CAN Interface.
The CandleLight firmware can however add timestamps in its CAN receive interrupt
routine, which gives a jitter-performance that is not as good as actual
hardware timestamps but miles ahead of the timestamps Linux can generate
on the other end of the USB connection, where it hat to travel through
several layers of soft- and hardware.
For simplicity's sake we will just call these timestamps generated in the
firmware hardware timestamps to differentiate them from the timestamps
generated in Linux which we will call software timestamps.</p>
<p>To see if your hardware supports timestamping, use <tt class="docutils literal">ethtool <span class="pre">--show-time-stamping</span> <device></tt>
which will list the capabilities of your hardware.
For a CAN interface with hardware timestamping support
the result will for example look like</p>
<div class="code-block">
<div class="highlight"><pre><span></span>>ethtool<span class="w"> </span>--show-time-stamping<span class="w"> </span>can0
Time<span class="w"> </span>stamping<span class="w"> </span>parameters<span class="w"> </span><span class="k">for</span><span class="w"> </span>can0:
Capabilities:
<span class="w"> </span>hardware-transmit
<span class="w"> </span>software-transmit
<span class="w"> </span>hardware-receive
<span class="w"> </span>software-receive
<span class="w"> </span>software-system-clock
<span class="w"> </span>hardware-raw-clock
PTP<span class="w"> </span>Hardware<span class="w"> </span>Clock:<span class="w"> </span>none
Hardware<span class="w"> </span>Transmit<span class="w"> </span>Timestamp<span class="w"> </span>Modes:
<span class="w"> </span>on
Hardware<span class="w"> </span>Receive<span class="w"> </span>Filter<span class="w"> </span>Modes:
<span class="w"> </span>all
</pre></div>
</div></div>
<div class="section" id="teaching-an-old-driver-new-tricks">
<h3>Teaching an old driver new tricks</h3>
<p>While the CandleLight firmware has support for hardware timestamps
<a href="https://github.com/candle-usb/candleLight_fw/commit/56192e76f63d9a0a0e934056a83f7e5a6e47950a">since 2016</a>,
the <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/usb/gs_usb.c">gs_usb driver</a> used for the CandleLight
did not read the timestamps transmitted over USB until recently.
The fact that the firmware with hardware timestamping works with
an older driver is due to a clever trick in the USB protocol:
the protocol has a bit field for indicating additional features.
Hardware timestamps is one of these features,
but as long as said feature is not supported on both sides,
it is simply ignored.
This allows for forward and backward compatibility of new firmware and new driver features.
With some pointers from the maintainers to other drivers implementing hardware
timestamping,
John added the required feature and published it on
<a href="https://github.com/torvalds/linux/compare/master...tuna-f1sh:linux:gs_usb_hwts">github</a>.
This work was also posted on the
<a href="https://lore.kernel.org/all/20220826104629.2837024-1-mkl@pengutronix.de/">linux-can mailing list</a>
and then finally made its way mainline with the 6.1 kernel release.</p>
<p>The results are quite impressive: John shared some measurement results
which show a significant improvement of the hardware timestamps over software timestamps.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3150x1780" href="https://www.pengutronix.de/media/blog/2023/2023-01-17_yes-we-can-add-new-features/measurement_results.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-01-17_yes-we-can-add-new-features/measurement_results.thumb.d27fa511dda9d74ddfcddfe27b83c791.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>In the diagram above the y-axis shows the observed timestamp jitter of the
hardware timestamps on the left vs. the software timestamping performed in
Linux.</p>
</div>
<div class="section" id="sharing-is-caring">
<h3>Sharing is Caring</h3>
<p>Not only did John share his driver patches,
which allows all CandleLight users to also have this new cool feature available,
but he also shared the
<a href="https://gist.github.com/tuna-f1sh/2abe421c2547d41e638253e04e509331">script</a>
used for analysis and plot of the measurement results.
He also presented the technical details and more detailed measurement results in a
<a href="https://engineer.john-whittington.co.uk/programming/2023/01/07/socketcan-gsusb-timestamping.html">post</a>
on his own blog.</p>
<p>This entire story shows the benefits of active participation in open-source development.
Not just using open source projects and making use of other peoples' efforts,
but also adding new features and contributing back to the projects is what makes
our everyday job so great.</p>
</div>
<div class="section" id="outlook">
<h3>Outlook</h3>
<p>This new feature on the gs_usb driver allows for precise timing measurement,
but there is also some other ongoing work in the CandleLight project:</p>
<ul class="simple">
<li>adding CAN-FD to the firmware (the USB protocol already supports CAN-FD)</li>
<li>currently the transmit timestamps are generated when the packet is inserted into the TX FIFO. Using the TX Complete Interrupt will increase their precision even more.</li>
<li>at the moment timestamps have 1µs resolution. The internal micro-controller clock could allow for some more precision, which is to be evaluated.</li>
</ul>
<p>If you want to participate in these tasks, you are more than welcome,
just according to last year's Pengutronix Christmas card motto <em>Send Patches</em>!</p>
</div>
</div>
<p>Have you ever experienced an otherwise fine product that
is missing <em>just</em> the one feature you need for your application?</p>2023-01-30T16:23:42+01:00tag:www.pengutronix.de,2023-01-24:/2023-01-24-kernel-panic-board-on-fire-003-ein-rennen-um-nanosekunden.html[Podcast] Kernel Panic - Board on Fire ~~> #003: Ein Rennen um Nanosekunden - Nebenläufigkeit mit Hardwareeinheiten2023-01-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-003-ein-rennen-um-nanosekunden-nebenlaufigkeit-mit-hardwareeinheiten">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#003: Ein Rennen um Nanosekunden - Nebenl\u00e4ufigkeit mit Hardwareeinheiten", "summary": "Michael Grzeschik und Leonard reden in dieser Folge \u00fcber einen USB-Treiber, der manchmal stecken bleibt, und wie viele Dinge in einem System on a Chip gleichzeitig passieren.", "publicationDate": "2023-01-24T10:10:10+00:00", "duration": "01:04:59", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2023-01-24-kernel-panic-board-on-fire-003-ein-rennen-um-nanosekunden.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/003_rennen_um_nanosekunden.mp3", "size": 93583298, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/003_rennen_um_nanosekunden.mp3", "size": 93583298, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In dieser Folge erzählt Michael Grzeschik die Geschichte eines USB-Controllers,
der dann und wann einfach aufhört zu funktionieren und davon wie er dem Fehler
mit Tracing, einem Disassembler und viel Codelektüre auf die Schliche gekommen ist.
Wir stellen einmal mehr fest, dass Probleme mit Nebenläufigkeit schwierig zu
debuggen sind und nicht nur Software-Software Interaktion betreffen,
sondern manchmal auch Software-Hardware.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Vorstellung und einleitende warme Worte.
Michael beschäftigt sich viel mit der Device-Seite von USB unter Linux.
In letzter Zeit insbesondere mit dem Fall, dass ein Linux Gerät sich verhält
wie eine USB-Webcam und Video an einen anderen Rechner überträgt.
Das gibt ihm sowohl Berührungspunkte mit Kernelthemen, als auch mit Grafikthemen.</dd>
<dt>07:00</dt>
<dd><p class="first">Einleitung der Lagerfeuergeschichte. Beim Bug-Quartett wäre sie mit drei
Zeilen angepasstem Code bei mehreren Wochen Suchzeit eine gute Karte.</p>
<p class="last">Ausgangspunkt ist ein Linux-Computer, der sich einem anderen Computer
gegenüber als USB-Gerät ausgeben sollte.
An diesem sollte er dann ein serielles Kommunikationsinterface bereitstellen,
über das man z.B. eine Linux Commandline benutzen kann.
Nach einigen Stunden Laufzeit blieb allerdings die gesamte Kommunikation
stecken und die USB-Einheit im Gerät ließ sich nicht mehr ansprechen.</p>
</dd>
<dt>11:00</dt>
<dd>Weil das Problem so schlecht reproduzierbar ist war Trial and Error kein
guter Ansatz.
Die Alternative ist erstmal scharfes Hinsehen im Treibercode, um das
Verhalten mit dem Datenblatt zu vergleichen.
Besonderes Augenmerk hat er dabei auf die Datenstrukturen gelegt,
die zwischen dem Treiber und der Hardware ausgetauscht werden.</dd>
<dt>13:00</dt>
<dd><p class="first">Zusammenfassung des bisher gehörten:</p>
<ul class="last simple">
<li>Das Gerät um das es geht spielt die Rolle eines USB-Device, ein anderes
Gerät (z.B. ein Desktoprechner) den USB Host.</li>
<li>Die Übertragungskette ist also Userspace-Software -> Kernel-Treiber ->
USB-Einheit -> Kabel -> USB-Einheit -> Kernel-Treiber -> Userspace-Software.</li>
<li>Der Fehler liegt zwischen Kernel-Treiber und USB-Einheit auf Geräteseite.
In den Treiber kann man hinein schauen, in die USB-Einheit nicht.</li>
</ul>
</dd>
<dt>16:00</dt>
<dd>Weiter mit der Bestandsaufnahme. Es handelt sich nicht um einen der typischen
USB-Fehler, wie einen leer gelaufenen Datenpuffer, die werden nämlich schon
behandelt. Es bleibt wirklich die ganze USB-Einheit hängen.</dd>
<dt>21:00</dt>
<dd>Peripherieeinheiten wie USB oder Netzwerkcontroller werden von Chipherstellern
oft eingekauft und in ihr eigenes Design integriert. So finden sich die selben
Einheiten oft in ganz unterschiedlichen Chips.
Bei USB waren in der Zeit besonders der dwc2 und der Chipidea Controller
relevant.</dd>
<dt>30:00</dt>
<dd>Ansatz um die fehlerhafte Stelle einzugrenzen: Einbau von Tracing in den Treiber,
um Daten aufnehmen zu können im Moment in dem der Fehler tatsächlich passiert.
Das Tracing ergibt, dass die Hardware nach Einhängen neuer Daten stehen
bleibt.</dd>
<dt>39:00</dt>
<dd><p class="first">Der selbe Treiber und die Peripherieeinheit werden auch auf anderen Systemen
genutzt, warum ist es da nicht aufgefallen?
Die CPU in der problematischen Hardware kann Daten nicht unaligned schreiben/
lesen. D.h. wenn z.B. ein 32 Bit Wert aus dem Speicher in ein Register
gelesen werden soll geht das nur dann in einer einzigen Prozessor-Instruktion,
wenn die Speicheradresse (in Bytes) durch vier teilbar ist (also durch 32 Bit).
Ansonsten muss es durch vier einzelne byteweise Reads passieren.
Auf anderen Platformen gibt es mitunter Befehle um auch unaligned in einer
Instruktion lesen/schreiben zu können.</p>
<p class="last">Im disassemblierten Code konnte man sehen, dass die Adresse der nächsten
Datenstruktur als vier einzelne Bytes geschrieben wurde und nicht als ein
32 Bit Wert.</p>
</dd>
<dt>43:00</dt>
<dd>In der Zeit in dem der neue Pointer Byte für Byte geschrieben wird kann die
Hardware vorbei kommen und einen Wert auslesen, der nur teilweise die
richtigen Daten enthält. Weil das Zeitfenster nur ein paar Nanosekunden lang
ist, tritt der Fehler so selten auf.</dd>
<dt>50:00</dt>
<dd>Warum hat der Compiler überhaupt angenommen, dass das Datenfeld nicht auf
32 Bit aligned war? Weil die Datenstruktur extra als <tt class="docutils literal">packed</tt> markiert
war. Mit der zusätzlichen Markierung <tt class="docutils literal">aligned(4)</tt> wird das Feld wieder in
einer Instruktion geschrieben.</dd>
<dt>58:00</dt>
<dd>Mit dem Markieren als <tt class="docutils literal">aligned(4)</tt> ist der
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a9c174302b1590ef3ead485d804a303c5f89174b">Patch</a>
auch quasi schon fertig. Der Vollständigkeit halber fügt er auch noch ein
<tt class="docutils literal">wmb()</tt> (Write-Memory-Barrier) ein, um sicherzustellen, dass der Compiler
das Schreiben der Daten in die Datenstruktur nicht hinter das Einhängen der
Datenstruktur verschiebt.</dd>
<dt>60:00</dt>
<dd>Zusammenfassung und Abschluss</dd>
</dl>
</div><p>In dieser Folge erzählt Michael Grzeschik die Geschichte eines USB-Controllers,
der dann und wann einfach aufhört zu funktionieren und davon wie er dem Fehler
mit Tracing, einem Disassembler und viel Codelektüre auf die Schliche gekommen ist.
Wir stellen einmal mehr fest, dass Probleme mit Nebenläufigkeit schwierig zu
debuggen sind und nicht nur Software-Software Interaktion betreffen,
sondern manchmal auch Software-Hardware.</p>2023-01-24T10:10:10+01:00tag:www.pengutronix.de,2023-01-13:/2023-01-13-dsa-in-barebox.htmlDSA in Barebox2023-01-13T10:06:27+01:00Oleksij RempelJohannes Zink<div class="section" id="dsa-in-barebox">
<p>The <a href="https://lore.pengutronix.de/barebox/20220518125852.GS25578@pengutronix.de/">v2022.05.0 Release</a>
of barebox introduced initial support for the Distributed Switch Architecture
(DSA) Framework.
DSA is originally a
<a href="https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt">subsystem from the Linux Kernel</a>,
which exposes the individual ports of a network switch IC as
virtual network interfaces.</p>
<div class="section" id="switches-on-embedded-devices">
<h3>Switches on Embedded Devices</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3220x3220" href="https://www.pengutronix.de/media/blog/2023/2023-01-13_dsa-in-barebox/switch.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-01-13_dsa-in-barebox/switch.thumb.9b90beb46b7c6df09e8a7bc55774d4c5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>On many embedded devices, switches solve a common issue:
many embedded applications require multiple Ethernet ports on a device,
e.g. for redundant data connection,
or to interface to multiple other devices.
Since many SoCs have only a single Ethernet controller,
switch ICs are used to multiplex the multiple network ports to the on-SoC Ethernet controller.</p>
<p>While for some applications forwarding packets between the external
ports may be acceptable or even desirable,
some applications need the external network ports to behave such as if
they were connected to different network controllers.
This implies that the ports are isolated one from another and traffic is not
forwarded, but all traffic is sent to the SoC only.</p>
</div>
<div class="section" id="switch-support-in-a-bootloader">
<h3>Switch Support in a Bootloader</h3>
<p>Especially kernel developers prefer <a href="https://www.barebox.org/doc/latest/user/booting-linux.html#network-boot">network boot</a>
for loading new kernel or device-tree images to an embedded board.
Not having to flash them on a storage medium saves some more time,
but the most important speedup can be gained by just mounting the root file
system over NFS instead of flashing an image with several MB to a storage device.
After a rebuild, all that is required to use the new images is just a reboot of
the device under test.
In an earlier <a href="https://www.pengutronix.de/en/blog/2017-09-04-ptxdist_did_you_know.html">blog article</a>
we described how this helps developers to get close-to-instant
turnaround times for testing code changes on embedded devices.</p>
<p>While DSA was introduced in the kernel quite some time ago,
handling switches in barebox was quite cumbersome until DSA support was merged.
Previously, custom board code was required to configure the different ports to
whatever modus is required during boot.
Now, it is possible to just
<a href="https://www.barebox.org/doc/latest/user/networking.html">configure IP addresses on the individual ports</a>
and call <tt class="docutils literal">boot net</tt> from the barebox shell,
which tries any available interface to find a server for booting.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="699x398" href="https://www.pengutronix.de/media/blog/2023/2023-01-13_dsa-in-barebox/screenshot_barebox.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2023/2023-01-13_dsa-in-barebox/screenshot_barebox.thumb.8d82211e9f48f909a29d99d487a4b47a.jpg"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div></div>
<div class="section" id="synergy-from-porting-the-subsystem">
<h3>Synergy from Porting the Subsystem</h3>
<p>Because the barebox DSA subsystem is ported from Linux, it uses the same
internal data structures and facilities.
This allows reusing kernel device-tree descriptions of on-board switches for the
switch setup in barebox as well.
Also, porting DSA drivers from the kernel to barebox is simplified by the
fact that the code shares all important data structure definitions.</p>
<p>This shows off one of the unique advantages of barebox: because its
driver model adheres strongly to the Linux driver model, porting device drivers
is as easy as can be, with only minor adjustments now and then.</p>
<p>Already supported are the Microchip KSZ8873, KSZ9477 and KSZ8873 and their
compatible variants as well as the NXP SJA1105, for which the manufacturers
have provided open documentation, which is still quire rare for network
switch ICs. Support for Realtek rtl8365mb and rtl8366rb is on the way and
will land upstream soon.</p>
</div>
<div class="section" id="unexpected-applications-in-the-wild">
<h3>Unexpected Applications in the Wild</h3>
<p>While network-booting embedded boards with switches was originally intended as a feature
to speed up development in our daily work,
some of our customers have found interesting applications of the possibilities
offered by easily setting up network ports as network devices with DSA in
barebox.</p>
<div class="section" id="security-considerations">
<h4>Security Considerations</h4>
<p>With DSA enabled, the switch can easily be configured as desired in a very early
stage of the boot process. Even if the boot process should stall or stop at a
later stage, this means that e.g. ports set to isolation mode won't leak any
traffic to other network ports,
which can reduce the attack surface and therefore increase security.</p>
</div>
<div class="section" id="improving-network-bandwidth">
<h4>Improving Network Bandwidth</h4>
<p>DSA works by adding so-called DSA-tags to network packets,
which are a few bytes with information on which Ethernet port of
the switch the packet shall exit the device.
As kernel protocol stacks are usually optimized to work directly on physical
network interfaces, adding these tags can cause quite some overhead and therefore
limit the usable network bandwidth, on some platforms even by 50%.
Configuring a switch in barebox and completely disabling DSA in the kernel is
for sure not a solution which fits all use-cases,
but for some it can work out quite well and avoid this overhead in the Linux
system.</p>
</div>
<div class="section" id="initial-factory-bring-up">
<h4>Initial Factory Bring-up</h4>
<p>Last but not least,
some of our customers use the DSA support in barebox for chain-loading a bring-up
Linux image in their production line,
which can then load the actual production image via the network and flash it onto
a local storage medium in the device to be provisioned.
As barebox can now easily configure the switch,
the default bootloader and devicetree can be used for this task,
avoiding the need for a custom image and configuration just for initial device bring-up.</p>
</div>
</div>
</div><p>The <a href="https://lore.pengutronix.de/barebox/20220518125852.GS25578@pengutronix.de/">v2022.05.0 Release</a>
of barebox introduced initial support for the Distributed Switch Architecture
(DSA) Framework.
DSA is originally a
<a href="https://www.kernel.org/doc/Documentation/networking/dsa/dsa.txt">subsystem from the Linux Kernel</a>,
which exposes the individual ports of a network switch IC as
virtual network interfaces.</p>2023-01-13T10:06:27+01:00tag:www.pengutronix.de,2023-01-10:/2022-12-21-rueckblick-auf-2022.html2022 at Pengutronix2023-01-10T10:00:00+01:00Leonard GöhrsEnrico JörnsMichael OlbrichJohannes Zink<div class="section" id="at-pengutronix">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x855" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/happy_2022.jpg" itemprop="contentUrl">
<img alt="buntes Feuerwerk vor schwarzem Hintergrund" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/happy_2022.thumb.6e73876b8cd6ec22b20777a9cb54a441.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>At Pengutronix and in the embedded Linux world in general, exciting things happen all year round,
but a carry in the date field is a great opportunity to sit back and talk about it.
In the broad categories of <em>kernel</em>, <em>open source software</em>, <em>hardware</em> and
<em>public relations</em> we want to tell you what happened at Pengutronix in 2022.</p>
<p>Since without it, Pengutronix would only be an <em>embedded … service provider</em>
instead of an <em>embedded Linux service provider</em>, we start with our contributions
to the Linux kernel, especially to the PWM subsystem.</p>
<p>The category "State of the Union our Open Source Projects" is about the bootloader
Barebox and the DistroKit BSP, which have learned to run Raspberry Pi 4 boards in 64Bit mode,
and the PTXdist embedded distribution builder, which has been extended by many
convenience features, e.g. to improve development in IDEs.
Also in this category we are talking about the Lab automation software labgrid,
which can now talk to even more automation hardware and is also being further developed architecturally.
Last but definitely not least, we are happy to find our software updating software
RAUC in various commercial products without our intervention, a good sign for a healthy open source project.</p>
<p>Also in the Pengutronix/Linux Automation GmbH hardware world there have been some developments,
even though the chip-shortage still slows us down a lot.
For example, our decision to mass produce and sell the open hardware project
candleLight (a USB to CAN adapter with excellent Linux driver support) has been well received.
But there has also been some progress with our own developments:
USB to 10Base-T1L Ethernet Adapter and the USB-Mux are now available for purchase
in the <a href="https://shop.linux-automation.com">Linux Automation GmbH shop</a>,
and the LXA TAC is also moving step by step towards market maturity.</p>
<p>The review is rounded off by our
<a href="https://www.pengutronix.de/de/tags/kernel-panic-podcast.html">podcast</a>,
launched at the end of the year,
with scary stories from embedded hardware and software development.
In two episodes so far, you can learn more about speculative execution in processors
(and how it can go wrong) and other tricky bug cases than you (and we) ever wanted to know about.</p>
<div class="section" id="linux-kernel">
<h3>Linux-Kernel</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="265x314" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/Tux.png" itemprop="contentUrl">
<img alt="Linux Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/Tux.thumb.498b4d36db839bc52c9373af03ea3d47.png"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>In the six kernel releases (v5.16 to v6.1) this year, we contributed more than
800 patches for various subsystems.</p>
<p>One change that made it into the kernel towards the end of the year should be
of particular interest beyond the embedded community:
USB support has been added to the Realtek RTW88 driver.
This means that some new WiFi USB sticks are now supported by Linux.</p>
<p>However, it still needs a little patience, because the change will only be part
of the upcoming v6.2 release of Linux.</p>
<p>Another useful change regarding USB has already made it into the v6.0 release:
With the new <tt class="docutils literal">disable</tt> <a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/core/port.c?id=f061f43d7418cb62b8d073e221ec75d3f5b89e17">sysfs interface</a>
individual ports of USB hubs can now be switched on and off in a controlled manner in the kernel.
For hubs that support power switching, the power supply will be switched off.
The latter was previously only isolated with the tool
<a class="reference external" href="https://github.com/mvp/uhubctl">uhubctl</a> possible, but without changing the
port state in the kernel, leading to inconsistent states.</p>
<p>With a follow-up <a class="reference external" href="https://github.com/mvp/uhubctl/pull/450">change</a> we
introduced, uhubctl now also uses the new sysfs kernel interface.</p>
<div class="section" id="pwm">
<h4>PWM</h4>
<p>In 2022, maintenance in the PWM kernel subsystem was characterised by clean-up work and standardisation.
A prominent feature is that the PWM framework now only supports the <a href="https://git.kernel.org/linus/5ec803edcb703fe379836f13560b79dfac79b01d">atomic updates abstraction</a>
for hardware drivers implemented since 2016, which can be used to make configuration changes with a single API call.
This means that (with the appropriate implementation of the hardware driver and the appropriate hardware) unwanted voltage swings can be prevented when reconfiguring the PWM.
In 2022, the legacy of converting all drivers to this model was finally tackled and completed with the change <a href="https://git.kernel.org/linus/0829c35dc5346e90f428de61896362b51ab58296">pwm: Drop support for legacy drivers</a>.</p>
<p>One change that is not yet complete is that users of the PWM API also use the atomic API described above.
This is one of the next goals.</p>
</div>
</div>
<div class="section" id="state-of-the-union-our-open-source-projects">
<h3>State of the Union our Open Source Projects</h3>
<div class="section" id="barebox">
<h4>Barebox</h4>
<p>Barebox is also being diligently developed further and so there are some newly supported boards:</p>
<ul class="simple">
<li>Quartz64 board</li>
<li>BananaPi R2 Pro</li>
<li>Radxa Rock3 board</li>
<li>96Boards Meerkat96</li>
<li>Enclustra AA1</li>
<li>Raspberry Pi4 in 32bit and 64bit mode</li>
<li>PHYTEC phyCORE stm32mp1</li>
<li>InnoComm WB15 i.MX8MM</li>
<li>TQ mba8mpxl</li>
<li>TQMa6UL</li>
<li>MYIR MYD-AM335X</li>
</ul>
<p>Features and improvements:</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/barebox.svg" itemprop="contentUrl">
<img alt="barebox Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/barebox.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>With improved TrustZone support, some newer SoCs can assign individual blocks of their hardware to either the <em>Normal World</em> or the <em>Secure World</em>.
While the bootloader and Linux, for example, run in the Normal World,
access to basic infrastructure such as clocks, resets and regulators can then only take place from the Secure World.
Since drivers in the Normal World still have to communicate with parts of these hardware components,
ARM introduced SCMI (System Control and Management Interface) as a standardised interface.
The drivers in Barebox must therefore also be able to communicate with the Secure World,
e.g. the ARM Trusted Firmware, via the corresponding Secure Montitor Calls, for which corresponding support was added in Barebox.</p>
<p>With the DSA (Distributed Switch Architecture) support in Barebox,
it is now possible to connect a switch to the xMII interface of a SoC and thus
support multiple network ports on a device even in the bootloader, for example for Netboot.
The individual switch ports are represented as separate virtual network interfaces and can have separate network configurations set.</p>
<p>In order to optimally utilise the available network bandwidth for TFTP downloads,
TFTP in Barebox now also supports the <em>windowsize</em> option from RFC7440.
By carefully tuning the parameters, a speedup by a factor of 4-30 can be achieved for TFTP downloads.</p>
<p>Since Python2 has been discontinued for some time, the tools in Barebox are now completely based on Python3.</p>
</div>
<div class="section" id="distrokit">
<h4>DistroKit</h4>
<p>Users of our example BSP <a class="reference external" href="https://www.pengutronix.de/de/software/distrokit.html">DistroKit</a> could look forward to 90 patches in 2022.
In addition to updates to the greatest and latest releases of various
components, DistroKit now supports two more boards: the <em>Raspberry Pi 4</em> and
the <em>Radxa Rock 3-A</em>.</p>
<p>Something has also changed on existing boards: The new FIP boot format is now
supported for the STM32MP1 boards and all ARMv7-A-compatible Raspberry Pi
boards are now supported with the same image, regardless of whether Raspberry
Pi 2, 3 or 4.</p>
</div>
<div class="section" id="labgrid">
<h4>labgrid</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/labgrid.svg" itemprop="contentUrl">
<img alt="labgrid Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/labgrid.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>In the embedded board control library <em>labgrid</em>, we have added resource and driver support for several new use cases this year, including for</p>
<ul class="simple">
<li><a href="https://github.com/labgrid-project/labgrid/pull/933">Devices in DFU mode</a>,</li>
<li><a href="https://github.com/labgrid-project/labgrid/pull/959">Network devices in Android Fastboot state</a> und</li>
<li><a href="https://github.com/labgrid-project/labgrid/pull/996">Proxy support for more power backends</a>.</li>
</ul>
<p>Among a host of bug fixes and other features, labgrid's documentation has been revised and some code samples have since been CI tested.
Under the bonnet, we have switched to <a href="https://github.com/labgrid-project/labgrid/pull/1001">pyproject.toml</a>.
A <a href="https://github.com/labgrid-project/labgrid/pull/1045">CI job for releases</a> should make it easier for us to do more frequent releases in the future.</p>
<p>Next, the <a href="https://github.com/labgrid-project/labgrid/pull/1042">authentication between coordinator, exporter and client will be switched</a>
(the current authentication will remain supported for a while).
This paves the way for us to split dependencies from the coordinator (currently Crossbar) and labgrid itself.
The goal is to allow unpinned dependencies. Version conflicts of dependencies should thus become the exception.</p>
</div>
<div class="section" id="ptxdist">
<h4>PTXdist</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/ptxdist.svg" itemprop="contentUrl">
<img alt="PTXdist Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/ptxdist.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>In addition to the usual maintenance of all the packages, this year there have been improvements in the user experience.</p>
<p>With the new <tt class="docutils literal">ptxdist</tt> subcommands <tt class="docutils literal"><span class="pre">fast-bsp-report</span></tt> and <tt class="docutils literal"><span class="pre">full-bsp-report</span></tt>, yaml files can be created that contain a lot of information about the BSP.
Details about the packages such as version, licence and patches, but also the toolchain used and what images are created.
This can then be used to generate a licence report, for example, with further tooling.
And there is already a <a href="https://github.com/pengutronix/ptxdist-ide-integration">small tool</a>
that retrieves the necessary information from this so that you can develop applications for the BSP with VS code.</p>
<p>For many packages PTXdist now generates a <tt class="docutils literal">compile_commands.json</tt> file.
This can be used by language servers like clangd to find the right headers for example.
This makes editing code with editors and IDEs that use a language server much more comfortable.
The prerequisite for this is that the build system of the package has support for it.
Currently, this includes all CMake and Meson based packages, the Linux kernel and Barebox.</p>
<p>Optionally, PTXdist can now add a so-called MiniDebugInfo section to all binaries.
This is an extremely reduced form of the debug symbols that is just enough to resolve function names.
This allows applications like systemd-coredump to create and log backtraces at runtime, even if the normal debug symbols are missing.
Very practical to store more information in the log in case of errors in the field without having to archive large amounts of data in the form of coredumps.</p>
</div>
<div class="section" id="rauc">
<h4>RAUC</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/rauc.svg" itemprop="contentUrl">
<img alt="RAUC Logo" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/rauc.svg" style="
width: 100px;
"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>For the RAUC update framework managed by Pengutronix, the past year was marked by a series of interesting developments in the area of OTA updates.</p>
<p>Our maintainers, who drive the project forward with a lot of passion,
are particularly proud that RAUC has in the meantime made it into many popular products,
such as <a href="https://www.collabora.com/news-and-blog/news-and-events/portable-linux-gaming-with-the-steam-deck.html#qcom1409">Valve's game console 'Steam Deck'</a>
or, as part of <a href="https://www.heise.de/select/ct/2022/27/2223808321839973008">Linux4ICE</a>, into the displays of the ICEs.</p>
<p>In 478 patches spread over 3 releases, based on the new 'verity' bundle format introduced in 2020, three basic features were implemented:</p>
<p>For the first time, RAUC supports the <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#http-streaming">streaming of update bundles via HTTP(S)</a> without external tools.
This means that the need for a buffer for update artefacts on the target system is a thing of the past.
Since even today transmission bandwidths are still often limited, expensive or unstable,
we have laid the foundation for various methods of delta-like transmission with the concept of <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#adaptive-updates">'adaptive updates'</a>.
The best thing about it:
thanks to RAUC's ability to have random access to the bundle, this is done largely transparently.
With 'block-hash-index', a first method for chunking and differential updates of block device images was created.</p>
<p>Since updates can also contain sensitive data or applications and both
the transport routes and the storage locations for OTA updates cannot always be completely sealed off,
there has often been a wish to be able to transmit encrypted update bundles in RAUC.
This year, this point was also implemented as part of a project.
With <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#bundle-encryption">crypt bundles</a>
updates can now be fully encrypted for a large number of individual recipient systems,
while it remains possible to use them for streaming and "adaptive updates".</p>
</div>
</div>
<div class="section" id="new-hardware-developments">
<h3>New Hardware Developments</h3>
<p>Together with our partner company Linux Automation GmbH, we have expanded our
hardware toolbox, even though development and especially production require a
lot of patience in times of scarce chips and electronic components.</p>
<div class="section" id="candlelights">
<h4>candleLights</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1827x1827" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/candlelight.jpg" itemprop="contentUrl">
<img alt="candleLight" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/candlelight.thumb.0faee0ad5929721d9dad7a8fd0082d49.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>We are a bit surprised by the success of Leonard's video
<a href="https://www.youtube.com/watch?v=JqTBzDN7VOk">"CAN Protocol Reverse Engineering with Wireshark"</a>
and are pleased to receive requests from the community about variants and
improvements relating to the Open Hardware USB-to-CAN adapter <em>candleLight</em>
used there.</p>
<p>For better handling for example, Chris Fiege has designed a <a href="https://linux-automation.com/en/products/candlelight.html">3D printed case</a>.</p>
<div><div class="clearfix"></div></div></div>
<div class="section" id="lxa-tac">
<h4>LXA TAC</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3749x2812" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/lxa-tac.jpg" itemprop="contentUrl">
<img alt="LXA TAC" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/lxa-tac.thumb.0679d06b9a8da241a8ad1a1ac96f3026.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>Those who met us at a trade fair or conference this year may already have caught a glimpse of the
LXA TAC, the <a href="https://www.linux-automation.com/en/products/lxa-tac.html">Linux Automation GmbH Test Automation Controller</a>.
There will also be opportunities to do so at future trade fairs.
However, if you want to catch more than just a glimpse, you will have to be patient for a while,
as the problems with procuring components, which have existed since 2020, will mean that series production will be postponed for a while.</p>
<p>The waiting time until production gives us the opportunity to fine-tune and polish the software side.
So future buyers have a lot to look forward to:</p>
<ul class="simple">
<li>Clean Labgrid integration of the various features.</li>
<li>An open and easily customisable Yocto layer as a basis for your own operating system images, including instructions on how to e.g. deliver your own configuration files directly in the image. (Of course, there will also be official pre-built image.)</li>
<li>A system management daemon that makes the device controllable via web interface and API.</li>
</ul>
</div>
<div class="section" id="usb-mux">
<h4>USB Mux</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1913x1913" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/usb-mux.jpg" itemprop="contentUrl">
<img alt="USB-Mux" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/usb-mux.thumb.ca84163a98cd8d39b075eec620ddc86b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>For a long time it was quiet about our USB Muxes, but as the saying goes,
"What's a long time coming is finally becoming good!"
In December 2022, we received the first devices from production and were able to pass them on to customers.</p>
<p>With the USB Mux, we are expanding our possibilities in test automation to USB interfaces.
More detailed information is available in the <a href="https://linux-automation.com/media/pages/products/usb-mux/Datasheet_USB-Mux.pdf">data sheet</a>.</p>
<p>The production of further devices will follow, so that we will see the USB-Mux in use next year.</p>
</div>
<div class="section" id="usb-t1l-adapter">
<h4>USB-T1L - Adapter</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2223x2223" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/usb-t1l.jpg" itemprop="contentUrl">
<img alt="USB-T1L Adapter" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/usb-t1l.thumb.af3102a272e526287d279c127a5a1ab9.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>The new 10Base-T1L Ethernet standard allows transmission rates of 10MBit/s via a single wire pair.
Those who now feel reminded of the 1980s and the time of vampire terminals can rest assured:
10Base-T1L brings some improvements compared to the technology of yesteryear.
10Base-T1L allows point-to-point Ethernet connections of devices over distances of up to 1.5km-2km with low power requirements.</p>
<p>10Base-T1L is well on its way to becoming the industrial Ethernet standard for long distances.</p>
<p>The USB-T1L adapter is a tool for embedded developers who want to develop 10Base-T1l
based products both in a timely manner and as close as possible to the actual product.
For this purpose, the USB-T1L is designed as a firmware-less device and the Linux kernel
of the connected device itself takes over the control and configuration of the 10Base-T1L Phy installed on the device.</p>
<p>A special feature of the USB-T1L is that it is our first in-house produced device for external sale.
The USB-T1L is the device with which we inaugurated our new Pick & Place machines.
This purchase will enable us to produce prototypes faster in the future and speed up our development cycles.
Fingers crossed that component availability will also improve soon.</p>
</div>
</div>
<div class="section" id="podcast">
<h3>Podcast</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="591x591" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/podcast.png" itemprop="contentUrl">
<img alt="Der Pengutronix Pinguin steht vor einem Mikrophon" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/podcast.thumb.941e5c7ea39d61a2409897e105225b35.png"/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div><p>On the way to multimedia world domination, we can now report another milestone in addition to our blog,
microblogging and our <a href="https://www.youtube.com/pengutronix">YouTube channel</a>: our own podcast!</p>
<p>The podcast "Kernel Panic - Board on Fire" (a reference to the dreaded Linux "kernel panic",
single board computers and the infamous error message "lp0 on fire")
is about telling campfire stories from the world of embedded software and hardware.</p>
<p>These campfire stories are, for example, about months of troubleshooting through
the various subsystems of a device to finally find the right "working bit".
Since the code changes from these searches are often inconspicuous one-liners,
we want to highlight the search process with all its twists and turns in the podcast.</p>
<table class="docutils field-list" frame="void" rules="none">
<col class="field-name"/>
<col class="field-body"/>
<tbody valign="top">
<tr class="field"><th class="field-name" colspan="2"><a class="reference external" href="https://www.pengutronix.de/data/kernel_panic/001_speculative_execution.mp3">Episode 1</a> - 2022-11-24 "Speculative Execution and an Execute Never Bit":</th></tr>
<tr class="field"><td> </td><td class="field-body">Ahmad Fatoum tells a story that starts with trying to turn on a device's backlight
while it's still in the bootloader, then gets lost in the idiosyncrasies of executing
programs on processors for a few months, and finally results in a handful of lines of code.</td>
</tr>
<tr class="field"><th class="field-name" colspan="2"><a class="reference external" href="https://www.pengutronix.de/data/kernel_panic/002_watchdogs_poe_and_wad.mp3">Episode 2</a> - 2022-12-24 "Watchdogs and (Not So) Ideal Components":</th></tr>
<tr class="field"><td> </td><td class="field-body">Leonard Göhrs tells about a device that restarts now and then,
and how he found the various reasons that are not the cause of this problem.
It's about watchdogs, overtemperature, less than ideal electrical components
and also a bit about reverse engineering on the hardware level.</td>
</tr>
</tbody>
</table>
<p>Unfortunately, this podcast is only available in German language.</p>
</div>
<div class="section" id="send-patches">
<h3>Send Patches</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="917x813" href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/title.jpg" itemprop="contentUrl">
<img alt="Ein Aufnäher mit einem Tux und einer Sprechblase, auf der
" itemprop="thumbnail" patches"="" send="" src="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/title.thumb.4da00d415dac2df3fe2dd009f079b072.jpg" steht"=""/>
</a><figcaption itemprop="caption description" style="
width: 100px;
"></figcaption>
</figure>
</div>
<div class="ptx-sidebar">
<div class="title">
Sources
<div class="corner"></div>
</div>
<div class="body">
<table border="1" class="docutils">
<colgroup>
<col width="30%"/>
<col width="70%"/>
</colgroup>
<tbody valign="top">
<tr><td>data sheet:</td>
<td><a href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/Send_Patches_Datenblatt.pdf">Send_Patches_Datenblatt.pdf</a></td>
</tr>
<tr><td>embroidery file (DST):</td>
<td><a href="https://www.pengutronix.de/media/blog/2022/2022-12-21_rueckblick-auf-2022/Send_Patches_Schrift60erGarn_1St.DST">Send_Patches_Schrift60erGarn_1St.DST</a></td>
</tr>
</tbody>
</table>
</div>
</div>
<p>The motto of our Christmas greeting this year was "Send Patches".
For this, Anna from <a href="https://kleinerwolkendrache.de">Atelier *Kleinerwolkendrache*</a>
created a wonderful patch.
In our open-source spirit we want to share the sources with you.</p>
<div><div class="clearfix"></div></div><p>The entire Pengutronix team wishes all customers, contributors, hackers and
friends of the Linux world domination a good and successful start into 2022!..</p>
<p>... and as few off-by-one errors as possible!</p>
</div>
</div>
<p>At Pengutronix and in the embedded Linux world in general, exciting things happen all year round,
but a carry in the date field is a great opportunity to sit back and talk about it.
In the broad categories of <em>kernel</em>, <em>open source software</em>, <em>hardware</em> and
<em>public relations</em> we want to tell you what happened at Pengutronix in 2022.</p>2023-01-10T10:00:00+01:00tag:www.pengutronix.de,2023-01-03:/2022-12-21-weston-vnc.htmlWeston, VNC Server2023-01-03T10:46:02+01:00Philipp Zabel<div class="section" id="weston-vnc-server">
<p>In March last year I gave a <a href="https://embedded-recipes.org/2022/talks/weston-multi-backend-screen-recording-streaming-and-remote-control/">talk about our work on the Wayland
compositor Weston</a>
at the Embedded Recipes conference, and demonstrated using multiple backends
simultaneously.
A single Weston instance provided content to a range of different outputs, e.g.:</p>
<ul class="simple">
<li>with the DRM backend to a local monitor (actually, in the live demonstration
this was replaced with a Wayland backend window),</li>
<li>with the new VNC backend via the <a href="https://www.rfc-editor.org/rfc/rfc6143">Remote Framebuffer Protocol</a> to a computer running a
VNC-client.</li>
<li>with the new PipeWire backend to a separate PipeWire application, allowing to
encode the output for video streaming or store it into a file.</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="660x535" href="https://www.pengutronix.de/media/blog/2022/2022-12-13_weston-vnc/weston-vnc-client.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-12-13_weston-vnc/weston-vnc-client.thumb.349102fdfa3c4da6b27e5f68fe9b1ee0.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Screenshot Weston VNC server via TigerVNC client</p>
</figcaption>
</figure>
</div><div class="section" id="current-mainline-status">
<h3>Current Mainline Status</h3>
<p>While the necessary building blocks for multi-backend support and output via
PipeWire - apart from already merged preparatory work
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/577">!577</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1064">!1067</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1078">!1078</a>)
- are still under review or being worked on
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/578">!578</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/879">!879</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1071">!1071</a>,
<a href="https://gitlab.freedesktop.org/pH5/weston/-/tree/multi-backend-pipewire">multi-backend-pipewire</a>),
the VNC backend has been merged into the main branch
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/880">!880</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1022">!1022</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1021">!1021</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1070">!1070</a>).</p>
<p>This allows running a Weston compositor without a local display, which listens
e.g. on port 5900 for connections from a VNC client. Thanks to the <a href="https://github.com/any1/neatvnc">Neat
VNC</a> server library, which the VNC backend is
based on, TLS encryption and authentication using the local user account are
supported:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>weston --backend vnc --width 1024 --height 768 --vnc-tls-cert tls.crt --vnc-tls-key tls.key
</pre></div>
</div><p>The necessary TLS key and certificate can be prepared just like for the already
included RDP backend, which allows to transmit an output to a Windows PC via the
Remote Desktop Protocol. Here is an extract from "man weston-vnc":</p>
<div class="code-block">
<div class="highlight"><pre><span></span>openssl genrsa -out tls.key 2048
openssl req -new -key tls-key -out tls.csr
openssl x509 -req -days 365 -signkey tls.key -in tls.csr -out tls.crt
</pre></div>
</div></div>
<div class="section" id="outlook">
<h3>Outlook</h3>
<p>Apart from multi-backend support, further changes to the VNC backend are in
flight, to reduce latency by letting the VNC client draw the cursor locally
(<a href="https://github.com/any1/neatvnc/pull/67">#67</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/984">!984</a>),
to allow using the OpenGL-renderer with the VNC backend
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/881">!881</a>),
or to improve configuration of the framebuffer size
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1072">!1072</a>).</p>
<p>We're still working on making the pending changes easier to review, and to get
them merged piece by piece, to finally have a main branch with a Weston
compositor capable of both displaying to a local monitor and being remotely
controlled via VNC:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>weston --backend drm,vnc --vnc-tls-cert tls.crt --vnc-tls-key tls.key
</pre></div>
</div><p>In the slightly more distant future lie possible improvements making use of
hardware acceleration.
For example, the Weston VNC backend could <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/880#note_1575260">directly pass</a>
OpenGL renderbuffers into Neat VNC, which could implement hardware accelerated JPEG
or h.264 compression.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/sTStJ2WwVLY"></iframe>
</div>
</div>
</div>
<p>In March last year I gave a <a href="https://embedded-recipes.org/2022/talks/weston-multi-backend-screen-recording-streaming-and-remote-control/">talk about our work on the Wayland
compositor Weston</a>
at the Embedded Recipes conference, and demonstrated using multiple backends
simultaneously.
A single Weston instance provided content to a range of different outputs, e.g.:</p>2023-01-03T10:46:02+01:00tag:www.pengutronix.de,2022-12-24:/2022-12-24-kernel-panic-board-on-fire-002-wachhunde-und-nicht-so-ideale-bauelemente.html[Podcast] Kernel Panic - Board on Fire ~~> #002: Wachhunde und (nicht so) ideale Bauelemente2022-12-24T10:10:10+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-002-wachhunde-und-nicht-so-ideale-bauelemente">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#002: Wachhunde und (nicht so) ideale Bauelemente", "summary": "Chris und Leonard reden in dieser Folge \u00fcber Watchdogs und andere Gr\u00fcnde aus denen Ger\u00e4te pl\u00f6tzlich neustarten.", "publicationDate": "2022-12-24T10:10:10+00:00", "duration": "01:04:22", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-santa-rund.png", "link": "/de/blog/2022-12-24-kernel-panic-board-on-fire-002-wachhunde-und-nicht-so-ideale-bauelemente.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/002_watchdogs_poe_and_wad.mp3", "size": 68688309, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/002_watchdogs_poe_and_wad.mp3", "size": 68688309, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In der zweiten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem
ich mich ausnahmsweise mal selbst beschäftigt habe.
Damit ich mich dazu nicht selbst ausfragen muss springt netterweise Chris als
Gastinterviewer ein.
Problem dieses mal ist ein Gerät, das dann und wann einfach neu startet, und
wieder einmal könnte die Ursache sowohl in der Software als auch in der
Hardware zu finden sein.
Es folgt eine Suche durch die verschiedenen möglichen Ursachen für Neustarts
von Geräten, die uns an Watchdogs, Übertemperatur, den Eigenheiten von PoE,
WAD pins und Dioden vorbei zur Lösung führt.
Und wieder einmal steht die Größe der Änderung in keiner Relation zur
vorherigen Suche.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden Zeitmarken
orientieren:</p>
<dl class="docutils">
<dt>00:00</dt>
<dd>Chris und Leonard fachsimpeln über LoRa, Gatways und Minimum Viable Products.
Es soll ein Prototyp eines LoRa Gateways gebaut werden um die Anforderungen
und Problemstellungen kennenzulernen.</dd>
<dt>08:40</dt>
<dd>Wie entwickelt man Software für ein eingebettetes System?
Hersteller-BSP/-Kernel/-Bootloader vs. Mainline - Vor- und Nachteile.
Was unterscheidet Yocto von "normalen" Linux-Distributionen?</dd>
<dt>12:15</dt>
<dd>LoRaWAN-Software Semtech Forwarder vs. Chirpstack.</dd>
<dt>13:40</dt>
<dd>Das eigentliche Problem - das Gerät läuft nicht durch sondern power-cycled
nach zwei Stunden.</dd>
<dt>15:00</dt>
<dd>Möglicher Grund für neustartendes System:
1. Ein Watchdog schlägt zu und startet es neu.</dd>
<dt>27:30</dt>
<dd>Möglicher Grund für neustartendes System:
2. Die CPU/ein anderes IC schaltet wegen Übertemperatur ab</dd>
<dt>30:15</dt>
<dd>Möglicher Grund für neustartendes System:
3. Sich falsch verhaltender PoE-Injector</dd>
<dt>34:15</dt>
<dd>Auf den PoE-Leitungen zeigen sich komische Effekte wie z.B. dann und wann
einbrechende Versorgungsspannung.
Aber: das periodische Neustarten tritt auch auf wenn die PoE-Spannung aus
einem stabilen Netzteil kommt.</dd>
<dt>39:00</dt>
<dd>Der PoE-IC auf dem Gerät selber schaltet die Versorgungsspannung ab.</dd>
<dt>42:15</dt>
<dd>Ursache des Abschaltens ist der WAD (Wall Adapter) Pin des PoE-IC,
der bei angeschlossenem Netzteil die PoE-Versorgung abschalten soll.
Allerdings ist kein Netzteil angeschlossen.</dd>
<dt>49:15</dt>
<dd>Grund für die Spannung am WAD-Pin ist das Aufladen der Eingangskapazität über
rückwärts durch eine Diode fließenden Leakage-Strom.
Durch einen Widerstand nach GND kann der Leakage-Strom abgeleitet werden.</dd>
<dt>57:00</dt>
<dd>Meldung an den Hersteller. Der WAD-Pin und einmal dort gewesener Widerstand
nach GND wird im Changelog der Boardrevision erwähnt, die wir haben.
Der Widerstand wurde bewusst entfernt.</dd>
<dt>60:00</dt>
<dd>Abschluss. Wieder einmal hat sich gezeigt: "Always check your voltages".
Erst die Spannungsversorgungen anschauen bevor man nach komplexeren Problemen
sucht.</dd>
</dl>
</div><p>In der zweiten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem
ich mich ausnahmsweise mal selbst beschäftigt habe.
Damit ich mich dazu nicht selbst ausfragen muss springt netterweise Chris als
Gastinterviewer ein.
Problem dieses mal ist ein Gerät, das dann und wann einfach neu startet, und
wieder einmal könnte die Ursache sowohl in der Software als auch in der
Hardware zu finden sein.
Es folgt eine Suche durch die verschiedenen möglichen Ursachen für Neustarts
von Geräten, die uns an Watchdogs, Übertemperatur, den Eigenheiten von PoE,
WAD pins und Dioden vorbei zur Lösung führt.
Und wieder einmal steht die Größe der Änderung in keiner Relation zur
vorherigen Suche.</p>2022-12-24T10:10:10+01:00tag:www.pengutronix.de,2022-12-14:/2022-11-07-netdevconf-0x16.htmlNetdevconf 0x162022-12-14T23:42:00+01:00Johannes Zink<div class="section" id="netdevconf-0x16">
<p>After a longer time with online-only events, the <em>Netdev 0x16</em>,
a conference about the technical aspects of Linux Networking,
was organized as hybrid event: online and on-site at Lisbon.</p>
<div class="section" id="day-1">
<h3>Day 1</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1694x3234" href="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/netdevconf_banner.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/netdevconf_banner.thumb.bc1dfcc0db06cb2ee1c67c2b118fe93a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>As for other conferences, the <em>Netdev 0x16</em> is about exchanging ideas with other
developers.
Even before the start of the actual conference program with discussion rounds and
breakout sessions,
discussions are already started at the coffee tables in the foyer.
Not surprisingly, the availability of network hardware without open documentation
is a considerable challenge for developers and end users alike
The often non-public documentation of hardware components poses a challenge to
projects like <a href="https://www.dent.dev">DENT</a> or
<a href="https://www.openvswitch.org/">Open vSwitch</a>
who often face severe challenges when having to providing hardware support beyond
the reference platforms.</p>
<p>Often, the hardware that is actually deployed in the field is running Linux,
but often very old kernel versions are deployed,
which cannot be updated due to firmware blobs or non-standardized</p>
<p>The developers at Netdev agreed that a selection of well-documented switch ICs in
documented switch ICs in various performance classes and from different
manufacturers, and good support for this hardware in mainline Linux would be ideal.
This would improve the situation for both manufacturers of whitebox hardware,
i.e generic hardware modules, as well as for manufacturers of end devices,
as for endusers in the field, which could then benefit from up-to-date and well-
maintained software.</p>
<div class="section" id="introduction-to-time-synchronization">
<h4>Introduction to time synchronization</h4>
<p>In the first session of the day, Maciek Machnikowski explained the precise
time synchronization of multiple systems over a network connection using PTP.
The "Precision Time Protocol", or PTP for short, is standardized in IEEE1588
and allows configuration-free synchronization of several systems over a network
with nanosecond accuracy</p>
<p>After an introduction into the motivation, Maciek briefly introduced the different
components in a Linux system that are responsible for the precise acquisition of
time (the so-called PTP Hardware Clock, or PHC for short),
as well as the different paths,
over which in the Kernel the information necessary for the PTP-Daemon are transported
to user space.</p>
<p>Maciek dedicates a larger part of his talk to practical examples and tools
from the ptp4l suite:</p>
<ul class="simple">
<li><tt class="docutils literal">ptp4l</tt>, the main daemon that handles the synchronization of the Leader- and
Follower-Clock (for the elderly among us: Grandmaster and Slave)
and is responsible for handling of the Best Master Clock Algorithm BMCA.</li>
<li><tt class="docutils literal">ts2phc</tt>, with which Time Events, e.g. the PHC on Pulse per Second (PPS) Events
from a precise clock (e.g. a GNSS receiver) to the PTP hardware clock
can be synchronized.
<tt class="docutils literal">ts2phc</tt> also supports the parsing of NMEA strings sent by GNSS receivers
sent over UART for obtaining the Time of Day.</li>
<li><tt class="docutils literal">phc2sys</tt> to synchronize the system time to the PTP hardware clock.</li>
<li><tt class="docutils literal">pmc</tt> to read debugging information from the various components.</li>
<li><tt class="docutils literal">timemaster</tt> to synchronize PTP and NTP.</li>
<li><tt class="docutils literal">phc_ctl</tt> to debug the PTP hardware clock.</li>
</ul>
<p>After this very practical part, Maciek briefly discusses the differences of the
various profiles of PTP that are supported in ptp4l.
He explains that all practical relevant profiles are supported in ptp4l,
but that a few features are subject to certain restrictions.</p>
<p>At the end of his talk, Maciek uses a simple setup as an example to briefly
explain the limitations and common difficulties of setting up PTP
and gives a short outlook on the upcoming release of ptp4l 4.0.</p>
<p>After the lunch break, the topics of the talks on the agenda are only of limited
importance for embedded applications,
but nevertheless they give a good overview of the variety of requirements in the
network subsystem of the Linux kernel.</p>
</div>
<div class="section" id="p4tc-your-network-datapath-will-be-p4-scripted">
<h4>P4TC - Your Network Datapath Will Be P4 Scripted</h4>
<p>In this workshop, Jamal Hadi Salim explained the basics of P4 and the
integration of P4 into the Linux kernel as P4TC.
P4 stands for the "Programming Protocol-independent Packet
Processors" ecosystem,
a programming language for Packet Forwarding Planes in network devices,
i.e. a programming language, which can be used to describe how
network packets can be forwarded directly in hardware to their destination,
without generating CPU load.</p>
<p>While P4 has been around for some time and has become an industry standard
for the description of the Packet Forwarding Plane,
no direct support for it is so far available in the kernel.
With P4TC the kernel is now to be extended by the possibility -analogous to BPF-
to load external P4 scripts.</p>
<p>These are compiled in combination with a description of the hardware Capabilities
such that as many tasks as possible can be performed in hardware,
typically Smart NICs, Neural Accelerators or Mesh Processors,
while the remaining tasks are performed transparently in software.</p>
<p>Another motivation for the initiators of the project at Intel was to use P4TC
for implementing traffic control features without having to compile kernel modules,
since that is not possible in the data center environment for various reasons.</p>
<p>Furthermore, this would save the time-consuming mainlining of the Traffic Control,
though this aspect was met with a divided response in the subsequent discussion.</p>
<p>There was also a need for further discussion from the ranks of the FRR,
since for an efficient efficient implementation,
the hardware offloading should be used for frequent routes,
while there is often no room in the limited hardware resources for less
frequently used ones.
In order to make best use of the available hardware offloading resources,
a communication channel between the routing daemon in the user space and P4TC
will be required, probably by extending the offload flag in switchdev.</p>
</div>
<div class="section" id="rdma-programming-tutorial">
<h4>RDMA programming tutorial</h4>
<p>In the last talk of the day, Roland Dreier used examples to explain the
the basics of Remote DMA and the programming of applications against
this framework.</p>
<p>RDMA is a feature that originates primarily from the Big Data and data center
world.
It allows the transfer of memory contents over the network without the CPUs of
the target device having to explicitly execute code.
RAM is therefore accessed remotely via the network, similar to a local DMA access.</p>
<p>After an introduction about the different forms of Asynchronous queues, Roland gave
an overview of their integration into the various subsystems of the kernel and into
the abstractions used.</p>
<p>Since different implementations exist in Layer 2 and Layer 3, the use of RDMA is no
longer limited to the probably most popular implementation Infiniband.
With rxe a soft-roCE implementation is available in the kernel,
which can be used over ordinary Ethernet.</p>
<p>After a short overview of the userspace libraries librdmacm for the connection
setup and libibverbs for the actual requests and datapath operations,
Roland demonstrated with some code snippets how to connect an application
to the memory with a local process or to a remote device's memory via RDMA.</p>
<p>For details he recommended to study the examples from the repository
<cite>RDMA Core <https://github.com/linux-rdma/rdma-core></cite></p>
</div>
</div>
<div class="section" id="day-2">
<h3>Day 2</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4640x3472" href="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_city.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_city.thumb.061aa757f4624efa08b81329812cc614.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>The second day of NetDev 0x16 started with a workshop on XDP.
The Express Data Path is a possibility to use eBPF (extended Berkeley Packet
Filter) in order to decide whether network packets should be discarded or
forwarded at a very early stage after the receive interrupt.</p>
<p>In addition, packets can bypass a large part of the network stack directly into
user space. This increases performance for special applications with high throughput.</p>
<p>The workshop presented the latest changes and developments in this environment,
such as Dynamic Pointers by Joanne Kong from Meta,
who has implemented a implemented a way to interact with data,
whose size is not yet known at the compile time of a BPF program.</p>
<p>Other topics, like the XDP_Hints for adding metadata to XDP buffers,
or the work of Zhan Xue (Intel) who uses XDP_REDIRECT to packets directly
into hardware accelerators (e.g. for cryptography) were also discussed.</p>
<p>From an embedded developer's perspective, the latter approach is very exciting.
Applications such as feeding video streams over the network directly into
hardware video codecs with only little CPU intervention sounds very promising.</p>
<p>It is yet unclear, if all required infrastructure is already available for such
applications, but nevertheless it is quite exciting to thing about possible future
system designs with this approach.</p>
<p>Once again, the strength of doing development in a vibrant community is very
obvious. Experts from different backgrounds come together and collaborating
on the design and implementation of the subsystem, covering lots of different
requirements due to their widespread expertise.</p>
<p>The coffee breaks at the conference offer a valuable addition to the otherwise
usual discussions on the mailing lists and provide a more direct and rapid
exchange of opinions, experience and ideas</p>
<p>Today, for example, I had the rare opportunity to talk to some developers who
work on TSN (Time Sensitive Networking), just like me,
about the latest developments on FRER (Frame Replication and Duplicate
Elimination for Reliability) and implementation variants of recent RFCs (Request
for Comments) from the DetNet (Deterministic Networking) working groups at the IETF
on redundant data transmission of real-time networks.</p>
<div class="section" id="frr-workshop">
<h4>FRR Workshop</h4>
<p>In the second session of the day, the developers of FRRouting showed the
current developments and improvements to the Free Routing Protocol Suite.
Mobashshera Rasool from VMWare presented the design decision and the
Support for MLD (Multicast Listener Discovery) and PIM (Protocol Independent
Multicast), which are now available for IPv4 and IPv6 via the pimd daemon in
FRR.
The technical substructure required for this has been available since kernel
version 4.19.</p>
<p>Thanks to the work of Dr. Olivier Dugeon at Orange Innovation Networks
FRR now also supports segment routing.
This allows a list of segment identifiers to be attached to a network packet
that determine the packet's path through the network.
In contrast to regular routing algorithms, this allows multiple ring-free
paths to be spanned through a network,
for example to send redundant packets over multiple routes,
which is a common implementation to address failure of links in real-time
applications.
Segment Routing is already being implemented in various commercial routers,
and their implementation is fully compatible with the implementation in FRR.</p>
<p>There are also interesting usecases of this for embedded. When combined with
DetNet, this can for example be used to explicitly create redundant Real-time
links in a network.
I am pretty sure it won't be long until segment routing is spotted in the wild
for these kinds of applications.</p>
<p>Finally, Donald Sharp gave an overview of the current developments
and a preview of the features in the next FRR release.
In addition to many incremental improvements, bug fixes and a continuous
increased code quality, he particularly mentioned the efforts of Donatas
Abraitas who merged the continuous changes in the BGP (Border Gateway
Protocol) into FRR.</p>
</div>
<div class="section" id="network-view-of-embedded-specific-challenges-for-non-embedded-network-developers">
<h4>Network view of embedded specific challenges for non-embedded network developers</h4>
<p>After lunch, Oleksij Rempel from Pengutronix gave two talks.
In "Network view of embedded specific challenges for non-embedded network
developers" Oleksij gave an overview of various practical examples
on the everyday work of a kernel hacker with a focus on embedded hardware.</p>
<p>Oleksij first introduced the differences between embedded and non-
embedded applications.
Although the boundaries are becoming increasingly blurred,
there are quite a few more specific restrictions such as power constraints or
maximum connection initialization times for embedded applications.
Analogous to the softening of the boundary between embedded devices
and non-embedded devices, field busses and on-board busses, such as CAN,
are also increasingly becoming replaced by Ethernet.</p>
<p>Nevertheless, it turns out that embedded use cases often dictate very different
requirements than conventional IT use cases.
As an example, Oleksij mentions the fq_codel queuing discipline,
which can be used well for TCP, but turns out to be very problematic when used
for CAN buses.
Since Linux is increasingly being used in embedded applications,
developers need to be sensitized for the special requirements of this environment
as well as for standard IT networks.</p>
<p>As another example, Oleksij introduces the various field buses in the
automotive environment, of which only CAN is mainline,
which are increasingly being replaced by Ethernet.
Due to the different requirements, however, deviating sub-standards,
such as Base-T1 over twisted pairs are used instead of conventional Base-TX.
These requirements are mostly related to the costs, performance and
energy consumption.
Some applications also have special timing requirements.
For example, autonegotiation cannot be used for automotive applications,
because this process takes too long,
a link must be activated within a few milliseconds.
Existing configuration interfaces must be expanded for this.</p>
<p>Oleksij mentions explosion-protected areas as another example.
In these, the amount of energy in a system is limited to a specific amount,
which also poses special challenges for network connections.
With 10Base-T1L the amplitude of the link can be limited to 1.0Vpp,
which allows use in a potentially explosive environment.
Support for this standard has recently been added to the kernel,
but require changes, for example to establish connections with remote stations
prevent announcing the 2.4Vpp links in the autonegotiation.</p>
<p>Another example is a special implementation variant for
link redundancy, where several Phys are connected to one MAC.
There is no suitable abstraction for this in the kernel, which is why
there is an ongoing discussion about this on the mailing list.
Another variant of this application is the connection of several Phys to one
MAC to be able to support different standards in layer 1.</p>
<p>Similar challenges arise from the communication chains of
MDIO links for SFP cages.</p>
<p>Using these examples, Oleksij shows which effects these special requirements
have in the kernel.
Some of them can be met by extending already existing interfaces,
however, it is sometimes necessary to create completely new interfaces in the kernel.</p>
</div>
<div class="section" id="implementing-cooperative-link-diagnostics-by-using-dusty-corners-of-ieee-802-3-specification">
<h4>Implementing cooperative link diagnostics by using dusty corners of IEEE 802.3 specification</h4>
<p>In his second talk immediately afterwards, Oleksij explains,
how Link Diagnostics can be implemented in Ethernet.
Link Diagnostics,
i.e. the detection of errors in the physical links,
such as defective cables, plugs, etc.
is often not considered an important feature by hardware manufacturers.
The contributions to this in the kernel therefore mostly come from individual contributors,
often hobbyists.
However, this feature is urgently needed in many applications.
Oleksij explains that there are many different failure modes
(Short circuits, ground faults, cable breaks, etc. of the various cable wire pairs).</p>
<p>With the command</p>
<blockquote>
ethtool -t eth0</blockquote>
<p>a self-test of MAC and PHY can be performed.
It switches the phy into loopback mode, which works in a current kernel.
This allows errors in the path between MAC and PHY to be detected.</p>
<p>with the command</p>
<blockquote>
ethtool --cable-test eth0</blockquote>
<p>a basic cable test can be performed.</p>
<p>The command</p>
<blockquote>
ethtool eth0 | grep -i sqi</blockquote>
<p>can be used to determine whether the phy connected to eth0 supports measuring
the signal quality Index (SQI).</p>
<p>The self-test can be expanded in terms of its functionality,
which, however, requires a means of communication with the link partner.</p>
<p>Furthermore, cable tests usually only work well if the remote station
is switched off, otherwise the Fast Link Pulses (FLPs) of the
Autonegotiation disturb the measurement.</p>
<p>To show how this problem can be solved,
Oleksij explains how a cable test using Time Domain Reflectometry (TDR) works.
For this purpose, a pulse is applied to a cable by the phy,
whose propagation and reflection the phy measures.
The measurement result can be used to distinguish between cable breaks,
short circuits or earth faults and correctly functioning cables.
The sampling rate of the Phys determines the precision of the measurement,
A measuring accuracy of 80 cm is usual.</p>
<p>Oleksij continues to explain,
that the link autonegotiation also uses pulses on the link,
which can distort the measurement results of the TDR.</p>
<p>Oleksij suggests adding the autonegotiation flag "remote fault" to the fast link
Pulses, which forces a transmission pause in the autonegotiation.
In the resulting silence, a measurement could be taken with TDR.
Because the autonegotiation pulses operate at a lower frequency than the
regular Ethernet link, there is a high probability
that this message arrives at the remote station
even with a certain degree of damage to the link.
In the link code word of the FLP of the autonegotiation, bit 13("RF) and bit 15
("NP") are used for this.
The RF flag (Remote Fault) indicates a general error,
the NP flag ("Next Page") is used to add further pages,
to communicate more precise requirements.</p>
<p>A vendor specific message would have to be used for this.</p>
<p>Oleksij has sent a first
<a href="https://lore.kernel.org/all/20220608093403.3999446-1-o.rempel@pengutronix.de/">patch</a>
to the netdev mailinglist and invites all listeners to review it and join the discussion.</p>
</div>
<div class="section" id="we-ve-got-realtime-networking-at-home-why-many-systems-are-moving-to-tsn-so-slowly">
<h4>"We've got realtime networking at home" - Why many systems are moving to TSN so slowly</h4>
<p>At the end of this day,
I had the pleasure to give my own talk.
In this talk I summarized the basic requirements for real-time networks:
time synchronization, maximum (bounded) transmission delays and quality of
service, i.e. the guaranteed transmission of prioritized content.</p>
<p>I then explained how conventional Ethernet implementations tried to fulfill these
requirements and compared them to TSN (Time Sensitive Networking).
I then discussed, which strategies can be used to systematically migrate systems
in the brownfield until a system is fully TSN capable.</p>
<p>At the end of my talk, I motivated the developers to add more documentation,
examples and tests.
This could help system engineers and end users and enables them to use these new
technologies.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/rpf1_JXztOY"></iframe>
</div>
<p>After the end of the talks, at the social event I took the chance to exchange
ideas with maintainers and developers and got to know the people behind the names
of the mailing list postings.</p>
</div>
</div>
<div class="section" id="day-3">
<h3>Day 3</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2104x2928" href="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_tram.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_tram.thumb.4f8513473ffec0eeb42b1f8b66a1ff1a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>The third day of Netdevcon is dedicated to data center networking.
Although the requirements for this application are significantly different from
most embedded use cases,
the talks on these topics nevertheless offer an exciting look beyond the horizon.</p>
<div class="section" id="it-s-time-to-replace-tcp-in-the-datacenter">
<h4>It's Time to Replace TCP in the Datacenter</h4>
<p>In his keynote, John Ousterhout presented that even though
TCP is used very widespread, it is actually relatively unsuitable for data
center applications.</p>
<p>He shows in detail that the basic properties of the protocol are
diametrically opposed to the fundamental requirements of this relatively
special workload.
He postulates that this means it is impossible to enhance TCP such that it
provides the performance required for datacenter applications.</p>
<p>From the results of his research, his working group developed the HOMA protocol.
He discussed the advantages of HOMA over TCP in detail,
and presented some quite astonishing measurement results.
Even though HOMA does not use hardware offloading yet, it already shows
significant improvements over TCP for typical data center workloads.
More than one order of magnitude can be achieved,
but he concludes that to achieve the line rate,
i.e. the theoretically available bandwidth,
Hardware offloading in the network cards is also necessary for HOMA.</p>
</div>
<div class="section" id="homals-tunneling-messages-through-secure-segments">
<h4>HomaLS: Tunneling messages through secure segments</h4>
<p>In the follow-up talk, Tianyi Gao shows how HOMA segments can be encrypted
analogous to DCTCP segments.
He presents a prototype of his implementation for hardware offloading on
Mellanox CX16 and presents first measurements.
His prototype already achieves 20% improvement compared to the usual DCTCP
implementations.</p>
</div>
<div class="section" id="dcpim-lowlatency-highthroughput-receiverdriven-transport-protocol">
<h4>dcPIM: Low–latency, High–throughput, Receiver–driven Transport Protocol</h4>
<p>In the subsequent talk, the authors give a first outlook on the challenges for
Link speeds >200Gbps, so-called terabit links.
Based on measurements, it was made clear that the main source of latencies
is the residence time in switches.
With terabit Ethernet, small network packets only need a few microseconds
to be sent, which is why the switch queues have a significant impact on data throughput.
Because the architecture of data centers and the data flows there are quite
similar to the coarse architecture of a switch, Qizhe Cai and Rachit Agarwal suggest
to solve this issue with a method already used in Ethernet switches.
They suggest extending Parallel Iterative Matching to the Datacenter, which introduces the
datacenter Parallel Iterative Matching (dcPIM).
dcPIM is an algorithm to for an iterative process to calculate the optimal
assignment of data streams to links and resources.</p>
<p>Since the mathematical model behind PIM it is well researched and since the
algorithm converges quickly and no changes to the protocols or APIs used are required,
the authors assume that this approach can be deployed easily.</p>
<p>After so much theory with many usecases that are rather far from the usual embedded ones
in my daily work, some interesting contacts and discussions arose over lunch,
among other things with developers from the WiFi stack, who end up in a joint review
of a 5 year old proof of concept code that applies surprisingly well to the
current multi-link extensions in the current iterations of the WiFi standards.</p>
</div>
<div class="section" id="bring-network-and-time-together-using-linux-tracing">
<h4>bring network and time together using Linux tracing</h4>
<p>After the lunch break, Alexander Aring showed in his talk how to record time-
synchronized traces from different
physical or virtual machines of a computer cluster with trace-cmd.
The result can be converted to slog2sdk format and analyzed using jumpshot,
to simplify e.g. analysis of the DLM lock protocol in a GANTT-like representation.</p>
</div>
<div class="section" id="inkernel-fast-path-performance-for-containers-running-telecom-workload">
<h4>In–Kernel Fast Path Performance For Containers Running Telecom Workload</h4>
<p>Nishanth Shyamkumar, Piotr Raczynski, Dave Cremins, Michal Kubiak
and Ashok Sunder Rajan demonstrated,
how a conventional setup of a 4G base station running proprietary software
on proprietary hardware with proprietary operating systems (which is in the
default telecommunications industry since many years) can be migrated to run
on commodity hardware, using Docker to run the software for multiple base stations
on a single hardware instance.
The main challenge was the efficient connection of the individual containerized
subsystems to the network hardware of the host system,
which could be solved well with SRIOV and AF_XDP zero copy.</p>
<p>This allows to operate the infrastructure on significantly cheaper hardware
and save time and cost when rolling out and operating mobile communications
infrastructure.</p>
<p>The result of their work also applies for embedded usecases,
where containers are seen more frequently nowadays.
This makes the 20-fold increase in performance they achieved in comparison to
the initial trivial implementation quite exciting.</p>
</div>
<div class="section" id="linux-kernel-networking-acceleration-using-p4ovs-on-ipu">
<h4>Linux kernel networking acceleration using P4–OVS on IPU</h4>
<p>Sandeep Nagapattinam, Nupur Uttarwar, Venkata Suresh Kumar and Namrata Limaye
showed in their talk how P4 can describe offloading of accelerating features,
which are then implemented in an Infrastructure Processing Unit (IPU).
They demonstrated, how this technique can achieve significant performance gains for
Layer2 forwarding, routing and VxLAN.</p>
<p>The throughput targeted by them will probably never be required for embedded usecases,
but it is nevertheless exciting to see how companies successfully work around the
saturation of silicon performance caused by the physical limits to Moore's law.</p>
</div>
<div class="section" id="high-performance-programmable-parsers">
<h4>High Performance Programmable Parsers</h4>
<p>The last talk of the day by Tom A. Herbert showed an interesting solution to a problem,
which can also often be observed in embedded projects.
Quite often network packets have to be parsed,
i.e. the individual fields in a data frame need to be analyzed,
in order to extract all necessary information from a packet.</p>
<p>The necessary software, a so-called parser,
is usually implemented manually,
which is a very laborious and therefore lengthy and prone-to-error process.</p>
<p>In his talk, Tom shows how the CPL,
the Common Parser Language,
can be used to describe a protocol declarativly in a json file.
From this description,
a parser can then be generated that uses the
kparser infrastructure in the kernel for parsing network packets.
In combination with XDP and eBPF,
an incoming packet can be examined easily and efficiently.
Depending on the results it can the either be dropped,
forwarded to the network stack
or directly forwarded to a userspace recipient via the Express Data Path.</p>
<p>Finally, Tom shows how hardware offloading via P4 can be integrated to this
infrastructure.
There are, however, still some issues to be solved.
I'm curious to see if we will soon be able to use this technology
in one of our customers' projects and how much development time this
will save our customers.</p>
</div>
</div>
<div class="section" id="day-4">
<h3>Day 4</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3327x4516" href="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_port.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_port.thumb.35b362544afeea4e468396935d7fe122.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>The fourth day of NetDev 0x16 had talks addressing many different networking
related topics, which gave a good overview on the variety of topics one can
encounter when dealing with networking.</p>
<div class="section" id="when-regular-expressions-meet-xdp">
<h4>When regular expressions meet XDP</h4>
<p>In the first talk of the day, Ivan Koveshnikov explained how he
implemented DDoS protection for game traffic with regex in XDP at GCore.
Since this application requires to parse many small UDP packets with very regular structures,
Ivan choose to use regex.</p>
<p>For regex matching he uses the BSD-licensed engine Hyperscan,
which is also often used for deep packet inspection and is already optimized for
high-performance scanning of network packets.
For an efficient implementation of Regex in eBPF programs he needed to patch the kernel
due to the size of the regex and because of eBPF's availability limitations
of Vector Instructions (XDP runs in a SoftIRQ context where the FPU
instructions are not available).
Ivan explains that they therefore save and restore the FPU state
in SoftIRQs, which however requires to turn off interrupts and preemptions as
soon as FPU load/store instructions be used.
As a result, the Vector instructions are also available and the regex parser can
run very efficiently in an eBPF helper.</p>
<p>For configuration one can either use eBPF maps,
which already bring synchronization with them
but enforce a fixed size of the entries and are application specific,
or entries in a configfs.</p>
<p>Because of the greater flexibility of a configFS Ivan decided to choose this
Implementation variant.</p>
<p>He also presented some benchmarks,
for XDP_DROP (i.e. for dropped packets) and XDP_TX
(i.e. for forwarded packets).</p>
<p>For packets larger than a few hundred bytes of payload,
their implementation can drop invalid packets "at line rate",
i.e. as fast as the connected network,
but forwarding of valid packets is somewhat more complex and therefore less efficient.</p>
<p>Ivan still sees room for improvement here,
although the new system is already being successfully used in production.</p>
<p>At the end of his talk, Ivan calls on network card manufacturers to
improve the interaction of XDP with hardware offloading,
since the drivers often only have DPDK (Dataplane Development Kit) support,
but no or only insufficient support for XDP is provided.
He sees the XDP hints in particular as a possible way
to improve this situation.</p>
<p>Ivan uploaded his code to <a href="https://github.com/G-Core/linux-regex-module">Github</a>
and suggests to the listeners to take their own measurements.</p>
</div>
<div class="section" id="towards-s-tail-latency-and-terabit-ethernet-disaggregating-the-host-network-stack">
<h4>Towards µs Tail Latency and Terabit Ethernet: Disaggregating the Host Network Stack</h4>
<p>In the subsequent talk, Qizhe Cai, Midhul Vuppalapati, Jaehyun Hwang,
Christos Kozyrakis, and Rachit Agarwal present their research results.
After upgrading their network lab from 10GBit to aggregated 100GBit links they
discovered that the basic structure of the Linux network stack imposes severe
limitations on the performance for fast links.</p>
<p>The underlying architecture with a pipeline concept is difficult to optimize,
since having long-lived data flows as well as short data bursts would require
changes in many different places,
which also have cross-dependencies.</p>
<p>They therefore suggest to change the underlying basic architecture to something
similar to the Linux Storage Subsystem which has loosely coupled layers.</p>
<p>Their first prototype,
which they published on <a href="https://github.com/Terabit-Ethernet/NetChannel">Github</a>,
already achieves very impressive increases in performance compared to
the current mainline implementation.</p>
</div>
<div class="section" id="the-anatomy-of-networking-in-high-frequency-trading">
<h4>The Anatomy of Networking in High Frequency Trading</h4>
<p>After this unusual proposal, PJ Waskiewicz presented the specific requirements
for network infrastructures in high-speed trading.
Even though high frequency trading is very secretive and hides behind a veil of trade secrets,
PJ was able to give the broad outlines of this very unusual world to his listeners.</p>
<p>While the connection to the stock exchanges still uses conventional 10Gbps
Ethernet links,
the decisions about the purchases and sales are made in High performance computing clusters,
in which the corresponding inference models are run partly in software,
partly in hardware.</p>
<p>In both cases high performance,
low latency,
but especially deterministic and predictable latency of
Network communication is absolutely essential
to avoid waiting times.
These would ultimately lead to poorer results in the financial transactions.</p>
<p>On the OS side, PJ showed that
optimizations quite similar to what we often build into many embedded applications,
for example
the use of RT_PREEMPT,
cpu isolation,
interrupt pinning,
choosing suitable CPU power states etc.
improve not only the average case and median,
but also the worst case performance significantly.</p>
<p>I was surprised to learn that for this special purpose the
loss of determinism through the SoftIRQs in the receive path
is simply circumvented by permanent polling.</p>
<p>For the high performance computing clusters, RDMA still prevails
as the communication medium of choice, often via Infiniband.
PJ is hoping to see more performance improvements by io_uring and XDP in particular,
since it nowadays becomes increasingly difficult
to find experienced developers and administrators for these technologies.
Besides having to provide training on it for younger engineers and administrators,
Infiniband is extremely expensive because it is an absolute niche product.
PJ therefore raises the question,
to what extent RoCE or iWARP can meet their requirements,
especially with converged networks
(i.e. in mixed operation with conventional Ethernet traffic).</p>
<p>New protocols like HOMA are being watched with great interest in the industry,
however, investigation whether they meet the low a latency and low jitter
requirements are still ongoing.</p>
</div>
<div class="section" id="merging-the-networking-worlds">
<h4>Merging the Networking Worlds</h4>
<p>After this interesting and special talk,
David Ahem and Shrijeet Mukherjee gave a talk about
how to combine Berkeley Sockets,
in particular for access to the Control Plane,
with RDMA or verbs-based communication in the data plane.
They argue that combining the advantages of both worlds for
high-performance data transmission could benefit the network stack significantly.</p>
<p>After the various talks in which the replacement of the "old world" by
better upcoming approaches were demanded,
is this approach of merging different parts of
well-functioning and well-known established approaches for infrastructure
looks very promising,
at least from the perspective of a veteran network programmer.
Evolution instead of revolution.</p>
</div>
<div class="section" id="fixing-tcp-slow-start-for-slow-fat-links">
<h4>Fixing TCP slow start for slow fat links</h4>
<p>Maryam Ataei Kachooei presents the results of her research on
the optimization of TCP congestion control for communication over
geostationary and low-orbit satellites.</p>
<p>The algorithms that TCP uses to match the available packet sizes and
data rates to the link's capabilities by default do not scale well for satellite links.
This is probably mainly due to the comparatively long packet round trip times over the
satellite link.
However, with her research, Maryam was able to find sets of parameters that achieves
significantly better performance for these algorithms.</p>
</div>
<div class="section" id="the-tsn-building-blocks-in-linux">
<h4>The TSN building blocks in Linux</h4>
<p>After this rather special topic,
Ferenc Fejes from Ericsson Research Traffic Lab gave a
brief introduction to the various standards for Time Sensitive
Networking and a detailed overview of the current status of
the individual components' implementation in Linux.</p>
<p>He not only showed the kernel components used,
but also provided the associated userspace interfaces for configuration
as well as options for hardware offloading.</p>
<p>In addition to his own measurements for some of the components,
he showed examples for configuration settings and discussed the remaining open issues,
for example the missing network configuration daemons and services.</p>
<p>In his opinion, self-tests and verification tools need to be implemented
and provided as open source,
in order to support users during development, commissioning, and verification of setups.</p>
<p>Finally, Ferenc underlined once again
that the TSN-capable switch hardware is already supported in the switchdev
and DSA frameworks today,
which makes them first class citizens.
He also added, that the hardware offloading features already work well with the existing
infrastructure, even though not every device has all their hardwareoffloading implemented yet.</p>
</div>
<div class="section" id="towards-a-layer3-datacenter-fabric-with-accelerated-linux-evpn-on-the-dpu">
<h4>Towards a layer–3 data–center fabric with accelerated Linux E–VPN on the DPU</h4>
<p>In the following talk Roopa Prabhu and Rohith Basavaraj demonstrated,
how they implemented hardware offloading for E-VPN in the Data Processing Unit DPU,
a hardware accelerator from Nvidia,
and achieved quite astonishing performance improvements.</p>
</div>
<div class="section" id="state-of-the-union-in-tcp-land">
<h4>State of the union in TCP land</h4>
<p>For the last talk of the day,
Eric Dumazet summarized the developments of the last year in the Linux TCP stack.
Amongst some security fixes,
most work done mostly concerns performance improvements.</p>
</div>
<div class="section" id="kernel-selftests-und-switch-testing">
<h4>Kernel Selftests und Switch Testing</h4>
<p>After the official event ended, some developers met on site with some colleagues
from Hildesheim via video call,
to discuss strategies for improving the in-kernel selftests for switches.</p>
<p>Also, a prototype from this year's Pengutronix's techweek for exporting network
interfaces to labgrid,
which could help for automated switch hardware testing was presented and well received.
We hope to see this buildingblock soon being implemented as a labgrid exporter,
this would also enable other developers in the community to improve their
testing infrastructure,
and would allow to find regressions in network drivers much faster.</p>
</div>
</div>
<div class="section" id="day-5">
<h3>Day 5</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3486x2046" href="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_jeronimos_monastery.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-07_netdevconf-0x16/lissabon_jeronimos_monastery.thumb.c95c5b6891e46b6e0a71b5d21b343824.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>After the usual conversations over the first coffee of the day
in the corridors of the Centro de Congressos do Instituto Superior Técnico,
the last day of NetDev 0x16 started with an insight into the current developments at OpenVPN.</p>
<div class="section" id="pushing-openvpn-down-the-stack-data-channel-offload-dco">
<h4>Pushing OpenVPN down the stack: Data Channel Offload (DCO)</h4>
<p>In this talk, Antonio Quartulli explains the current
Optimization efforts at OpenVPN.
OpenVPN so far implements both Control Plane and Data Plane for
VPN connections in user space.
While this offers some advantages for implementation variants
and a much less restrictive environment compared to an implementation
of the data plane in the kernel,
this yields a significant loss of performance.</p>
<p>With the userspace implementation, the network traffic from an
application (e.g. web browser) needs to be sent from userspace to
a tun device,
i.e. a Layer3 tunnel device,
into the kernel,
which then loops the traffic back to the OpenVPN application in userspace.</p>
<p>This userspace application then encrypts the data and sends it back to the kernel,
which eventually sends data to the target via the network stack and onto the network.
Each data packet must therefore cross the kernel-userspace boundary twice,
resulting in significant performance penalties compared to in-kernel implementations
(like wireguard).</p>
<p>Besides the fact that the OpenVPN application is single-threaded
and therefore cannot benefit from the multitude of processor cores
available on modern CPUS,
this leads to a performance level of OpenVPN is well behind available hardware
bandwidths in modern networks.
Since the OpenVPN code-base is getting a bit long in the tooth anyway,
Antonio did not optimize the userspace code but rather examined
how this problem can solved by directly offloading the data plane into the kernel.</p>
<p>Since in proprietary extensions of the control plane, i.e. the bringup,
teardown,
and and management of connections are common practice ("BYOV" - bring your
own VPN),
the control plane is still kept in userspace while encryption is implemented
using Kernel Crypto API and encapsulating the network data is implemented in
the DCO (Data Channel Offload).
The DCO is a virtual device driver that is configured via Netlink API and
exchanges data with userspace via standard APIs.</p>
<p>In contrast to the previous implementation, which required to keep an entire
routing table in the userspace client,
this also allows to use the kernel routing table for the peer-to-multipeer
mode (server mode) which is just extended by some more specific routes.</p>
<p>We will see if this implementation can keep up with the performance of wireguard,
but for sure it will make up some ground.</p>
<p>The solution presented by Antonio is already fully functional and can be downloaded
from <a href="https://github.com/OpenVPN/ovpn-dco">Github</a>. However, using it in OpenVPN2 will
require the current master branch or the soon-to-be-released Version 2.6 of OpenVPN.</p>
</div>
<div class="section" id="nvmetcp-offload-implementation-and-performance-gains">
<h4>NVMeTCP Offload – Implementation and Performance Gains</h4>
<p>In their talk Shai Malin and Aurelien Aptel present optimizations
to NVMe-TCP.
NVMe-TCP is a protocol for connecting storage via TCP.
Each storage queue is connected via a TCP socket,
on which the read and write operations,
marked accordingly via a Command Identifier (CID),
can be tunnelled into a remote system.</p>
<p>In order to achieve the highest possible performance,
servers are allowed to reorder requests and
to prioritize small requests over longer accesses.
Data integrity is guaranteed by a checksum (CRC).</p>
<p>After a very brief introduction to this unusual subject
Shai and Aurelia explained,
that in the current implementation,
despite various optimizations,
the biggest performance penalties is the copying of received data.
The CRC validation takes the second largest amount computing time and is therefore
an attractive optimization target as well.</p>
<p>Since the NVMe-TCP PDUs can also be distributed over several TCP segments
(or multiple NVMe-TCP PDUs can be contained in a single TCP segment),
a trivial zero-copy approach cannot work for this application.</p>
<p>Instead, they propose the DDP (Direct Data Placement) infrastructure.
The basic idea is of this approach is to use dedicated pre-allocated buffers
for protocols based on request-response pairs,
such as NVMe-TCP.</p>
<p>Since the NIC data is copied to this dedicated buffer via DMA,
they can immediately and easily be analyzed,
whether hardware offloading is possible.</p>
<p>If this approach is combined with, for example, CRC offloading,
up to 58% more bandwidth can be achieved for NVMe-TCP while
reducing the CPU load required by 20% at the same time.</p>
<p>Shai and Aurelian recommended to the audience,
to take careful measurements with perf and flamegraphs,
to optimize performance first on the most expensive operations
complete chain.</p>
<p>For example, in their case, they found that the context switches,
that were triggered by the interrupts for each UMR event per PDU,
led to a significant drop in performance.
By assuming that offloading is opportunistic and waiting for completion
is not necessary,
they were able to bring improve performance significantly.</p>
<p>They also explained that coalescing packets for offloading,
i.e. the execution of offloading operations for several packages at once,
lead to significant performance gains compared to offloading for individual packages.
If the offloading for the respective individual operations
(here CRC calculation and DDP)
is carried out separately
packets can be pooled more often,
which increases performance again.</p>
<p>For achieving best results when optimizing the offloading in real-world applications,
they recommend to carefully examine real traffic with TCPDump
and Wireshark for the statistical distribution of the packet sizes.</p>
</div>
<div class="section" id="to-tls-or-not-to-tls-that-is-not-the-question">
<h4>To TLS or not to TLS - That is not the question</h4>
<p>Nabil Bitar, Jamal Hadi Salim and Pedro Tammela presented the results
on analyzing the performance of different variants of TLS on x86.</p>
<p>They compared measurement results for uTLS (i.e. in userspace),
to different variants of kTLS (in the kernel - with and without platform optimization)
as well as with and without hardware offloading.</p>
<p>While unsurprisingly for larger data streams, kTLS with offloading offers
a significant advantage, the overhead required for offloading is greater than the
achievable improvements for short data streams.
They conclude that uTLS therefore yields better performance for short streams.</p>
<p>The authors presented extensive measurements and demonstrated,
how they analyzed the performance overhead on short streams with ftrace
and tracked it down to the point where the offloading socketoptions are set.</p>
<p>While the direct results of this talk are probably less relevant for the embedded
development reminds me very much of my mentor's mantra:
<em>Always check your assumptions.</em></p>
</div>
<div class="section" id="crosslayer-telemetry-support-in-linux-kernel">
<h4>Cross–Layer Telemetry Support in Linux Kernel</h4>
<p>In their talk Justin Iurman and Benoit Donnet demonstrated
that the ubiquitous migration from monolithic services to a distributed
micro services architecture poses new challenges,
especially debugging and performance analysis.</p>
<p>Application performance management (APM) and distributed tracing
(e.g. openTelemetry) tackle this issue by rolling out tracing
infrastructure over entire network cluster.
This allows fine-grained tracing requests and the corresponding function
calls throughout all instances, layers and micro-services involved by handling the request.</p>
<p>A particular challenge here is the different orders of magnitude for time spans,
since, for example, an HTTP request requires a relatively long round-trip time
compared to a single function call.
Furthermore, the correlation of network traffic to function calls is a
difficult challenge,
since the distributed calls need to be tracked across multiple sub-components
of the architecture.
The authors suggest to use generic identifiers in the network packets for this,
which then could be propagated across the different layers.
This suggestion however spiked a lively subsequent discussion,
also the corresponding drafts in the IETF have faced significant objection,
because the advantage of better traceability involves considerable overhead.
For this reason, the authors invite to an open discussion,
and hope to find alternative and less invasive solutions to this requirement together.</p>
</div>
<div class="section" id="integrating-power-over-ethernet-and-power-over-dataline-support-to-the-linux-kernel">
<h4>Integrating Power over Ethernet and Power over Dataline support to the Linux kernel</h4>
<p>In the last regular talk of the conference, Oleksij Rempel from Pengutronix explains
how he created a framework for Power Delivery over Media Dependent Interface</p>
<p>While Power over MDI as PoE,
i.e. Power over Ethernet,
is probably known by most engineers,
the original set of standards in the IEEE has been expanded several times and
is also extended to other Layer1 implementations such as Base100x-T1.</p>
<p>Oleksij explains,
that not only the huge variety of standards
(which are IEEE standards and usually not freely available),
but also the variety of names for the individual components
where challenging for creating a generic infrastructure in the kernel and
of the userspace API.</p>
<p>Furthermore, the standards include various optional and
mandatory functional components and communication channels,
for example to negotiate power availability out-of-band to the network
traffic between components.</p>
<p>Oleksij therefore chose the approach
to bring an as-minimal-as-possible implementation to mainline.
In particular, his approach to only add components of Power over MDI,
which he could test,
and to submit further aspects later,
is a very understandable and sensible approach.</p>
<p>For this reason, only the PoDL PSE support is currently implemented using this framework,
i.e. the power sourcing equipment (energy source) for PoDL (Power over DataLine
for Base-T1).
The admin state of the PSE per port can already be checked using the framework,
this must happen independant from the link admin state for obvious reasons.
As soon as the uapi has stabilized,
Oleksij will also add ethtool support for this;
so far he has already implemented and demonstrated a proof of concept
as part of his talk.</p>
<p>The next steps will then be to implement classification,
i.e. out-of-band negotiation of the details of a specific PoMDI implementation,
as well as interfaces to the power delivery framework.
This will allow to manage the total power available
and split the power budget between the hardware ports or to
prioritize specific ports.
Also, the corresponding interfaces for the Powered Device (PD),
i.e. power sink, need to be added.
This would allow powered devices to deal with the available power budget,
and adapt their power consumption or at least output the power available
depending on the PSE's delivery capabilities.</p>
<p>In addition, Oleksij hopes to be able to add support for conventional PoE in the kernel soon.</p>
</div>
<div class="section" id="outreachy">
<h4>Outreachy</h4>
<p>Roopa Prabhu then presented the <a href="https://www.outreachy.org/">Outreachy</a>
program for networking projects.
Outreachy arranges internships in open source projects and provides mentorship
programs,
with a particular focus on supporting groups of people who are underrepresented
in the technical industry.</p>
<p>As an example of a successful outreachy internship, Jaehee Park presented
the result of her internship during the last summer,
in which she made network stack optimizations in various places,
such as using AVX2-Extension for accelerated clearing of skb-structures,
the accelerated execution and improvement of self-test or
improvements for gratious arps.</p>
</div>
<div class="section" id="closing-ceremony">
<h4>Closing Ceremony</h4>
<p>NetDev 0x16 ended with the Closing Ceremony.
In addition to a lot of praise for the organizers and speakers,
the challenges of the hybrid event were discussed amongst organizers and participants.
It's refreshing to work in a community
who is aware of its strengths and challenges,
and rises to challenges and discusses openly,
how things can be improved.</p>
</div>
</div>
</div>
<p>After a longer time with online-only events, the <em>Netdev 0x16</em>,
a conference about the technical aspects of Linux Networking,
was organized as hybrid event: online and on-site at Lisbon.</p>2022-12-14T23:42:00+01:00tag:www.pengutronix.de,2022-11-24:/2022-11-24-kernel-panic-board-on-fire-001-spekulative-ausfuehrung-und-ein-execute-never-bit.html[Podcast] Kernel Panic - Board on Fire ~~> #001: Speculative Execution und ein Execute Never Bit2022-11-24T16:10:52+01:00Leonard Göhrs<div class="section" id="podcast-kernel-panic-board-on-fire-001-speculative-execution-und-ein-execute-never-bit">
<div id="podcastplayer">
<script src="https://www.pengutronix.de/static/podlove/embed.js"></script>
<div id="player"></div>
<script>
window.podlovePlayer("#player", {"version": 5, "show": {"title": "Kernel Panic - Board on Fire", "subtitle": "Embedded Lagerfeuergeschichten", "summary": "'Kernel Panic - Board on Fire' ist ein Podcast in dem Leonard lagerfeuertaugliche Geschichten aus der Embedded Linux Entwicklung vorstellt.", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/tags/kernel-panic-podcast.html"}, "podcast_id": "kernel-panic", "title": "#001: Speculative Execution und ein Execute Never Bit", "summary": "Leonard und Ahmad reden in dieser Folge \u00fcber spekulative Ausf\u00fchrung und dar\u00fcber wie lang eine Bugsuche manchmal dauern kann.", "publicationDate": "2022-11-24T16:10:52+00:00", "duration": "00:56:55", "poster": "/static/img/logo-eisscholle-kurzschnabelpinguin-mikrofon-rund.svg.png", "link": "/de/blog/2022-11-24-kernel-panic-board-on-fire-001-spekulative-ausfuehrung-und-ein-execute-never-bit.html", "audio": [{"url": "https://www.pengutronix.de/data/kernel_panic/001_speculative_execution.mp3", "size": 81982280, "title": "MP3 Audio", "mimeType": "audio/mpeg"}], "files": [{"url": "https://www.pengutronix.de/data/kernel_panic/001_speculative_execution.mp3", "size": 81982280, "title": "MP3 Audio", "mimeType": "audio/mpeg"}]}, {"version": 5, "base": "/static/podlove/", "subscribe-button": {"feed": "https://www.pengutronix.de/de/feeds/kernel_panic.xml", "clients": [{"id": "rss"}, {"id": "antenna-pod"}, {"id": "itunes"}, {"id": "beyond-pod"}, {"id": "clementine"}, {"id": "downcast"}, {"id": "gpodder"}, {"id": "i-catcher"}, {"id": "instacast"}, {"id": "overcast"}, {"id": "pod-grasp"}, {"id": "podcast-addict"}, {"id": "podcast-republic"}, {"id": "podcat"}, {"id": "podscout"}, {"id": "rss-radio"}, {"id": "pocket-casts", "service": "fvw8jsak"}]}})
</script>
</div>
<p>In der ersten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem
sich mein Kollege Ahmad Fatoum beschäftigt hat.
Wie so oft beginnt die Geschichte mit einer Aufgabe, die eigentlich™ in fünf
Minuten erledigt sein sollte, driftet aber rasant ab in eine Fehlersuche in den
Untiefen der Systemprogrammierung.
Es geht um Caches, Adressbereiche, Spekulative Ausführung von Code,
um Funktionierbits und auch um Nicht-Funktionier-Bits.</p>
</div>
<div class="section" id="uber-den-kernel-panic-board-on-fire-podcast">
<h2>Über den Kernel Panic - Board on Fire Podcast</h2>
<p>In wahrscheinlich jedem Berufsfeld gibt es Schauergeschichten, die man sich
abends am Lagerfeuer mit einer Taschenlampe am Kinn erzählen kann.
So auch in der Welt der Software.
In diesem Podcast geben wir in unregelmäßigen Abständen Entwicklerinnen und
Entwicklern die Möglichkeit ihre Schauergeschichten zu erzählen.
Es geht um monatelange Fehlersuchen, deren Ergebnis nur eine Hand voll Zeilen
falscher Code sind, um subtil fehlerhafte Hardware, die zu sporadisch
auftretenden Geistern im System führt, um bröckelnde Software,
deren Quellcode schon vor Jahren verloren gegangen ist,
und manchmal auch um ganz was anderes.</p>
</div>
<div class="section" id="shownotes">
<h2>Shownotes</h2>
<p>Wer nicht die ganze Folge hören möchte kann sich an den folgenden fünf
Eskalationsstufen mit ungefähren Zeitangaben orientieren:</p>
<div class="section" id="eskalationsstufe-0-licht-einschalten-crashed-den-bootloader">
<h3>Eskalationsstufe 0 - "Licht einschalten Crashed den Bootloader"</h3>
<dl class="docutils">
<dt>00:00</dt>
<dd>Vorstellung des Podcasts und der Personen</dd>
<dt>05:30</dt>
<dd>Die ursprüngliche Problemstellung.
Es gibt ein eingebettetes Gerät mit einem Display dran und darauf soll,
um BenutzerInnen das Gefühl zu geben, dass nach dem Einschalten etwas
passiert, frühestmöglichst die Display-Hintergrundbeleuchtung
eingeschaltet werden.</dd>
<dt>06:00</dt>
<dd><p class="first">Versucht man die Beleuchtung um Bootloader einzuschalten crashed dieser,
und zwar in einem ganz anderen Bereich des Codes.</p>
<p>Mehr zum Thema Barebox:</p>
<ul class="simple">
<li><a class="reference external" href="https://www.youtube.com/watch?v=Oj7lKbFtyM0">Ahmad Fatoum "Beyond Just Booting - Barebox Bells and Whistles"</a></li>
</ul>
<p>Mehr dazu, was schon passiert bevor überhaupt der Bootloader startet:</p>
<ul class="last simple">
<li><a class="reference external" href="https://www.youtube.com/watch?v=-Ak9MWGxd7M">Ahmad Fatoum "From Reset Vector to Kernel - Navigating the ARM Matryoshka"</a></li>
<li><a class="reference external" href="https://www.youtube.com/watch?v=5IasAAP0lvs">Rouven Czerwinski "How ARM Systems are Booted: An Introduction to the ARM Boot Flow"</a></li>
</ul>
</dd>
<dt>08:30</dt>
<dd><p class="first">Erste Vermutungen:</p>
<ul class="last simple">
<li>Probleme im NAND-Code (der Speicher auf dem die Daten
und Programme des Systems abgelegt werden).</li>
<li>Probleme durch Änderungen an der Hardware (z.B. mehr Arbeitsspeicher)</li>
</ul>
</dd>
</dl>
</div>
<div class="section" id="eskalationsstufe-1-printf-lasst-das-problem-verschwinden">
<h3>Eskalationsstufe 1 - "printf lässt das Problem verschwinden"</h3>
<dl class="docutils">
<dt>10:00</dt>
<dd><p class="first">Neuer Lösungsansatz: Fehlersuche mit printf.</p>
<p>Neues Problem: mit printf verschwinden die Fehler.</p>
<p>Warum können Probleme durch Einfügen von printfs verschwinden?</p>
<ul class="simple">
<li>Timing der ausgeführten Funktionen ändert sich</li>
<li>Codestücke verschieben sich im Speicher</li>
</ul>
<p class="last">Timing sollte eigentlich keine große Rolle spielen, da im Bootloader noch
alles ohne Nebenläufigkeit eins nach dem anderen ausgeführt wird.</p>
</dd>
<dt>13:30</dt>
<dd><p class="first">Vermutung: DMA</p>
<p class="last">Durch falsch eingestelltes DMA (Direct Memory Access) könnten auch im
Bootloader Dinge im Hintergrund passieren.
Im Bootloader wird DMA genutzt, um Daten aus dem NAND in den Hauptspeicher
zu lesen.</p>
</dd>
<dt>15:30</dt>
<dd><p class="first">Vermutung: Schlecht angebundener RAM</p>
<p class="last">Beim neuen Hardwaredesign könnte sich z.B. das Layout der RAM-Leitungen
verschlechtert haben.</p>
</dd>
<dt>17:00</dt>
<dd><p class="first">Brainstorming mit den Kollegen. Sind es vielleicht die Caches?</p>
<p class="last">Das DMA im verwendeten Prozessor ist nicht Cache coherent.
Das heißt man muss zu den richtigen Zeiten den Inhalt der Caches wegwerfen,
sonst erhält man falsche Daten.</p>
</dd>
<dt>18:00</dt>
<dd><p class="first">Ist es vielleicht Spekulation?</p>
<p>Um nicht immer darauf warten zu Müssen, dass die richtigen Daten vom Cache
in den RAM geladen wurden führt der Prozessor zukünftige Operationen schon
einmal "spekulativ" aus und lädt dabei Daten in die Caches.
Falls falsch spekuliert wird, werden diese Daten eigentlich einfach verworfen.</p>
<p class="last">Oder vielleicht nicht?</p>
</dd>
<dt>20:00</dt>
<dd><p class="first">Warum können auch lesende spekulative Speicherzugriffe ein Problem sein?</p>
<p class="last">Nicht alles was im Adressraum des Prozessors liegt ist auch Speicher,
sondern es gibt dort auch eine Vielzahl an Peripherieeinheiten.</p>
</dd>
<dt>21:30</dt>
<dd><p class="first">Lösungsansatz: Nicht-Speicher auch spekulative nicht ausführen.</p>
<p>Um zu verhindern, dass ein Adressbereich (spekulativ) ausgeführt wird kann
er als nicht ausführbar markiert werden.
Bei Programmen, die unter einem Betriebssystem laufen macht man das z.B. für
alle Daten, die nicht Teil des Programmcodes sind, z.B. aus dem Internet
geladene Dinge.
Im Bootloader ist man da etwas laxer, auch weil Sachen in den Speicher zu
laden und auszuführen zur Kernfunktionalität gehört.</p>
<p class="last">Die entsprechende Markierung der Adressbereiche lieferte auch keine Abhilfe.</p>
</dd>
</dl>
</div>
<div class="section" id="eskalationsstufe-2-der-jtag-debugger-lasst-das-problem-verschwinden">
<h3>Eskalationsstufe 2 - "Der JTAG-Debugger lässt das Problem verschwinden"</h3>
<dl class="docutils">
<dt>24:00</dt>
<dd>Fehlersuche mit Hardwaredebugger / JTAG-Adapter.
Führt man das Programm im Debugger Befehl für Befehl aus tritt der Fehler,
wie auch schon mit den printfs, nicht mehr auf.</dd>
<dt>28:00</dt>
<dd>Fragestellung: Unterscheiden sich die Daten in den Caches von den Daten
im Arbeitsspeicher?</dd>
</dl>
</div>
<div class="section" id="eskalationsstufe-3-andern-von-nie-ausgefuhrtem-code-lasst-das-problem-verschwinden">
<h3>Eskalationsstufe 3 - "Ändern von nie ausgeführtem Code lässt das Problem verschwinden"</h3>
<dl class="docutils">
<dt>30:00</dt>
<dd>Da printfs, der Debugger und neu Kompilieren das Verhalten des Programms
ändern patcht Ahmad stattdessen den generierten Maschinencode.</dd>
<dt>39:00</dt>
<dd>Durch Tauschen von zwei Instruktionen in einer nie ausgeführten Funktion
verschwindet das Problem.</dd>
<dt>43:00</dt>
<dd>Fragestellung: Crasht das System auch wenn der entsprechende Code unter
Linux als Programm ausgeführt wird?</dd>
</dl>
</div>
<div class="section" id="eskalationsstufe-4-handbuch-lesen">
<h3>Eskalationsstufe 4 - "Handbuch lesen"</h3>
<dl class="docutils">
<dt>45:00</dt>
<dd><p class="first">Letzter Akt der Verzweiflung: lesen des
<a class="reference external" href="https://developer.arm.com/documentation/ddi0487/ia/">Arm Architecture Reference Manual (Seite 9198)</a> liefert den entscheidenden Hinweis.</p>
<blockquote>
When using the Short-descriptor translation table format, the XN attribute
is not checked for domains marked as Manager.
Therefore, the system must not include read-sensitive memory in domains marked as Manager,
because the XN field does not prevent speculative fetches from a Manager domain.</blockquote>
<p class="last">Im Modus "Manager" ignoriert der Prozessor die gesetzten Restriktionen für
Speicherbereiche.
Der Bootloader läuft im Manager-Modus.</p>
</dd>
<dt>49:00</dt>
<dd><p class="first"><a class="reference external" href="https://lore.barebox.org/barebox/20191009164009.24265-1-a.fatoum@pengutronix.de/">Die Codeänderung</a>
damit der Bootloader in der Client Domain und nicht in der Manager Domain
läuft löst das Problem.</p>
<p class="last">Außerdem: ein kleiner Ausblick darauf welche Software es sonst falsch /richtig
gemacht hat.</p>
</dd>
<dt>53:00</dt>
<dd>Abschließende Worte</dd>
</dl>
</div>
</div><p>In der ersten Folge des Kernel Panic Podcasts geht es um ein Problem mit dem
sich mein Kollege Ahmad Fatoum beschäftigt hat.
Wie so oft beginnt die Geschichte mit einer Aufgabe, die eigentlich™ in fünf
Minuten erledigt sein sollte, driftet aber rasant ab in eine Fehlersuche in den
Untiefen der Systemprogrammierung.
Es geht um Caches, Adressbereiche, Spekulative Ausführung von Code,
um Funktionierbits und auch um Nicht-Funktionier-Bits.</p>2022-11-24T16:10:52+01:00tag:www.pengutronix.de,2022-11-15:/2022-11-15-pengutronix-at-electronica-in-munich.htmlPengutronix at Electronica in Munich2022-11-15T12:48:59+01:00<div class="section" id="pengutronix-at-electronica-in-munich">
<p>This year Pengutronix again has a Booth at the
<a class="reference external" href="https://electronica.de/">Electronica</a> trade fair in Munich, Germany.
You find us in Hall B4 Booth 104
(<a class="reference external" href="https://exhibitors.electronica.de/onlinecatalog/2018/details_halloverview/hall_b5/?this_hallen_id=12&sb1=&sb_n=&elb=800.1100.1818.1.1111&elm_boo_viewsize=1">map</a>).</p>
<p>We are presenting demonstrators from our different topics:</p>
<ul class="simple">
<li>Open source graphics stack on the i.MX8MQ</li>
<li>Rockchip with Mainline Linux</li>
<li>Safe updating with <a class="reference external" href="https://www.rauc.io/">RAUC</a></li>
<li>Labgrid / LXA Test Automation Controller</li>
</ul>
<p>We are happy to welcome you at our booth.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2688x1512" href="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/i-mx8-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/i-mx8-demo.thumb.d7d24d9d0ef8d78ad776af8cc3638828.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/labgrid-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/labgrid-demo.thumb.a5be913ade0fc2664a0d09944b984545.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/rauc-hawkbit-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/rauc-hawkbit-demo.thumb.dc2bfc8a5e2f8202590c2e8d06788e1a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/rockchip-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-11-15_pengutronix-at-electronica-in-munich/rockchip-demo.thumb.cb8b434f035ffe70440c5f68a9507e59.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
<p>This year Pengutronix again has a Booth at the
<a class="reference external" href="https://electronica.de/">Electronica</a> trade fair in Munich, Germany.
You find us in Hall B4 Booth 104
(<a class="reference external" href="https://exhibitors.electronica.de/onlinecatalog/2018/details_halloverview/hall_b5/?this_hallen_id=12&sb1=&sb_n=&elb=800.1100.1818.1.1111&elm_boo_viewsize=1">map</a>).</p>2022-11-15T12:48:59+01:00tag:www.pengutronix.de,2022-10-12:/2022-10-12-rauc-adaptive-updates.htmlSaving Download Bandwidth with RAUC Adaptive Updates2022-10-12T18:00:00+01:00Enrico Jörns<div class="section" id="saving-download-bandwidth-with-rauc-adaptive-updates">
<p>With version 1.7, the RAUC update framework was equipped with built-in HTTP(S)
streaming support.
While this avoided the need for additional storage on the target to serve
as temporary bundle storage, it still required to download the entire update
bundle.</p>
<p>But, especially when network throughput is a bottleneck or traffic is quite
expensive, the need to save download bandwidth comes up and the common answer
to this is <strong>delta updates</strong>.</p>
<p>A conventional delta update is generated by creating the binary or file-based
difference between the current version and the intended version.
While this allows the update to be as small as possible, it adds some
significant conceptional complexity to the update:</p>
<ul class="simple">
<li>one need to know which source versions you have in the field</li>
<li>one needs to deploy the matching updates</li>
<li>an update to an arbitrary version works only by sequentially applying the
delta updates for all intermediate versions.</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2628x1084" href="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-vs-delta_delta.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-vs-delta_delta.thumb.042e438be1435f5220a8e29e72defe84.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Conventional delta updates only allow updating from one specific version to
another specific version</p>
</figcaption>
</figure>
</div><p>Yes, one can partly address this problem by adding more complexity to the
server logic and provide or generate the required delta
on-demand, but this significantly limits the possible use-cases
and requires storing data for the all previous versions.</p>
<p>Thus, for RAUC, we have decided to follow another (high-level) approach for
optimizing the download bandwidth: We have called it <strong>adaptive updates</strong>.</p>
<p>If you cannot immediately picture what it's all about, don't hesitate and read
on.
It took us a second try to find the right name <a class="footnote-reference" href="https://www.pengutronix.de/en/blog/2022-10-12-rauc-adaptive-updates.html#incremental" id="footnote-reference-1">[1]</a>.</p>
<div class="section" id="adaptive-updates">
<h3>Adaptive Updates</h3>
<p>Adaptive updates are a general concept to save download bandwidth in RAUC.
In version 1.8, one adaptive mode is implemented in RAUC, called
<tt class="docutils literal"><span class="pre">block-hash-index</span></tt> that we will discuss in more detail in the next sections.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2620x1153" href="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-vs-delta_adaptive.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-vs-delta_adaptive.thumb.cd1a5c2580255e2ae1b21da866ab6fe8.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>With adaptive updates one can update from any version</p>
</figcaption>
</figure>
</div><p>The basic idea of adaptive updates is to place additional (meta-)data in the
bundle that allows the RAUC service to optimize the
download while always allowing updates from any version.</p>
<p>As a reminder: Since we have streaming capabilities in RAUC allowing verified
random access to the remote bundle, additional files in the bundle only need
to be downloaded when they are used.</p>
<p>The update bundle's
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/basic.html#update-artifacts-bundles">manifest</a>
describes which adaptive method(s) are enabled for each slot image individually
using the <tt class="docutils literal">adaptive</tt> key (as a semicolon-separated list):</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[update]</span>
<span class="na">compatible</span><span class="o">=</span><span class="s">Test System</span>
<span class="na">...</span>
<span class="k">[image.rootfs]</span>
<span class="na">filename</span><span class="o">=</span><span class="s">rootfs.ext4</span>
<span class="na">adaptive</span><span class="o">=</span><span class="s">block-hash-index</span><span class="c1">;rsync-delta-checksum;...</span>
</pre></div>
</div><p>To be fully backwards compatible and to easily allow adding new adaptive
methods, RAUC simply ignores all unknown adaptive methods.
Thus, in the 'worst' case, RAUC just streams the full image into the target
slot, but it will never reject it.
If RAUC knows one or multiple methods, it will select one as appropriate.</p>
<p>Since most adaptive methods make (or will make) use of the newly introduced RAUC
<cite>data directory</cite> for storing information, one should also make sure to have
this configured in the target's <tt class="docutils literal">system.conf</tt>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[system]</span>
<span class="na">compatible</span><span class="o">=</span><span class="s">Test System</span>
<span class="na">...</span>
<span class="na">data-directory</span><span class="o">=</span><span class="s">/data</span>
</pre></div>
</div></div>
<div class="section" id="adaptive-update-method-block-hash-index">
<h3>Adaptive Update Method <tt class="docutils literal"><span class="pre">block-hash-index</span></tt></h3>
<p>The <tt class="docutils literal"><span class="pre">block-hash-index</span></tt> adaptive method can be used for file system images,
mainly for file systems such as <tt class="docutils literal">ext4</tt> that align the data to 4K (or larger)
blocks.
It is the first method implemented in RAUC and part of the v1.8 release.</p>
<p>The method leverages RAUC streaming capabilities that provide random access to
remote update bundles via HTTP range requests to download only necessary parts
of the bundle.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1935x802" href="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/block-hash-index.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/block-hash-index.thumb.1cbaca235c0e79a50a1a28b104a06126.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>block-hash-index: Creation</p>
</figcaption>
</figure>
</div><p>If <tt class="docutils literal"><span class="pre">block-hash-index</span></tt> is set as a method for an image in the manifest, RAUC
generates a hash index file during bundle creation.
This works by splitting the image into 4K-sized <em>chunks</em> and calculating the
SHA-256 hash for each.
The resulting list of chunk hashes unambiguously describes the source data and
is what we will refer to as the <cite>block hash index</cite>.
The block hash index file is placed next to the original image inside the
bundle at a well-known location.</p>
<p>They key concept for reducing the actual data to download is to find matching
data chunks on the device's local storage and use these in instead of
downloading the remote ones.
In an A/B update scheme, the best chance for finding identical chunks is to
search in the active and inactive slots.</p>
<p>Thus, when RAUC installs an image from the bundle that has the
<tt class="docutils literal"><span class="pre">block-hash-index</span></tt> adaptive mode enabled, RAUC first downloads only the (much
smaller, <1%) block hash index file.</p>
<p>RAUC then performs the same chunking and hashing operation (as described above)
on both the (inactive) target slot as well as its corresponding currently
active slot and generates a block hash index for each.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2469x1850" href="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-hash-index-simple.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-10-12_saving-download-bandwith-with-rauc-adaptive-updates/adaptive-hash-index-simple.thumb.608b13da2f558aed3acbf62ba0a0ccac.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>block-hash-index: Installation</p>
</figcaption>
</figure>
</div><p>To write the new image to the target slot, RAUC iterates through the image's
block hash index.
For each hash, RAUC checks if this hash (and thus the required chunk data)
can be found in any block hash index.
If a hash is found, RAUC copies the corresponding data chunk from the block
device/image described by the hash index.</p>
<p>RAUC searches through the hash indexes in the following order:</p>
<ol class="arabic simple">
<li>the active slot</li>
<li>the inactive (update) slot</li>
<li>the update image in the bundle</li>
</ol>
<p>This ensures that local chunks are searched and used first and only those
chunks that are not available locally have to be downloaded.</p>
<div class="section" id="built-in-optimization">
<h4>Built-in Optimization</h4>
<p>Since the on-demand generation of block hash indexes for the slots will
(depending on CPU and IO performance) add some time to the installation, they
are cached in the RAUC data directory.
Only if there is no cache or the cached information does not match the actual
data, the hash index will be re-generated from the block device.</p>
<p>Especially since images often do not fill the entire space in a slot, one of
the very frequently used hashes will be those for the zero-chunk.
RAUC has a zero chunk in memory that it will use before any lookup mechanism
takes place.</p>
</div>
</div>
<div class="section" id="outlook-future-adaptive-methods">
<h3>Outlook: Future Adaptive Methods</h3>
<p>While <tt class="docutils literal"><span class="pre">block-hash-index</span></tt> is the initial adaptive method implemented and is
part the RAUC 1.8 release, there are plans for additional methods.</p>
<div class="section" id="adaptive-update-method-tree-rsync-checksum">
<h4>Adaptive Update Method <tt class="docutils literal"><span class="pre">tree-rsync-checksum</span></tt></h4>
<p>While the previously introduced adaptive method is applicable to block images
only, the underlying approach can be used for directory-tree-based updates (as
RAUC already supports in the form of tar archives), too.</p>
<p>Instead of generating a hash index for a block device on a chunk basis, for
directory trees one can simply generate a hash index by calculating and storing
one hash for each file.
By doing this for the directory tree that comes with the update
'images' as well as for the directory trees of the currently active and
inactive slots one again has a set of three hash index files.</p>
<p>When installing the update, we can again download the hash list describing the
update directory tree and iterate over it while searching for a file with
the same hash in the local slots first.
Only files whose hash RAUC cannot find locally have to be downloaded from the
remote bundle.</p>
<p>With <tt class="docutils literal">rsync</tt>, there is already a tool available that can handle the
checksum-based synchronization of files with using multiple sources as
reference.</p>
<p>The only missing piece of the puzzle is the ability to store/cache the
checksums so that they do not have to be re-calculated on each update.</p>
<p>There are two possible solutions for this out in the field as patches:</p>
<ul>
<li><p class="first">saving and storing checksums in <tt class="docutils literal">.rsyncsums</tt> files:</p>
<p><a class="reference external" href="https://github.com/WayneD/rsync-patches/blob/e8526f7ffa33e7b3a55f592133070b43d82b04d6/checksum-reading.diff">https://github.com/WayneD/rsync-patches/blob/e8526f7ffa33e7b3a55f592133070b43d82b04d6/checksum-reading.diff</a></p>
</li>
<li><p class="first">saving and storing checksums in xattrs:</p>
<p><a class="reference external" href="https://github.com/WayneD/rsync-patches/blob/86a72ad7dcf34ca0ffb52fb36e291ef253894da4/checksum-xattr.diff">https://github.com/WayneD/rsync-patches/blob/86a72ad7dcf34ca0ffb52fb36e291ef253894da4/checksum-xattr.diff</a></p>
</li>
</ul>
<p>The actual copying will the be as similar as running</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsync --delete --copy-dest=<active-slot> <bundle>/rootfs.tree <inactive-slot>
</pre></div>
</div></div>
<div class="section" id="adaptive-update-method-delta-image">
<h4>Adaptive Update Method <tt class="docutils literal"><span class="pre">delta-image</span></tt></h4>
<p>Remember? In the beginning of this post we've argued against the use of
<em>conventional</em> delta updates.
Now, having <em>adaptive udpates</em> introduced, we can rehabilitate them a bit.</p>
<p>The idea behind the adaptive method <tt class="docutils literal"><span class="pre">delta-image</span></tt> is quite simple:
We create conventional delta images between old bundle versions and a new
bundle version using some binary diff tool.</p>
<p>But, instead of using only one delta image, we can add several as <em>additional</em>
artifacts to the bundle so that we gain benefit from both:
If there is an optimized delta artifact matching a currently available bundle
version, use it.
If there is none, just perform a normal image update.</p>
<table class="docutils footnote" frame="void" id="incremental" rules="none">
<colgroup><col class="label"/><col/></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="https://www.pengutronix.de/en/blog/2022-10-12-rauc-adaptive-updates.html#footnote-reference-1">[1]</a></td><td>Trivia: The working title of 'adaptive udpates' was
'incremental updates'</td></tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="getting-started-with-block-hash-index-adaptive-method">
<h3>Getting Started With <tt class="docutils literal"><span class="pre">block-hash-index</span></tt> Adaptive Method</h3>
<p>If this brief excursion has piqued your interest and you intend to evaluate
adaptive updates for your project, here is a summary of things to do to enable
adaptive updates:</p>
<ul>
<li><p class="first">Ensure you are using <strong>block device images</strong></p>
<p>It is highly recommended to use a 4k-aligned file system like ext4, erofs or
squashfs</p>
</li>
<li><p class="first">Ensure you build <tt class="docutils literal">verity</tt> bundles
(see <a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#sec-ref-format-verity">docs</a>)</p>
</li>
<li><p class="first">Ensure you have <strong>HTTP streaming support</strong> working
(see <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#http-streaming">docs</a>)</p>
</li>
<li><p class="first">Configure a <tt class="docutils literal"><span class="pre">data-directory</span></tt> in your <tt class="docutils literal">system.conf</tt>
(see <a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#data-directory">docs</a>)</p>
</li>
<li><p class="first">Enable <tt class="docutils literal"><span class="pre">adaptive=block-hash-index</span></tt> in your bundle manifest</p>
</li>
<li><p class="first">Build and install a bundle (over HTTP)</p>
</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">You also need to ensure that both the target block device size as
well as the size of your image are a multiple of 4kiB.</p>
</div>
<div class="admonition important">
<p class="first admonition-title">Important</p>
<p>The <tt class="docutils literal"><span class="pre">block-hash-index</span></tt> method does not work with NAND / UBIFS
yet.</p>
<p class="last">If an adaption for NAND is required, feel free to <a class="reference external" href="mailto:sales@pengutronix.de">contact</a> us or to discuss and contribute via GitHub.</p>
</div>
<div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p>For testing without actual hardware, the <tt class="docutils literal"><span class="pre">meta-rauc-qemux86</span></tt> layer
from the <a class="reference external" href="https://github.com/rauc/meta-rauc-community">meta-rauc-community</a> project is a good
starting point.</p>
<p>I have prepared <a class="reference external" href="https://github.com/rauc/meta-rauc-community/pull/37">PR #37</a> as a jump-start for
trying out adaptive updates.</p>
<p class="last">See <a href="https://www.pengutronix.de/en/blog/2022-02-03-tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto.html">this post</a>
for an introduction to using the RAUC-enabled QEMU image built by
meta-rauc-community.</p>
</div>
<div class="section" id="measuring-debugging">
<h4>Measuring & Debugging</h4>
<p>To check if adaptive updates are working, you should inspect the rauc
<strong>service</strong> log, e.g. with:</p>
<pre class="literal-block">
journalctl -u rauc
</pre>
<p>when using systemd.</p>
<p>Look for lines noting 'hash index', like this one:</p>
<pre class="literal-block">
using existing hash index for target_slot from /data/slot.rootfs.1/hash-d60b4e16226f704249fc6bf4d99c9aae0be41706ac7dcee0e4aa1d53792c9577/block-hash-index
hash index (35223 chunks) does not cover complete data range (38400 chunks), ignoring the rest
building new hash index for active_slot with 38400 chunks
using existing hash index for source_image from /mnt/rauc/bundle/core-image-minimal-qemux86-64.ext4.block-hash-index
</pre>
<p>To see if adaptive updates are working and for evaluating how it performs on
your system, you should have a look at the access stats that are printed:</p>
<pre class="literal-block">
access stats for zero chunk: count=8235 sum=8235.000 min=1.000 max=1.000 avg=1.000 recent-avg=1.000
access stats for target_slot_written (reusing source_image): count=25567 sum=204.000 min=0.000 max=1.000 avg=0.008 recent-avg=0.000
access stats for target_slot: count=25363 sum=1.000 min=0.000 max=1.000 avg=0.000 recent-avg=0.000
access stats for active_slot: count=25362 sum=25304.000 min=0.000 max=1.000 avg=0.998 recent-avg=0.969
access stats for source_image: count=58 sum=58.000 min=1.000 max=1.000 avg=1.000 recent-avg=1.000
</pre>
<p>You can ignore the <tt class="docutils literal">min</tt>, <tt class="docutils literal">max</tt>, <tt class="docutils literal">avg</tt>, and <tt class="docutils literal"><span class="pre">recent-avg</span></tt> values since
they are only emitted by the generic RAUC stats framework.</p>
<p>You see the four internally used block hash indexes being printed in the order
they are accessed by RAUC as well as an additional <tt class="docutils literal">zero chunk</tt> entry that
represents the built-in access to the zero chunk hash optimization noted above.</p>
<p>The <tt class="docutils literal">count</tt> refers to the number of times the corresponding index was
accessed while the <tt class="docutils literal">sum</tt> is the number of found chunks in this index.</p>
<div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p class="last">The lower the <tt class="docutils literal">count</tt> or <tt class="docutils literal">sum</tt> for <tt class="docutils literal">source_image</tt> is, the more
chunks RAUC was able to find locally and the less it has to download.</p>
</div>
<p>In the example above 58 chunks were downloaded from the bundle, while 25304
were used from the active slot and 204+1 chunks were (re)used from the target
slot.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">In addition to checking the stats for chunks, you should also check
the download stats printed by RAUC, especially the <tt class="docutils literal">dl_size</tt>.</p>
</div>
</div>
<div class="section" id="optimization-approaches">
<h4>Optimization Approaches</h4>
<p>If, even for small rootfs changes, the resulting difference, i.e. the number of
fetched chunks is quite high, these are some things one should have a look at:</p>
<ul>
<li><p class="first">Ensure using a build system that has
<a class="reference external" href="https://reproducible-builds.org/who/projects/">reproducible builds</a>
enabled.</p>
</li>
<li><p class="first">When using ext4, ensure your block size is 4096.
You can check this with:</p>
<pre class="literal-block">
dumpe2fs rootfs.ext4 | grep "Block size"
</pre>
<p>To enforce block size for <tt class="docutils literal">mkfs.ext4</tt>, add <tt class="docutils literal"><span class="pre">-b</span> 4096</tt> argument.</p>
</li>
<li><p class="first">Even if file system contents are (nearly) identical, the generated images may
have significant differences.
Have a look at <a class="reference external" href="https://reproducible-builds.org/docs/system-images/">https://reproducible-builds.org/docs/system-images/</a> for
possible solutions to this.</p>
</li>
<li><p class="first">The bundle image chunks are accessed through the bundle SquashFS, thus with a
large SquashFS block size, some unnecessary data may have to be downloaded,
as each compressed SquashFS block needs to be downloaded completely.</p>
<p>You can e.g. reduce the block size to 32kiB by adding <tt class="docutils literal"><span class="pre">--mksquashfs-args="-b</span>
32k"</tt> to the <tt class="docutils literal">rauc bundle</tt> call.</p>
</li>
</ul>
</div>
</div>
</div>Based on RAUC's HTTP(S) streaming capabilities, adaptive updates are a generic concept in RAUC to allow saving download bandwidth and form an alternative to conventional delta updates. This post introduces both the generic concept as well the first implemented method 'block-hash-index'.2022-10-12T18:00:00+01:00tag:www.pengutronix.de,2022-10-06:/2022-10-06-rauc-v1-8-released.htmlRAUC v1.8 Released2022-10-06T12:00:00+01:00Enrico Jörns<div class="section" id="rauc-v1-8-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.8 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.8">release page</a></p>
</div>
</div>
<p>When September ends and summer is over, it's a good opportunity to take
advantage of the shorter days and comfortably update to the latest RAUC version
we have just released into the wild: v1.8</p>
<p>In times when saving energy is more important than ever, this RAUC release comes
around the corner with a particularly economical feature that implements the
next logical step after introducing the <tt class="docutils literal">verity</tt> bundle format in v1.5 and
HTTP(S) streaming support in v1.7:
The ability to download only the necessary parts of a update bundle, with the
newly introduced <strong>adaptive update</strong> mechanism that also serves as a base for
various future enhancements in this direction.</p>
<p>Below you will find an excerpt of further improvements since RAUC v1.7.
For a complete list, refer to the
<a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.8">release notes</a></p>
<div class="section" id="adaptive-updates">
<h3>Adaptive Updates</h3>
<p>RAUC v1.8 introduces adaptive updates which allow saving download bandwidth by
requesting only necessary parts of the update.
They are RAUC's answer to the common request for <strong>delta updates</strong> but solve
this a bit more flexible than conventional delta updates.</p>
<p>With RAUC v1.8, an initial adaptive update method, called <tt class="docutils literal"><span class="pre">block-hash-index</span></tt>,
is implemented.
It optimizes download size for block-based image updates for file systems that
are aligned to 4k sectors (such as ext4 or erofs).</p>
<p>To enable this mode during bundle creation, configure in your manifest:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[rootfs.image]</span>
<span class="na">adaptive</span><span class="o">=</span><span class="s">block-hash-index</span>
<span class="na">filename</span><span class="o">=</span><span class="s">rootfs.ext4</span>
</pre></div>
</div><p>and simply run <tt class="docutils literal">rauc bundle</tt> as usual.</p>
<p>A more comprehensive overview of what adaptive updates are and what we can
expect from them in the future will be in a separate blog post soon.</p>
</div>
<div class="section" id="atomic-bootloader-updates-for-rockchip-rk3568">
<h3>Atomic Bootloader Updates For Rockchip RK3568</h3>
<p>The Rockchip RK3568 ROM loader searches for a valid image at two (or more)
fixed offsets on the boot medium by checking headers, checksums, etc.</p>
<p>The newly-introduced <tt class="docutils literal"><span class="pre">boot-raw-fallback</span></tt> slot type leverages this behavior to
implement an atomic bootloader update mechanism similar to the ones already
supported by RAUC (e.g. for eMMC boot partitions, GPT, or MBR).</p>
<p>While this was written with a specific ROM loader in mind, the approach can be
used for all ROM loaders that behave similarly.
Just let the <tt class="docutils literal"><span class="pre">region-start</span></tt> point to the first search offset and set
<tt class="docutils literal"><span class="pre">region-size</span></tt> properly so that the second offset starts after the half of the
region-size.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[slot.bootloader.0]</span>
<span class="na">device</span><span class="o">=</span><span class="s">/dev/mmcblk0</span>
<span class="na">type</span><span class="o">=</span><span class="s">boot-raw-fallback</span>
<span class="na">region-start</span><span class="o">=</span><span class="s">32k</span>
<span class="na">region-size</span><span class="o">=</span><span class="s">4M</span>
</pre></div>
</div></div>
<div class="section" id="the-new-data-directory">
<h3>The New Data Directory</h3>
<p>RAUC v1.8 adds support for specifying a <strong>data directory</strong> in the RAUC
<tt class="docutils literal">system.conf</tt>.
The data directory must be located on a shared partition that is not
overwritten during updates.
It will serve as a general storage location for RAUC-related
information and will be of more importance for new features.
Currently, it is primarily used for storing the block hash indexes for the
adaptive update method of the same name.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[system]</span>
<span class="na">...</span>
<span class="na">data-directory</span><span class="o">=</span><span class="s">/data/rauc</span>
</pre></div>
</div><p>For new configurations, setting a data directory is recommended and (unless
otherwise configured via <tt class="docutils literal">statusfile=</tt>) is also used to store the central
slot status file.
See the <a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#data-directory">documentation for details</a>.</p>
</div>
<div class="section" id="allow-passing-pem-passhprase">
<h3>Allow passing PEM Passhprase</h3>
<p>RAUC now allows setting a passphrase for encrypted PEM files via the
environment variable <tt class="docutils literal">RAUC_KEY_PASSPHRASE</tt>.</p>
</div>
<div class="section" id="some-words-about-casync-and-desync-support">
<h3>Some Words About casync and desync Support</h3>
<p>Long before the introduction of built-in HTTP(S) streaming and adaptive
updates, RAUC's support for the casync content chunking tool has been the only
option to satisfy both the need for updating over network without significant
intermediate storage and for reducing download bandwidth requirements by
fetching only the required chunks of an image.</p>
<p>Although this has been working (except for some known limitations), there
was a disclaimer in the RAUC documentation noting it was still 'experimental',
mainly because there was hardly any coverage in the test suite.
Another reason for keeping the disclaimer was that the original casync tool
lacks some features that would make it more efficient and space-saving on
embedded targets and that it was not so actively maintained for a while.</p>
<p>On the other hand, with <a class="reference external" href="https://github.com/folbricht/desync">desync</a>, an
extended casync reimplementation in <em>Go</em> and <a class="reference external" href="https://github.com/florolf/casync-nano">casync-nano</a>, a C-based project which focused on
the block-based chunking, two alternative implementations came up over the
years that solved limitations casync had.</p>
<p>And finally, we also learned that Collabora chose RAUC together with desync as the
A/B update solution for the <em>Valve Steam Deck</em>.
Something where we do not want to hide that we've been very proud to see RAUC
in such a popular product.</p>
<div class="ptx-sidebar">
<div class="title">
desync support
<div class="corner"></div>
</div>
<div class="body">
<p>The adaptions in RAUC required to support desync were <a class="reference external" href="https://github.com/rauc/rauc/pull/817">mainlined</a> by Collabora and now finally made
their way into this release.</p>
</div>
</div>
<p>We took this opportunity to finally write the missing test cases, merge
some open casync-related fixes and to finally get rid of the 'experimental'
note in the documentation.</p>
<p>However, this should not be seen as the great announcement and motivation to
start with casync in RAUC.
It is more the finalization of an open chapter.</p>
<p>The future for optimizing updates with respect to download size we clearly see
in <em>adaptive udpates</em>.
But nevertheless, the casync support and adaptive updates will co-exist for
the next years since currently both will be used and still both have their
advantages and disadvantages.</p>
<p>For a short summary about casync vs. adaptive updates, I have also added an
extra
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#casync-vs-rauc-built-in-streaming-adaptive-updates">section</a>
in the RAUC documentation.</p>
</div>
<div class="section" id="improvements-and-bug-fixes">
<h3>Improvements and Bug Fixes</h3>
<ul class="simple">
<li>RAUC now avoids retrying on HTTP 404 errors during streaming.
This allows aborting much faster if for example the bundle URL is invalid.</li>
<li>The bootloader interaction framework will now print more targeted and less
redundant information about what went wrong.</li>
<li>The handling of errors during loop device block size configuration was
improved with the potential to be more stable.</li>
<li>The <tt class="docutils literal"><span class="pre">boot-mbr-switch</span></tt> atomic bootloader update mode for MBR now also
correctly handles MBR tables with empty partitions (such as when only
three partitions are configured).</li>
<li>RAUC does not attempt to take ownership of plain bundles when running as
non-root.</li>
</ul>
</div>
<div class="section" id="there-is-more-to-come">
<h3>There is More to Come</h3>
<ul>
<li><p class="first">New <tt class="docutils literal"><span class="pre">meta.<label></span></tt> manifest sections are intended to provide a
forwards-compatible way to add data to the manifest which is not interpreted
by RAUC in any way.
Currently, they are just ignored when reading a manifest.
In future releases, they will be accessible via <tt class="docutils literal">rauc info</tt>, the D-Bus API
and in hooks/handlers.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[meta.pengutronix]</span>
<span class="na">mac</span><span class="o">=</span><span class="s">de:ad:be:ef:01</span>
<span class="na">location</span><span class="o">=</span><span class="s">Hildesheim</span>
<span class="na">class</span><span class="o">=</span><span class="s">edge</span>
<span class="k">[meta.device]</span>
<span class="na">key</span><span class="o">=</span><span class="s">value</span>
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A compatibility preparation for this is already part of this release:
RAUC will already ignore <tt class="docutils literal"><span class="pre">meta.<label></span></tt> sections in the manifest.</p>
</div>
</li>
<li><p class="first">The D-Bus API for bundle inspection will be extended so that it can be used
together with HTTP streaming and authentication and with the
complete bundle information.</p>
</li>
<li><p class="first">Installation and Event History that allows to track and trace all
installations on the device for inspection and debugging purpose</p>
</li>
<li><p class="first">We have had requests for <strong>application updates</strong> or container updates
that do not necessarily require an update of the entire system.
Since this did not fit well into the current design of RAUC, we thought about
if and how this should be made possible (or if that is to be solved outside
of RAUC).</p>
<p>We now have a first proposal for app/container/data updates with RAUC:</p>
<p><a class="reference external" href="https://github.com/rauc/rauc/issues/969">https://github.com/rauc/rauc/issues/969</a></p>
</li>
</ul>
</div>
<div class="section" id="contributions">
<h3>Contributions</h3>
<p>We would like to thanks all contributors how helped
realize this new release. Namely (in alphabetical order):
Ahmad Fatoum, Enrico Jörns, Jan Lübbe, Jonas Licht, Ludovico de Nittis, Marc
Kleine-Budde, Marcus Hoffmann, Matthias Fend, Morgan Bengtsson, Ulrich Ölmann,
Uwe Kleine-König</p>
<p>If <strong>you</strong> want to support the project, a good source for open issues is the
<a class="reference external" href="https://github.com/rauc/rauc/issues?q=is%3Aissue+is%3Aopen+label%3ARFE">[RFE]</a>
(request for enhancement) tag on the GitHub issues page.
Some issues are additionally flagged with <a class="reference external" href="https://github.com/rauc/rauc/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22">[help wanted]</a>
where we would like to encourage contributors to enhance and fix things in RAUC
with more low-hanging fruits.</p>
</div>
</div>
<p>When September ends and summer is over, it's a good opportunity to take
advantage of the shorter days and comfortably update to the latest RAUC version
we have just released into the wild: v1.8</p>2022-10-06T12:00:00+01:00tag:www.pengutronix.de,2022-09-17:/2022-09-16-rsc-s-diary-elc-e-2022-day-4.htmlrsc's Diary: ELC-E 2022 - Day 42022-09-17T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-day-4">
<p>Friday, the last day of ELC-E 2022, is traditionally the day of the
Embedded Linux Closing Game, with Tim Bird reporting about the embedded
Linux world (universe?) domination progress and the overall state of the
union. Of course, there were again several interesting talks.</p>
<div class="section" id="oniro-project-how-to-push-iot-development-to-the-next-level">
<h3>Oniro Project: How to Push IoT Development to the Next Level</h3>
<blockquote>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_oniro.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_oniro.thumb.1f8882d77c1f5de9b84b717b63c4d0fc.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div></blockquote>
<p>Ettore Chimenti (SECO SpA) outlined in my first talk of the last day of
ELC-E the ideas of the Oniro project - an eclipse foundation project.
The main idea is to have a common and open base for big (Linux based)
and small (Zephyr based) IoT devices; they don't want to reinvent the
wheel, but re-use as much as possible. Linux systems are built with
Yocto, using the clang toolchain. Besides the usual Yocto layers, a
system services layer provides device management functionality, and
finally an app layer provides the customer application. Good to know:
Oniro uses RAUC for field upgrade, but at least generally have the
option to support other systems. Besides the runtime platform, the Oniro
project also provides infrastructure for development, with GitLab, LAVA,
OpenChain software supplychain and other tools. All in all, the project
seems to be a good "best practice" collection.</p>
</div>
<div class="section" id="bof-automated-testing-and-board-farming">
<h3>BoF: Automated Testing and Board Farming</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_automated_testing1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_automated_testing1.thumb.98f694e45b1844be9876d4ebb6b0455e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Chris Fiege then led a BoF about automated testing and board farming.
For us, board farms usually need interactive access from developers (in
the office or at home) and CI test access to the embedded devices. At
Pengutronix, we have 16 devices in one 19" rack, with a test server,
ethernet switch and serial console. Serial ports make a lot of trouble,
both the old ethernet/rack based and the newer USB/serial devices. Until
2020, we had GPIOs on onewire, nowadays moved to CAN based IO boards. A
lot of automation is done by CAN and multiplexing devices.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_automated_testing2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_automated_testing2.thumb.34423adf495d7a637db5d4f67de385f8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The group then discussed how their test labs look like. Tim Bird
explained that he is mainly interested in power control; it turned out
everyone seems to be hit by USB being flaky and tries to avoid it, but
in reality it's not really possible. So people use things like Sonos
WiFi plugs, Gude IT power switches etc. A TI guy operates 40 racks in
one facility, 300 ports in another one, with OpenTest and labgrid. For
them, camera and display testing is interesting. One participant has a
board that is able to framegrab, emulate keyboard+mouse and even remote
control the BIOS of x86 PCs; he explained that PiKVM turned out to work
best. Another one suggested PicoKVM (on GitHub). Oleksij explained that
we are currently working on network and switch test support in labgrid.
A neat tool is ykush: it can plug/unplug crappy USB devices physically.
Rouven explained that we got a patch into the kernel recently that makes
it possible to switch off single USB hub ports.</p>
<p>The discussion moved on to which specific testsuites are used; at
Pengutronix, in most cases we run device specific tests. The TI folks
use a forked variant of LTP. Oleksij explained that his experience is
that most testsuites are difficult to integrate into production
environments.</p>
<p>Does anyone test hardware things from the outside? For WiFi and
Bluetooth, the Pengutronix labs have one Access Point and a Bluetooth
device per rack.</p>
<p>One guy asked if it was possible to control multiple places from
labgrid; Jan explained that this is already possible.</p>
<p>For further discussion, there is the automated-testing mailing list.</p>
</div>
<div class="section" id="linux-for-space-mission-begins">
<h3>Linux for Space - Mission Begins</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_linux4space.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_linux4space.thumb.d99e97e03145eb44cf3baab0280b930a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Lenka Kosková Třísková & Lukáš Mázl (Technical University of Liberec)
then talked about an open Linux for space applications. They found that
many people in the Space business are doing open source, but there are
not so many ones using Linux. They work on the Linux4Space project and
work on making it compliant with several ESA standards.</p>
<p>They found that, right now, hardware becomes ready for example for
cubesat style applications. The satellites are 10x10x10 cm³, have a
controller and some application. Building one is easy, but launching it
is still a little bit expensive. As the hardware becomes more
accessible, more and more companies build it, so there definitely is an
opportunity to collaborate.</p>
<p>Operating a Linux computer in space means that certain requirements have
to be fulfilled, but luckily the space agencies already defined
standards for that. The biggest challenge is that there is a lot of
radiation; the power budget is low, and generally it is difficult to
control the system remotely. The group collected lots of requirements
and wrote the ECSS-E-ST-10-06 requirements specification.</p>
<p>Most systems on the satellite are doubled, as they can be shutdown
quickly when there is a radiation impact. There are several well known
interfaces such as SpaceWire or SpaceFibre, and generally filesystems
have to be operated read-only.</p>
<p>The project is still in an early state, but there are already some
meeting minutes available on <a class="reference external" href="https://linux4space.org">https://linux4space.org</a>. They are currently
working on a stratosphere balloon demo setup, working on a raspberry pi.</p>
<p>The team is working on a reference board based on some unnamed ARM
processor. For communication, there is a special cubesat protocol.</p>
</div>
<div class="section" id="podman-101-and-beyond">
<h3>Podman 101 and Beyond!</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_podman.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_podman.thumb.b15349f9ef030348006a520a914ceb0f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In my next talk, Pierre Blanc (Red Hat) talked about the podman
container (or better: pod) manager. It is rootless, daemonless and thus
aims to be secure by design. Pierre started with the history of
containers, then started to show how to search for container images.
Once one has found an appropriate container image, one can start it,
connect to it and expose network ports. To get access to data, volumes
can be mounted inside the container. A good thing with user containers
is that it is not necessary to run containers as root.</p>
<p>Pods are groups of containers used for a common usecase. Stopping a pod
means stopping all containers it consists of. So applications composed
of several containers can be managed with podman as well.</p>
<p>Pierre showed that there are quite a lot other security features in
podman; there are also several other helpful tools in the ecosystem like
buildah (container creation) or skopeo.</p>
<p>While the normal usecase is to run the containers on a Kubernetes
cluster, it is also possible to run them in a VM (podman machine).</p>
</div>
<div class="section" id="open-source-enabled-power-grid-management-architecture">
<h3>Open Source Enabled Power Grid Management Architecture</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_lfenergy.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_lfenergy.thumb.cb6198d5f47215e593c8fcb59d2fc687.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After lunch, Lucian Balea & Benoît Jeanson (RTE) highlighted their open
source strategy together with Linux Foundation: the idea is to build a
new power grid software control architecture. RTE operates the French
power distribution network. They found that it is now necessary to
migrate towards a more distributed architecture with a growing number
of actors across the power grid and thus growing complexity. An analysis
has shown that the pain points are interoperability, modularity,
upgradability, cost effectiveness and speed of innovation. They looked
at how other industries solved similar problems, and - surprise! - found
out that open source could help, thus they joined the LF Energy project.</p>
<p>The software that was then put on the table was OperatorFabric
GridExchangeFabric and PowSyBl, and they started creating an
architecture around that; nowadays, they have 18 open source projects,
still with several holes. But more than just software, they see the main
value in the community collaboration that happens in the projects, so
the project is searching for more contributions.</p>
</div>
<div class="section" id="from-zero-to-a-b-swimming-upstream-with-yocto-barebox-and-rauc">
<h3>From Zero to A/B: Swimming Upstream with Yocto, Barebox and RAUC</h3>
<p>Roland Hieber & Ahmad Fatoum (Pengutronix) then tried to encourage the
audience to use upstream components instead of vendor made downstream
code.</p>
</div>
<div class="section" id="risc-v-and-open-source-hardware-projects-bof">
<h3>RISC-V and Open Source Hardware Projects BoF</h3>
<p>Drew Fustini (BayLibre) led a BoF session about open source RISC-V.
While RISC-V inherently is not open source but open spec, it of course
makes it possible to make open source processors. Recently, several chip
companies seem to open up their semiconductor processes for open source
projects, i.e. chipflow.io. In the industry, several open source
processors are being developed, like SweRV, Core-V and LowRISC Ibex.</p>
</div>
<div class="section" id="closing-game">
<h3>Closing Game</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game1.thumb.b97fa0a4793cf6b25b7b7e8e1921002e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game2.thumb.3adbdaa5f638b0b8dd5a3e261384ebce.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-16_rsc-s-diary-elc-e-2022-day-4/2022-09-16_elce_day4_game3.thumb.9dea3669c77c7f1960e45e4e30cf418c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>Friday, the last day of ELC-E 2022, is traditionally the day of the
Embedded Linux Closing Game, with Tim Bird reporting about the embedded
Linux world (universe?) domination progress and the overall state of the
union. Of course, there were again several interesting talks.</p>2022-09-17T10:00:00+01:00tag:www.pengutronix.de,2022-09-16:/2022-09-15-rsc-s-diary-elc-e-2022-day-3.htmlrsc's Diary: ELC-E 2022 - Day 32022-09-16T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-day-3">
<p>The Convention Centre is directly at the water front of the Liffey
river, just a few walking minutes away from O'Connell Bridge, Temple Bar
and Trinity College. Visiting ELC-E is always a good opportunity to
visit interesting cities in Europe. However, here is my story of the
talks I heard on day 3.</p>
<div class="section" id="continuous-delivery-of-iot-sensors">
<h3>Continuous Delivery of IoT Sensors</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_drogue.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_drogue.thumb.decbfbd8ac12eef1fc03414c7d3e36a4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The first talk on Thursday, by Ulf Lilleengen (Red Hat) reported about
the <a class="reference external" href="https://drogue.io">Drogue IoT</a> project, a system (written in
Rust) for continuous IoT deployment.</p>
<p>The setup consists of:</p>
<ul class="simple">
<li>continuous integration</li>
<li>continuous testing (for any change)</li>
<li>continuous deployment (when a step is reached that makes sense to be deployed)</li>
</ul>
<p>The devices he cares about are not in the Linux league, they are
microcontrollers that have an updating mechanism built into the
application. The devices are connected in a different, in most cases
wireless (WiFi, LoRaWAN, LTE-M, Bluetooth), way, and usually use
different sets of tooling for the actual firmware build (vendor
toolchains). Some of the channels might be air time restricted: LoRaWAN
for example might need three days to update a 64 kB firmware image when
using a standard gateway. To make the devices failsafe, they need at
least a minimal bootloader that is able to fetch an update image and
persist it on the device.</p>
<p>Communication in Drogue IoT works via several API endpoints with a REST
API. Devices can be grouped into applications, and many different
protocols can be used to talk between the backends and devices.
Basically, the devices ask if there is a firmware update available for
them, and the delivery service answers. The actual delivery can for
example be done with HawkBit. Finally, a demo showed how to roll out
firmware for a MicroBit controller.</p>
<p>Many of the components don't really fit our Embedded Linux environments,
but there might be some interesting components to have a closer look at,
such as keycloak (for identity management) or the used communication
protocols.</p>
</div>
<div class="section" id="beyond-complex-cameras-complex-video-graphs-using-pipewire">
<h3>Beyond Complex Cameras: Complex Video Graphs Using PipeWire</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_pipewire1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_pipewire1.thumb.ede34008631e13476cdf3e9da9dfd2b2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>George Kiagiadakis (Collabora) then motivated recent issues with
increasingly complex cameras. Modern cameras might have several sensor
chips, combination algorithms and lots of hardware units, all resulting
in one picture or video, maybe even with AI accelerators being involved.
However, the processing pipeline to manage all of that becomes
increasingly complex. Some of the functionality for this is nowadays
provided by libcamera, but there are unsolved questions:</p>
<ul class="simple">
<li>How to combine data from separate devices?</li>
<li>Can we separate processing, even into several containers?</li>
<li>How to realize a "divide and conquer" strategy?</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_pipewire2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_pipewire2.thumb.93ad385bffeff7193e83ff5478baef6b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>PipeWire was invented as a multi process, resource sharing, low latency
multimedia bus. A processing graph, split across several processes, is
constructed and can be managed by WirePlumber. WirePlumber is a
scriptable daemon and can discover and connect all devices in the
system.</p>
<p>As a demo, George showed a PipeWire demo with a face detection
algorithm. There is a nice little tool that shows the resulting PipeWire
graphs. A 2nd demo showed a video playback usecase with two output
windows connected to one video decoder, and the setups can even be
combined.</p>
<p>The talk gave a nice overview of PipeWire; our experience is that it
appears in more and more recent Linux media projects.</p>
</div>
<div class="section" id="growing-a-lab-for-automated-upstream-testing-challenges-and-lessons-learned">
<h3>Growing a Lab for Automated Upstream Testing: Challenges and Lessons Learned</h3>
<p>In my next talk, Laura Nao (Collabora) reported about the struggles
from Collabora's automated test lab. They are operating a lab for
automated testing with LAVA in Cambridge; the lab consists of 158
devices of 32 different types, controlled by 15 servers and the usual
set of networking switches, debugging interfaces, USB hubs etc. Most of
their devices are ARM64 chromebooks, often more than one device of the
same sort. They have the boards in 19" racks. Sounds pretty similar to
what we have in the Pengutronix LAVA lab, only that the Pengutronix lab
has more industrial style hardware.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_collabora_lab.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_collabora_lab.thumb.55c1fc0a9c61f0ee731f25356eca6954.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The test flow starts with switching on the device, running the
bootloader, stop booting, then transfer the kernel and ramdisk, setup
the commandline, resume boot, then start the kernel, boot, login, then
run a test script and finally turn the board off again. The device
configuration consists of a set of jinja 2 and yaml files. A health job
with a known-good result checks if the lab works correctly. Laura showed
the different test job configurations. A dmesg job checks the kernel log
for errors. A LAVA GitLab runner makes it possible to schedule jobs in
GitLab, then run them on the LAVA lab. For new devices, they run 1000
health checks before sending the device into production.</p>
<p>The actual test flow for chromebooks looks pretty different from normal
Linux applications. As testing on Chrome OS is difficult, they replace
it by a normal Linux.</p>
<p>The lab is split into a staging and a production area: in staging, lots
of health checks are provided. It is also the place where the upstream
is tested. Staging usually runs the latest and greatest. The production
area of the lab continuously supervises released revisions.</p>
<p>The lab is fed by KernelCI and Mesa's CI and helps the upstream
developers both inside and outside of Collabora to spot bugs as early
as possible. Mesa is relatively new and does pre-merge conformance
testing; the majority of tests run on x86.</p>
<p>As there are many jobs in the lab, a lot of things may go wrong:
sometimes the hardware is flaky, sometimes the servers, sometimes the
configuration in the racks do fail and even firmware bugs might kick in.
As Mesa blocks new merge requests when the tests fail, it is important
to differentiate infrastructure fails (i.e. network failures) from real
test fails.</p>
<p>Their findings are:</p>
<ul class="simple">
<li>Monitoring the devices' health status is important, as are robust
health checks.</li>
<li>LAVA infrastructure errors need to be found.</li>
<li>With enough device redundancy, good device coverage is possible.</li>
<li>It is necessary to have two people on-side to maintain the devices.</li>
</ul>
<p>With the growth of the lab, more space, equipment and maintenance
manpower is needed as well as more database performance. Monitoring that
closely, it was possible to optimize LAVA for better performance.</p>
</div>
<div class="section" id="technical-introduction-to-everest-open-source-firmware-for-ev-charging-stations">
<h3>Technical Introduction to EVerest: Open Source Firmware for EV Charging Stations</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_everest1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_everest1.thumb.ace63a2103255342455e287d155761a0.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Renewable energy is currently an interesting topic for us, and once
we'll have infrastructure at Pengutronix, we'll of course run it with as
many open source components as possible. So having a look at what
Kai-Uwe Hermann and Piet Gömpel (PIONIX GmbH) have to tell sounds
interesting.</p>
<p>EVerest is a software stack for charging infrastructure for vehicles.
It turns out that charging is a surprisingly complex topic. Charging
stations usually consist of a power component and a control component,
the latter one often running embedded Linux. One has to deal with lots
of different standards, both on the connector and communication side.
Then, between the charger and the cloud backend, the OCPP protocol is
used (implemented in more than 150 dialects), but also IEC631100, MQTT
and others. There is an ongoing effort to establish a "plug and charge"
mechanism, but it requires complex authentication, so almost nobody uses
that in reality.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_everest2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_everest2.thumb.edb060d59601fb0d66255a5b2322241c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another topic that needs to be cared of is to interact with local
charging infrastructure, i.e. for controlling to charge when the sun is
shining and a local PV system is producing energy. In this area, there
are even more protocols involved. The situation is similar when it comes
to grid communication.</p>
<p>All in all, there are way too many standards, and it's even growing. As
this cannot be solved by <a class="reference external" href="https://xkcd.com/922">adding another standard</a>,
the EVerest tries to provide a community reference implementation. They
try to support as many hardware platforms as possible, while not
reinventing the wheel. The Apache 2.0 licensed code base is written in
C++ and can be found on GitHub. To make the configuration easy, there is
some web application. Currently they support OCPP 1.6 in a feature
complete way and aim for 2.0 support. In addition, they have a little
flutter app for the GUI on the local charge point.</p>
<p>The project is about two years old, has a mailing list and regular
meetings. It runs on some commercial hardware (Phytec, Mahle), but
nothing ready-for-the-market yet.</p>
</div>
<div class="section" id="a-month-off-migrating-a-robot-controller-from-the-proprietary-intime-rtos-to-linux">
<h3>A Month Off: Migrating a Robot Controller from the Proprietary INtime RTOS to Linux</h3>
<p>Dirk Eibach works at Carl Cloos Schweisstechnik GmbH, an industrial
welding robot manufacturer. In 2021 they started to migrate a robot to
Preempt RT.</p>
<p>The robot controller consists of an inhouse developed PC, with CAN bus,
EtherCAT and a bunch of servos that run as EtherCAT slaves. The axis run
in a cyclic synchronous position mode (CSP): On each 1-4 ms bus cycle,
the system provides a new target position for all axis. The motion
planner runs at 8...16 ms, interpolating the faster bus cycle. The
dynamic is simulated with a physical model of the robot.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_welding.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-15_rsc-s-diary-elc-e-2022-day-3/2022-09-15_elce_day3_welding.thumb.c78a7cb2300462f33c928d8c27517dbb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The code base is about 3 million lines of source code, originally
written in PL/M, later converted to C; it still contains 386 code and
ANSI C, an old MFC GUI and a new Qt GUI (still not feature complete).
There is the usual amount of technical debt in the codebase, including
knowledge from people that have left the company.</p>
<p>In 2021 they talked to KEBA, they had an automation controller (D3)
running Linux (Debian 32 bit) and Preempt RT, with an integrated safety
solution. With all software running on the system itself, they could get
rid of lots of proprietary licenses. In this situation he proposed to
try a 6-week porting sprint and try to port everything to Linux;
surprisingly, everyone agreed. One of the challenges was to create a
comfortable environment for all of the (non-Linux) developers.</p>
<p>The whole API was completely written in userspace, as a shared library,
so the whole application wasn't touched at all. After some header file
hackery, all functions the linker missed had to be implemented. At the
same time the GUI developers started to migrate the GUI. However, some
more horrifying features like doing IPC on physical memory resulted in
some application redesign.</p>
<p>After 6 weeks, the Cloos main realtime applications were starting up;
the GUIs started working, but were not finished. They learned a lot from
the effort and it was definitely the right approach: the team gained a
good feeling about how complicated it might be to do the rest of the
port. Using Visual Studio made the former windows developers feel
comfortable, so there was a collective decision to continue the effort.
Unfortunately, then the chip crisis hit the team and they had to focus
on other tasks first.</p>
</div>
</div>
<p>The Convention Centre is directly at the water front of the Liffey
river, just a few walking minutes away from O'Connell Bridge, Temple Bar
and Trinity College. Visiting ELC-E is always a good opportunity to
visit interesting cities in Europe. However, here is my story of the
talks I heard on day 3.</p>2022-09-16T10:00:00+01:00tag:www.pengutronix.de,2022-09-15:/2022-09-14-rsc-s-diary-elc-e-2022-day-2.htmlrsc's Diary: ELC-E 2022 - Day 22022-09-15T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-day-2">
<p>The Dublin Convention Centre is huge - there is more than enough space
for all the developers participating in the Open Source Summit.
Fortunately, the talks will be on YouTube after the conference, so it's
no problem that one can only hear a small selection of talks. However,
here is my report of the talks I heard on the 2nd day of the
conference.</p>
<div class="section" id="board-farms-for-everyone-making-hardware-debugging-easier-and-sharing-boards-across-the-globe">
<h3>Board Farms for Everyone: Making Hardware Debugging Easier and Sharing Boards Across the Globe!</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_labgrid.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_labgrid.thumb.717f4b5b1ce302cd1c131a16f350b95d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Open Source is about collaboration (often even between competitors
working in the same market segment), and thus this year's labgrid test
lab automation talk was not given by Pengutronix, but by Christopher
Obbard (Collabora).</p>
<p>In the beginning, Chris motivated that it is often necessary to "try
something out" on a board, but this board could be in some remote
location. So flashing a remote board and automated testing is something
the Collabora guys needed as much as we did. Chris explained that, in
his local lab, he needs about 10 boards, the lab needs to be
reconfigurable quickly, it has to be low power and silent (WAF!). His
lab uses a Raspberry Pi 4 as a controller with USB serial converters
for the console (with the same robustness issues we experienced) and a
network switch. He uses ansible to set up the software on the Raspi.</p>
<p>On the software side, he started with LAVA, but quickly found that it is
mainly made for automated test runs, but not for interactive work. He
found the maintenance effort to be high; flashing full disk images is
difficult, and the loop to run a job takes quite a long time. So for a
home lab and interactive work with a focus on actual development, LAVA
was not suitable.</p>
<p>For interactive work, controlling the power and turning boards on and
off is important, as well as flashing and booting into the software.
The same requirements lead us at Pengutronix to developing labgrid, as a
python framework for hardware test automation. A controller maintains
system state and is able to connect to several exporters that actually
talk to the devices, abstracting things like power ports and serial
interfaces. Chris found that the simplicity to configure labgrid is
really a bonus: just write two YAML files with a hardware description
and places and be done. For interactive use, you can lock and unlock a
board, so it is possible to share a place with a CI. To switch 230 V
devices, he uses Sonoff WiFi PDUs that can be controlled with MQTT. For
automatic tests, Chris uses GitLab CI.</p>
<p>All in all, Chris seems to be quite happy with his lab. A small
pain point is that there is no standard way to upload files to the
exporter. However, it is good to know that people seem to be happy with
our open source projects...</p>
</div>
<div class="section" id="using-openembedded-inside-containers-how-and-why">
<h3>Using OpenEmbedded Inside Containers? How and Why?</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_container.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_container.thumb.e511fb2107473d19d842b472953d11e1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 225px;
"></figcaption>
</figure>
</div><p>The 2nd talk I heard was given by Drew Moseley from Toradex, who
reported about his experiences with OpenEmbedded inside containers.
According to his experience, containers are a convenient way to package
software without dependencies to the host system and deliver it to the
embedded system. Containers mainly make use of standard kernel
functionality to encapsulate software; however, in contrast to virtual
machines, there is no separate kernel. Drew outlined that, with
container registries like Docker Hub, it is pretty easy to install any
kind of software without struggles.</p>
<p>The main question is: how do you create containers? One common problem
with predefined container registries is that you have to trust a
container image made by someone else, and the usual distribution containers
include a lot of standard software that might not even be needed. With
OE, pretty small container images can be built - I leave the details out
here, so if you are interested, the video of the talk should be
available soon.</p>
</div>
<div class="section" id="leveraging-next-generation-cellular-networks-for-drone-telemetry-and-payload-communication">
<h3>Leveraging Next Generation Cellular Networks for Drone Telemetry and Payload Communication</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_drone.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_drone.thumb.0cc83a7d5cd65096202c1d9ad395b0a5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Unfortunately, the "How Automotive Grade Linux UCB Transitioned to Make
Use of Flutter" talk was cancelled; the next talk by Ngonidzashe
Mombeshora couldn't be held in person due to visa issues, but was shown
as a prerecorded video.</p>
<p>The advantage of using mobile networks for drone control is that cellular
networks are available almost everywhere. However, to be able to fly a
drone in realtime, latency is pretty important, so in order to optimize
for latency, he first built an SDR based open source 4G network for
drone communication, based on an SDR hat for a Raspberry Pi and a set of
docker containers for the software stack. Then, a 2nd generation testbed
with 5G was set up and he achieved 90/30 MBit/s down-/uplink at 5 ms
latency. Compared to commercial networks, the testbed had much better
performance w.r.t. latency. Finally, he run a drone testflight in his own
non-public mobile network, using MavLink for telemetry.</p>
<p>All in all it was an impressive talk, but of course mainly from an
academic point of view.</p>
</div>
<div class="section" id="automating-and-managing-an-iot-fleet-using-git">
<h3>Automating and Managing an IoT Fleet Using Git</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_gitops.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_gitops.thumb.05e47966ff59f128211e2e47da01ab51.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In my last talk of the day, Matthias Lüscher (Schindler AG) talked about
how to manage an IoT fleet with git. The mission of his open source
project, <a class="reference external" href="https://www.get-edi.io">edi</a>, is to automate as much as
possible for building, managing and delivering embedded Linux for
embedded devices. The setup starts with Debian for the packages, he then
constructs a Mender update image and deploys it to a test field first,
runs his testsuite with Testinfra and gets test results back. If
everything goes well, he gets a qualified image for the target device.</p>
<p>To avoid a golden image approach, Matthias uses debootstrap, runs the
resulting minimal Debian image in QEMU and integrates the necessary
changes and configs with the help of ansible. Testinfra turned out as a
convenient environment to write tests in pytest, as it can be run on a
development machine and work against an embedded target.</p>
<p>As an example, Matthias showed an edi workflow that turned a Raspberry
Pi into a GitHub Action Runner, using the tools outlined above. In
result, the runner registers itself at GitHub. In a 2nd example, a
Raspberry Pi was turned into a Kiosk computer with 6 lines of ansible
code.</p>
<p>In order to move from a single device to a whole fleet, Matthias showed
his home demo fleet with devices from legacy Raspberry Pi 2 up to
current i.MX8M evalkits. He models his fleet in a set of git branches: a
development branch is where all of the development takes place. Then a
main branch collects more complete features, and a canary branch is what
is delivered to for example a realistic but nicely accessible
environment. If nothing explodes there, things are rolled out into the
real production environment. Clients usually work in pull mode, he uses
Mender and the clients look if there is something new for them to pull
in.</p>
<p>As devices might be offline at the moment of change, it is necessary to
monitor the field setup, and for huge fleets, device definitions will
probably not be put in an ansible inventory but into some database.
However, small fleets work nicely with everything just living in git.</p>
<p>The toolbox turned out to be extremely powerful, and it is even possible
to exchange the individual components, i.e. use Yocto instead of Debian
etc.</p>
</div>
<div class="section" id="booth-crawl">
<h3>Booth Crawl</h3>
<p>Traditionally, there is a booth crawl where several projects show their
embedded Linux demos. Unfortunately, this year there were only 6 demos,
presented by three groups, one of which was Pengutronix. Hopefully there
will be more in the next years, as the demos are always a highlight.</p>
<p>The Pengutronix crew demonstrated the labgrid test automation framework,
the LXA Test Automation Controller (TAC) prototype, the RAUC update
framework and our recent mainlining activities for Rockchip SoCs. Like
every year, there have been lots of interesting talks with an interested
audience.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase1.thumb.fda5ee97d4c88991674eeb8d0e7c339d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase2.thumb.e37b0afaf40d78d52ab3d1939af2427f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase3.thumb.6e10eeba9b17ee6a1883a4b4dd0b1bd8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase4.thumb.b68da1eec644fda4f4db988c7c68f6d1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase5.thumb.51f7c3b7a3fcd664b07dc64b3d45ccdd.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase6.thumb.07a0e4e069257f1f1d237d27e7baefa8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase7.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase7.thumb.e2179d976c83e27813654874ff414ef3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase8.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase8.thumb.bf5574791c6dcd3856884a9ab941ba7b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase9.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase9.thumb.a8d956a7bd127ac9a428fadd191ad7ed.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase10.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-14_rsc-s-diary-elc-e-2022-day-2/2022-09-14_elce_day2_showcase10.thumb.d7f882e427168d1d1253b8ec9ac8fad3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>The Dublin Convention Centre is huge - there is more than enough space
for all the developers participating in the Open Source Summit.
Fortunately, the talks will be on YouTube after the conference, so it's
no problem that one can only hear a small selection of talks. However,
here is my report of the talks I heard on the 2nd day of the
conference.</p>2022-09-15T10:00:00+01:00tag:www.pengutronix.de,2022-09-14:/rsc-s-diary-elc-e-2022-day-1.htmlrsc's Diary: ELC-E 2022 - Day 12022-09-14T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-day-1">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1045x723" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_airport.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_airport.thumb.567fdfc7fd30bce3f5becf9d6d2a9bb8.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After two years with online conferences, the embedded Linux community
once again meets in person for their annual <em>Embedded Linux Conference
Europe</em> in Dublin, Ireland this year. Since many years, ELC-E is part of
the Linux Foundation's Open Source Summit, and the best opportunity of
the year to meet other Linux kernel and wider core ecosystem developers
and discuss recent and future technological topics.</p>
<p>The Pengutronix crew went to Dublin with 14 developers on Sunday, and
several other colleagues participate in the talks online during the week
(of course missing the famous beer events and other social activities
;). Parallel to the ELC-E, the Linux Plumbers Conference took also place
in Dublin.</p>
<div class="section" id="how-arm-systems-are-booted-an-introduction-to-the-arm-boot-flow">
<h3>How ARM Systems are Booted: An Introduction to the ARM Boot Flow</h3>
<p>In the first of our talks at ELC-E, Rouven Czerwinski gave an
introduction into booting on ARM64 on Tuesday, as part of the "Embedded
Essentials" talk series. The idea of this new series is to give
newcomers a good insight into some more "general purpose", not highly
specialized, topics. The concept seems to work, as the room was well
filled.</p>
<p>In contrast to ARM32, where there are basically only the bootloader and
the kernel and two exception levels, on ARM64 there are more components
involved.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3072x4096" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_rouven-booting.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_rouven-booting.thumb.56b32ad7f476b861152fff63ba78b372.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 225px;
"></figcaption>
</figure>
</div><p>The first stage is the ROM code (BL1), and mass storage access is vendor
specific. For development, they provide some sort of serial upload. This
stage loads the 2nd stage (BL2), which is either U-Boot SPL, a barebox
PBL or TF-A.</p>
<p>ARM Trusted Firmware, TF-A, implements several standard firmware runtime
services these days, such as PSCI or SCMI. Unfortunately, TF-A is MIT
licensed, so the vendors are not required to publish their source code
or go through some well justified review system (such as the kernel's).
Besides secure boot mechanics, the DDR frequency scaling is done here,
as well as the Power State Coordination Interface (PSCI).</p>
<p>SCMI, the System Control and Memory Interface, takes care of switching
on and off CPU cores and changing clocks; these services must live in
TF-A, as even if Linux wants a clock to be off, the secure world might
want to use it.</p>
<p>The actual bootloader then starts in exception level 2, is able to for
example parse a devicetree hardware description and takes care of the
usual interfaces that make it possible to get a kernel from somewhere.</p>
<p>In contrast to ARM32, there is no standard decompression in the kernel,
so the bootloader needs to take care, then masks interrupts, initializes
the standard ARM timer and loads the kernel to a defined offset. The MMU
and data caches are disabled, the address of the device tree is put into
register 0 and the bootloader jumps into the kernel.</p>
</div>
<div class="section" id="all-attendees-reception">
<h3>All Attendees Reception</h3>
<p>As in 2015 (when ELC-E was in Dublin for the last time), the attendee
party took place in the Guiness Storehouse. The building is a great
place to meet, but unfortunately, due to the ELC-E being part of the Open
Source Summit, it's always a little bit difficult to find other embedded
people among the thousands of cloud and Kubernetes and Hyperledger
folks at these mega events.</p>
<p>However, the evening was a nice opportunity to talk and find out about
what the other embedded Linux hackers did during the Corona years when
meeting in person was not possible.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="892x669" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_liveact.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_liveact.thumb.00ec09bae3004fdd86120582559bf548.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_storehouse.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_storehouse.thumb.dc876614dc1ca418edfe0d3c5fbe327e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="580x773" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_menu.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_menu.thumb.babac920f36f1a19dec4a471296c8686.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_dessert.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_dessert.thumb.221e6a349b2075bbd02b756789e2262d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x576" href="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_liffey.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-09-13_rsc-s-diary-elc-e-2022-day-1/2022-09-13_elce_day1_liffey.thumb.fe5a59f14e34f49ae732774fa5856b8c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>After two years with online conferences, the embedded Linux community
once again meets in person for their annual <em>Embedded Linux Conference
Europe</em> in Dublin, Ireland this year. Since many years, ELC-E is part of
the Linux Foundation's Open Source Summit, and the best opportunity of
the year to meet other Linux kernel and wider core ecosystem developers
and discuss recent and future technological topics.</p>2022-09-14T10:00:00+01:00tag:www.pengutronix.de,2022-07-15:/2022-07-15-rauc-v1-7-released.htmlRAUC v1.7 Released2022-07-15T12:00:00+01:00Enrico JörnsJan Lübbe<div class="section" id="rauc-v1-7-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.7 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.7">release page</a></p>
</div>
</div>
<p><em>Better late than never: Finally, here is our blog post for RAUC v1.7, which
was released a month ago.</em></p>
<p>In its 1.7 release, RAUC comes with two much-requested features:
Built-in <strong>HTTP(S) streaming</strong> support and <strong>bundle encryption</strong>.
Both are built on the capabilities provided by the 'verity' bundle format and
cannot be supported by the legacy 'plain' format.</p>
<p>We will use the release as an opportunity to give a deep-dive into the
technology, requirements and purposes of streaming and encryption.
But let's have a short glance at a few other notable changes, first:</p>
<ul>
<li><p class="first">PR <a class="reference external" href="https://github.com/rauc/rauc/pull/907">#907</a> added a RAUC
configuration option to allow <strong>partial chain verification</strong> for bundles.</p>
<p>This can be interesting for use-cases where one does not want to trust the
entire PKI but only one or several sub-trees.
This can be used to have a single company PKI but different sub-trees for
various products or product variants where one wants to allow only the
installation of bundles signed for the specific product or product variant.</p>
<p>To enable this, set <tt class="docutils literal"><span class="pre">allow-partial-chain=true</span></tt> in your <tt class="docutils literal">system.conf</tt> and
place the intermediate certificate(s) in the keyring.
For details, see the documentation.</p>
</li>
<li><p class="first">Due to their implementation model, the progress information emitted by RAUC
so far emitted 100% multiple times during installation finalization.
As this could cause confusion, this was fixed in <a class="reference external" href="https://github.com/rauc/rauc/pull/784">#784</a> to report 100% only for the very
last progress update.</p>
</li>
<li><p class="first">A common configuration error for RAUC is a compatible mismatch.
Until v1.7, the error emitted was quite meaningless:</p>
<pre class="literal-block">
Installation error: Compatible mismatch.
</pre>
<p>Since v1.7 we now print a more helpful error message instead:</p>
<pre class="literal-block">
Installation error: Compatible mismatch: Expected 'demo platform' but bundle manifest has 'demo platfrom'
</pre>
</li>
</ul>
<div class="section" id="streaming-updates-over-http">
<h3>Streaming Updates Over HTTP</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2906x1447" href="https://www.pengutronix.de/media/blog/2022/2022-07-15_rauc-v1-7-released/download_vs_streaming.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-07-15_rauc-v1-7-released/download_vs_streaming.thumb.8cb3dc1b11d9a1aeb6fcd445527eedc4.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>Although RAUC has some basic HTTP download functionality, it so far focused on
installing from update bundles on local storage.
When not using casync, an update with a bundle provided by a remote web server
was a two-step process:
First download the bundle to local storage (e.g. by rauc-hawkbit-updater) and
then install it using RAUC.</p>
<p>But, even when most modern embedded systems are not that short on storage,
the need for reserving extra space for a temporary update image is still quite
inefficient.</p>
<p>RAUC's new built-in HTTP streaming removes the need for intermediate local storage.
The bundle data (i.e. file system images) is read on-demand while writing it
to its destination device(s) on the target.
No intermediate storage is required.</p>
<p>To build RAUC with streaming support, you must enable the network and the
streaming option during configuration:</p>
<pre class="literal-block">
$ ./configure --enable-network --enable-streaming [..]
</pre>
<p>Also note that your kernel must have <tt class="docutils literal">CONFIG_BLK_DEV_NBD</tt> enabled as either
module or compiled-in.</p>
<p>The RAUC command line tool (as well as the <tt class="docutils literal">InstallBundle()</tt> D-Bus method)
then allows starting an installation directly from a remote URL:</p>
<pre class="literal-block">
# rauc install https://example.com/update-bundle.raucb
</pre>
<div class="section" id="how-does-this-work-internally">
<h4>How Does This Work Internally?</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2254x2095" href="https://www.pengutronix.de/media/blog/2022/2022-07-15_rauc-v1-7-released/rauc-streaming.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-07-15_rauc-v1-7-released/rauc-streaming.thumb.a646bbf9d0a9402a21a84fe2ee59d37d.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>Component overview for streaming in RAUC</p>
</figcaption>
</figure>
</div><p>The HTTP streaming support leverages another well-established Linux kernel
feature, the network block device (NBD).
NBD provides access to a remote block device via a standardized
network protocol and a client/server architecture.
The Linux kernel implements the NBD client and allows transparent access via a
<tt class="docutils literal">/dev/nbdN</tt> block device.</p>
<p>In RAUC, an unprivileged helper process implements the NBD server part that
converts NBD read requests to HTTP range requests.
This way, RAUC has random access to a remote bundle.</p>
<p>Since almost all common web servers (and CDNs) support range requests, the
requirements on server side are actually quite simple.</p>
<p>Streaming supports HTTP/1.1 and HTTP/2, basic authentication (user/password),
HTTPS (with TLS-based client authentication) and custom headers.</p>
</div>
</div>
<div class="section" id="bundle-encryption">
<h3>Bundle Encryption</h3>
<p>With its use of signed bundles, RAUC is explicitly designed to not require
any trusted/secure communication channel or infrastructure.
For example, this makes it possible to use a USB memory stick as well as
untrusted cloud storage as update source.</p>
<p>However, in some scenarios though, it's not enough to ensure the authenticity of
the bundle, but also that it cannot be extracted or examined by third
party.
Sensitive application code or calibration data might be part of an update and
should be protected during transport.</p>
<p>This is where the new bundle encryption comes into play.
With 1.7, RAUC allows encrypting a bundle for one or more different recipients.
An encrypted bundle can still be streamed, which makes it possible to use the
same bundle for both the USB and the untrusted cloud storage cases above.</p>
<p>Encrypted bundles introduce a third <em>bundle format</em>: the <tt class="docutils literal">crypt</tt> bundle.
Just like for the legacy <tt class="docutils literal">plain</tt> format and the recommended <tt class="docutils literal">verity</tt>
format, you can specify the bundle format to use in your bundle's manifest:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[bundle]</span>
<span class="na">format</span><span class="o">=</span><span class="s">crypt</span>
</pre></div>
</div><p>The actual encryption is designed as a two-step process as often the entity
that builds the system software and thus generates the bundle and the entity
that manages the per-device keys use independent infrastructure.</p>
<p>Thus in a <em>first step</em>, one can build a so-called 'unencrypted crypt bundle',
which means that the payload is already (symmetrically) encrypted, but with a
random unencrypted key:</p>
<pre class="literal-block">
$ rauc bundle [..] unencrypted-crypt-bundle.raucb
</pre>
<p>In a <em>second step</em>, the CMS structure holding the signature and the bundles
manifest can be asymmetrically encrypted for one or multiple recipients:</p>
<pre class="literal-block">
$ rauc encrypt [..] --to recipients.pem unencrypted-crypt-bundle.raucb encrypted-crypt-bundle.raucb
</pre>
<div class="section" id="how-does-this-work-internally-1">
<h4>How Does This Work Internally?</h4>
<p>This (and how to get started with bundle encryption) was described in my blog post
<a class="reference external" href="https://www.pengutronix.de/de/blog/2022-03-31-tutorial-rauc-bundle-encryption-using-meta-rauc.html">Tutorial: Start With RAUC Bundle Encryption Using meta-rauc</a>
already in chapter 'Implementation Background'.
Refer to this for more information.</p>
</div>
</div>
<div class="section" id="what-will-come-next">
<h3>What Will Come Next?</h3>
<p>This is of course not always predictable, as contributions are community or
customer project driven, but we can already give a preview of some features
that are already being worked on or close to being merged:</p>
<ul class="simple">
<li>Support for <tt class="docutils literal">desync</tt> (as an alternative implementation of the <tt class="docutils literal">casync</tt>
protocol) which is used together with RAUC on Valve's Steam Deck finally made
its way into the master branch.</li>
<li>Support for atomic bootloader updates for support ROM loaders
that support fallback images at fixed addresses/offsets (instead of
a partition) was contributed and merged in PR <a class="reference external" href="https://github.com/rauc/rauc/pull/918">#918</a>.</li>
<li>We are working on built-in incremental updates, also leveraging the new
built-in streaming capabilities.
The draft PR <a class="reference external" href="https://github.com/rauc/rauc/pull/936">#936</a> contains
working code, but still needs review and documentation.
A preparation PR that supports the <tt class="docutils literal">incremental</tt> image property is already
part of RAUC 1.7 to ease compatibility.</li>
<li>There has been ongoing discussion and also promising PRs to enhance the
progress handling of RAUC on various levels (better partitioning, more
fine-grained updates, etc.)</li>
</ul>
<p>Even more ideas and PRs are in progress already.
Stay tuned and feel invited to participate and guide the direction of RAUC's
development, for example by joining our <a class="reference external" href="https://app.element.io/#/room/#rauc:matrix.org">Matrix channel</a>.</p>
</div>
</div>
<p><em>Better late than never: Finally, here is our blog post for RAUC v1.7, which
was released a month ago.</em></p>2022-07-15T12:00:00+01:00tag:www.pengutronix.de,2022-06-21:/2022-06-20-embedded-world-2022.htmlPengutronix at Embedded World 20222022-06-21T10:00:00+01:00Chris FiegeMarie MannJan LübbeEnrico Jörns<div class="section" id="pengutronix-at-embedded-world-2022">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="681x153" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/booth_4-261.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/booth_4-261.thumb.9665ad636d21950f5663a5e589b1a137.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>Welcome to our booth at the Embedded World 2022 in Nürnberg!</p>
<p>Finally, the developers, producers and users of embedded systems gather
again at Embedded World in Nürnberg.
Almost everything seems as usual, except that this year the trade fair is
taking place in summer instead of winter.
Our booth is set up and we are waiting for customers and visitors to talk about
new developments in Embedded Linux systems, Open Source, updating strategies
and our gorgeous experiences and inventions concerning remote working and
testing.</p>
<p>For those unable to attend or those who didn't have enough time to see them
all, here is a brief summary of both familiar (but updated) and entirely new
demonstrators.</p>
<div class="section" id="rauc-field-update-demonstrator">
<h3>RAUC Field Update Demonstrator</h3>
<p>Here we demonstrate robust and secure image-based updating with the flexible
RAUC update framework.
Six Raspberry Pis represent a fleet of devices that we would like to maintain.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/slQSCoNlCJQ"></iframe>
</div>
<p>Updating is always a necessary but critical step during the life cycle of an
embedded system.
Updates are important - either to fix system bugs, solve security problems or
simply to add new features.
But, as embedded devices are often placed in locations that make them difficult or
expensive to access, updates must be performed unattended and thus have
special needs in terms of robustness and security.</p>
<p>In practice, the actual deployment mechanism can vary from simple individual
updates over USB sticks up to fully automated network-based deployments using
sophisticated roll-out scheduling strategies.</p>
<p>RAUC itself focusses on being a lightweight service that reliably controls the
process of updating your device with a new firmware version.
It is flexible by design and can handle all common system layouts.
And of course: it's Open Source and licensed under LGPL.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/rauc-hawkbit-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/rauc-hawkbit-demo.thumb.36339a0b0adfc674c6d29f19a4bf8e01.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 225px;
"></figcaption>
</figure>
</div><p>In our demo, all Raspberry Pis are connected via WiFi to a central deployment
server running the Eclipse hawkBit roll-out framework.
The RAUC hawkBit Client, also a RAUC project, interfaces between the hawkBit
server and RAUC.
This setup demonstrates one possibility of using RAUC in a larger context with
custom roll-out scheduling.</p>
<p>The devices are running two variants of firmware: one based on Pengutronix'
PTXdist, the other based on Yocto - two completely different Embedded
Linux distribution build systems, but both equipped with RAUC.</p>
<p>In the demo, the update is scheduled in 3 phases. When the devices of the prior
phase did update successfully, the next phase will be scheduled.</p>
<p>When an update is scheduled for a device, it will download the new image.
After successful cryptographic verification, the image will be written to the
next free slot.
If this is successful, the new image will be marked as "active" and the system
will reboot.
The bootloader will now select the new image.</p>
<p>Latest developments and added features for RAUC are:</p>
<ul class="simple">
<li>Streaming updates over HTTP(S) without the need for local intermediate bundle
storage</li>
<li>Full encryption of update bundles</li>
<li>Built-in incremental updates for partition images</li>
</ul>
</div>
<div class="section" id="labgrid-lxa-test-automation-controller">
<h3>Labgrid / LXA Test Automation Controller</h3>
<p>Engineering a working Linux for your Embedded Device is one thing.
Maintaining this software stack over security updates and new features,
maybe even for 10 or more years, is a completely different story.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/FCdkBli2kJ4"></iframe>
</div>
<p>Automated testing of the complete embedded software on real hardware plays an
important role in maintaining the device for a long time.
In this demonstration we will show you some tools that can help you with
this challenge.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/labgrid-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/labgrid-demo.thumb.7ac3d42bdeb373b847ef10c812b1399b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 225px;
"></figcaption>
</figure>
</div><p>The first component is Labgrid: Labgrid is a Python-based Open Source board
control library.
It allows you to interactively control embedded devices on your desk - or at a
remote location.
It also has a strong focus on automation: You can either use it as a library in
your scripts or as a pytest plugin.
This way, you can run tests on real hardware that feel like pure software
testing.</p>
<p>The next component is a product from our spin-off: Linux Automation.
Our <a class="reference external" href="https://linux-automation.com/de/products/lxa-tac.html">Test Automation Controller</a> (TAC) connects the
physical world to labgrid.
It provides interfaces such as an UART, a power switch with voltage and current
measurement, USB host and device ports and general purpose I/Os.</p>
<p>The test controller can be powered using Power over Ethernet (PoE) and has an
integrated Ethernet switch.
This means, that in most cases, you only have two connections to your test
setup: power for your device under test and Power over Ethernet for the Test
Automation Controller.
The device runs Linux based on Yocto.
Of course, the Yocto layers will be released as Open Source once the device is
launched.
It will most likely be available at the end of 2022.</p>
<p>In this demonstration we run a few tests on the device under test (DUT), in this
case, a Beagle Bone with a separate motor board.</p>
<p>At the beginning of a test-run, labgrid switches the device off and provisions
the newest software image on the SD-Card using the <a class="reference external" href="https://linux-automation.com/de/products/usb-sd-mux.html">USB-SD-Mux</a>.
Afterwards, the DUT is powered on and labgrid interrupts the boot process to run
a first test inside the bootloader.
Then, the boot process is resumed and labgrid takes control over the
Linux shell.</p>
<p>In the shell, the main functionality of this device is tested: We want to spin
the disk at a given speed.
By slowing the disk down manually, we can let the tests fail intentionally.
In a real-world scenario these results would now be collected by the test
runner and some engineer would have to investigate what has happened.
But in our demonstrator the process simply starts over again.</p>
</div>
<div class="section" id="i-mx8mq-four-video-demo">
<h3>i.MX8MQ Four Video Demo</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2688x1512" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/i-mx8-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/i-mx8-demo.thumb.faf7acb0323f80a6689cf45969ba1546.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>Here, we will show you a use-case for hardware-accelerated video decoding and
output on the NXP i.MX8MQ.
The hardware is an entertainment panel, as sometimes seen on airplanes or long
distance coaches and features a 4K display.
The real-world use-case for this device would be to play videos either from
local or network storage or from your own smartphone.
The software stack running on this device consists of Mainline Linux,
GStreamer, Qt Quick, OpenGL and the Etnaviv graphics driver.
So, the software is one hundred percent Open Source - no vendor blobs needed.
This gives you full control over the software running on your device and
reduces dependencies on any single supplier.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/Z9xvVn0hwnc"></iframe>
</div>
<p>In this <a class="reference external" href="https://www.pengutronix.de/de/blog/2021-02-26-showcase-i-mx8mp.html">blogpost</a>, Lucas
Stach takes a deep dive into the issues we had with the closed source driver
for this GPU in the past and shows how the
Open Source drivers solved these problems.</p>
</div>
<div class="section" id="rockchip-with-mainline-linux">
<h3>Rockchip with Mainline Linux</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1512x2688" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/rockchip-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/rockchip-demo.thumb.febf7cb8eafeb96ccb23ca767ddba51c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 225px;
"></figcaption>
</figure>
</div><p>In this demonstration we show you the driver for the VOP2 display controller
used on modern Rockchip SoCs starting with RK3566 / RK3568, which was recently
merged into the Mainline Linux kernel with 5.18.
Think about it as a hardware unit that transforms a rectangular piece of memory
into signals for your display.</p>
<p>Traditionally, our customers have been using well established European or
American CPU vendors for their industrial, aerospace or medical devices.
But since a few years Asian vendors have been targeting these markets as well.
Now add a global chip shortage for devices from western suppliers: This makes
devices from the Asian market even more attractive; simply because you can buy
them.</p>
<p>In this case a customer selected a Rockchip SoC and decided to invest in
mainlining the still-missing components into the Mainline Kernel.
So our colleague Sascha had the opportunity to get the drivers for these
components ready for merging by reworking them according to the requirements of
the upstream kernel.</p>
<div><div class="clearfix"></div></div>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/OyU8A6MOPLA"></iframe>
</div>
</div>
<div class="section" id="open-software-on-open-gateware">
<h3>Open Software on Open Gateware</h3>
<p>Here we demonstrate Linux booting to a login prompt on a soft core RISC-V.
While this might not look like much, there are many interesting parts under the
hood:</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2688x1512" href="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/fpga-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-06-20_embedded-world-2022/fpga-demo.thumb.1b5f11ca1761599edeb1c41b0ad8b2be.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>The board is an ECPIX-5, which is built around Lattice's ECP5, a medium size
FPGA.
In the last few years, the open FPGA toolchain community has improved the
support for this FPGA to the point where it's often easier and faster to use
LiteX, Yosys and nextpnr to generate the bitstream from a high-level description
of the SoC.</p>
<p>The ECP5 has no built-in CPU, so we have to include a CPU in the FPGA
bitstream.
As RISC-V is free and open architecture, of course there are also free and open
FPGA IP cores available such as the multi-core <a class="reference external" href="https://github.com/SpinalHDL/VexRiscv">vexRiscv</a> from SpinalHDL, which was used in
our demo.</p>
<p>We used Yocto to automate the full build process of the gateware and software
from source, ensuring full reproducibility.
As the upstream FPGA toolchain is still evolving quickly, this approach makes
it possible to preform pin-point fixes without the risk of running into
incompatible changes.</p>
</div>
</div>
<p>Welcome to our booth at the Embedded World 2022 in Nürnberg!</p>2022-06-21T10:00:00+01:00tag:www.pengutronix.de,2022-03-31:/2022-03-31-tutorial-rauc-bundle-encryption-using-meta-rauc.htmlTutorial: Start With RAUC Bundle Encryption Using meta-rauc2022-03-31T19:00:00+01:00Enrico Jörns<div class="section" id="tutorial-start-with-rauc-bundle-encryption-using-meta-rauc">
<div class="ptx-sidebar">
<div class="title">
GitHub Pull Request
<div class="corner"></div>
</div>
<div class="body">
<p>The initial discussion about the feature took place in
issue <a class="reference external" href="https://github.com/rauc/rauc/issues/633">#633</a>.</p>
<p>The implementation done for a Pengutronix customer was proposed and
merged in PR <a class="reference external" href="https://github.com/rauc/rauc/pull/863">#863</a>.</p>
</div>
</div>
<p>In its current <a class="reference external" href="https://github.com/rauc/rauc/tree/master">master</a> branch, RAUC
now supports encrypted Bundles.
This tutorial will introduce you to the basics of using encryption in
RAUC and show how to use it in a simplified Yocto setup with the <a class="reference external" href="https://github.com/rauc/meta-rauc">meta-rauc</a> Layer.</p>
<div class="section" id="use-case-considerations">
<h3>Use Case Considerations</h3>
<p>RAUC allows encrypting update bundles to prevent third parties from reading the
bundle's content and thus from gaining information about potentially sensitive
data such as configuration or custom firmware.</p>
<p>In contrast to transport encryption (HTTPS), an encrypted bundle protects
its contents independently directly and can thus be used for unprotected
transport mediums and channels like HTTP, CAN, USB, etc. but also on potentially
insecure storage like cloud servers or USB sticks.</p>
<p>Before using encryption, I would recommended to carefully think about your
actual use case, make a threat analysis and have a concept for:</p>
<ul class="simple">
<li>key deployment and handling during manufacturing</li>
<li>private key storage and protection on hardware</li>
<li>key validity, key scope and revocation</li>
</ul>
</div>
<div class="section" id="implementation-background">
<h3>Implementation Background</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="704x960" href="https://www.pengutronix.de/media/blog/2022/2022-03-31_tutorial-rauc-bundle-encryption-using-meta-rauc/dm-crypt-layers.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-03-31_tutorial-rauc-bundle-encryption-using-meta-rauc/dm-crypt-layers.thumb.9e4f27153a1db37668f2ca3864b1f9a9.png"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"><p>How RAUC uses device mapper for authenticated encryption</p>
</figcaption>
</figure>
</div><p>RAUC implements encryption with a new bundle format, called 'crypt'.
The 'crypt' format is based on the 'verity' format (that in turn is the
successor of the original 'plain' format).
Like the 'verity' format, 'crypt' makes use of the Linux kernel's device
mapper subsystem for decryption (dm-crypt) and verification (dm-verity) to
have transparent, block-based random access to the local or remote bundle
payload.
This also allows using encryption with RAUC's native HTTP(S) streaming
support that requires no intermediate storage space on the device.</p>
<p>The symmetric AES key used for encrypting/decrypting the payload is stored in
the bundle's manifest (as the CMS payload of the signature).
To protect this key and thus fully encrypt the bundle, the manifest is
encrypted using asymmetric CMS encryption.</p>
<p>Using CMS-based asymmetric encryption allows encrypting for one or more
different recipients with individual keys, mitigating part of the risk caused
by key disclosure.</p>
<p>Because the generation of the base bundle and the encryption to the final
recipients are decoupled from each other, the encryption
process in RAUC is a <em>two-step</em> one:</p>
<ol class="arabic">
<li><p class="first">Generation of a 'crypt' bundle with symmetrically encrypted payload</p>
<p>This is typically the result of a BSP build and requires knowledge about the
image content and the type of platform it targets, but it requires no
information about the individual devices.</p>
</li>
<li><p class="first">Asymmetric encryption of the bundle's manifest and signature for one or more
recipients</p>
<p>This typically happens in a later step and requires the public keys
of the individual devices or device groups out in the field.</p>
</li>
</ol>
<div class="ps-gallery single-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3249x1158" href="https://www.pengutronix.de/media/blog/2022/2022-03-31_tutorial-rauc-bundle-encryption-using-meta-rauc/two-stage-encryption.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-03-31_tutorial-rauc-bundle-encryption-using-meta-rauc/two-stage-encryption.thumb.71d9a57679e37b4487e5c4fae232787a.png"/>
</a><figcaption itemprop="caption description" style="
width: 800px;
"><p>Two-step process of creating an encrypted RAUC bundle</p>
</figcaption>
</figure>
</div></div>
<div class="section" id="private-key-storage">
<h3>Private Key Storage</h3>
<p>One of the most critical aspects in encryption is of course the protection of
the private key.
In contrast to verification, where the private signing key is only used on the
build host and can be well protected, for encryption another private decryption
key must be stored securely on the target device where using interactive
password or PIN entry would not be an option.</p>
<p>Depending on the threat model and the level of security required, it might be
sufficient to have the key stored as plain PEM file on the target.
This can be of interest if the access to the transport medium (USB stick,
public server) is much easier than the access to the device's storage.</p>
<p>However, for a security-sensitive application, the private key needs better
protection.
Depending on your hardware, the private key can be stored in a HSM, TPM, or
TEE.
RAUC can then access these keys on the target via a <strong>PKCS#11 API</strong>.</p>
</div>
<div class="section" id="prepare-for-using-encryption-support-in-meta-rauc">
<h3>Prepare for Using Encryption Support in meta-rauc</h3>
<p>To follow this tutorial, you may use your own bundle recipe, create a new one,
or just use the example bundle from the <tt class="docutils literal"><span class="pre">meta-rauc-qemux86</span></tt> layer of
<a class="reference external" href="https://github.com/rauc/meta-rauc-community">meta-rauc-community</a>.</p>
<p>The example snippets here will mainly use <em>meta-rauc-qemux86</em>.
A tutorial on how to set this up for using it with RAUC can be found on
<a class="reference external" href="https://www.pengutronix.de/de/blog/2022-02-03-tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto.html">our blog</a>.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>At the time of writing, encryption support is not part of a RAUC release,
yet.
This requires using the <strong>development version</strong> of RAUC.</p>
<p>You can enable building the development version by adding to your local.conf:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>RAUC_USE_DEVEL_VERSION = "1"
</pre></div>
</div><p class="last">Encryption support will be available with the upcoming RAUC 1.7 release.</p>
</div>
<p>To have the <tt class="docutils literal">rauc</tt> native tool available in your host system for use with
<tt class="docutils literal"><span class="pre">oe-run-native</span></tt>, ensure it is added to the native sysroot:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>rauc-native<span class="w"> </span>-c<span class="w"> </span>addto_recipe_sysroot
</pre></div>
</div></div>
<div class="section" id="prepare-target-system-for-encryption">
<h3>Prepare Target System for Encryption</h3>
<p>In this section, you will adapt your BSP to build an image for your target
system that is prepared for encryption support.</p>
<p>We need to add the section below to our existing RAUC system configuration file
<tt class="docutils literal">system.conf</tt>.
In meta-rauc-qemux86, this means editing <tt class="docutils literal"><span class="pre">recipes-core/rauc/files/qemux86-64/system.conf</span></tt>.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[encryption]</span>
<span class="na">key</span><span class="o">=</span><span class="s">crypt-key.pem</span>
<span class="na">cert</span><span class="o">=</span><span class="s">crypt-cert.pem</span>
</pre></div>
</div><p>This tells RAUC where to find the private key and cert for decrypting bundles.
Providing the <tt class="docutils literal">cert</tt> is not mandatory, but, especially for setups with a large
number of recipients, it speeds up finding the proper recipient significantly.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p>For the sake of simplicity, we use plain files in our example.
When using PKCS#11 API as recommended, this would look like</p>
<div class="last"><div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[encryption]</span>
<span class="na">key</span><span class="o">=</span><span class="s">pkcs11:token=rauc</span><span class="c1">;object=crypt-key</span>
<span class="na">cert</span><span class="o">=</span><span class="s">pkcs11:token=rauc</span><span class="c1">;object=crypt-cert</span>
</pre></div>
</div></div></div>
<p>The actual key and cert file will not be placed in the BSP as we use per-device
keys and thus add them during device bring-up in the 'factory'.</p>
<p>As previously mentioned, RAUC uses the kernel device mappers dm-crypt and
dm-verity for crypt bundles.
Support for these must be enabled in the kernel.
Thus make sure your kernel is compiled with:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="na">CONFIG_MD</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_BLK_DEV_DM</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_BLK_DEV_LOOP</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_DM_VERITY</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_SQUASHFS</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_CRYPTO_SHA256</span><span class="o">=</span><span class="s">y</span>
<span class="na">CONFIG_DM_CRYPT</span><span class="o">=</span><span class="s">y</span>
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For the tutorial, also make sure you also have an SSH server installed and
running on your target system.
We will use this for copying files later.</p>
</div>
<p>Now we can build the target system's rootfs.
For meta-rauc-qemux86 this would mean running:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>core-image-minimal
</pre></div>
</div><p>We can then start our system.
Use a separate shell for this so we can continue working with our current BSP
environment.</p>
<p>For the QEMU machine, this would mean running:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span><span class="nb">source</span><span class="w"> </span>poky/oe-init-build-env<span class="w"> </span>build
$<span class="w"> </span>runqemu<span class="w"> </span>nographic<span class="w"> </span>slirp<span class="w"> </span>ovmf<span class="w"> </span>wic<span class="w"> </span>core-image-minimal
</pre></div>
</div></div>
<div class="section" id="building-a-crypt-bundle">
<h3>Building A 'crypt' Bundle</h3>
<p>In this section, we will now perform <strong>step 1</strong> of the two-step process of
creating an encrypted bundle.</p>
<p>Building a 'crypt' bundle is as simple as setting your bundle type to 'crypt'
in the manifest used for generation.
With meta-rauc, you can set this in you bundle recipe file
(<tt class="docutils literal"><span class="pre">recipes-core/bundles/qemu-demo-bundle.bb</span></tt> for meta-rauc-qemux86) with:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>RAUC_BUNDLE_FORMAT = "crypt"
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p>Since we will use decryption keys that are not part of the BSP build,
we need to ensure that these keys are transfered to the updated system.
(In our demo this is not strictly required as we do not intend to update
from the just-installed system again).</p>
<p>A simple solution to this is to use a <strong>post-install hook</strong> in our bundle
that copies the key and certificate files to the target slot after having
written it.</p>
<p>An example hook file would look like:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="ch">#!/bin/sh</span>
<span class="nb">set</span><span class="w"> </span>-ex
<span class="k">case</span><span class="w"> </span><span class="s2">"</span><span class="nv">$1</span><span class="s2">"</span><span class="w"> </span><span class="k">in</span>
<span class="w"> </span>slot-post-install<span class="o">)</span>
<span class="w"> </span><span class="c1"># only rootfs class is valid to be handled</span>
<span class="w"> </span><span class="nb">test</span><span class="w"> </span><span class="s2">"</span><span class="nv">$RAUC_SLOT_CLASS</span><span class="s2">"</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">"rootfs"</span><span class="w"> </span><span class="o">||</span><span class="w"> </span><span class="nb">exit</span><span class="w"> </span><span class="m">1</span>
<span class="w"> </span>cp<span class="w"> </span>/etc/rauc/crypt-key.pem<span class="w"> </span><span class="nv">$RAUC_SLOT_MOUNT_POINT</span>/etc/rauc/
<span class="w"> </span>cp<span class="w"> </span>/etc/rauc/crypt-cert.pem<span class="w"> </span><span class="nv">$RAUC_SLOT_MOUNT_POINT</span>/etc/rauc/
<span class="w"> </span><span class="p">;;</span>
<span class="w"> </span>*<span class="o">)</span>
<span class="w"> </span><span class="nb">exit</span><span class="w"> </span><span class="m">1</span>
<span class="w"> </span><span class="p">;;</span>
<span class="k">esac</span>
</pre></div>
</div><p>In your bundle recipe, you can add this by placing it in your bundle recipe's
file directory and setting:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>SRC_URI += "file://hook.sh"
RAUC_BUNDLE_HOOKS[file] = "hook.sh"
RAUC_SLOT_rootfs[hooks] = "post-install"
</pre></div>
</div><p class="last">Note that the settings may differ when not using meta-rauc-qemux86.</p>
</div>
<p>And then just build your bundle:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>qemu-demo-bundle
</pre></div>
</div><p>This will generate what we call an <strong>'unencrypted crypt bundle'</strong>, reflecting that
the payload is encrypted, but the CMS holding the manifest and thus the
dm-crypt symmetric AES key isn't.</p>
<div class="admonition important">
<p class="first admonition-title">Important</p>
<p class="last">For a real scenario, make sure that this 'intermediate' bundle does not
leave your secure environment so that the dm-crypt AES key is not leaked.
Anyone knowing the dm-crypt AES key will have full access to the bundle
payload!</p>
</div>
<p>You can inspect the resulting bundle with <tt class="docutils literal">rauc info</tt> which will give you the hint
<tt class="docutils literal">[unencrypted CMS]</tt>.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>oe-run-native<span class="w"> </span>rauc-native<span class="w"> </span>rauc<span class="w"> </span>info<span class="w"> </span>--keyring<span class="o">=</span>example-ca/ca.cert.pem<span class="w"> </span>tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb
Compatible:<span class="w"> </span><span class="s1">'qemu86-64 demo platform'</span>
Version:<span class="w"> </span><span class="s1">'1.0'</span>
Description:<span class="w"> </span><span class="s1">'qemu-demo-bundle version 1.0-r0'</span>
Build:<span class="w"> </span><span class="s1">'20220328213514'</span>
Hooks:<span class="w"> </span><span class="s1">''</span>
Bundle<span class="w"> </span>Format:<span class="w"> </span>crypt<span class="w"> </span><span class="o">[</span>unencrypted<span class="w"> </span>CMS<span class="o">]</span>
<span class="w"> </span>Crypt<span class="w"> </span>Key:<span class="w"> </span><span class="s1">'<hidden>'</span>
<span class="w"> </span>Verity<span class="w"> </span>Salt:<span class="w"> </span><span class="s1">'e6800d82b6d37df11bae194e28abfbea53bd40e2ccd7ac1d85435a2ea47ab552'</span>
<span class="w"> </span>Verity<span class="w"> </span>Hash:<span class="w"> </span><span class="s1">'83ab98d255488e96c59b8e5fe122c70b6206b35c4b885f8ca3b8af1a95da7302'</span>
<span class="w"> </span>Verity<span class="w"> </span>Size:<span class="w"> </span><span class="m">512000</span>
<span class="o">[</span>...<span class="o">]</span>
</pre></div>
</div><p>This bundle cannot be deployed and install, yet.
We have to fully encrypt it first.</p>
<p>This is the moment when the built bundle normally leaves the development
environment and is transferred to your deployment preparation infrastructure.
However, the bundle's payload/content is already signed and will not be changed
anymore beyond this point!</p>
</div>
<div class="section" id="create-and-deploy-device-keys">
<h3>Create and Deploy Device Keys</h3>
<p>In this section, we simulate the factory process of creating and deploying
asymmetric per-device keys/certificates that will be used for encryption and
decryption.</p>
<div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p class="last">The keys and certificates used for encryption do not need to have any
relation to the keys and certificates used for the signing process.</p>
</div>
<p>To encrypt the bundle for a number of recipients, we typically need to have
access to our device management system, which stores the devices' public
recipient certificates.
All steps described here are normally done before bringing your devices in the
field.</p>
<p>In general, it is up to you and your use case how finely-grained you need to
encrypt your bundle.
Here we assume that each device has its own individual key.
This allows revoking a device's key if it should be compromised.
Future bundles will then be encrypted for all but the compromised key.
See more about use cases and workflows in the RAUC documentation <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#encryption-key-workflows">here</a></p>
<p>While RAUC potentially allows encrypting a bundle to a large number of
recipients, this minimal example will use only a few recipients for the sake of
simplicity.</p>
<p>Let's create some ECC key pairs with certificates first:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>mkdir<span class="w"> </span>-p<span class="w"> </span>keys/private
$<span class="w"> </span><span class="k">for</span><span class="w"> </span>i<span class="w"> </span><span class="k">in</span><span class="w"> </span><span class="k">$(</span>seq<span class="w"> </span><span class="m">0</span><span class="w"> </span><span class="m">4</span><span class="k">)</span><span class="p">;</span><span class="w"> </span><span class="k">do</span>
><span class="w"> </span>openssl<span class="w"> </span>ecparam<span class="w"> </span>-name<span class="w"> </span>prime256v1<span class="w"> </span>-genkey<span class="w"> </span>-noout<span class="w"> </span>-out<span class="w"> </span>keys/private/private-key-<span class="nv">$i</span>.pem
><span class="w"> </span>openssl<span class="w"> </span>ec<span class="w"> </span>-in<span class="w"> </span>keys/private/private-key-<span class="nv">$i</span>.pem<span class="w"> </span>-pubout<span class="w"> </span>-out<span class="w"> </span>keys/public-key-<span class="nv">$i</span>.pem
><span class="w"> </span>openssl<span class="w"> </span>req<span class="w"> </span>-new<span class="w"> </span>-x509<span class="w"> </span>-key<span class="w"> </span>keys/private/private-key-<span class="nv">$i</span>.pem<span class="w"> </span>-out<span class="w"> </span>keys/recipient-cert-<span class="nv">$i</span>.pem<span class="w"> </span>-days<span class="w"> </span><span class="m">365250</span><span class="w"> </span>-subj<span class="w"> </span><span class="s2">"/O=RAUC/CN=RAUC Test </span><span class="nv">$i</span><span class="s2">"</span>
><span class="w"> </span><span class="k">done</span>
</pre></div>
</div><p>This will generate you 5 individual encryption key pairs in the <tt class="docutils literal">keys/</tt>
directory where the sensitive private keys are stored in the
<tt class="docutils literal">keys/private/</tt> directory.</p>
<p>We use a single key pair as decryption keys for our demo target, the others
could be used for other targets.
Simply copy these key pairs to the devices' root filesystems (note that the
final file names must match those we configured in <tt class="docutils literal">system.conf</tt>):</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>keys/private/private-key-0.pem<span class="w"> </span>root@localhost:/etc/rauc/crypt-key.pem
$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>keys/recipient-cert-0.pem<span class="w"> </span>root@localhost:/etc/rauc/crypt-cert.pem
</pre></div>
</div><p>Your target's rootfs <tt class="docutils literal">/etc/rauc</tt> directory should now look as follows:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>root@qemux86-64:~#<span class="w"> </span>ls<span class="w"> </span>-1<span class="w"> </span>/etc/rauc
ca.cert.pem
crypt-cert.pem
crypt-key.pem
system.conf
</pre></div>
</div><p>Your target is now fully capable of decrypting and installing RAUC bundles.</p>
</div>
<div class="section" id="encrypt-bundle-for-our-recipients">
<h3>Encrypt Bundle For Our Recipients</h3>
<p>Now that we have our target ready, in this section we will perform <strong>step 2</strong>
of the two-step bundle encryption:
Creating a fully CMS-encrypted 'crypt' bundle for our target and other potential recipients.</p>
<p>To allow encrypting for a huge number of recipients, RAUC supports loading the
recipient certificates as a concatenated list from a single file.</p>
<p>To create such, we simply run</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>cat<span class="w"> </span>keys/recipient-cert-0.pem<span class="w"> </span>keys/recipient-cert-2.pem<span class="w"> </span>keys/recipient-cert-4.pem<span class="w"> </span>><span class="w"> </span>keys/recipients.pem
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We intentionally omit recipient-cert-1.pem and recipient-cert-3.pem
here for later purposes.</p>
</div>
<p>Now, we can encrypt our bundle using the new <tt class="docutils literal">rauc encrypt</tt> command:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>oe-run-native<span class="w"> </span>rauc-native<span class="w"> </span>rauc<span class="w"> </span>encrypt<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--keyring<span class="o">=</span>example-ca/ca.cert.pem<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>--to<span class="w"> </span>keys/recipients.pem<span class="w"> </span>tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb<span class="w"> </span><span class="se">\</span>
<span class="w"> </span>encrypted.raucb
Encrypted<span class="w"> </span>bundle<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>encrypted.raucb
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We could also specify each recipient cert separately by using
<tt class="docutils literal"><span class="pre">--to</span></tt> multiple times, but this quickly becomes inconvenient, especially
with larger numbers of recipients.</p>
</div>
<p>The resulting <tt class="docutils literal">encrypted.raucb</tt> is now a fully <strong>encrypted crypt bundle</strong>.</p>
<p>A simple <tt class="docutils literal">rauc info</tt> call (as already done above) should not show any
information anymore.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>oe-run-native<span class="w"> </span>rauc-native<span class="w"> </span>rauc<span class="w"> </span>info<span class="w"> </span>--keyring<span class="o">=</span>example-ca/ca.cert.pem<span class="w"> </span>encrypted.raucb
Encrypted<span class="w"> </span>bundle<span class="w"> </span>detected,<span class="w"> </span>but<span class="w"> </span>no<span class="w"> </span>decryption<span class="w"> </span>key<span class="w"> </span>given
</pre></div>
</div><p>Showing the bundle information is now only possible with one of the decryption
keys given!
We provide it and add the <tt class="docutils literal"><span class="pre">--dump-recipients</span></tt> argument to make the list of
recipients of this bundle visible.
Note that the Bundle format is now printed as <tt class="docutils literal">[encrypted CMS]</tt>.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>oe-run-native<span class="w"> </span>rauc-native<span class="w"> </span>rauc<span class="w"> </span>info<span class="w"> </span>--keyring<span class="o">=</span>example-ca/ca.cert.pem<span class="w"> </span>--key<span class="o">=</span>keys/private/private-key-0.pem<span class="w"> </span>--dump-recipients<span class="w"> </span>encrypted.raucb
Compatible:<span class="w"> </span><span class="s1">'qemu86-64 demo platform'</span>
Version:<span class="w"> </span><span class="s1">'1.0'</span>
Description:<span class="w"> </span><span class="s1">'qemu-demo-bundle version 1.0-r0'</span>
Build:<span class="w"> </span><span class="s1">'20220328213514'</span>
Hooks:<span class="w"> </span><span class="s1">''</span>
Bundle<span class="w"> </span>Format:<span class="w"> </span>crypt<span class="w"> </span><span class="o">[</span>encrypted<span class="w"> </span>CMS<span class="o">]</span>
<span class="w"> </span>Crypt<span class="w"> </span>Key:<span class="w"> </span><span class="s1">'<hidden>'</span>
<span class="w"> </span>Verity<span class="w"> </span>Salt:<span class="w"> </span><span class="s1">'e6800d82b6d37df11bae194e28abfbea53bd40e2ccd7ac1d85435a2ea47ab552'</span>
<span class="w"> </span>Verity<span class="w"> </span>Hash:<span class="w"> </span><span class="s1">'83ab98d255488e96c59b8e5fe122c70b6206b35c4b885f8ca3b8af1a95da7302'</span>
<span class="w"> </span>Verity<span class="w"> </span>Size:<span class="w"> </span><span class="m">512000</span>
<span class="o">[</span>...<span class="o">]</span>
<span class="m">3</span><span class="w"> </span>Recipients:
<span class="w"> </span><span class="m">0</span><span class="w"> </span>Issuer:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC<span class="w"> </span>Test<span class="w"> </span><span class="m">0</span>
<span class="w"> </span>Serial:<span class="w"> </span>0x3078C175A64B65BAADC9751FF4B52624D98CDE01
<span class="w"> </span>Algorithm:<span class="w"> </span>dhSinglePass-stdDH-sha1kdf-scheme
<span class="w"> </span><span class="m">1</span><span class="w"> </span>Issuer:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC<span class="w"> </span>Test<span class="w"> </span><span class="m">2</span>
<span class="w"> </span>Serial:<span class="w"> </span>0x61999A7BBC9B9FE3F05CB100B6E4D1899F699782
<span class="w"> </span>Algorithm:<span class="w"> </span>dhSinglePass-stdDH-sha1kdf-scheme
<span class="w"> </span><span class="m">2</span><span class="w"> </span>Issuer:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>RAUC<span class="w"> </span>Test<span class="w"> </span><span class="m">4</span>
<span class="w"> </span>Serial:<span class="w"> </span>0x620632AECA563A343A35BC53205021732C58AE19
<span class="w"> </span>Algorithm:<span class="w"> </span>dhSinglePass-stdDH-sha1kdf-scheme
</pre></div>
</div></div>
<div class="section" id="install-encrypted-bundle-on-the-target">
<h3>Install Encrypted Bundle on the Target</h3>
<p>Now, we have everything prepared to actually install the bundle on the target.
This is exactly what we will do in this final section.</p>
<p>First, copy the bundle to the target.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>encrypted.raucb<span class="w"> </span>root@localhost:/data/
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">We could also install the bundle directly over HTTPS by making use of
RAUC's streaming capabilities, but since this requires us to set up an HTTP
server first, we skip this for the sake of simplicity.</p>
</div>
<p>Then, on the target, simply run <tt class="docutils literal">rauc install</tt> to install your encrypted bundle.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="n">root</span><span class="nv">@qemux86</span><span class="o">-</span><span class="mi">64</span><span class="err">:</span><span class="o">~</span><span class="err">#</span><span class="w"> </span><span class="n">rauc</span><span class="w"> </span><span class="n">install</span><span class="w"> </span><span class="o">/</span><span class="k">data</span><span class="o">/</span><span class="n">encrypted</span><span class="p">.</span><span class="n">raucb</span>
<span class="n">installing</span>
<span class="w"> </span><span class="mi">0</span><span class="o">%</span><span class="w"> </span><span class="n">Installing</span>
<span class="w"> </span><span class="mi">0</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">states</span>
<span class="w"> </span><span class="mi">20</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">states</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">20</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">bundle</span>
<span class="w"> </span><span class="mi">20</span><span class="o">%</span><span class="w"> </span><span class="n">Verifying</span><span class="w"> </span><span class="n">signature</span>
<span class="w"> </span><span class="mi">40</span><span class="o">%</span><span class="w"> </span><span class="n">Verifying</span><span class="w"> </span><span class="n">signature</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">40</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">bundle</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">40</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">manifest</span><span class="w"> </span><span class="n">contents</span>
<span class="w"> </span><span class="mi">60</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">manifest</span><span class="w"> </span><span class="n">contents</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">60</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">target</span><span class="w"> </span><span class="n">install</span><span class="w"> </span><span class="k">group</span>
<span class="w"> </span><span class="mi">80</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">target</span><span class="w"> </span><span class="n">install</span><span class="w"> </span><span class="k">group</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">80</span><span class="o">%</span><span class="w"> </span><span class="n">Updating</span><span class="w"> </span><span class="n">slots</span>
<span class="w"> </span><span class="mi">80</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">efi</span><span class="mf">.0</span>
<span class="w"> </span><span class="mi">85</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">efi</span><span class="mf">.0</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">85</span><span class="o">%</span><span class="w"> </span><span class="n">Copying</span><span class="w"> </span><span class="nc">image</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">efi</span><span class="mf">.0</span>
<span class="w"> </span><span class="mi">90</span><span class="o">%</span><span class="w"> </span><span class="n">Copying</span><span class="w"> </span><span class="nc">image</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">efi</span><span class="mf">.0</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">90</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">rootfs</span><span class="mf">.1</span>
<span class="w"> </span><span class="mi">95</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">rootfs</span><span class="mf">.1</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">95</span><span class="o">%</span><span class="w"> </span><span class="n">Copying</span><span class="w"> </span><span class="nc">image</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">rootfs</span><span class="mf">.1</span>
<span class="mi">100</span><span class="o">%</span><span class="w"> </span><span class="n">Copying</span><span class="w"> </span><span class="nc">image</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">rootfs</span><span class="mf">.1</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="mi">100</span><span class="o">%</span><span class="w"> </span><span class="n">Updating</span><span class="w"> </span><span class="n">slots</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="mi">100</span><span class="o">%</span><span class="w"> </span><span class="n">Installing</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="n">idle</span>
<span class="n">Installing</span><span class="w"> </span><span class="err">`</span><span class="o">/</span><span class="k">data</span><span class="o">/</span><span class="n">encrypted</span><span class="p">.</span><span class="n">raucb</span><span class="err">`</span><span class="w"> </span><span class="n">succeeded</span>
</pre></div>
</div><p>Finally, to see that this is not all just for show but actually works, let's
exchange the decryption key with one we did not sign the bundle for:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>keys/private/private-key-3.pem<span class="w"> </span>root@localhost:/etc/rauc/crypt-key.pem
$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>keys/recipient-cert-3.pem<span class="w"> </span>root@localhost:/etc/rauc/crypt-cert.pem
</pre></div>
</div><div class="code-block">
<div class="highlight"><pre><span></span><span class="n">root</span><span class="nv">@qemux86</span><span class="o">-</span><span class="mi">64</span><span class="err">:</span><span class="o">~</span><span class="err">#</span><span class="w"> </span><span class="n">rauc</span><span class="w"> </span><span class="n">install</span><span class="w"> </span><span class="o">/</span><span class="k">data</span><span class="o">/</span><span class="n">encrypted</span><span class="p">.</span><span class="n">raucb</span>
<span class="n">installing</span>
<span class="w"> </span><span class="mi">0</span><span class="o">%</span><span class="w"> </span><span class="n">Installing</span>
<span class="w"> </span><span class="mi">0</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">states</span>
<span class="w"> </span><span class="mi">20</span><span class="o">%</span><span class="w"> </span><span class="n">Determining</span><span class="w"> </span><span class="n">slot</span><span class="w"> </span><span class="n">states</span><span class="w"> </span><span class="n">done</span><span class="p">.</span>
<span class="w"> </span><span class="mi">20</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">bundle</span>
<span class="w"> </span><span class="mi">40</span><span class="o">%</span><span class="w"> </span><span class="n">Checking</span><span class="w"> </span><span class="n">bundle</span><span class="w"> </span><span class="n">failed</span><span class="p">.</span>
<span class="mi">100</span><span class="o">%</span><span class="w"> </span><span class="n">Installing</span><span class="w"> </span><span class="n">failed</span><span class="p">.</span>
<span class="nl">LastError</span><span class="p">:</span><span class="w"> </span><span class="n">Failed</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">decrypt</span><span class="w"> </span><span class="nl">bundle</span><span class="p">:</span><span class="w"> </span><span class="n">Failed</span><span class="w"> </span><span class="k">to</span><span class="w"> </span><span class="n">decrypt</span><span class="w"> </span><span class="n">CMS</span><span class="w"> </span><span class="nl">EnvelopedData</span><span class="p">:</span><span class="w"> </span><span class="nl">error</span><span class="p">:</span><span class="mi">1</span><span class="nl">C800066</span><span class="p">:</span><span class="n">Provider</span><span class="w"> </span><span class="nl">routines</span><span class="p">:</span><span class="err">:</span><span class="n">cipher</span><span class="w"> </span><span class="k">operation</span><span class="w"> </span><span class="n">failed</span>
<span class="n">Installing</span><span class="w"> </span><span class="err">`</span><span class="o">/</span><span class="k">data</span><span class="o">/</span><span class="n">encrypted</span><span class="p">.</span><span class="n">raucb</span><span class="err">`</span><span class="w"> </span><span class="n">failed</span>
</pre></div>
</div><p>As expected, the bundle decryption fails and thus the installation is aborted
with an error.</p>
<p>You can now play around with encryption support on your own, integrate it into
your setup (if you haven't done already while following the tutorial), discuss
on our community channel <a class="reference external" href="https://app.element.io/#/room/#rauc:matrix.org">IRC/Matrix</a> or on <a class="reference external" href="https://github.com/rauc/rauc/discussions">GitHub</a>, or contact <a class="reference external" href="mailto:sales@pengutronix.de">Pengutronix</a> for professional support.</p>
</div>
</div>
<p>In its current <a class="reference external" href="https://github.com/rauc/rauc/tree/master">master</a> branch, RAUC
now supports encrypted Bundles.
This tutorial will introduce you to the basics of using encryption in
RAUC and show how to use it in a simplified Yocto setup with the <a class="reference external" href="https://github.com/rauc/meta-rauc">meta-rauc</a> Layer.</p>2022-03-31T19:00:00+01:00tag:www.pengutronix.de,2022-02-28:/2022-02-28-clt-2022.htmlCLT-2022: Voll verteilt!2022-02-28T09:56:44+01:00Marie Mann<div class="section" id="clt-2022-voll-verteilt">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3840x2160" href="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/logo-clt-2022.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/logo-clt-2022.thumb.895e9711b871149f558f29f63e5eb240.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div>
<div class="ptx-sidebar">
<div class="title">
Raum für unsere Vorträge
<div class="corner"></div>
</div>
<div class="body">
<p><a href="https://jitsi.live.linux-tage.de/global-clt22-live-pengu">https://jitsi.live.linux-tage.de/global-clt22-live-pengu</a></p>
</div>
</div>
<p>Unter dem Motto "Voll verteilt" finden die <a href="https://chemnitzer.linux-tage.de/2022/de/">Chemnitzer Linux Tage</a> auch 2022 im virtuellen Raum
statt.
Wie auch im letzten Jahr, könnt ihr uns in der bunten Pixelwelt des
Workadventures treffen und auf einen Schnack über Linux, Open Source,
oder neue Entwicklungen vorbei kommen.</p>
<div class="section" id="vortrage">
<h3>Vorträge</h3>
<ul class="simple">
<li><a href="https://chemnitzer.linux-tage.de/2022/de/programm/beitrag/141">Howto build your own home linux router</a>,
Rouven Czerwinski
<strong>Wann</strong>: Sonntag, 10:00 - Raum V4 - Dauer 90 Min.</li>
<li><a href="https://chemnitzer.linux-tage.de/2022/de/programm/beitrag/228">DOOM auf STM32: Barebox Mars Domination</a>,
Ahmad Fatoum
<strong>Wann</strong>: Sonntag, 15:00 - Raum V1 - Dauer 60 Min.</li>
</ul>
</div>
<div class="section" id="pengutronix-stand-programm">
<h3>Pengutronix Stand Programm</h3>
<table border="1" class="docutils">
<colgroup>
<col width="6%"/>
<col width="39%"/>
<col width="55%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">Wann</th>
<th class="head">Samstag, 12. März</th>
<th class="head">Sonntag, 13. März</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>11:30</td>
<td>Git-Workflows (Bastian)</td>
<td>Wie man zum Linux-Kernel beitragen kann (Roland)</td>
</tr>
<tr><td>12:30</td>
<td>Platinen für zu Hause 1: Fertigen (Chris)</td>
<td>Serielle (Linux)-Schnittstelle im eigenen Heim entdecken (Chris)</td>
</tr>
<tr><td>14:30</td>
<td>Pengutronix-Quiz</td>
<td>Pengutronix-Quiz</td>
</tr>
<tr><td>15:30</td>
<td>Platinen für zu Hause II: Löten (Chris)</td>
<td>Ansible Module nach 1/30/1000 Tagen (Björn)</td>
</tr>
<tr><td>16:30</td>
<td>15ms of F(r)ame: Video unter Linux (Philipp)</td>
<td>Berufswahl Embedded Linux Software Engineer (Marie)</td>
</tr>
<tr><td>17:30</td>
<td>Pengutronix-Quiz</td>
<td>Pengutronix-Quiz</td>
</tr>
</tbody>
</table>
<div class="section" id="pengutronix-quiz">
<h4>Pengutronix-Quiz</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x892" href="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/quiz-gewinne.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/quiz-gewinne.thumb.83e05648f72b80c359cf109e6dcd173c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><ul class="simple">
<li><strong>Samstag, 14:30 Uhr</strong></li>
<li><strong>Samstag, 17:30 Uhr</strong></li>
<li><strong>Sonntag, 14:30 Uhr</strong></li>
<li><strong>Sonntag, 17:30 Uhr</strong></li>
</ul>
<p>Stell Dich unseren Fragen rund um Open Source, Linux, den CLT und dem Rest der
Welt.
Es gibt wieder schöne Preise zu gewinnen: Darunter kleine Platinen, um löten zu
lernen und sie blinken zu lassen, hochwertige Tux-Kaffeetassen oder unsere
kultigen offline-Notebooks (Notizblöcke und Bleistifte).</p>
</div>
<div class="section" id="git-workflows">
<h4>Git-Workflows</h4>
<p><strong>Samstag, 11:30 Uhr</strong></p>
<p>[Tutorial] Welche Strategien gibt es, effektiv mit Git kollaborativ zu
arbeiten?
Wie werden Branche sinnvoll verwaltet?
Wie sieht eine gute Commit-Message aus?
Bastian beleuchtet die Fragen und Arbeitsweisen, die sich auch erfahrene
Git-Nutzer immer wieder bewusst machen sollten.</p>
<p>Voraussetzung: Git-Grundlagen</p>
</div>
<div class="section" id="platinen-fur-zuhause-1-bestellen-und-bestucken">
<h4>Platinen für Zuhause 1: Bestellen und Bestücken</h4>
<p><strong>Samstag, 12:30 Uhr</strong></p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="800x800" href="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/P2260004_800.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/P2260004_800.thumb.1095991fadef88a575703e2de6cea347.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>[Live Hacking] Am Beispiel kleiner Platinen zeigt Chris, wie diese in China
bestellt werden können, und was beim Bestücken am heimischen Küchentisch
beachtet werden sollte.</p>
</div>
<div class="section" id="platinen-fur-zuhause-2-loten-im-mini-muffin-maker">
<h4>Platinen für Zuhause 2: Löten im Mini-Muffin-Maker</h4>
<p><strong>Samstag, 15:30 Uhr</strong></p>
<p>[Live Hacking] Nachdem die Platinen bestückt sind, folgt das Löten – und für
viele kleine SMD-Bausteine legt man die Platinen lieber in einen Reflow-Ofen,
als an jede den Lötkolben zu halten.
Gängige Reflow-Öfen für zu Hause sind bekanntlich die Pizzaöfen, aber die sind
groß und nehmen Platz weg.
Chris zeigt, wie er einen Mini-Muffin-Maker in einen Reflow-Ofen verwandelt hat.</p>
</div>
<div class="section" id="ms-of-f-r-ame-video-unter-linux">
<h4>15ms of F(r)ame. Video unter Linux</h4>
<p><strong>Samstag, 16:30 Uhr</strong></p>
<p>[Tutorial] Damit ein Bild von einer Videokamera auf einem Monitor angezeigt
werden kann, muss dieses aufgenommen, umgewandelt, encodiert, übertragen,
decodiert und wieder umgewandelt werden.
Philipp und Robert schauen sich diese Kette an und entmystifizieren,
was in Hardware und Software passiert, damit ihr diesen Vortrag auf
eurem Monitor sehen könnt.</p>
</div>
<div class="section" id="wie-man-zum-linux-kernel-beitragen-kann">
<h4>Wie man zum Linux-Kernel beitragen kann</h4>
<p><strong>Sonntag, 11:30 Uhr</strong></p>
<p>[Live Hacking] Roland schickt einen Kernel-Patch ab und erklärt dabei, wie ihr
ebenfalls ganz leicht zu Linux beitragen könnt.
Ihr erfahrt, was überhaupt dieses "Mainline-Linux" ist, und wie der
Linux-Kernel-Patch- Workflow funktioniert.
Welche Qualitätsstandards gibt es, und wie könnt ihr überprüfen, dass ihr diese
auch einhaltet?</p>
</div>
<div class="section" id="serielle-linux-schnittstelle-im-eigenen-heim-entdecken">
<h4>Serielle (Linux)-Schnittstelle im eigenen Heim entdecken</h4>
<p><strong>Sonntag, 12:30 Uhr</strong></p>
<p>[Live Hacking] Chrissi nimmt euch mit auf eine Entdeckungstour
durch seine Wohnung und schaut mal, in welchen Geräten sich
überall serielle Schnittstellen verbergen und was man damit so
anstellen kann.</p>
</div>
<div class="section" id="ansible-module-nach-1-30-1000-tagen">
<h4>Ansible Module nach 1/30/1000 Tagen</h4>
<p><strong>Sonntag, 15:30 Uhr</strong></p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="800x640" href="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/P2260017_800.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-28_clt-2022/P2260017_800.thumb.ba9abd99c66c777dd3e9c6cebc0a3d63.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>[Tutorial] In der letzten Zeit hat sich Björn viel mit Ansible beschäftigt.
Er nimmt euch mit auf einen Streifzug duch real existierende Firmenstruktur.
Dabei berichtet Björn von seiner Reise in die Benutzung von Ansible und wie sich
seine Erkenntnis entwickelt haben.
Welche Muster vermeidet er nach 1000 Tagen, die er nach 30 noch benutzt hat?
Welche Herangehensweise und welche Struktur hat sich bewährt? Außerdem erfahrt
ihr, warum es sich lohnt, White Papers zu lesen.</p>
</div>
<div class="section" id="berufswahl-embedded-linux-software-engineer">
<h4>Berufswahl Embedded Linux Software Engineer</h4>
<p><strong>Sonntag, 16:30 Uhr</strong></p>
<p>Frontend-, Backend-, Full-Stack-Softwareentwickler – die Stellenausschreibungen
sind dutzendfach, und jeder, der sich für eine Karriere in der IT interessiert,
hat eine ungefähre Vorstellung davon, was sich dahinter verbirgt.
Aber was ist ein Embedded Engineer?
Wie werden BSPs integriert und was ist das überhaupt?
Marie unterhält sich mit ihren Kollegen über ihre tägliche Arbeit als Embedded
Linux Sofrtware Engineer, welche Herausforderungen ihnen begegnen und wie sie
eigentlich bei Pengutronix gelandet sind.</p>
</div>
</div>
</div>
<p>Unter dem Motto "Voll verteilt" finden die <a href="https://chemnitzer.linux-tage.de/2022/de/">Chemnitzer Linux Tage</a> auch 2022 im virtuellen Raum
statt.
Wie auch im letzten Jahr, könnt ihr uns in der bunten Pixelwelt des
Workadventures treffen und auf einen Schnack über Linux, Open Source,
oder neue Entwicklungen vorbei kommen.</p>2022-02-28T09:56:44+01:00tag:www.pengutronix.de,2022-02-17:/2022-02-17-first-steps-using-the-candlelight.htmlFirst Steps using the candleLight2022-02-17T14:55:50+01:00Marc Kleine-BuddeLeonard Göhrs<div class="section" id="first-steps-using-the-candlelight">
<p>So you went and got yourself one of our fancy rocket-penguin branded
<a class="reference external" href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00">CandleLight dongles</a>
or, being the die hard hacker you are, went and soldered one up in your toaster
oven labeled "not food safe". What's next then? How do you use this thing?
Let's answer these question by grabbing a Raspberry Pi and exploring some of the
possibilities.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/JqTBzDN7VOk"></iframe>
</div>
<p>On our Pi we will be using the October 30th 2021 release of the
<a class="reference external" href="https://www.raspberrypi.com/software/operating-systems/">"Raspberry Pi OS"</a>.
Once the Pi is booted you should first of all log in and make sure that you have
a working internet connection.
Once that's done yo can go ahead and install the <tt class="docutils literal"><span class="pre">can-utils</span></tt> packet using
<tt class="docutils literal">apt</tt>.
<tt class="docutils literal"><span class="pre">can-utils</span></tt> will come in handy for sending and receiving CAN message to/from
the CAN bus:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ sudo apt install can-utils
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
can-utils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 118 kB of archives.
After this operation, 492 kB of additional disk space will be used.
Get:1 http://ftp.halifax.rwth-aachen.de/raspbian/raspbian bullseye/main armhf can-utils ar
Fetched 118 kB in 1s (161 kB/s)
Selecting previously unselected package can-utils.
(Reading database ... 40796 files and directories currently installed.)
Preparing to unpack .../can-utils_2020.11.0-1_armhf.deb ...
Unpacking can-utils (2020.11.0-1) ...
Setting up can-utils (2020.11.0-1) ...
Processing triggers for man-db (2.9.4-2) ...
</pre>
<p>If you did not yet connect the CandleLight you should see that the <tt class="docutils literal">gs_usb</tt>
driver, that's responsible for handling the CandleLight, has not been loaded.
We would also not expect to see any CAN interfaces already present on the Pi.
Let's confirm these assumpptions using a few commands on the commandline:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ lsmod | grep gs_usb
pi@raspberrypi:~ $ ip addr show can0
Device "can0" does not exist.
</pre>
<p>We do however expect both of these things to change once we have connected the
CandleLight to the Pi.
Let's do so and have a look at the kernel log for confirmation:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ journalctl -kn9
-- Journal begins at Sat 2021-10-30 12:29:41 BST, ends at Wed 2022-01-19 13:49:39 GMT. --
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: new full-speed USB device number 4 using xh
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: New USB device found, idVendor=1d50, idProd
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: New USB device strings: Mfr=1, Product=2, S
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: Product: candleLight USB to CAN adapter
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: Manufacturer: bytewerk
Jan 19 13:49:39 raspberrypi kernel: usb 1-1.1: SerialNumber: 000000000002
Jan 19 13:49:39 raspberrypi kernel: CAN device driver interface
Jan 19 13:49:39 raspberrypi kernel: gs_usb 1-1.1:1.0: Configuring for 1 interfaces
Jan 19 13:49:39 raspberrypi kernel: usbcore: registered new interface driver gs_usb
</pre>
<p>We can see that the USB device was detected and the <tt class="docutils literal">gs_usb</tt> driver was
loaded.
But do we also see a CAN interface?:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ ip addr show can0
5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
link/can
</pre>
<p>Yes we do!</p>
<div class="section" id="configuring-the-link">
<h3>Configuring the Link</h3>
<p>A CAN device does not perform the kinds of autonegotiation you've come to expect
from regular network devices.
Instead we'll have to manually configure some CAN parameters before connecting a
CandleLight to an existing bus.
If you're lucky this only meens setting the bitate.
For a bus operating at 500 kbit/s this can be done using the following command:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ sudo ip link set dev can0 up type can bitrate 500000
</pre>
<p>Now we see the status of the <tt class="docutils literal">can0</tt> CandleLight-Inteface is "<tt class="docutils literal">UP</tt>", which means
it's started:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ ip addr show can0
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
link/can
</pre>
<p>With the <tt class="docutils literal">ip</tt> tool we can query CAN specific options:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ ip -details -statistic link show can0
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group defa
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 48000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 n
RX: bytes packets errors dropped missed mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
</pre>
<p>The device is in "state ERROR-ACTIVE", which means that it is happily up and
running and listening for CAN messages. We also see that it's
configured for 500 kbit/s with a sample point of 87.5% (<tt class="docutils literal">bitrate
500000 <span class="pre">sample-point</span> 0.875</tt>).</p>
</div>
<div class="section" id="candump">
<h3><tt class="docutils literal">candump</tt></h3>
<p>Now let's receive some CAN messages. To do so we are going to start the
<tt class="docutils literal">candump</tt> tool and let it decode the incoming messages.
In order for it to receiv anything there has to be a sending node on the bus,
in this case this is just another CandleLight plugged into my laptop:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ candump any,0:0,#FFFFFFFF -extA
(2022-01-19 13:51:50.144617) can0 RX - - 002 [4] 04 00 00 00
(2022-01-19 13:51:50.644835) can0 RX - - 002 [5] 05 00 00 00 00
(2022-01-19 13:51:51.145058) can0 RX - - 002 [6] 06 00 00 00 00 00
(2022-01-19 13:51:51.645290) can0 RX - - 002 [7] 07 00 00 00 00 00 00
(2022-01-19 13:51:52.145435) can0 RX - - 002 [8] 08 00 00 00 00 00 00 00
(2022-01-19 13:51:52.645477) can0 RX - - 002 [1] 09
(2022-01-19 13:51:53.145785) can0 RX - - 002 [1] 0A
(2022-01-19 13:51:53.645952) can0 RX - - 002 [2] 0B 00
(2022-01-19 13:51:54.146142) can0 RX - - 002 [3] 0C 00 00
(2022-01-19 13:51:54.646362) can0 RX - - 002 [4] 0D 00 00 00
(2022-01-19 13:51:55.146577) can0 RX - - 002 [5] 0E 00 00 00 00
(2022-01-19 13:51:55.646752) can0 RX - - 002 [6] 0F 00 00 00 00 00
(2022-01-19 13:51:56.146970) can0 RX - - 002 [7] 10 00 00 00 00 00 00
(2022-01-19 13:51:56.647190) can0 RX - - 002 [8] 11 00 00 00 00 00 00 00
(2022-01-19 13:51:57.147229) can0 RX - - 002 [1] 12
(2022-01-19 13:51:57.647433) can0 RX - - 002 [1] 13
(2022-01-19 13:51:58.147653) can0 RX - - 002 [2] 14 00
(2022-01-19 13:51:58.647844) can0 RX - - 002 [3] 15 00 00
(2022-01-19 13:51:59.147993) can0 RX - - 002 [4] 16 00 00 00
(2022-01-19 13:51:59.648122) can0 RX - - 002 [5] 17 00 00 00 00
(2022-01-19 13:52:00.148298) can0 RX - - 002 [6] 18 00 00 00 00 00
^C
</pre>
<p>Once you have seen enough you can quit the capture using <tt class="docutils literal">Ctrl+c</tt>.</p>
</div>
<div class="section" id="cansend">
<h3><tt class="docutils literal">cansend</tt></h3>
<p>Next, let's send some CAN messages, in order to have someone to receive these
messages I've started the <tt class="docutils literal">candump</tt> command on my laptop.
To send messages instead of dumping them we can use <tt class="docutils literal">cansend</tt>.
When starting <tt class="docutils literal">cansend</tt> without arguments it shows some
examples how CAN messages are encoded on the command line:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ cansend
cansend - send CAN-frames via CAN_RAW sockets.
Usage: cansend <device> <can_frame>.
<can_frame>:
<can_id>#{data} for 'classic' CAN 2.0 data frames
<can_id>#R{len} for 'classic' CAN 2.0 data frames
<can_id>##<flags>{data} for CAN FD frames
<can_id>:
3 (SFF) or 8 (EFF) hex chars
{data}:
0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.')
{len}:
an optional 0..8 value as RTR frames can contain a valid dlc field
<flags>:
a single ASCII Hex value (0 .. F) which defines canfd_frame.flags
Examples:
5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311223344 /
1F334455#1122334455667788 / 123#R / 00000123#R3
</pre>
<p>Let's send the can message with data <tt class="docutils literal">ff 01 00 00 00 00 00 22</tt> (all
values in hex) with CAN-ID <tt class="docutils literal">0x023</tt> on our CandleLight:</p>
<pre class="literal-block">
pi@raspberrypi:~ $ cansend can0 023#ff.01.00.00.00.00.00.22
</pre>
<p>The command expects the data bytes without spaces, but you can use <tt class="docutils literal">.</tt>
for separation. The receiving side shows:</p>
<pre class="literal-block">
➜ (pts/40) frogger@hardanger:socketcan/linux-rpi (rpi-v5.16) candump any,0:0,#FFFFFFFF -ex
(2022-01-19 14:52:31.979395) can0 RX - - 023 [8] FF 01 00 00 00 00 00 22
</pre>
<p>With the <tt class="docutils literal">candump</tt> and <tt class="docutils literal">cansend</tt> commands most of your CAN sending and
dumping needs should be covered. But there is also a third command that comes in
handy from time to time.</p>
</div>
<div class="section" id="cangen">
<h3><tt class="docutils literal">cangen</tt></h3>
<p>The <tt class="docutils literal">cangen</tt> command is used to generate lots of CAN messages.
If you start it like shown belog it will send CAN messages with an increasing
counter (<cite>-Di</cite>) with increasing length (<tt class="docutils literal"><span class="pre">-Li</span></tt>), on CAN-ID 2 (<tt class="docutils literal"><span class="pre">-I2</span></tt>) with a
gap of 500 ms in between each CAN frame (<tt class="docutils literal"><span class="pre">-g</span> 500</tt>).
If you try and send more messages than the bus or controller can handle
<tt class="docutils literal">cangen</tt> will retry after 10 ms (<tt class="docutils literal"><span class="pre">-g10</span></tt>):</p>
<pre class="literal-block">
pi@raspberrypi:~ $ cangen can0 -Di -Li -I2 -p10 -g 500
</pre>
<p>The receiver show this:</p>
<pre class="literal-block">
➜ (pts/40) frogger@hardanger:socketcan/linux-rpi (rpi-v5.16) candump any,0:0,#FFFFFFFF -ex
(2022-01-19 14:52:45.159111) can0 RX - - 002 [1] 00
(2022-01-19 14:52:45.659342) can0 RX - - 002 [1] 01
(2022-01-19 14:52:46.159425) can0 RX - - 002 [2] 02 00
(2022-01-19 14:52:46.659597) can0 RX - - 002 [3] 03 00 00
(2022-01-19 14:52:47.159744) can0 RX - - 002 [4] 04 00 00 00
(2022-01-19 14:52:47.659815) can0 RX - - 002 [5] 05 00 00 00 00
(2022-01-19 14:52:48.159983) can0 RX - - 002 [6] 06 00 00 00 00 00
(2022-01-19 14:52:48.660118) can0 RX - - 002 [7] 07 00 00 00 00 00 00
(2022-01-19 14:52:49.160262) can0 RX - - 002 [8] 08 00 00 00 00 00 00 00
(2022-01-19 14:52:49.660324) can0 RX - - 002 [1] 09
(2022-01-19 14:52:50.160334) can0 RX - - 002 [1] 0A
(2022-01-19 14:52:50.660485) can0 RX - - 002 [2] 0B 00
(2022-01-19 14:52:51.160733) can0 RX - - 002 [3] 0C 00 00
(2022-01-19 14:52:51.660876) can0 RX - - 002 [4] 0D 00 00 00
(2022-01-19 14:52:52.161052) can0 RX - - 002 [5] 0E 00 00 00 00
(2022-01-19 14:52:52.661169) can0 RX - - 002 [6] 0F 00 00 00 00 00
(2022-01-19 14:52:53.161308) can0 RX - - 002 [7] 10 00 00 00 00 00 00
(2022-01-19 14:52:53.661451) can0 RX - - 002 [8] 11 00 00 00 00 00 00 00
(2022-01-19 14:52:54.161489) can0 RX - - 002 [1] 12
(2022-01-19 14:52:54.661626) can0 RX - - 002 [1] 13
(2022-01-19 14:52:55.161793) can0 RX - - 002 [2] 14 00
(2022-01-19 14:52:55.661923) can0 RX - - 002 [3] 15 00 00
(2022-01-19 14:52:56.162071) can0 RX - - 002 [4] 16 00 00 00
(2022-01-19 14:52:56.662295) can0 RX - - 002 [5] 17 00 00 00 00
(2022-01-19 14:52:57.162353) can0 RX - - 002 [6] 18 00 00 00 00 00
(2022-01-19 14:52:57.662560) can0 RX - - 002 [7] 19 00 00 00 00 00 00
</pre>
<p>And will continue to do so, until we stop it or the sender.
Next up: figure out where the CAN bus of your CAR is and which bit rate
is uses.
Given what you've learned you should be well prepared to dump the messages on
its CAN busses.
The rest is left as an exercise to the reader.</p>
</div>
</div><p>So you went and got yourself one of our fancy rocket-penguin branded
<a class="reference external" href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00">CandleLight dongles</a>
or, being the die hard hacker you are, went and soldered one up in your toaster
oven labeled "not food safe". What's next then? How do you use this thing?
Let's answer these question by grabbing a Raspberry Pi and exploring some of the
possibilities.</p>2022-02-17T14:55:50+01:00tag:www.pengutronix.de,2022-02-11:/2022-02-11-fosdem-2022-recap.htmlPengutronix at FOSDEM 20222022-02-11T10:00:22+01:00Chris FiegeJan Lübbe<div class="section" id="pengutronix-at-fosdem-2022">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="771x1024" href="https://www.pengutronix.de/media/blog/2022/2022-02-08_fosdem-2022-recap/waffle.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-08_fosdem-2022-recap/waffle.thumb.d183626ad519d1a1f5d3ed3c4ec8a8bf.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>German <em>Herzwaffeln</em> as a makeshift replacement for the real Belgian thing.</p>
</figcaption>
</figure>
</div><p>"FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels."
-- <a href="https://fosdem.org/2022/">FOSDEM</a></p>
<p>Sadly in 2022 we, again, gathered online instead of in Brussels.
But this did not stop us from searching local supermarkets for Belgian beers
and baking our own waffles. (What would FOSDEM be without beer and waffles!)</p>
<p>We want to thank the FOSDEM team, all volunteers, devroom staff, speakers and
guests for this great event.
We hope to meet in Brussels in 2023!</p>
<p>In this post we want to recommend a few talks that we think are especially interesting.</p>
<div class="section" id="jan-s-suggestions">
<h3>Jan's Suggestions</h3>
<div class="section" id="what-s-coming-in-virtio-1-2-new-virtual-i-o-devices-and-features">
<h4>What's coming in VIRTIO 1.2 - new virtual I/O devices and features</h4>
<p>Stefan Hajnoczi's excellent talk gives a concise overview of VIRTIO in general
and the many improvements added in version 1.2 of the standard.
From the embedded perspective, especially the new specifications for GPIO, I2C,
SCMI, RPMB and sound are interesting, as they also allow moving the direct control
of the physical interfaces to isolated co-processors on the same SoC for safety-related
scenarios.</p>
<p>Even if you're new to VIRTIO, this talk is a well worth your time.</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/vai_virtualio/">Abstract and slides</a></li>
<li><a href="https://video.fosdem.org/2022/D.virtualization/vai_virtualio.webm">Recording</a></li>
</ul>
</div>
<div class="section" id="arm-cca-enablement-through-the-trusted-firmware-community-project">
<h4>Arm CCA enablement through the Trusted Firmware community project</h4>
<p>With the introduction of the Confidential Compute Architecture (CCA) in the ARMv9 architecture,
some changes are coming: in addition to the normal world (Linux) and secure world (TrustZone/OP-TEE),
the new CPUs support multiple "Realms".
A Realm is protected against access from other contexts by default and can optionally allow access
to parts of it's memory for communication with the rest of the system.</p>
<p>In their talk, Charles Garcia-Tobin and Matteo Carlini explain
how the different software components will work together to
allow use of these new hardware features.</p>
<p>If you are currently using OP-TEE on ARMv7/8, this is a must-see.</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/tee_arm_cca/">Abstract</a></li>
<li><a href="https://video.fosdem.org/2022/D.trusted-hardware/tee_arm_cca.webm">Recording</a></li>
</ul>
</div>
<div class="section" id="ply-lightweight-ebpf-tracing">
<h4>ply: lightweight eBPF tracing</h4>
<p>On servers, bpftrace and BCC are powerful tools to analyze how the system
(or just the kernel) behaves while under real-world load.
As these tools use the LLVM toolchain to generate the eBPF bytecode, they are
not very lightweight when seen from an embedded background.</p>
<p>In his talk, Frank Vasquez gives an introduction to the ply tracing tool.
It just needs the libc and a modern kernel, while supporting aarch64,
arm, powerpc and x86_64.
The trace probes are written in a custom language (describe by Frank as awk-like).
It can probe kernel function entry/return, any kernel tracepoint and also any
instruction (via dynamic probes).
Optionally, maps can be used to aggregate results.</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/ply_ebpf/">Abstract</a></li>
<li>Recording: not yet available</li>
</ul>
</div>
<div class="section" id="playstation-3-emulation-re-implementing-the-impossible">
<h4>PlayStation 3 emulation - (re)implementing the impossible</h4>
<p>Alexandro Sanchez Bach gave a highly information-packed one-hour talk about the
PlayStation 3 and how it is emulated by RPCS3.
RPCS3 was started more than 10 years ago and is now capable of running about 65%
of the games in a playable state.
The PS3's unique system architecture (CPU with 1xPPE+8xSPE and a discrete GPU)
makes for a challenging emulation target, but also a very interesting story of
how the project continues to improve.</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/ps3/">Abstract and slides</a></li>
<li><a href="https://video.fosdem.org/2022/D.emulator/ps3.webm">Recording</a></li>
</ul>
</div>
</div>
<div class="section" id="chris-suggestions">
<h3>Chris' suggestions</h3>
<div class="section" id="kicad-project-update">
<h4>KiCad project update</h4>
<p>KiCad is <em>the</em> open source PCB design tool for professionals.
At Pengutronix we use KiCad for all electronics development such as the
<a href="https://www.linux-automation.com/en/products/usb-sd-mux.html">USB-SD-Mux</a>.</p>
<p>Like every year at FOSDEM, Wayne Stambaugh talked about the state of the project.
And like every year the KiCad developers have delivered a lot of useful new features
for the
<a href="https://www.kicad.org/blog/2021/12/KiCad-6.0.0-Release/">KiCad 6 release</a>.</p>
<p>This talk is a must-see if you use KiCad!</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/kicad/">Abstract, Slides and Recording</a></li>
</ul>
</div>
<div class="section" id="advanced-pcb-simulation-with-kicad-introduction-to-ibis-and-fem-based-simulations">
<h4>Advanced PCB simulation with KiCad - introduction to IBIS and FEM-based simulations</h4>
<p>At the moment, KiCad has support for SPICE simulations using
<a href="http://ngspice.sourceforge.net/">ngspice</a> as the backend.
SPICE simulations allow us to model time- and frequency- domain
behavior of electronic components.
This is a great tool if you want to develop, for example, an analog circuit around an OpAmp.</p>
<p>In this talk Fabien Corona presents his work on two more simulation approaches for KiCad:</p>
<p>First: integrate a FEM (finite element model) simulation into KiCad.
He shows a prototype based on KiCad, Gmsh and Sparselizard that allows us to do
current density,
voltage drop,
plane capacitance analysis
and more on a KiCad PCB.</p>
<p>Second: the integration of IBIS-models into the SPICE simulation in KiCad.
IBIS-models contain an electrical description of the properties of an input or output pin of
an integrated circuit.
With IBIS capabilities, the KiCad SPICE simulation would not only be able to simulate simple
analog circuits but also complex mixed signal ICs in their circuit.</p>
<p>These functions currently only exist in a fork of KiCad and are not yet ready for production.
But his talk lets me really hope that these features will be available in KiCad in a few years!</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/advanced_sim/">Abstract and Slides</a></li>
<li>Recording: not yet available</li>
</ul>
</div>
<div class="section" id="a-brief-history-of-spreadsheets-from-lanpar-to-visicalc-to-lotus-to-libreoffice">
<h4>A brief history of spreadsheets - from LANPAR to VisiCalc to Lotus to LibreOffice</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="800x800" href="https://www.pengutronix.de/media/blog/2022/2022-02-08_fosdem-2022-recap/beer.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-08_fosdem-2022-recap/beer.thumb.398d4cf9aa0de2ba1d366a16ff8161d7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Cold beer during this talk in our <a href="https://stratum0.org">hackerspace</a>.</p>
</figcaption>
</figure>
</div><p>Ever wondered why spreadsheets look like a relic from the 1970s?
That is because a lot of their properties are based on software from the last century...</p>
<p>In this talk Jim Hall traces the origin of modern office software back to 1969.
He even does live demos using the original software.</p>
<p>This talk is not so much about open source, but it is a good opportunity to grab a cold
beverage and relax. 🙂</p>
<ul class="simple">
<li><a href="https://fosdem.org/2022/schedule/event/retro_spreadsheets/">Abstract:</a></li>
<li>Recording: not yet available</li>
</ul>
</div>
</div>
</div>
<p>"FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels."
-- <a href="https://fosdem.org/2022/">FOSDEM</a></p>2022-02-11T10:00:22+01:00tag:www.pengutronix.de,2022-02-10:/2022-02-10-rauc-v1-6-released.htmlRAUC v1.6 Released2022-02-10T13:00:00+01:00Enrico Jörns<div class="section" id="rauc-v1-6-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.6 release of RAUC</p>
<p>GitHub <a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.6">release page</a></p>
</div>
</div>
<p>While major changes are about to come, the RAUC v1.6 release already paves the
way under the hood.
Built-in <a class="reference external" href="https://github.com/rauc/rauc/pull/755">streaming support</a>
will be one of the next features built on top of the 'verity' bundle
format in RAUC.</p>
<p>But even if the v1.6 release contains only some preparations with regards to
streaming support, it provides a number of other new features and fixes worth
mentioning.
They originate from 63 merged pull requests with a total of
<a class="reference external" href="https://github.com/rauc/rauc/compare/v1.5.1...v1.6">181 commits</a>.</p>
<p>A special thanks goes out to the notable number of first-time contributors
showing RAUC's growing popularity and community!</p>
<p>Below you will find an excerpt of things that have changed since RAUC v1.5.1.
For a complete list, refer to the
<a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.6">release notes</a></p>
<div class="section" id="improved-misconfiguration-checking-and-handling">
<h3>Improved Misconfiguration Checking and Handling</h3>
<p>This release adds some more protections against common pitfalls when
configuring RAUC.
One of the most obvious is that commands like <tt class="docutils literal">rauc service</tt>, which cannot work
without a system configuration present, will now refuse to start without a valid
configuration.</p>
<p>Also common mistakes in the configuration of slots and hooks are now checked
and reported during parsing.</p>
</div>
<div class="section" id="new-slot-types-for-flash-storage">
<h3>New Slot Types for Flash Storage</h3>
<p>Although use of raw flash storage is being phased out in favor of eMMCs, there
are still some use cases for them.
RAUC received support for two new slot types.</p>
<div class="row"><div class="col-sm-6"><p>With</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[slot.rootfs.0]</span>
<span class="na">type</span><span class="o">=</span><span class="s">nor</span>
<span class="na">...</span>
</pre></div>
</div><p>it now supports writing images to raw NOR flash (using flashcp).</p>
<div class="clearfix"></div></div><div class="col-sm-6"><p>With</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[slot.rootfs.0]</span>
<span class="na">type</span><span class="o">=</span><span class="s">jffs2</span>
<span class="na">...</span>
</pre></div>
</div><p>writing a JFFS2 partition from a tar archive is supported.</p>
<div class="clearfix"></div></div></div></div>
<div class="section" id="improved-hook-handling">
<h3>Improved Hook Handling</h3>
<p>Hook handling gained improvements in various ways in this release:</p>
<ul>
<li><p class="first">Hook configuration parsing and handling gained some consistency checks to
prevent manifest authors from running into common misconfiguration, misspelling
etc.</p>
</li>
<li><p class="first">Pre- and post-install hooks of boot-* slots now support manipulation of
data written due to changed execution order and additional information passed via
environment variables.</p>
</li>
<li><p class="first">If an image is given, hooks now also have access to the size of the image in the
environment variable <tt class="docutils literal">RAUC_IMAGE_SIZE</tt>.</p>
</li>
<li><p class="first">Installing a slot using an <tt class="docutils literal">install</tt> slot hook will now be more visible in
the log which now prints:</p>
<pre class="literal-block">
Updating /dev/sda5 with 'install' slot hook
</pre>
</li>
</ul>
</div>
<div class="section" id="install-hooks-for-data-migration">
<h3>Install Hooks for Data Migration</h3>
<p>A potential use case for <tt class="docutils literal">install</tt> hooks (that allow to fully customize the
slot installation) is to use them for copying the content of one <strong>redundant
data partition</strong> to the other one.
While this does not require any image at all, having an image (i.e.
<tt class="docutils literal">filename</tt> set) for a slot was mandatory so far.
With this release, you can now omit the <tt class="docutils literal">filename</tt> property if an
<tt class="docutils literal">install</tt> slot hook is used.</p>
<div class="row"><div class="col-sm-4"><p>The manifest would then contain:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[hooks]</span>
<span class="na">filename</span><span class="o">=</span><span class="s">hooks.sh</span>
<span class="na">...</span>
<span class="k">[image.datafs]</span>
<span class="na">hooks</span><span class="o">=</span><span class="s">install</span>
</pre></div>
</div><div class="clearfix"></div></div><div class="col-sm-8"><p>Copying can then be done with this (simplified) hook snippet for example:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">case</span><span class="w"> </span><span class="s2">"</span><span class="nv">$1</span><span class="s2">"</span><span class="w"> </span><span class="k">in</span>
<span class="w"> </span>slot-install<span class="o">)</span>
<span class="w"> </span>mkdir<span class="w"> </span>-p<span class="w"> </span><span class="nv">$RAUC_MOUNT_PREFIX</span>/data
<span class="w"> </span>mkfs.ext4<span class="w"> </span><span class="nv">$RAUC_SLOT_DEVICE</span>
<span class="w"> </span>mount<span class="w"> </span><span class="nv">$RAUC_SLOT_DEVICE</span><span class="w"> </span><span class="nv">$RAUC_MOUNT_PREFIX</span>/data
<span class="w"> </span>cp<span class="w"> </span>-a<span class="w"> </span>/data/*<span class="w"> </span><span class="nv">$RAUC_MOUNT_PREFIX</span>/data/
<span class="w"> </span>umount<span class="w"> </span><span class="nv">$RAUC_MOUNT_PREFIX</span>/data
<span class="w"> </span><span class="p">;;</span>
<span class="o">[</span>...<span class="o">]</span>
</pre></div>
</div><div class="clearfix"></div></div></div></div>
<div class="section" id="mounting-rauc-bundles-on-the-target">
<h3>Mounting RAUC Bundles on the Target</h3>
<div class="row"><div class="col-sm-6"><p>The new <tt class="docutils literal">rauc mount</tt> command was added as a preparation for the
upcoming streaming support where a simple <tt class="docutils literal">mount</tt> call will not be
sufficient anymore for mounting the bundle (for development or
debugging purposes).</p>
<p>However, you can already benefit from this command in terms of
convenience and security as this ensures the bundle is verified and
protected against malicious access.</p>
<div class="clearfix"></div></div><div class="col-sm-6"><div class="admonition important">
<p class="first admonition-title">Important</p>
<p class="last">Note that this is really only meant for development / debugging
purposes and not for misusing RAUC bundles as a signed container.</p>
</div>
<div class="clearfix"></div></div></div><div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>rauc<span class="w"> </span>mount<span class="w"> </span>/path/to/bundle.raucb
Mounted<span class="w"> </span>bundle<span class="w"> </span>at<span class="w"> </span>/mnt/rauc/bundle.<span class="w"> </span>Use<span class="w"> </span><span class="s1">'umount /mnt/rauc/bundle'</span><span class="w"> </span>to<span class="w"> </span>unmount
$<span class="w"> </span>umount<span class="w"> </span>/mnt/rauc/bundle
</pre></div>
</div></div>
<div class="section" id="manual-signature-extraction-and-replacement-for-external-signing">
<h3>Manual Signature Extraction and Replacement for External Signing</h3>
<p>In some use-cases it is required that the bundle signature is created in a
dedicated isolated room or environment where external tools like <tt class="docutils literal">rauc</tt> are
not permitted.</p>
<p>The new commands <tt class="docutils literal">rauc <span class="pre">extract-signature</span></tt> and <tt class="docutils literal">rauc <span class="pre">replace-signature</span></tt>
target this use case.
See the <a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#external-signing-and-pki">documentation</a>
for a comprehensive example on how to use it in this scenario.</p>
<p>The <tt class="docutils literal"><span class="pre">extract-signature</span></tt> command can also be useful when manually debugging
signing or verification issues.</p>
<p>With</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>./rauc<span class="w"> </span>extract-signature<span class="w"> </span>--keyring<span class="w"> </span>test/openssl-ca/dev-ca.pem<span class="w"> </span>test/good-verity-bundle.raucb<span class="w"> </span>extracted-signature.cms
</pre></div>
</div><p>you get the extracted signature that (for the 'verity' bundle format) you can process using openssl cmdline tool to either inspect the ASN1 content</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>openssl<span class="w"> </span>cms<span class="w"> </span>-verify<span class="w"> </span>-CAfile<span class="w"> </span>test/openssl-ca/dev-ca.pem<span class="w"> </span>-out<span class="w"> </span>manifest.raucm<span class="w"> </span>-inform<span class="w"> </span>DER<span class="w"> </span>-in<span class="w"> </span>extracted-signature.cms
</pre></div>
</div><p>or extract the inline manifest.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>openssl<span class="w"> </span>asn1parse<span class="w"> </span>-inform<span class="w"> </span>der<span class="w"> </span>-in<span class="w"> </span>extracted-signature.cms
</pre></div>
</div></div>
<div class="section" id="trusted-host-environment">
<h3>Trusted Host Environment</h3>
<p>When using <tt class="docutils literal">rauc convert</tt> with the older <tt class="docutils literal">plain</tt> format, people encountered
problems by the 'trusted environments' checks that were introduced as a
mitigation for
<a class="reference external" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25860">CVE-2020-25860</a>
with RAUC v1.5.</p>
<p>The new option <tt class="docutils literal"><span class="pre">--trust-environment</span></tt> allows to explicitly override these checks for
<tt class="docutils literal">rauc convert</tt>.</p>
<p>Similar to this, a new option <tt class="docutils literal"><span class="pre">--no-check-time</span></tt> was added for <tt class="docutils literal">rauc resign</tt>
and <tt class="docutils literal">rauc info</tt> to allow ignoring a possibly incorrect system clock on the host
system.</p>
</div>
<div class="section" id="testing">
<h3>Testing</h3>
<p>In 2021, as Docker decided to remove autobuilds from their free plan, we
switched to GitHub Actions for building our test container.</p>
<p>A new <a class="reference external" href="https://github.com/rauc/rauc/actions/workflows/scan-build.yml">scan-build</a>
workflow adds another static code checker to our CI to detect potential issues
early.
However, we had to disable memory leakage checks since llvm is not yet able
to deal with glib's autofree handling.</p>
</div>
<div class="section" id="testing-changes-in-an-interactive-qemu-system">
<h3>Testing Changes in an Interactive QEMU System</h3>
<p>The <a class="reference external" href="https://github.com/rauc/rauc/blob/master/qemu-test">qemu-test</a> script,
that is primarily meant for executing the RAUC test suite under QEMU, got a new
<tt class="docutils literal">system</tt> argument.
With this specified, the QEMU will roughly behave like a system running RAUC.
It will boot into an interactive shell, start the RAUC service, etc.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>./qemu-test<span class="w"> </span>system
</pre></div>
</div><div class="code-block">
<div class="highlight"><pre><span></span># rauc status
=== System Info ===
Compatible: Test Config
Variant:
Booted from: rootfs.0 (A)
[..]
</pre></div>
</div><p>You can use this for a quick interactive test of changes done to the code.</p>
</div>
<div class="section" id="documentation">
<h3>Documentation</h3>
<p>In the past, we have seen some people running into misconfiguration or
misinterpretation of how the RAUC <tt class="docutils literal"><span class="pre">boot-mbr/gpt-switch</span></tt> slot types and
feature is to be configured.
A partial rewrite of <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#update-boot-partition-in-mbr">these sections</a>
should prevent this in the future.</p>
</div>
<div class="section" id="bugs-fixed">
<h3>Bugs Fixed</h3>
<p>Some of the bugs that were fixed since v1.5.1:</p>
<ul class="simple">
<li>The check for 'safe' file systems that was introduced as a CVE mitigation in
v1.5 now also allows installing bundles from ZFS and ramfs.</li>
<li>An unexpected abort of raw image copying could have led to a file descriptor
being left open (potentially preventing further installations until a service
restart).</li>
<li>A failed boot state determination of single slots sometimes led to all slots
being displayed as <em>bad</em>.</li>
<li>The VFAT filesystem label names generated by RAUC didn't pass the stricter
checks in new <tt class="docutils literal">mkfs.vfat</tt> versions.
The generation was adapted to always emit valid label names.</li>
<li>Limiting the bundle download size did not work when the server does not advertise
the content size.</li>
</ul>
</div>
<div class="section" id="thanks">
<h3>Thanks!</h3>
<p>... to the long list of contributors since v1.5.1:</p>
<p>Ahmad Fatoum, Alexander Dahl, Arnaud Rebillout,
Bastian Krause, Christian Hitz, Christoph Steiger, Daniel Mack, Enrico
Jörns, Fabian Büttner, Holger Assmann, Ian Abbott, Jan Lübbe,
Jean-Pierre Geslin, Ladislav Michl, Livio Bieri, Ludovico de Nittis,
Marcel Hellwig, Michael Heimpold, Michael Tretter, Omer Akram, Pascal
Huerst, Richard Forro, Roland Hieber, Rouven Czerwinski, Sijmen
Huizenga, Taras Zaporozhets, Vivien Didelot, Vyacheslav Yurkov.</p>
</div>
</div>
<p>While major changes are about to come, the RAUC v1.6 release already paves the
way under the hood.
Built-in <a class="reference external" href="https://github.com/rauc/rauc/pull/755">streaming support</a>
will be one of the next features built on top of the 'verity' bundle
format in RAUC.</p>2022-02-10T13:00:00+01:00tag:www.pengutronix.de,2022-02-04:/2022-02-04-initializing-can-interfaces-with-systemd-networkd.htmlDid you know? Initializing CAN interfaces with systemd-networkd2022-02-04T14:18:47+01:00Chris Fiege<div class="section" id="did-you-know-initializing-can-interfaces-with-systemd-networkd">
<p>End of January <em>systemd</em> 250 was added to Debian <em>bullseye backports</em>.
With a lots of new features and fixes now comes the possibility to
set the timing of CAN bus interfaces with <em>systemd-networkd</em>.
In this blogpost I will take a look at why this helps us maintain
our embedded Linux labs.</p>
<div class="section" id="why-can-in-our-labs">
<h3>Why CAN in our labs?</h3>
<p>At Pengutronix we run a lot of <em>labs</em> where we can remote control embedded Linux
devices.
We use these labs for interactive development and continuous testing.
If you want to have a closer look at our lab infrastructure you should take a look
at my talk from ELC 2021 or into our blogpost about
<a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-remote-working.html">remote working</a>.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/rfOe-se4zx0"></iframe>
</div>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="800x599" href="https://www.pengutronix.de/media/blog/2022/2022-02-04_initializing-can-interfaces-with-systemd-networkd/4do.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-04_initializing-can-interfaces-with-systemd-networkd/4do.thumb.6479a80d80f723ab38a1cb75750a3024.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>We use the <a class="reference external" href="https://www.linux-automation.com/en/products/lxa-iobus.html">Linux Automation CAN-IO</a> for GPIOs in our labs.</p>
</figcaption>
</figure>
</div><p><strong>tl;dr:</strong>
Our labs are build around a 19" server rack,
an Ethernet switch,
a mains power switch,
a fanless x64 mini-server,
and lots of USB hubs and USB devices.</p>
<p>One thing we learned over the years:
Do not use USB if you want your embedded Linux lab to be reliable.
So we started to reduce the number of USB devices where possible.
Whereever we need GPIOs (for example to control the boot mode or reset of a
device under test) we nowadays use the CAN-based
<a class="reference external" href="https://www.linux-automation.com/en/products/lxa-iobus.html">LXA IOBus</a>
in our labs.</p>
<p>So reducing the number of USB devices comes at the price of maintaining
a new bus in our labs.</p>
<p>In our labs we use Peak Systems
<a class="reference external" href="https://www.peak-system.com/PCAN-miniPCIe-FD.464.0.html">Mini-PCIe CAN FD</a>
cards.
(But to be honest: On our developer's desk we often use the more cost-sensitive
and Open Source and Open Hardware
<a class="reference external" href="https://www.linux-automation.com/en/products/candlelight.html">candleLight</a>.)</p>
</div>
<div class="section" id="the-old-way">
<h3>The old way</h3>
<p>Until now configuring this bus was a mishmash of <em>systemd-networkd</em> and
some additional commands.
<em>networkd</em> renamed the network device to a well-known name and set up
the bitrate:</p>
<pre class="literal-block">
cfi@rlabA-srv:~$ cat /etc/systemd/network/80_can0-iobus.link
# This file is managed by ptx-admin-ansible. Changes will be overwritten.
[Match]
OriginalName=can0
[Link]
Name=can0_iobus
cfi@rlabA-srv:~$ cat /etc/systemd/network/80_can0-iobus.network
# This file is managed by ptx-admin-ansible. Changes will be overwritten.
[Match]
Name=can0_iobus
[CAN]
BitRate=100000
FDMode=False
RestartSec=10s
</pre>
<p>But: Timing on a CAN bus is defined by a lot more parameters than just the <em>bitrate</em>.
Other important parameters are:</p>
<ul class="simple">
<li><strong>Sampling Point:</strong> The point in time inside a bit on the bus at which the value of the
bit is determined.</li>
<li><strong>Time Quanta:</strong> The length of a sub-bit. Usually given in nanoseconds.</li>
<li><strong>Synchronization Jump Width:</strong> The number of <em>time quanta</em> the clocks of sending and receiving
node are allowed to deviate.
Especially important if some nodes on the bus derive their clock from a trimmed RC-oscillator
rather than a crystal.</li>
</ul>
<p>Since we want to set a specific sampling point and synchronization jump width for the LXA IOBus
we had to set these parameters after <em>systemd-networkd</em> has already set up our interface.
This was cumbersome done as <cite>ExecStartPre</cite>-statements in the
<a class="reference external" href="https://github.com/linux-automation/lxa-iobus">LXA IOBus Server</a> service-unit:</p>
<pre class="literal-block">
cfi@rlabA-srv:~$ cat /etc/systemd/system/lxa-iobus.service
# This file is managed by ptx-admin-ansible. Changes will be overwritten.
[Unit]
Description=LXA iobus Server
After=network.target
[Service]
Type=simple
ExecStartPre=/bin/mkdir -p /var/cache/lxa-iobus
ExecStartPre=/bin/ip l set can0_iobus down
ExecStart=/bin/ip link set can0_iobus type can tq 500 prop-seg 9 phase-seg1 5 phase-seg2 5 sjw 4
ExecStartPre=/bin/ip l set can0_iobus up
ExecStart=/usr/ptx-venvs/lxa-iobus/bin/lxa-iobus-server -l WARN --lss-address-cache-file /var/cache/lxa-iobus/lss-cache --host "*" can0_iobus
Environment="PYTHONUNBUFFERED=1"
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
</pre>
<p>While writing this blogpost I even realized that setting the detailed timing
in the <em>lxa-iobus.service</em> -unit overrides the bitrate set in the
<em>.network</em> -file.
So consolidating this seems a good idea 😀.</p>
</div>
<div class="section" id="the-new-way">
<h3>The new way</h3>
<p>Thanks to <a class="reference external" href="https://github.com/yuwata">yuwata</a> for <a class="reference external" href="https://github.com/systemd/systemd/pull/20442">PR 20442</a>!
This change now allow us to set these additional timing parameters using <em>systemd-networkd</em>.</p>
<p>Taking a look into the
<a class="reference external" href="https://www.freedesktop.org/software/systemd/man/systemd.network.html#[CAN]%20Section%20Options">documentation</a>
we can change our <em>.network</em> file as follows:</p>
<pre class="literal-block">
cfi@rlabA-srv:~$ cat /etc/systemd/network/80_can0-iobus.network
[Match]
Name=can0_iobus
[CAN]
TimeQuantaNSec=500
PropagationSegment=9
PhaseBufferSegment1=5
PhaseBufferSegment2=2
SyncJumpWidth=4
RestartSec=10
</pre>
<p>Note that you can only define the bitrate or the detailed timing parameters
since defining both would be overdetermined.
In this case we define the detailed timing parameters.
We can control the actual bitrate using:</p>
<pre class="literal-block">
cfi@rlabA-srv:~$ ip -detail link show dev can0_iobus
5: can0_iobus: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 10000
bitrate 100000 sample-point 0.750
tq 500 prop-seg 9 phase-seg1 5 phase-seg2 5 sjw 4
peak_canfd: tseg1 1..256 tseg2 1..128 sjw 1..128 brp 1..1024 brp-inc 1
peak_canfd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..1024 dbrp-inc 1
clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
</pre>
</div>
</div><p>End of January <em>systemd</em> 250 was added to Debian <em>bullseye backports</em>.
With a lots of new features and fixes now comes the possibility to
set the timing of CAN bus interfaces with <em>systemd-networkd</em>.
In this blogpost I will take a look at why this helps us maintain
our embedded Linux labs.</p>2022-02-04T14:18:47+01:00tag:www.pengutronix.de,2022-02-03:/2022-02-03-tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto.htmlTutorial: Evaluating RAUC on QEMU - A Quick Setup With Yocto2022-02-03T10:00:00+01:00Enrico Jörns<div class="section" id="tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto">
<p><a class="reference external" href="https://rauc.io">RAUC</a> is an update framework for safely deploying verified
updates on your embedded Linux devices.
It ensures atomicity of the update process to protect from sudden power
outages, hardware failures, etc.
So, why would one like to run RAUC on an emulated platform?</p>
<p>The answer to this is not only "because you can!", but it also allows you to</p>
<ul class="simple">
<li>get an idea of the basic concepts and behavior of RAUC</li>
<li>try out its command line interface</li>
<li>use parts of this as a reference integration for your real HW project</li>
<li>test your integration of RAUC into your own application (also in CI)</li>
<li>test interaction of RAUC with your (deployment) ecosystem (also in CI)</li>
<li>simply play around</li>
</ul>
<div class="ptx-sidebar">
<div class="title">
meta-rauc-community
<div class="corner"></div>
</div>
<div class="body">
<p>The <a class="reference external" href="https://github.com/rauc/meta-rauc-community">meta-rauc-community</a>
Yocto Layer was initiated by
<a class="reference external" href="https://www.youtube.com/c/LeonAnavi">Leon Anavi</a> in the context of two talks
held at the <a class="reference external" href="https://elinux.org/images/9/91/Software-update-solutions-for-yocto-openembedded-leon-anavi-elce-2020.pdf">ELCE 2020</a>
and the <a class="reference external" href="https://www.youtube.com/watch?v=jlSFM-L76d8">Yocto Project Summit 2020</a> and an additional
<a class="reference external" href="https://www.konsulko.com/getting-started-with-rauc-on-raspberry-pi-2/">blogpost</a>.
It started with support for the Raspberry PI, but has since been extended
with support for more platforms.</p>
</div>
</div>
<p>Luckily, there is no need to perform a full integration of RAUC here on our
own.
Instead, we take advantage of the <a class="reference external" href="https://github.com/rauc/meta-rauc-community">meta-rauc-community</a>-Layer.</p>
<p>During our annual Pengutronix-internal hacking week 'TechWeek', I finalized
my support for integrating RAUC for the x86-64 QEMU platform in Yocto/poky and
<a class="reference external" href="https://github.com/rauc/meta-rauc-community/pull/25">contributed</a> this to
meta-rauc-community.
Some additional <a class="reference external" href="https://github.com/rauc/meta-rauc-community/pull/29">fixes</a>
I recently contributed as part of the preparation of this tutorial.</p>
<p>So let's get started with using this!</p>
<div><div class="clearfix"></div></div><div class="section" id="setup-overview">
<h3>Setup Overview</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="829x809" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-overview.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-overview.thumb.8003da752a52d03c634e3a69b3acb456.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Overview over QEMU A+B+recovery setup</p>
</figcaption>
</figure>
</div><p>The integration shows one possible example of a redundancy boot set-up with RAUC on x86.
The layout is a symmetric A+B system with an additional rescue system.
The GRUB bootloader (started by the UEFI firmware) is configured to select the
proper boot target.</p>
<p>To demonstrate the bootloader update capabilities of RAUC, it is also
configured to allow updating the EFI partition atomically (by switching the GPT
entry).</p>
</div>
<div class="section" id="requirements-and-preparation">
<h3>Requirements and Preparation</h3>
<p>For the tutorial, it is not strictly necessary (but recommended) to have
basic knowledge of embedded (Linux) systems and the Yocto project.</p>
<p>As no hardware is involved, all we need to follow this tutorial is a shell on a
Linux system. It could also be virtual machine but should be powerful enough to
build basic Yocto-based systems in finite time.</p>
<p>Also make sure to have the <a class="reference external" href="http://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages">build requirements</a>
for the Yocto project installed.</p>
</div>
<div class="section" id="creating-our-project">
<h3>Creating Our Project</h3>
<p>First, we set up our build directory using <a class="reference external" href="https://www.yoctoproject.org/software-item/poky/">poky</a> and add some layer
repositories that we will need in the following.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This example uses the <cite>honister-3.4.1</cite> release of poky, but you can also
use <cite>master</cite> or any future release.</p>
</div>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>mkdir<span class="w"> </span>rauc-qemu-demo
$<span class="w"> </span><span class="nb">cd</span><span class="w"> </span>rauc-qemu-demo
$<span class="w"> </span>git<span class="w"> </span>clone<span class="w"> </span>-b<span class="w"> </span>honister-3.4.1<span class="w"> </span>https://git.yoctoproject.org/poky
$<span class="w"> </span>git<span class="w"> </span>clone<span class="w"> </span>-b<span class="w"> </span>honister<span class="w"> </span>https://github.com/rauc/meta-rauc.git
$<span class="w"> </span>git<span class="w"> </span>clone<span class="w"> </span>-b<span class="w"> </span>master<span class="w"> </span>https://github.com/rauc/meta-rauc-community.git
</pre></div>
</div><p>The layer we actually need to activate are</p>
<ul class="simple">
<li><strong>meta-rauc</strong> for providing basic RAUC recipes and classes</li>
<li><strong>meta-rauc-qemux86</strong> for the example QEMU integration</li>
</ul>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span><span class="nb">source</span><span class="w"> </span>poky/oe-init-build-env<span class="w"> </span>build
$<span class="w"> </span>bitbake-layers<span class="w"> </span>add-layer<span class="w"> </span>../meta-rauc-community/meta-rauc-qemux86
$<span class="w"> </span>bitbake-layers<span class="w"> </span>add-layer<span class="w"> </span>../meta-rauc
</pre></div>
</div></div>
<div class="section" id="configuring-our-project">
<h3>Configuring Our Project</h3>
<p>(tl;dr: Scroll down to the end of this section and copy the lines from the box
to your <tt class="docutils literal">conf/local.conf</tt>.)</p>
<p>Now that we have sourced the environment and added the required layers, you
could already potentially start building an image.
But for an actually working set-up, there are some additional items to configure.</p>
<p>So far, adding <tt class="docutils literal"><span class="pre">meta-rauc</span></tt> only provides additional recipes, but does not
change your build, yet.
For some useful overrides of standard recipes (like busybox or linux-yocto) to
take effect, we have to enable the <tt class="docutils literal">DISTRO_FEATURE</tt> named <tt class="docutils literal">rauc</tt>.</p>
<p>Thus you can open your <tt class="docutils literal">conf/local.conf</tt> and add this line:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>DISTRO_FEATURES += "rauc"
</pre></div>
</div><div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p class="last">If your project already uses a custom distribution, that would be the proper
place to set <tt class="docutils literal">DISTRO_FEATURES</tt>.</p>
</div>
<p>To actually have RAUC installed into the <tt class="docutils literal"><span class="pre">core-image-minimal</span></tt> target rootfs
image that we will use, add this line to your <tt class="docutils literal">conf/local.conf</tt>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>CORE_IMAGE_EXTRA_INSTALL += "rauc"
</pre></div>
</div><p>As we intend to build and boot not only a file system image but a full disk
image, we need to add some more configuration for gaining full UEFI boot
capabilities:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="n">MACHINE_FEATURES</span><span class="o">:</span><span class="n">append</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s2">" pcbios efi"</span>
<span class="n">EXTRA_IMAGEDEPENDS</span><span class="w"> </span><span class="o">+=</span><span class="w"> </span><span class="s2">"ovmf"</span>
</pre></div>
</div><p>And finally select the proper GRUB boot configuration.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>PREFERRED_RPROVIDER_virtual-grub-bootconf = "rauc-qemu-grubconf"
</pre></div>
</div><div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p>It is recommended (but not strictly required) for RAUC to use <tt class="docutils literal">systemd</tt> as
your init system. If you intend to do so, you can set:</p>
<pre class="literal-block">
INIT_MANAGER = "systemd"
</pre>
<p class="last">In your <tt class="docutils literal">conf/local.conf</tt> (or custom distro config).</p>
</div>
<p>In a later step in this tutorial we also intend actually perform a RAUC update
in our evaluation system.
This requires being able to copy a bundle to the target using <tt class="docutils literal">scp</tt>.
Thus, as a final step, we also make sure that we have an SSH server installed on
the target by adding to <tt class="docutils literal">conf/local.conf</tt>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>EXTRA_IMAGE_FEATURES += "ssh-server-openssh"
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p>As a copy&paste template, the additional content of your <tt class="docutils literal">conf/local.conf</tt>
now should look as follows:</p>
<div class="last"><div class="code-block">
<div class="highlight"><pre><span></span><span class="n">DISTRO_FEATURES</span> <span class="o">+=</span> <span class="s">"rauc"</span>
<span class="n">CORE_IMAGE_EXTRA_INSTALL</span> <span class="o">+=</span> <span class="s">"rauc"</span>
<span class="n">MACHINE_FEATURES</span><span class="p">:</span><span class="n">append</span> <span class="o">=</span> <span class="s">" pcbios efi"</span>
<span class="n">EXTRA_IMAGEDEPENDS</span> <span class="o">+=</span> <span class="s">"ovmf"</span>
<span class="n">PREFERRED_RPROVIDER_virtual</span><span class="o">-</span><span class="n">grub</span><span class="o">-</span><span class="n">bootconf</span> <span class="o">=</span> <span class="s">"rauc-qemu-grubconf"</span>
<span class="n">INIT_MANAGER</span> <span class="o">=</span> <span class="s">"systemd"</span>
<span class="n">EXTRA_IMAGE_FEATURES</span> <span class="o">+=</span> <span class="s">"ssh-server-openssh"</span>
</pre></div>
</div></div></div>
</div>
<div class="section" id="setting-up-bundle-signing-keys">
<h3>Setting up Bundle Signing Keys</h3>
<p>Updates with RAUC are always cryptographically signed and verified using public
key certificates according to the X.509 standard (as known from TLS, S/MIME and
CMS).</p>
<div class="admonition important">
<p class="first admonition-title">Important</p>
<p>Normally, this requires setting up full public key infrastructure (PKI) as a
trust anchor.</p>
<p class="last">The <a class="reference external" href="https://pki-tutorial.readthedocs.io/en/latest/">pki-tutorial</a> from
Stefan H. Holek may serve as a good starting point.</p>
</div>
<p>For this example scenario, we narrow this down to a simplified setup:</p>
<ul class="simple">
<li>A self-signed certificate key pair consisting of the private key and a public
key certificate serves as the root CA.</li>
<li>A single subordinate 'development' key pair (signed by the CA) to sign the
example bundle</li>
</ul>
<p>The <cite>meta-rauc-community</cite> layer already comes with a <a class="reference external" href="https://github.com/rauc/meta-rauc-community/blob/master/create-example-keys.sh">convenience script</a>
to
create the required key pairs and integrate them into the build by automatically
setting the required variables in the local configuration file <tt class="docutils literal">conf/site.conf</tt>.</p>
<p>To execute it, change into the meta-rauc-community layer, run
<tt class="docutils literal"><span class="pre">./create-example-keys.sh</span></tt> and switch back to the build directory:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span><span class="nb">cd</span><span class="w"> </span>../meta-rauc-community/meta-rauc-qemux86/
$<span class="w"> </span>./create-example-keys.sh
Development<span class="w"> </span>CA
Generating<span class="w"> </span>a<span class="w"> </span>RSA<span class="w"> </span>private<span class="w"> </span>key
..+++++
..+++++
writing<span class="w"> </span>new<span class="w"> </span>private<span class="w"> </span>key<span class="w"> </span>to<span class="w"> </span><span class="s1">'private/ca.key.pem'</span>
-----
Using<span class="w"> </span>configuration<span class="w"> </span>from<span class="w"> </span>/ptx/work/WORK_SANAH/ejo/bsps/rauc-qemu-demo/build/example-ca/openssl.cnf
Check<span class="w"> </span>that<span class="w"> </span>the<span class="w"> </span>request<span class="w"> </span>matches<span class="w"> </span>the<span class="w"> </span>signature
Signature<span class="w"> </span>ok
Certificate<span class="w"> </span>Details:
<span class="w"> </span>Serial<span class="w"> </span>Number:<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="o">(</span>0x1<span class="o">)</span>
<span class="w"> </span>Validity
<span class="w"> </span>Not<span class="w"> </span>Before:<span class="w"> </span>Jan<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="m">00</span>:00:00<span class="w"> </span><span class="m">1970</span><span class="w"> </span>GMT
<span class="w"> </span>Not<span class="w"> </span>After<span class="w"> </span>:<span class="w"> </span>Dec<span class="w"> </span><span class="m">31</span><span class="w"> </span><span class="m">23</span>:59:59<span class="w"> </span><span class="m">9999</span><span class="w"> </span>GMT
<span class="w"> </span>Subject:
<span class="w"> </span><span class="nv">organizationName</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org
<span class="w"> </span><span class="nv">commonName</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org<span class="w"> </span>rauc<span class="w"> </span>CA<span class="w"> </span>Development
<span class="w"> </span>X509v3<span class="w"> </span>extensions:
<span class="w"> </span>X509v3<span class="w"> </span>Subject<span class="w"> </span>Key<span class="w"> </span>Identifier:
<span class="w"> </span><span class="m">23</span>:25:46:79:1B:10:08:AA:B6:83:22:7F:D4:76:BC:FD:ED:78:DD:CF
<span class="w"> </span>X509v3<span class="w"> </span>Authority<span class="w"> </span>Key<span class="w"> </span>Identifier:
<span class="w"> </span>keyid:23:25:46:79:1B:10:08:AA:B6:83:22:7F:D4:76:BC:FD:ED:78:DD:CF
<span class="w"> </span>DirName:/O<span class="o">=</span>Test<span class="w"> </span>Org/CN<span class="o">=</span>Test<span class="w"> </span>Org<span class="w"> </span>rauc<span class="w"> </span>CA<span class="w"> </span>Development
<span class="w"> </span>serial:01
<span class="w"> </span>X509v3<span class="w"> </span>Basic<span class="w"> </span>Constraints:
<span class="w"> </span>CA:TRUE
Certificate<span class="w"> </span>is<span class="w"> </span>to<span class="w"> </span>be<span class="w"> </span>certified<span class="w"> </span><span class="k">until</span><span class="w"> </span>Dec<span class="w"> </span><span class="m">31</span><span class="w"> </span><span class="m">23</span>:59:59<span class="w"> </span><span class="m">9999</span><span class="w"> </span>GMT<span class="w"> </span><span class="o">(</span><span class="m">2913877</span><span class="w"> </span>days<span class="o">)</span>
<span class="o">[</span>...<span class="o">]</span>
Writing<span class="w"> </span>RAUC<span class="w"> </span>key<span class="w"> </span>configuration<span class="w"> </span>to<span class="w"> </span>site.conf<span class="w"> </span>...
Key<span class="w"> </span>configuration<span class="w"> </span>successfully<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>/ptx/work/WORK_SANAH/ejo/bsps/rauc-qemu-demo/build/conf/site.conf
$<span class="w"> </span><span class="nb">cd</span><span class="w"> </span>-
</pre></div>
</div><p>The result you can see when dumping <tt class="docutils literal">conf/site.conf</tt>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>cat<span class="w"> </span>conf/site.conf
<span class="nv">RAUC_KEYRING_FILE</span><span class="o">=</span><span class="s2">"[..]/build/example-ca/ca.cert.pem"</span>
<span class="nv">RAUC_KEY_FILE</span><span class="o">=</span><span class="s2">"[..]/build/example-ca/private/development-1.key.pem"</span>
<span class="nv">RAUC_CERT_FILE</span><span class="o">=</span><span class="s2">"[..]/build/example-ca/development-1.cert.pem"</span>
</pre></div>
</div><p>Now we have set up all that is required to build the project.</p>
</div>
<div class="section" id="building-the-qemu-system-image">
<h3>Building The QEMU System Image</h3>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Make sure you have selected the proper distro <tt class="docutils literal">poky</tt> and machine
<tt class="docutils literal"><span class="pre">qemux86-64</span></tt> in your <tt class="docutils literal">conf/local.conf</tt> (both should be the default).</p>
</div>
<p>We can start building poky's default minimal system image
<tt class="docutils literal"><span class="pre">core-image-minimal</span></tt> by invoking:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>core-image-minimal
</pre></div>
</div><div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p class="last">This will take some time, depending on your build machine. Grab a coffee. Or two.</p>
</div>
<p>At the end of the build process, you should have some artifacts in your
machine's deploy folder (<tt class="docutils literal"><span class="pre">tmp/deploy/images/qemux86-64</span></tt>):</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>ls<span class="w"> </span>-1<span class="w"> </span>tmp/deploy/images/qemux86-64
bzImage@
bzImage--5.14.17+git0+b3ac9c40a2_35888b3a9a-r0-qemux86-64-20220125010439.bin
bzImage-qemux86-64.bin@
<span class="o">[</span>..<span class="o">]</span>
core-image-minimal-qemux86-64.ext4@
core-image-minimal-qemux86-64.manifest@
core-image-minimal-qemux86-64.qemuboot.conf@
core-image-minimal-qemux86-64.tar.bz2@
core-image-minimal-qemux86-64.testdata.json@
core-image-minimal-qemux86-64.wic@
<span class="o">[</span>..<span class="o">]</span>
</pre></div>
</div><p>The symlink <tt class="docutils literal"><span class="pre">core-image-minimal-qemux86-64.wic</span></tt> is the most important here as
this points to the full disk image we will use to boot from in the next section.</p>
</div>
<div class="section" id="booting-the-qemu-system">
<h3>Booting the QEMU System</h3>
<p>Having sourced the bitbake environment script, you automatically also have the
poky QEMU wrapper script <tt class="docutils literal">runqemu</tt> in your <tt class="docutils literal">PATH</tt>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>runqemu<span class="w"> </span>-h
</pre></div>
</div><p>This script eases setting up QEMU by reading a Yocto-generated QEMU
configuration from your deploy folder and provides some convenience
configuration options.</p>
<p>We call it with the arguments <tt class="docutils literal">nographic</tt> for non-graphical mode, <tt class="docutils literal">slirp</tt>
to have network as non-root, <tt class="docutils literal">ovmf</tt> to boot with the OVMF EFI Firmware, and
<tt class="docutils literal">wic</tt> to use the <tt class="docutils literal">.wic</tt> disk image generated for our rootfs:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>runqemu<span class="w"> </span>nographic<span class="w"> </span>slirp<span class="w"> </span>ovmf<span class="w"> </span>wic<span class="w"> </span>core-image-minimal
</pre></div>
</div><p>This will start the system and let EFI boot into the GRUB bootloader menu:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="803x466" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-grub-bootselection.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-grub-bootselection.thumb.95fac6a53a88bb51ee9d8633e9f63049.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div>
<div class="ptx-sidebar">
<div class="title">
Bootloader Interaction
<div class="corner"></div>
</div>
<div class="body">
<p>If you are interested in details on how RAUC interacts with GRUB and other
bootloaders, you might want to have a look at the RAUC documentation
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#bootloader-interaction">here</a></p>
</div>
</div>
<p>The boot menu contains a boot entry for each slot (A, B, rescue) used in our
redundancy setup (as described above).
The values in brackets represent variables persisted in the grubenv and used by
RAUC to select the proper partition to boot.</p>
<p>If not already selected, choose <strong>Slot A</strong> here and press <tt class="docutils literal"><Enter></tt>,
otherwise just wait for the auto-boot countdown to complete.</p>
<p>The QEMU should then boot your system up to the login prompt:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="766x446" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-login-prompt.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-login-prompt.thumb.dd92c489dce2be699baef5dbc5f1d89f.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>Log in as user <strong>root</strong> with <strong>empty password</strong>.</p>
<p>Now you are in a system that is running RAUC and is capable of being updated
like a real system.</p>
<p>RAUC provides a command line interface for debugging and development purposes.
This also allows us to introspect the current state of the redundancy setup.
We can request an overview by calling the <tt class="docutils literal">rauc status</tt> command:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="758x505" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status.thumb.cee9c019b5ec3f1474c395cd1a7904c0.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>For RAUC, the A+B redundancy slots are referred to as <tt class="docutils literal">rootfs.0</tt> and
<tt class="docutils literal">rootfs.1</tt>. The rescue system is called <tt class="docutils literal">rescue.0</tt> and the EFI partition
holding the bootloader is referred to as <tt class="docutils literal">efi.0</tt></p>
<p>As expected, we see the rootfs.0 slot being the one that is currently activated
and booted.</p>
<div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p class="last">The slot names and values are not magic, they are defined in the plain text
ini-style <a class="reference external" href="https://github.com/rauc/meta-rauc-community/blob/master/meta-rauc-qemux86/recipes-core/rauc/files/qemux86-64/system.conf">system configuration file</a>
<tt class="docutils literal">/etc/rauc/system.conf</tt>.</p>
</div>
</div>
<div class="section" id="building-the-update-bundle">
<h3>Building The Update Bundle</h3>
<p>The meta-rauc-qemux86 layer also comes with a ready-to-build recipe for a RAUC
update bundle.
In addition to a rootfs image, it also provides a bootloader/EFI image to
demonstrate RAUC's capability of performing <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#update-boot-partition-in-gpt">atomic bootloader updates on GPT</a>.</p>
<p>Build the demo bundle using this command:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>qemu-demo-bundle
</pre></div>
</div><p>This will leave an update bundle in the deploy folder under
<tt class="docutils literal"><span class="pre">tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb</span></tt>.</p>
<p>To check the content of this bundle on your host, you can manually invoke the
<tt class="docutils literal">rauc</tt> host tool by using the <tt class="docutils literal"><span class="pre">oe-run-native</span></tt> helper script:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>bitbake<span class="w"> </span>rauc-native<span class="w"> </span>-c<span class="w"> </span>addto_recipe_sysroot
$<span class="w"> </span>oe-run-native<span class="w"> </span>rauc-native<span class="w"> </span>rauc<span class="w"> </span>info<span class="w"> </span>--keyring<span class="o">=</span>/path/to/ca.cert.pem<span class="w"> </span>tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb
Running<span class="w"> </span>bitbake<span class="w"> </span>-e<span class="w"> </span>rauc-native
Compatible:<span class="w"> </span><span class="s1">'qemu86-64 demo platform'</span>
Version:<span class="w"> </span><span class="s1">'1.0'</span>
Description:<span class="w"> </span><span class="s1">'qemu-demo-bundle version 1.0-r0'</span>
Build:<span class="w"> </span><span class="s1">'20220128160205'</span>
Hooks:<span class="w"> </span><span class="s1">''</span>
Bundle<span class="w"> </span>Format:<span class="w"> </span>verity
<span class="w"> </span>Verity<span class="w"> </span>Salt:<span class="w"> </span><span class="s1">'9774a9fce2c06c5513c3339bb46d591c5dc393af1bf8c8e8ee292a0c0c707dfb'</span>
<span class="w"> </span>Verity<span class="w"> </span>Hash:<span class="w"> </span><span class="s1">'e7383c28833ae92389546d5c0779158220cd72342ca94a4e2fc5ba45fe2b526c'</span>
<span class="w"> </span>Verity<span class="w"> </span>Size:<span class="w"> </span><span class="m">352256</span>
<span class="m">2</span><span class="w"> </span>Images:
<span class="w"> </span><span class="o">[</span>efi<span class="o">]</span>
<span class="w"> </span>Filename:<span class="w"> </span>efi-boot.vfat
<span class="w"> </span>Checksum:<span class="w"> </span>6ca86bc62014ff21f2cfe2773d08218a57fb24d07651a3d46c1ae791b10845ad
<span class="w"> </span>Size:<span class="w"> </span><span class="m">33572864</span>
<span class="w"> </span>Hooks:
<span class="w"> </span><span class="o">[</span>rootfs<span class="o">]</span>
<span class="w"> </span>Filename:<span class="w"> </span>core-image-minimal-qemux86-64.tar.bz2
<span class="w"> </span>Checksum:<span class="w"> </span>2bdfe2c3eaec4add3ba6c1baaf82dfd6fb9c97c105dab98fd70ae8248016feff
<span class="w"> </span>Size:<span class="w"> </span><span class="m">44355818</span>
<span class="w"> </span>Hooks:
Certificate<span class="w"> </span>Chain:
<span class="w"> </span><span class="m">0</span><span class="w"> </span>Subject:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org<span class="w"> </span>Development-1
<span class="w"> </span>Issuer:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org<span class="w"> </span>rauc<span class="w"> </span>CA<span class="w"> </span>Development
<span class="w"> </span>SPKI<span class="w"> </span>sha256:<span class="w"> </span><span class="m">08</span>:D2:08:25:06:2D:74:25:63:DF:64:A2:50:EF:96:1F:E1:C5:54:32:2F:36:0C:5E:6A:FF:2C:16:E1:8D:D9:DB
<span class="w"> </span>Not<span class="w"> </span>Before:<span class="w"> </span>Jan<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="m">00</span>:00:00<span class="w"> </span><span class="m">1970</span><span class="w"> </span>GMT
<span class="w"> </span>Not<span class="w"> </span>After:<span class="w"> </span>Dec<span class="w"> </span><span class="m">31</span><span class="w"> </span><span class="m">23</span>:59:59<span class="w"> </span><span class="m">9999</span><span class="w"> </span>GMT
<span class="w"> </span><span class="m">1</span><span class="w"> </span>Subject:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org<span class="w"> </span>rauc<span class="w"> </span>CA<span class="w"> </span>Development
<span class="w"> </span>Issuer:<span class="w"> </span><span class="nv">O</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org,<span class="w"> </span><span class="nv">CN</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>Test<span class="w"> </span>Org<span class="w"> </span>rauc<span class="w"> </span>CA<span class="w"> </span>Development
<span class="w"> </span>SPKI<span class="w"> </span>sha256:<span class="w"> </span>E1:EC:C5:31:27:43:50:19:0B:6D:66:21:A4:90:CA:AD:F8:94:D6:D2:FD:ED:41:BA:66:6A:F6:AA:33:5B:0C:A3
<span class="w"> </span>Not<span class="w"> </span>Before:<span class="w"> </span>Jan<span class="w"> </span><span class="m">1</span><span class="w"> </span><span class="m">00</span>:00:00<span class="w"> </span><span class="m">1970</span><span class="w"> </span>GMT
<span class="w"> </span>Not<span class="w"> </span>After:<span class="w"> </span>Dec<span class="w"> </span><span class="m">31</span><span class="w"> </span><span class="m">23</span>:59:59<span class="w"> </span><span class="m">9999</span><span class="w"> </span>GMT
</pre></div>
</div><div class="admonition tip">
<p class="first admonition-title">Tip</p>
<p>You can also simplify specify the verification keyring by using:</p>
<pre class="last literal-block">
eval `grep RAUC_KEYRING_FILE conf/site.conf`
oe-run-native rauc-native rauc info --keyring=$RAUC_KEYRING_FILE tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb
</pre>
</div>
<p>As expected, the bundle contains two images: one for the slot of class <tt class="docutils literal">efi</tt>
and one for a slot of class <tt class="docutils literal">rootfs</tt>.
You can also see that the <tt class="docutils literal">compatible</tt> matches the one defined for the target
system.
So as this looks correct, let's install the update.</p>
</div>
<div class="section" id="installing-the-update-bundle">
<h3>Installing The Update Bundle</h3>
<p>To actually install the RAUC bundle in this example setup, we need to copy it
into the QEMU system's file system.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">RAUC also supports updates from remote URLs for <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#rauc-casync-support">casync</a>
and will receive
built-in <a class="reference external" href="https://github.com/rauc/rauc/pull/755">streaming installation</a>
capabilities soon.</p>
</div>
<p>As we have set up slirp, we can do this over network via scp:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$<span class="w"> </span>scp<span class="w"> </span>-P<span class="w"> </span><span class="m">2222</span><span class="w"> </span>tmp/deploy/images/qemux86-64/qemu-demo-bundle-qemux86-64.raucb<span class="w"> </span>root@localhost:/data/
</pre></div>
</div><div class="admonition note">
<p class="first admonition-title">Note</p>
<p>The port must match the one printed as <tt class="docutils literal">hostfwd</tt> for port <tt class="docutils literal">22</tt> during
qemu startup in the line:</p>
<pre class="literal-block">
runqemu - INFO - Port forward: hostfwd=tcp::2222-:22 hostfwd=tcp::2323-:23
</pre>
<p class="last">Also note that you might run into scp failing if invoked too early and the
keys on the target side are not created, yet.
Just retry after a few seconds in that case.</p>
</div>
<p>After copying the update bundle to your QEMU target, you can run <tt class="docutils literal">rauc install
<span class="pre">/data/qemu-demo-bundle-qemux86-64.raucb</span></tt> from within QEMU to start the actual
installation:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="877x577" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-install.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-install.thumb.07d293a804c4d8a34b8286c1b37a29db.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>After successful installation, RAUC activates the formerly inactive slot.
It also stores information about the update in the configured central status
file <tt class="docutils literal">/data/rauc.status</tt>.</p>
<p>You can inspect this all by calling <tt class="docutils literal">rauc status <span class="pre">--detailed</span></tt>:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="885x1114" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status-detailed-after.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status-detailed-after.thumb.237d57c327074fb9402d5c53c550146e.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>Note the different slots referred to as "Booted from" and "Activated" (and the
<tt class="docutils literal">x</tt> marking <tt class="docutils literal">rootfs.1</tt> now).</p>
</div>
<div class="section" id="reboot-into-updated-system">
<h3>Reboot into Updated System</h3>
<p>You can now reboot into the just-installed system using normal <tt class="docutils literal">reboot</tt>
(or <tt class="docutils literal">systemctl reboot</tt> when using systemd).</p>
<p>As upon first boot, you will see the GRUB boot menu again, but now with the
<tt class="docutils literal">Slot B</tt> entry being pre-selected:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="803x471" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-grub-bootselection-after-update.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-grub-bootselection-after-update.thumb.87464335244dcc53dddd3c871e742ba4.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>Just wait for GRUB to continue and see your freshly installed system
booting up.</p>
<p>As the very last step in our tutorial we'll verify that we actually ended up in
the correct situation.</p>
<p>For this, we call <tt class="docutils literal">rauc status</tt> one last time:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="740x503" href="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status-after-reboot.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-03_tutorial-evaluating-rauc-on-qemu-a-quick-setup-with-yocto/qemu-rauc-status-after-reboot.thumb.6f150bc7725fe99b628aeeccf2fa06df.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>As you can see, the booted slot (marked green and having the <tt class="docutils literal">booted</tt> flag
set) is now <tt class="docutils literal">rootfs.1</tt>.
You can also see that it is reported as the slot being mounted to <tt class="docutils literal">/</tt> and
thus is actually your currently active root file system.</p>
<p>The tutorial ends here, you can now play around on your own, try another
platform provided by meta-rauc-community, or start <a class="reference external" href="https://rauc.readthedocs.io/en/latest/integration.html#yocto">integrating</a> RAUC for your
own Yocto-/poky-based project and use cases.</p>
</div>
</div>
<p><a class="reference external" href="https://rauc.io">RAUC</a> is an update framework for safely deploying verified
updates on your embedded Linux devices.
It ensures atomicity of the update process to protect from sudden power
outages, hardware failures, etc.
So, why would one like to run RAUC on an emulated platform?</p>2022-02-03T10:00:00+01:00tag:www.pengutronix.de,2022-02-01:/2022-02-01-schluessel-mit-optee-verschluesseln.htmlWir haben doch etwas zu verbergen: Schlüssel mit OP-TEE verschlüsseln2022-02-01T09:45:03+01:00Rouven Czerwinski<div class="section" id="wir-haben-doch-etwas-zu-verbergen-schlussel-mit-op-tee-verschlusseln">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="200x200" href="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/title-optee.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/title-optee.thumb.980567226d856faffcd934b3ec10dab4.png"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"></figcaption>
</figure>
</div><p>Moderne Linux Systeme müssen häufig zwecks Authentifizierung bei einer Cloud-
basierten Infrastruktur oder einer On-Premise Maschine eigene kryptografische
Schlüssel speichern. Statt der Verwendung eines Trusted Platform Modules (TPM),
bieten moderne ARM Prozessoren die TrustZone-Technologie an, auf deren Basis
ebenfalls Schlüssel oder andere Geheimnisse gespeichert werden können. Dieses
Paper zeigt die Nutzung des Open Portable Trusted Execution Environments (OP-
TEE) mit der Standardkonformen PKCS#11 Schnittstellen und i.MX6 Prozessoren
von NXP als Beispiel.</p>
<p>Durch die weitreichendere Vernetzung von Systemen und die Anforderungen an
diese, auch mit anderen Systemen reden zu können, sehen wir einen immer
größeren Anwendungsfall für eingebettete Linux-Systeme. Diese bringen bereits
alle nötigen Komponenten und Bibliotheken mit, um über Netzwerkschnittstellen
mit anderen Komponenten kommunizieren zu können. Ein Problempunkt ist häufig
die Authentifizierung des Systems, das Gerät selbst soll sich kryptografisch
authentifizieren können, eine Extraktion der kryptografischen Daten soll
allerdings nicht möglich sein.</p>
<p>Die bisher häufig gewählte Vorgehensweise ist ein Trusted Platform Module
(TPM), welches die kryptografischen Daten erzeugt, speichert und für
kryptografische Operationen zur Verfügung stellt. Dabei stellt das TPM sicher,
dass der private Teil des Privat/Öffentlichen Schlüsselpaares nicht aus diesem
extrahiert werden kann.</p>
<div class="section" id="trustzone-op-tee-und-seine-funktionen">
<h3>TrustZone, OP-TEE und seine Funktionen</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4627x3780" href="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/optee.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/optee.thumb.deff3a332d0256d89369a1c88a7bc463.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Auflistung der ARM exception Level (32-Bit). Der schwarze Balken in der
Mitte zeigt die Trennung zwischen Secure World und Normal World, sodass die
Kommunikation nur über den Secure Monitor stattfinden kann.</p>
</figcaption>
</figure>
</div><p>Als Alternative bietet sich die Verwendung der ARM TrustZone Technologie an.
Moderne ARMv7 Prozessoren implementieren die TrustZone als separaten
Prozessorzustand, sogenannter Secure Mode, bei dem z.B. der Arbeitsspeicher vor
Zugriffen durch den normalen Prozessorzustand geschützt ist. Dies ermöglicht es,
ähnlich zu einem TPM, im Secure Mode ein privat/öffentliches Schlüsselpaar zu
erzeugen und nur den öffentlichen Teil an den normalen Prozessorzustand
abzugeben.</p>
<p>Als Nutzung der TrustZone bietet sich das Open Portable Trusted Execution
Environment <a href="https://www.op-tee.org/">(OP-TEE)</a> an.
Veröffentlicht unter der Open Source BSD Lizenz fallen
nur die Integrationsaufwände für das eigene System an.
Es implementiert die <a href="https://globalplatform.org/specs-library/?filter-committee=tee">Global Platform TEE Spezifikation</a>
und kann somit Applikationen starten, die gegen diese
programmiert wurden. Die Applikationen werden als Trusted Applications (TA)
bezeichnet. Wichtig ist, dass OP-TEE kein klassisches Betriebssystem ist,
sondern nur eine Umgebung, in welcher Datenverarbeitungsvorgänge sicher
ausgeführt werden können.
Es besitzt selbst keine Eigenschaften wie z.B. Scheduling.
Des Weiteren verfügen aktuelle Varianten von OP-TEE über eine optionale
<a href="https://github.com/OP-TEE/optee_os/tree/master/ta/pkcs11">PKCS#11 TA</a>,
welche eine PKCS#11 Standard konforme Schnittstelle bereitstellt, um im Secure
Mode Schlüssel zu generieren, Zertifikate abzulegen und die dort abgelegten
Schlüssel zu verwenden.</p>
<p>Über die PKCS#11 Schnittstelle ist dann eine Einbindung über die eigene
Anwendung möglich.
Dabei wird auf der Anwendungsseite OpenSSL verwendet, zusammen mit der
sogenannten PKCS#11 Engine aus der libp11 Bibliothek. Diese Engine stellt die
Schnittstelle zwischen PKCS#11 und einer TLS basierten Authentifizierung her.
Auch ist damit z.B. die Einbindung eines Webserver Zertifikats oder der Import
vorhandener Schlüssel möglich.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5656x3009" href="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/kommunikationswege.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/kommunikationswege.thumb.d68cf57074471e52c40625a36275a001.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Kommunikation der Nutzer Applikation mit einer Trusted Applikation im
OP-TEE. Dabei verwendet die Nutzer Applikation die libteeclient Bibliothek,
welche das Aufsetzen der geteilten Speicherbereiche sowie das serialisieren
der Parameter übernimmt. Der Kernel reicht diese dann ans OP-TEE weiter
welches den Aufruf an die korrekte Trusted Applikation übergibt.</p>
</figcaption>
</figure>
</div><p>Für das Speichern von Daten hält OP-TEE zwei Möglichkeiten bereit.
Dabei können zum einen die Daten verschlüsselt an das Linux System
zurückgegeben werden, dieses legt die verschlüsselten Daten im Dateisystem ab.
Weiterhin ist OP-TEE in der Lage, ein Feature moderner eMMC Speicher zu
verwenden, die sogenannten Replay Protected Memory Blocks.
Dabei wird einmalig bei der Inbetriebnahme des Systems ein Schlüssel
mit der eMMC ausgetauscht, welcher anschließend für die Authentifizierung von
Transaktionen wie Lesen und Schreiben verwendet wird. Durch die zusätzliche
Authentifizierung ist dieser Bereich vor dem Zurückspielen alter, aber valider
verschlüsselter Daten geschützt.
Koordiniert wird das Speichern der Daten im Linux System vom Tee-Supplicant,
einem Daemon, der für die Verwendung durch OP-TEE im Linux System gestarteti
wird.</p>
</div>
<div class="section" id="integrationsschritte-fur-i-mx-prozessoren">
<h3>Integrationsschritte für i.MX-Prozessoren</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="9049x2332" href="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/boot-verification-chain.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-02-01_schluessel-mit-optee-verschluesseln/boot-verification-chain.thumb.c68b69a6b04715c86d4e7219196103a4.png"/>
</a><figcaption itemprop="caption description" style="
width: 582px;
"><p>Beispiel einer sicheren Boot-Kette mit OP-TEE, Barebox, FIT Images und
DM-Verity. Das BootROM verifiziert dabei Barebox & OP-TEE, welche wiederrum
einen kryptografischen Schlüssel enthalten um das FIT Image zu verifizieren.
Der Kernel verwendet dann dm-verity auf einem read-only file system um
sicherzustellen das keine Daten modifiziert wurden.</p>
</figcaption>
</figure>
</div><p>Als nächstes betrachten wir die notwendigen Integrationsschritte für OP-TEE auf
einem i.MX6-Prozessor.
Die Verwendung von OP-TEE auf beliebten Systemen, wie z.B. Raspberry-Pi 3, ist
zwar möglich, aber für den Produktiveinsatz nicht ratsam, da die Raspberry-Pi
Plattform nicht in der Lage ist, Bereiche des Arbeitsspeichers nur für den
Zugriff aus dem Secure Mode zu unterteilen.
Für diese Unterteilung ist auf dem i.MX6 Prozessor der TrustZone Address Space
Controller (TZC-380), eine Standardperipherie Einheit von ARM zuständig.
Diese wird von OP-TEE so konfiguriert, dass die letzten 32MiB des
Arbeitsspeichers ausschließlich aus dem Secure Mode verwendbar sind.
Des Weiteren benötigt OP-TEE einen Hardware Unique Key (HUK), dieser pro
Prozessor einzigartige Schlüssel wird verwendet, um weitere Schlüssel
abzuleiten, wie z.B. den Schlüssel, welcher zum Verschlüsseln der zu
speichernden Daten verwendet wird.
Auf einem Raspberry Pi 3 wird der Default Key bestehend aus Nullen verwendet,
da es dort keine Möglichkeit gibt, einen für den Secure Mode einzigartigen
Schlüssel zu erstellen.
Fast alle i.MX6 Prozessoren (mit Ausname des i.MX6ULL/SLL) besitzen ein
Crypotographic Accelerator and Assurance Module (CAAM).
Dieses ist in der Lage, einen für den Secure Mode einzigartigen Hash zu
erzeugen, welcher als HUK verwendet wird. Zusätzlich ist es möglich, ein
Register innerhalb der CAAM zu schreiben, welches dafür sorgt, dass nach dem
Schreiben ein anderer Hash erzeugt wird.
Ein Zurücksetzen des Registers ist dabei nur durch einen Reset des Systems
möglich.
Wichtig ist zu beachten, dass dieser Hash nur für Systeme einzigartig ist,
welche sich im High Assurance Boot (HAB) Modus befinden.
Dies ist die von NXP implementierte Variante des Authentifizierten Bootens,
bei dem der ROM-Code den zu startenden Bootloader authentifiziert.
Sollte der HAB Modus nicht eingeschaltet und aktiviert worden sein, verwendet
die CAAM statt des pro Prozessor einzigartigen Master Keys (MK) einen
Testschlüssel, welcher für alle Prozessoren gleich ist.
Daher ist eine sichere Verwendung von OP-TEE nur möglich, wenn das System per
HAB gestartet wird.</p>
<p>Als nächstes auf der Liste stehen die am System on Chip (SoC) angebundenen
Peripheriegeräte. Häufig ist nicht nur der Prozessor in der Lage, auf den
Arbeitsspeicher zuzugreifen, auch die Peripherie-Geräte können als Direct
Memory Access (DMA) Master Daten aus dem Arbeitsspeicher lesen und schreiben.
Im Falle der i.MX6 Prozessoren ist dafür die Central Security Unit (CSU)
verantwortlich.
Dort werden sowohl der Zugriffsmodus für die Einheit selbst als auch die
notwendigen Berechtigungen für den Zugriff auf eine Einheit festgelegt.
So ließe sich als Beispiel eine serielle Schnittstelle des SoCs allein aus dem
Secure Mode und damit aus dem OP-TEE zugreifbar machen.
Die Standard Konfiguration für den i.MX6UL im OP-TEE ist das Einstellen aller
Peripheriegeräte auf einen Normal Mode Zugriff.
Dadurch kann zum Beispiel die Grafikeinheit nicht mehr auf den für den Secure
Mode zugewiesenen Arbeitsspeicher zuzugreifen.</p>
</div>
<div class="section" id="zusammenfassung">
<h3>Zusammenfassung</h3>
<p>Nach Erläuterung der Problemstellung wurden die Fähigkeiten und Limitationen
von OP-TEE aufgezeigt sowie die enthaltene PKCS#11 TA kurz erläutert.
Danach folgte eine Erklärung der nötigen Integrationsschritte, um OP-TEE mit
i.MX6-Prozessoren sicher einsetzen zu können.
Dabei wurden vor allem die nötigen Schritte zur Absicherung des
Arbeitsspeichers vor fremden Zugriffen erläutert.</p>
</div>
</div>
<p>Moderne Linux Systeme müssen häufig zwecks Authentifizierung bei einer Cloud-
basierten Infrastruktur oder einer On-Premise Maschine eigene kryptografische
Schlüssel speichern. Statt der Verwendung eines Trusted Platform Modules (TPM),
bieten moderne ARM Prozessoren die TrustZone-Technologie an, auf deren Basis
ebenfalls Schlüssel oder andere Geheimnisse gespeichert werden können. Dieses
Paper zeigt die Nutzung des Open Portable Trusted Execution Environments (OP-
TEE) mit der Standardkonformen PKCS#11 Schnittstellen und i.MX6 Prozessoren
von NXP als Beispiel.</p>2022-02-01T09:45:03+01:00tag:www.pengutronix.de,2022-01-18:/2022-01-14-konferenzen-2021.htmlConferences 2021: A Retrospective and Outlook2022-01-18T17:00:00+01:00Marie Mann<div class="section" id="conferences-2021-a-retrospective-and-outlook">
<p>Besides the improvements around embedded Linux software and ongoing development
of Linux kernel components, the Pengutronix team took the corona pandemic as
an opportunity: Last year, many conferences were accessible via internet, so
we joined from the comfort of our home offices and shared our experiences and
ideas with the community.</p>
<p>For the statistics nerds among us: We were present at</p>
<ul class="simple">
<li>10 conferences with</li>
<li>15 presentations and published</li>
<li>18 new <a class="reference external" href="https://www.youtube.com/pengutronix">YouTube</a> videos</li>
</ul>
<div class="section" id="fosdem">
<h3>FOSDEM</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/waffeln.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/waffeln.thumb.fbc30ed81dcb22e61da9c0c362066a50.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>CC-BY: Jan Lübbe</p>
</figcaption>
</figure>
</div><p>Traditionally, the open source community meets for its annual meeting in
Brussels at the beginning of February - In 2021 however, beer and waffles
had to be consumed at the desk at home. Yummy :-)</p>
<p>The exchange took place via online lectures and the matrix messaging protocol.
Of course, waffles will be baked in the kitchen at home again in February 2022.</p>
<p><strong>Our Contributions:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=Uer9TpemmmE">About the joy and tears of testing Embedded Devices (C. Fiege)</a></li>
<li><a href="https://www.youtube.com/watch?v=wpaY7LiAKpg">The road to the mainline ZynqMP VCU driver (M. Tretter)</a></li>
<li><a href="https://www.youtube.com/watch?v=-Ak9MWGxd7M">From Reset Vector to Kernel - Navigating the ARM Matryoshka (A. Fatoum)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>5th and 6th February 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://fosdem.org/2022/">https://fosdem.org/2022/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="chemnitzer-linux-tage">
<h3>Chemnitzer Linux Tage</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="607x715" href="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/ptx-workadventure.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/ptx-workadventure.thumb.f6d0b1a32fc51372c2cbc698695147ed.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Screenshot of Workadventure</p>
</figcaption>
</figure>
</div><p>The CLT learned from the Chaos Computer Club and pixelated the lecture hall
building in a workadventure. The result was a real conference experience where
people spontaneously met and chatted in the corridors. At every corner, lovely
designed details or participants streaming videos of their guinea pigs
surprised everyone.</p>
<p>The world was complemented by numerous lectures and Big Blue Button rooms,
offering workshops or lightening talks.</p>
<p>We are looking forward to the implementation in 2022 and will be there again
with the Pengutronix Quiz with questions about Linux, open source and embedded
topics.</p>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>12th and 13th March 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://chemnitzer.linux-tage.de/2022/de/">https://chemnitzer.linux-tage.de/2022/de/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="building-iot">
<h3>building IoT</h3>
<p>"building IoT is the trade conference for IT professionals developing
applications and products in the Internet of Things and IIoT."</p>
<p>We would like to thank the speakers for their excellent support during the
conference and for the interesting selection of topics.
We look forward to attending <em>building IoT</em> in the future.</p>
<p><strong>Our Contributions:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=qU99-S_1ll4">Raspbian vs. Build-Systeme: Das richtige Werkzeug für solide Produkte
(B. Krause)</a></li>
<li>Wir haben doch etwas zu verbergen: Schlüssel mit OP-TEE verschlüsseln
(R. Czerwinski)</li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>10th and 11th May 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://www.buildingiot.de/index.php">https://www.buildingiot.de/index.php</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="osadl-cool">
<h3>OSADL COOL</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/cool.svg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/cool.svg" style="
width: 200px;
"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Logo COOL: All rights reserved</p>
</figcaption>
</figure>
</div><p>The monthly online conference programme of Open Source Development Lab (OSADL)
has become an integral part of the Pengutronix team's schedule.</p>
<p>In the editions, various topics relating to open source software in the
industrial environment are discussed and debated. The structure follows the
pattern: introduction to the topic by an overview lecture, followed by an
expert lecture and subsequent discussion.</p>
<p><strong>Our Contribution:</strong></p>
<ul class="simple">
<li>Security requirements of embedded systems with special emphasis on field
update (J. Lübbe)</li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>26th January 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://www.osadl.org/">https://www.osadl.org/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="live-embedded-event">
<h3>Live Embedded Event</h3>
<p>The <strong>Live Embedded Event</strong> is another format that has emerged during the pandemic
to gather the embedded community.</p>
<p>As the conference is initiated and hosted by our colleagues from France, the
conference language is mixed French and English.</p>
<p><strong>Our Contribution:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=_0Ipv9Rf1Rc">The Woos and Woes of Open-Source FPGA-Tools: A journey (S. Trumtrar)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>18th May 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://live-embedded-event.carrd.co/">https://live-embedded-event.carrd.co/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="digitaltag">
<h3>Digitaltag</h3>
<p>"Over 2,000 actions nationwide and 4,325 hours of programming across Germany
and in virtual space. That was Digitaltag 2021!"</p>
<p>For Hildesheim, we looked at the question of how to transform a city into a
"smart city". To do this, we first looked at LoRaWAN as a technical building
block for a smart Hildesheim and then tried to work out what a smart city can
learn from Freifunk as a community project.</p>
<p><strong>Our Contribution:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=f5xDaSFZZBY">Smart City - vom Rapid Prototyping bis zur Tragfähigen Infrastruktur
(C. Fiege, L. Göhrs, R. Schwebel)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>24th June 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://digitaltag.eu/">https://digitaltag.eu/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="fpga-conference-europe">
<h3>FPGA-Conference Europe</h3>
<p>The FPGA Conference is aimed primarily at industry with specialist
presentations on the development of FPGAs. The focus was on supply chain
security, AI and edge computing with a focus on concrete product solutions.</p>
<p><strong>Our Contribution:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=LBQqQFsnoeg">Your product is broken, and you don't know - An uncomfortable truth
(M. Tretter)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>5th to 7th July 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://www.fpga-conference.eu/">https://www.fpga-conference.eu/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="froscon">
<h3>FrOSCon</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/froscon.svg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-01-14_konferenzen-2021/froscon.svg" style="
width: 200ppx;
"/>
</a><figcaption itemprop="caption description" style="
width: 200ppx;
"><p>Logo FrOSCOn: All rights reserved</p>
</figcaption>
</figure>
</div><p>The summer meeting of the German-speaking open source community also took place
online in 2021. In ~ 36 hours lecture recordings, experiences with working
in a home office, security vulnerabilities, entry possibilities into open
source development are conveyed. A new addition is the category "Woodworking
instead of IT" about hobbies and compensation possibilities that speakers have
tried out and discovered during the COVID-19 contact restrictions.</p>
<p><strong>Our Contribution:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=af0P62ZLrvk">DOOM portieren für Einsteiger: Heavy Metal auf Bare Metal (A. Fatoum)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>unkown</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://www.froscon.de/">https://www.froscon.de/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="elc-e">
<h3>ELC-E</h3>
<p>This time the ELC-E was not only a conference in Europe, but a hybrid event
in the USA with guests from all over the world, on site and via the internet.</p>
<p>Understandably, it is difficult to accommodate all sleeping habits when a
global audience gathers at a conference. Thanks to a spontaneously provided
Jitsi, a technically sound exchange among the participants was well possible,
but nevertheless this can hardly replace the discussion in the corridors. We
are therefore very much looking forward to meeting again live at the next ELC-E
conference.</p>
<p><strong>Our Contributions:</strong></p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=fpt2A36ML-c">Initializing RISC-V: A guided tour for ARM developers (A. Fatoum,
R. Czerwinski)</a></li>
<li><a href="https://www.youtube.com/watch?v=lA7rvVscZTs">Teach an old network driver new tricks (O. Rempel)</a></li>
<li><a href="https://www.youtube.com/watch?v=rfOe-se4zx0">Automated Testing for Embedded development: Next generation Board
Farming (C. Fiege)</a></li>
<li><a href="https://www.youtube.com/watch?v=HgRZpe702JM">Building Open Hardware with Open Software (M. Tretter)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="24%"/>
<col width="76%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>13th to 16th September 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/">https://events.linuxfoundation.org/embedded-linux-conference-europe/</a></td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="ese-congress">
<h3>ESE-Congress</h3>
<p>The <strong>Embedded Software Engineering (ESE) Congress</strong> describes itself as the leading
congress for the embedded industry. In addition to an extensive track on
management and team leadership, the congress offers basic lectures in many
relevant areas of embedded development, such as test automation and code
quality.</p>
<p><strong>Our Contributions:</strong></p>
<ul class="simple">
<li>Wir haben doch etwas zu verbergen: Schlüssel mit OP-TEE verschlüsseln
(R. Czerwinski)</li>
<li><a href="https://www.youtube.com/watch?v=_9OMJyB5kBk">QM meets CI - Entwicklerfreundliche Prozessdokumentation (M. Mann)</a></li>
</ul>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Next Date</td>
<td>5th to 9th December 2022</td>
</tr>
<tr><td>Event URL</td>
<td><a href="https://ese-kongress.de/">https://ese-kongress.de/</a></td>
</tr>
</tbody>
</table>
</div>
</div>
<p>Besides the improvements around embedded Linux software and ongoing development
of Linux kernel components, the Pengutronix team took the corona pandemic as
an opportunity: Last year, many conferences were accessible via internet, so
we joined from the comfort of our home offices and shared our experiences and
ideas with the community.</p>2022-01-18T17:00:00+01:00tag:www.pengutronix.de,2022-01-01:/2022-01-01-pengutronix-kernel-contributions-in-2021.htmlPengutronix Kernel Contributions in 20212022-01-01T13:46:36+01:00Robert Schwebel<div class="section" id="pengutronix-kernel-contributions-in-2021">
<p>2022 has started, and although Corona had a huge impact on our workflow,
the Pengutronix team again made quite some contributions to the Linux
kernel. The last kernel release in 2020 was 5.10, the last one in 2021
was 5.15, so let's have a look at what happened in between.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x855" href="https://www.pengutronix.de/media/blog/2022/2022-01-01_pengutronix-kernel-contributions-in-2021/happy_2022.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2022/2022-01-01_pengutronix-kernel-contributions-in-2021/happy_2022.thumb.25a32c0de6bc85fbf76e1e21540412a2.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Like always, Pengutronix' kernel contributions are driven by industrial
embedded linux projects: our customers build devices, we look at what's
already supported by the kernel and help with what's missing. Sometimes
that means picking up patches from the mailing lists and improving them
until they are ready for prime time, sometimes drivers have to be
written from scratch, and sometimes even frameworks have to be modified
to make a certain feature possible.</p>
<p>Patch series are usually first written to fulfill the project's
requirements, then posted to the mailinglists and reviewed by the
community and maintainers. So when a patch enters mainline, it often has
a months-long, sometimes years-long history.</p>
<p>All in all, 675 patches written by Pengutronix found their way into the
kernel in the 5.10 to 5.15 period - more than 1.8 patches per day, and
authored by 14 colleagues:</p>
<table border="1" class="docutils">
<colgroup>
<col width="20%"/>
<col width="30%"/>
<col width="20%"/>
<col width="30%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">No of Patches</th>
<th class="head">Author</th>
<th class="head">No of Patches</th>
<th class="head">Author</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>202</td>
<td>Uwe Kleine-König</td>
<td>9</td>
<td>Marco Felsch</td>
</tr>
<tr><td>149</td>
<td>Marc Kleine-Budde</td>
<td>8</td>
<td>Sascha Hauer</td>
</tr>
<tr><td>118</td>
<td>Oleksij Rempel</td>
<td>2</td>
<td>Jürgen Borleis</td>
</tr>
<tr><td>48</td>
<td>Lucas Stach</td>
<td>2</td>
<td>Rouven Czerwinski</td>
</tr>
<tr><td>47</td>
<td>Michael Tretter</td>
<td>1</td>
<td>Jan Lübbe</td>
</tr>
<tr><td>45</td>
<td>Philipp Zabel</td>
<td>1</td>
<td>Leonard Göhrs</td>
</tr>
<tr><td>26</td>
<td>Michael Grzeschik</td>
<td>1</td>
<td>Steffen Trumtrar</td>
</tr>
<tr><td>16</td>
<td>Ahmad Fatoum</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p>However, the pure number of patches rarely reflects the amount of work
that was spent into bringing things mainline. Compared to earlier years,
we have much more complex series related to graphics or network topics,
which often need quite some rounds of review & rework until they hit
mainline. In the end, kernel development continues being about high
quality code, and it remains a lot of hard work to get even smaller
patches into the kernel.</p>
<p>To get an impression about our work, let me look at the larger topics
that have been worked on:</p>
<ul>
<li><p class="first">Uwe Kleine-König's patches are dominated by his interest in the PWM
subsystem: 116 of the 202 patches are in that area. While PWM looks
like an easy thing on the first glance, it turned out that there is a
lot of undefined semantics and differing behavior between drivers. So
many of these patches are made to improve the kernel towards better
subsystem quality.</p>
<p>Other patches are in the NFC, Input, SPI, hwmon, firmware, backlight,
leds, tty, device tree, clock, i2c, rtc and driver core area -
functionality that turn up when you bring up random customer hardware
and clean up things you find along the way.</p>
</li>
<li><p class="first">Marc Kleine-Budde maintains the Linux CAN subsystem, so it's no
surprise that 143 of his 149 patches are in the CAN subsystem. In many
cases they have been made to improve performance of a certain CAN
driver in a given customer scenario: the driver for the Microchip
MCP251x (a widely used SPI-to-CAN controller) got 37 patches alone.
Other work has been done for many other drivers (rcar, c_can,
tcan4x5x, flexcan, at91, hi311x, peak_usb, m_can) and for the CAN
subsystem itself.</p>
</li>
<li><p class="first">Oleksij Rempel wrote many patches in the area of CAN / J1939 and related to
ethernet switches and "modern" ethernet physics, such as 10-Base T1s.</p>
</li>
<li><p class="first">Lucas Stach's patches are of course related to Etnaviv, the open
source drivers for Vivante GPUs, but also related to clk, power and
gpcv2. This reflects his work on bringing i.MX8M support in mainline
forward.</p>
</li>
<li><p class="first">Michael Tretter worked mainly on the Xilinx UltraScale family and on
the "allegro" video encoder and decoder drivers on those chips - a big
and complex series that needed many iterations and quite some time to
come mainline. UltraScale is a great platform for customer specific
video processing - a topic that is becoming more and more interesting
for our customers!</p>
</li>
<li><p class="first">Philipp Zabel maintains the reset subsystem in the kernel. In
addition, he continued his work on the CODA and other i.MX graphics
and video components.</p>
</li>
<li><p class="first">Michael Grzeschik worked mainly in two areas: The KSZ8795 ethernet
switch and USB UVC.</p>
</li>
<li><p class="first">Ahmad Fatoum took care of many i.MX8M related bug fixes, including
clock issues, TF-A interfacing and deferred probe handling. He also
worked on STM32MP1, nvmem, dm crypt and sensors.</p>
</li>
<li><p class="first">Marco Felsch, Sascha Hauer, Jürgen Borleis, Rouven Czerwinski, Jan
Lübbe and Steffen Trumtrar worked on spi, ASoC, the CODA, ethernet
chips and switches, pwms, i2c, Etnaviv, ecryptfs, quota, NAND flash,
ubifs, DMA on i.MX, regulators, OP-TEE and network timestamping.</p>
</li>
<li><p class="first">Last but not least, our hardware developer Leonard Göhrs got his
first patch into the kernel, fixing an ALSA sound problem on
PowerPC. :-)</p>
</li>
</ul>
<p>Looking through the impressive list of 675 patches and knowing all the
engineering stories behind small one-liners as well as super-huge patch
series, I think we can be satisfied with what we improved in the kernel
in 2021. A lot of interaction with the other kernel developers and
maintainers happened along the way, and we learned a lot.</p>
<p>And, last but not least, quite many customer problems got solved in a
sustainable way. Issues that are fixed in mainline will not hurt other
people out there in the future. So please, if you would have been hit by
a problem that we (or others in the community) already solved, please
express your thankfulness by bringing your patches mainline as well. :-)</p>
<p>The kernel history goes back to Linux 2.5.0, and with the recent
contributions, we now have 6278 patches in mainline.</p>
<p>Happy new year!</p>
</div>
<p>2022 has started, and although Corona had a huge impact on our workflow,
the Pengutronix team again made quite some contributions to the Linux
kernel. The last kernel release in 2020 was 5.10, the last one in 2021
was 5.15, so let's have a look at what happened in between.</p>2022-01-01T13:46:36+01:00tag:www.pengutronix.de,2021-12-02:/2021-12-02-qm-meets-ci.htmlQM meets CI2021-12-02T14:00:00+01:00Marie Mann<div class="section" id="qm-meets-ci">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3504x2480" href="https://www.pengutronix.de/media/blog/2021/2021-12-02_qm-meets-ci/qm-meets-ci.jpg" itemprop="contentUrl">
<img "aktuell".="" "anforderungen="" "authorisiert",="" "benutzerfreundlich",="" "buildserver="" "cc-by-sa"="" "fairness"="" "linux="" "m.mann@pengutronix.de"."="" "marie="" "mitarbeit"="" "plaintextdateien",="" "prozess-lifecycle".="" "qm="" "tux".="" "versionskontrolle",="" "webdarstellung".="" "werkzeuge".="" "x"="" (continuous="" (while="" +="" -="" 3="" 6="" 9="" [check]="" [clock]="" [cuboid="" [monitor="" [sheet="" [stick="" [y-shaped="" a="" alt="This picture visualizes the most important statements of the talk and
corresponding blogpost: " an="" and="" are="" arranged="" arrow="" arrows:="" at="" author="" beneath="" book="" bottom="" branch]="" bright="" by="" check="" ci="" ci"="" clockwise="" connected="" contact="" contains="" copyright="" cuboid="" dashed="" deployment)",="" divided="" dotlist="" dots="" drawing="" drawings="" each="" entwicklerfreundliche="" fifth="" figure="" figure,="" figure]="" figures="" first="" four="" fourth="" from="" front.="" front]="" green="" group="" hammer="" handing="" hat="" hat.="" headline="" huge="" in="" information="" integration="" into="" is="" itemprop="thumbnail" kernel="" leads="" left="" letters="" linux="" looks="" mann="" mann.="" marie="" mascot="" meets="" monitor.="" noon="" o'clock="" o'clock:="" of="" on="" other.="" paper="" paper.="" paper]="" part="" parts:="" patch="" pencil,="" pencil.="" penguin,="" pengutronix".="" points="" prozessdokumentation"="" prozesse:",="" qm="" red="" replaced="" says:="" seal,="" second="" sheet="" shows="" side="" similar="" six="" sixth="" src="https://www.pengutronix.de/media/blog/2021/2021-12-02_qm-meets-ci/qm-meets-ci.thumb.32efdb4837e3df55aeac7a4d54048a8d.jpg" star.="" stick="" streaks.="" surrounded="" symbols="" symbols)="" talking="" testing="" that="" the="" third="" three="" title="" to="" top="" two="" upwards="" wearing="" wears="" with="" word="" workflow":="" www]="" yellow=""/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Sketchnote of the talk</p>
</figcaption>
</figure>
</div><p>"Hey Marie, how do I schedule my vacation dates again?", since I'm working
in the management division of Pengutronix, I know these kind of questions
very well.
Writing down the processes enables me to answer "RTFM".
Processes are organizational tasks that need to be performed over and over
again, sometimes based on a fixed interval - sometimes on demand.</p>
<p>When the process documentation at Pengutronix was revised from scratch in 2018,
the main question was how to involve the employees in the creation of the
processes.
For the documentation, a workflow and tools were chosen that were already
established among the majority of employees.</p>
<p>This article presents the chosen tools, shows the workflow and explains the
structure of a process description as an example.</p>
<p><em>Why write down processes?</em></p>
<p>As soon as a company is large enough that not all employees are sitting in the
same room and can see which tasks are being worked on at any given time, it
becomes necessary to write down precisely these processes.
Process documentation makes it possible to record the knowledge about the
processes and to establish rules.</p>
<p>Although the rules are set by the management, they are visible to all employees
and can therefore be demanded.
This enables fair treatment of all employees.</p>
<p><em>How can employees be involved?</em></p>
<p>Writing down the processes is not an end in itself, but serves to enable
employees to read up on how to apply for vacation, for example.</p>
<p>Often the process users are the content experts, because they follow the
process every day and live with it.
They know best how a process can be optimized.
This fact alone should be reason enough to involve the process users in the
design of the processes:</p>
<ul class="simple">
<li>the processes can be improved by the users and</li>
<li>the processes will be followed much more willingly if they make sense to the
users.</li>
</ul>
<p>Getting started in software development is often compared to a recipe.</p>
<p>A cookbook could also be called process documentation:
a process, like cooking, has a trigger (hunger) or entry point and describes a
set of instructions for action.</p>
<p>If the process documentation is the source code that runs the business, why not
use the tools from software development to write the process documentation?</p>
<p>At Pengutronix, the train of thought was taken seriously and the process
descriptions are designed in the form of a process manual using the tools of
software development.</p>
<p>For the implementation, there were the following requirements for the processes
and their presentation:</p>
<ul class="simple">
<li>the processes should be easily accessible,</li>
<li>the employees should have an opportunity to participate and be involved in
the design of the processes,</li>
<li>the processes are (therefore) subject to an approval process by the management,</li>
<li>the processes should be regularly checked to ensure that they are up to date.</li>
</ul>
<div class="section" id="tools-and-workflows">
<h3>Tools and workflows</h3>
<p>In order to meet the requirements and implement the process manual as a
"software project", both workflow and tooling, which are already established in
the company, are used.
These workflows and tooling are briefly described below.
The description will be reduced to the essential features that are necessary
for the design of the process documentation.</p>
<div class="section" id="linux-kernel-workflow">
<h4>Linux kernel workflow</h4>
<p>One of the most important and widely used workflows at Pengutronix is the one
used to develop the Linux kernel.</p>
<p>The Linux kernel is divided into different subsystems, which are roughly
comparable to individual departments of a company.
Depending on the complexity, there may be further subsystems.
Possible changes to the Linux kernel (bug fixes, new drivers, code quality
improvements) are first discussed within the subsystem.
A maintainer is responsible for each subsystem (this can be compared to a
middle management level), who carries out tests and checks whether the quality
standards are met.
If everything is in order, the changes of all subsystems flow into the next
version of the Linux kernel.
This is released by Linus Torvalds (the first author and maintainer of Linux)
himself.</p>
<p>We have adapted the described workflow for the work on the process manual:
changes to the process documentation are discussed with the respective process
users and then passed on to the management for approval.
Currently, the Pengutronix process manual project is still small enough that
"subsystem maintainers" e.g. a middle management layer is not required.</p>
</div>
<div class="section" id="version-control">
<h4>Version control</h4>
<p>In order to be able to implement this workflow, the processes are written as
structured text files that are managed in a version-controlled manner.
The release branch of the version management can only be written for the
management, so that a new release of the process manual also ensures the
release at the same time.</p>
<p>The advantage of files written in reStructuredText (.rst) or Markdown (.md)
plain-text formats as opposed to non-text-based formats such as .docx or .odf is
that the change in content can be easily tracked in a version management system
along with a timestamp and the respective authors.
Furthermore, in addition to just tracking changes, a version management system
also allows descriptive text to be written to record why a change was made and
what decisions led to the process change.</p>
</div>
<div class="section" id="web-representation">
<h4>Web representation</h4>
<p>As great as the charm of text files is from the point of view of the process
writers, for the process users the user-friendliness is not ideal.
Therefore, Pengutronix uses the open source software documentation tool Sphinx
to generate a web view of the process manual.
In this, the processes can be linked directly as well as forms belonging to a
process can be made available for download.</p>
</div>
<div class="section" id="build-server">
<h4>Build server</h4>
<p>With the help of a build server, the current release of the process
documentation is built and made available as a web view.
At the same time, the build server enables the use of automated tests.</p>
<p>At Pengutronix, the build server checks, among other things, whether the date
on which the next process review is due has been exceeded.
If this occurs, reminder e-mails are sent so that the process can be checked
promptly to ensure that it is up to date.</p>
<p>The setup has only been described schematically here, as the focus is not on
concrete products but on their use for process documentation.
What is more important is that any form of version management is used to track
changes and that any kind of build server is used for continuous testing and
continuous deployment.</p>
</div>
<div class="section" id="structure-of-a-process-description">
<h4>Structure of a process description</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1096x1079" href="https://www.pengutronix.de/media/blog/2021/2021-12-02_qm-meets-ci/process.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-12-02_qm-meets-ci/process.thumb.ef2cac687956a70909750aebf27c11c6.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Webpage of the Pengutronix process documentation (snippet)</p>
</figcaption>
</figure>
</div><p>In order for the setup to be used to its full extent, it is crucial that a
structure for the handbook and the structure of a process is determined in
advance.
A good example of the structure of processes and how such a manual can
be designed is the <a class="reference external" href="https://about.gitlab.com/handbook/">"Company Handbook"</a>
by GitLab Inc.</p>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a href="https://www.pengutronix.de/media/blog/2021/2021-12-02_qm-meets-ci/example.txt">Process_Template.txt</a></p>
</div>
</div>
<p>In order to go into practice, the structure of a process in the process
documentation of Pengutronix is described in excerpts, and a test is presented
as an example.</p>
<p>A process consists of three sections:
the first section is a table in which metadata is recorded.
When was the process last updated?
When is the next review due?
Is there a predecessor process?
Which process follows on from the current process?
Are there any forms to download?</p>
<p>The second section contains the actual process description.
There is no fixed form for this.
To make the process easy to read, additional structuring elements such as info
boxes or enumerations are used.</p>
<p>The third section is reserved for general information based on the quality
criteria of ISO 9001.
Among others, the following questions should be answered:
Who are the process users and owners? When is the process activated?
What requirements are there for the process users and what quality criteria are
there for the process to fulfill?</p>
<p>On the one hand, the structure is aimed at the process users so that the
information can be found as easily as possible.
On the other hand, the metadata table allows the use of test automation.</p>
</div>
<div class="section" id="test-automation">
<h4>Test automation</h4>
<p>One of the most important uses for test automation is a regular reminder that
processes are due for review.</p>
<p>In order for certain elements, such as the next review date of a process, to be
reviewed, it is necessary to specify very precisely where the element can be
found.
The table structure is particularly suitable for this.</p>
<p>The tests here were written in Python and the docutils library was used to
parse the file.
This code example shows the test for the review date of a process.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">check_Wiedervorlage</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">document</span><span class="p">):</span>
<span class="k">assert</span> <span class="s1">'Wiedervorlage'</span> <span class="ow">in</span> <span class="bp">self</span><span class="o">.</span><span class="n">_data</span><span class="p">,</span> \
<span class="n">annotate</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_table</span><span class="p">,</span> <span class="s2">"metadata table missing 'Wiedervorlage' row"</span><span class="p">)</span>
<span class="n">value</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">_data</span><span class="p">[</span><span class="s1">'Wiedervorlage'</span><span class="p">]</span>
<span class="n">match</span> <span class="o">=</span> <span class="n">re</span><span class="o">.</span><span class="n">match</span><span class="p">(</span><span class="sa">r</span><span class="s2">"(\w+): ([\d\-]+)"</span><span class="p">,</span> <span class="n">value</span><span class="p">)</span>
<span class="k">assert</span> <span class="n">match</span><span class="p">,</span> \
<span class="n">annotate</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_table</span><span class="p">,</span> <span class="s2">"metadata 'Wiedervorlage' row has the wrong format"</span><span class="p">)</span>
<span class="n">groups</span> <span class="o">=</span> <span class="n">match</span><span class="o">.</span><span class="n">groups</span><span class="p">()</span>
<span class="k">try</span><span class="p">:</span>
<span class="n">dt</span> <span class="o">=</span> <span class="n">datetime</span><span class="o">.</span><span class="n">strptime</span><span class="p">(</span><span class="n">groups</span><span class="p">[</span><span class="mi">1</span><span class="p">],</span> <span class="s2">"%Y-%m-</span><span class="si">%d</span><span class="s2">"</span><span class="p">)</span>
<span class="k">except</span> <span class="ne">ValueError</span><span class="p">:</span>
<span class="n">dt</span> <span class="o">=</span> <span class="kc">None</span>
<span class="k">assert</span> <span class="n">dt</span> <span class="ow">is</span> <span class="ow">not</span> <span class="kc">None</span><span class="p">,</span> \
<span class="n">annotate</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_table</span><span class="p">,</span> <span class="s2">"metadata review time ('</span><span class="si">{}</span><span class="s2">') format is invalid"</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="n">groups</span><span class="p">[</span><span class="mi">1</span><span class="p">]))</span>
<span class="k">assert</span> <span class="n">dt</span> <span class="o">>=</span> <span class="n">datetime</span><span class="o">.</span><span class="n">strptime</span><span class="p">(</span><span class="n">datetime</span><span class="o">.</span><span class="n">now</span><span class="p">()</span><span class="o">.</span><span class="n">strftime</span><span class="p">(</span><span class="s2">"%Y-%m-</span><span class="si">%d</span><span class="s2">"</span><span class="p">),</span> <span class="s2">"%Y-%m-</span><span class="si">%d</span><span class="s2">"</span><span class="p">),</span> \
<span class="n">annotate</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">_table</span><span class="p">,</span> <span class="s2">"metadata review time ('</span><span class="si">{}</span><span class="s2">') is in the past"</span><span class="o">.</span><span class="n">format</span><span class="p">(</span><span class="n">groups</span><span class="p">[</span><span class="mi">1</span><span class="p">]))</span>
</pre></div>
</div><p>This test consists of three test steps: first, it checks whether the table
column was found at all, then whether the date corresponds to the expected
format, and finally whether this date is in the past.</p>
</div>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
<p>The process documentation has been successfully managed in this form at
Pengutronix for three years now and is used by developers, admins as well as
the administration (partly in independently managed documentations).</p>
<p>The goal of enabling employees to participate in the design of processes has
been achieved.
Of course, the process manual, like a software project, is never finished.
Therefore, it is also important for the maintenance of the process
documentation that there is a responsible person with a corresponding time
budget.</p>
</div>
</div><p>"Hey Marie, how do I schedule my vacation dates again?", since I'm working
in the management division of Pengutronix, I know these kind of questions
very well.
Writing down the processes enables me to answer "RTFM".
Processes are organizational tasks that need to be performed over and over
again, sometimes based on a fixed interval - sometimes on demand.</p>2021-12-02T14:00:00+01:00tag:www.pengutronix.de,2021-09-20:/2021-09-20-rauc-hawkbit-updater-release.htmlrauc-hawkbit-updater v1.0 Released2021-09-20T12:00:00+01:00Bastian KrauseEnrico Jörns<div class="section" id="rauc-hawkbit-updater-v1-0-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/releases/tag/v1.0">v1.0</a> of
rauc-hawkbit-updater or visit its
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">GitHub page</a>.</p>
</div>
</div>
<p>Back in 2018, <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a> was started
by Prevas A/S as a C/GLib port of our <a class="reference external" href="https://github.com/rauc/rauc-hawkbit">rauc-hawkbit Python prototype</a> (also called <em>RAUC hawkBit Client</em>) that was mainly
developed for showcases and to serve as a demonstration and evaluation platform for others.</p>
<p>rauc-hawkbit-updater instead is explicitly developed with real-world use cases in mind.
Just as its earlier Python counterpart, it operates on the target as an interface between <a class="reference external" href="https://rauc.io">RAUC</a>, the embedded Linux update framework,
and <a class="reference external" href="https://www.eclipse.org/hawkbit/">hawkBit</a>, an OTA roll-out backend framework.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="356x521" href="https://www.pengutronix.de/media/blog/2021/2021-09-20_rauc-hawkbit-updater-release/rauc-hawkbit.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-09-20_rauc-hawkbit-updater-release/rauc-hawkbit.thumb.90a7d65ed201beb0252d92f9f78a70fa.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>RAUC interfacing with hawkBit: Components overview</p>
</figcaption>
</figure>
</div><p>Since its first incarnation in 2018, rauc-hawkbit-updater's code was refactored, bugs were fixed,
and features were added.
With the addition of a test suite that was capable of performing interaction tests with actual
hawkBit test instances, the project got more mature and, with the beginning of 2020,
rauc-hawkbit-updater was finally moved to the <a class="reference external" href="https://github.com/rauc">RAUC GitHub organization</a>
under the maintenance of Lasse Klok Mikkelsen (Prevas A/S).</p>
<p>Now, more than a year later after more refactoring, stabilization and initial <a class="reference external" href="https://rauc-hawkbit-updater.readthedocs.io">documentation</a>,
we're very happy to announce the first release version:
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/releases/tag/v1.0">rauc-hawkbit-updater 1.0</a>!</p>
<div class="section" id="up-next">
<h3>Up Next</h3>
<p>We won't stop here.
A whole bunch of feature pull requests are already
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/pulls?q=is%3Aopen+is%3Apr">queued up</a>, i.e.:</p>
<ul class="simple">
<li>HTTP retry handling</li>
<li>Resuming interrupted downloads</li>
<li>Support for action cancellation</li>
</ul>
<p>So if you are interested in managing your embedded system's updates with RAUC and hawkBit, make
sure to check it out.</p>
</div>
<div class="section" id="wonder-how-to-get-started">
<h3>Wonder How To Get Started?</h3>
<ul class="simple">
<li>Set up a hawkBit instance (e.g. via <a class="reference external" href="https://github.com/eclipse/hawkbit#getting-started">docker</a>)</li>
<li>Set up RAUC for your target</li>
<li>Cross compile rauc-hawkbit-updater for your target
(a Yocto recipe for this is available in <a class="reference external" href="https://github.com/rauc/meta-rauc/blob/master/recipes-support/rauc-hawkbit-updater/rauc-hawkbit-updater_1.0.bb">meta-rauc</a>)</li>
<li>Provide a configuration file that points to your rauc-hawkbit-updater instance</li>
<li>Start the rauc-hawkbit-updater daemon on your target to let it authenticate and poll for updates</li>
</ul>
<p>For more details follow our <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater#quickstart">Quickstart</a> guide and the <a class="reference external" href="https://rauc.readthedocs.io/">documentation</a>.
You're invited to join the community, discuss and contribute!
Either via matrix channel <a class="reference external" href="https://app.element.io/#/room/#rauc:matrix.org">#rauc</a> or on GitHub
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/issues">Issues</a>,
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/pulls">Pull requests</a> or
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater/discussions">Discussions</a>.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1166x610" href="https://www.pengutronix.de/media/blog/2021/2021-09-20_rauc-hawkbit-updater-release/rauc-hawkbit-updater-poll.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-09-20_rauc-hawkbit-updater-release/rauc-hawkbit-updater-poll.thumb.c672e0c323051ec5bc2a5c4d33a17fff.png"/>
</a><figcaption itemprop="caption description" style="
"><p>rauc-hawkbit-updater initially identifies with hawkBit (debug mode).</p>
</figcaption>
</figure>
</div><p>Finally, we would like to thank the folks from Prevas A/S for starting this project and making it
open source under LGPL-2.1, and especially to Prevas' Lasse Klok Mikkelsen, the lead maintainer
until the v1.0 release.
Starting with v1.0, the project will now be primarily maintained by the Pengutronix developers
Bastian Krause and Enrico Jörns.</p>
</div>
</div>
<p>Back in 2018, <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a> was started
by Prevas A/S as a C/GLib port of our <a class="reference external" href="https://github.com/rauc/rauc-hawkbit">rauc-hawkbit Python prototype</a> (also called <em>RAUC hawkBit Client</em>) that was mainly
developed for showcases and to serve as a demonstration and evaluation platform for others.</p>2021-09-20T12:00:00+01:00tag:www.pengutronix.de,2021-09-16:/2021-09-16-labgrid-tutorials.htmllabgrid Tutorials2021-09-16T12:00:00+01:00Bastian Krause<div class="section" id="labgrid-tutorials">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="367x309" href="https://www.pengutronix.de/media/blog/2021/2021-09-16_labgrid-tutorials/image.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-09-16_labgrid-tutorials/image.thumb.3f5d8bfc5763c2ca633c8538a2e75e9c.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>This week, we started our series of YouTube labgrid tutorials.
In the next few weeks we will publish more video tutorials showing you labgrid's features and
giving you handy tips and tricks.</p>
<p>Keep an eye on the
<a class="reference external" href="https://www.youtube.com/watch?v=In_mOO35V7c&list=PLPy6BX4pJosCEq7CIU06bt2WM7lFAy1CF">labgrid tutorials playlist</a>.</p>
<div class="section" id="setup-cli">
<h3>#1 Setup & CLI</h3>
<p>In the first episode, we go through the steps needed to set up labgrid's distributed
infrastructure.
While doing that, we get to know <em>labgrid Resources</em>.
Then, we learn how to use labgrid's command-line interface "labgrid-client".</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The installation of labgrid changed since the videos were recorded.
Please follow the updated instructions for <a class="reference external" href="https://labgrid.readthedocs.io/en/latest/getting_started.html#installation">labgrid (client/exporter) setup</a>
and <a class="reference external" href="https://labgrid.readthedocs.io/en/latest/getting_started.html#coordinator">labgrid coordinator setup</a>.</p>
</div>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/In_mOO35V7c"></iframe>
</div>
</div>
<div class="section" id="strategy-basics">
<h3>#2 Strategy Basics</h3>
<p>In the second episode, we learn the concept behind <em>labgrid Drivers</em> and <em>Strategies</em>.
How does your board reach a well-defined state?
And what has the <em>labgrid Environment Configuration</em> to do with it?
With the command-line interface "labgrid-client", we transition into the states of the
<em>BareboxStrategy</em>.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/6sK89PSBM-Y"></iframe>
</div>
</div>
<div class="section" id="workflow-automation-automated-tests">
<h3>#3 Workflow Automation & Automated Tests</h3>
<p>Are you tired of repeating the same steps over and over again while developing on your embedded
board?
We learn how to automate such steps using labgrid as a Python library.
Then, we see how easy it is to write automated tests for your embedded device.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/rHEzD6V_lQY"></iframe>
</div>
</div>
<div class="section" id="write-your-own-strategy">
<h3>#4 Write Your Own Strategy</h3>
<p>Whenever you have a slightly more complex or different use case, labgrid's shipped Strategies are
not sufficient anymore.
In this video, we learn how to write our own Strategy, unleashing the versatility of labgrid's
collection of Drivers.
The custom Strategy we create in this video allows us to test the images built by an auto-builder
automatically, without anyone moving a single finger.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/APIA8aUH98Q"></iframe>
</div>
</div>
</div>
<p>This week, we started our series of YouTube labgrid tutorials.
In the next few weeks we will publish more video tutorials showing you labgrid's features and
giving you handy tips and tricks.</p>2021-09-16T12:00:00+01:00tag:www.pengutronix.de,2021-09-03:/2021-09-03-pengutronix-on-elc-2021.htmlPengutronix on ELC 20212021-09-03T14:55:48+01:00<div class="section" id="pengutronix-on-elc-2021">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2021/2021-09-03_pengutronix-on-elc-2021/studio.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-09-03_pengutronix-on-elc-2021/studio.thumb.ee4eed931e72dfa115642ca7a6c15ee5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Speaker view of our studio</p>
</figcaption>
</figure>
</div><p>The sun is shining for the last days of summer 2021.
It doesn't only mean that autumn is coming, but also
that this year's ELC is in preparation.</p>
<p>Since the ELC takes place in North America in-person and in Europe virtually,
our colleagues are recording their talks.
We are proud to contribute to the ELC's schedule with
four talks and covering a wide range of topics: from writing
kernel mainline drivers to hardware testing.</p>
<div class="section" id="teach-an-old-network-driver-new-tricks">
<h3>Teach an Old Network Driver New Tricks</h3>
<p><strong>Oleksij Rempel & Marc Kleine-Budde</strong></p>
<p>This talk gives an overview of several new features in the networking driver
world and how your Ethernet or CAN driver can benefit from it. In most cases
there is HW support, but old network drivers implement only a limited amount of
functionality: PHY support in Ethernet drivers is hard coded (AX88772) or
switches aren't connected to the Kernel's switch framework (AR9331). Today PHYs
(gigabit or single pair ETH) need special handling, hard coding PHY support is
not an option. So let's convert Ethernet drivers to make use of the phylib as
an Abstraction Layer. This brings access to ready to use PHY drivers and new
functionalities, like diagnostic, self testing, cable testing, and workarounds
for PHY specific errata. The functionality of Ethernet switches perfectly fits
under the DSA framework which is the kernel's abstraction for different types
of switching HW offloading capabilities. Another nifty feature to add is RX/TX
hardware timestamping that modern MACs support, to increases diagnostic
capabilities. Devices can benefit from lower latencies with Byte Queue Limit
support, those connected with slow buses (USB, SPI) can combine outgoing
network packets into one transaction. The talk will briefly mention XDP, what it
does and if your ETH and CAN driver can benefit from it.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/lA7rvVscZTs"></iframe>
</div>
</div>
<div class="section" id="initializing-risc-v-a-guided-tour-for-arm-developers">
<h3>Initializing RISC-V: a Guided Tour for ARM Developers</h3>
<p><strong>Ahmad Fatoum & Rouven Czerwinski</strong></p>
<p>RISC-V is the hot and upcoming architecture in the embedded space. While a
majority of embedded developers have earned their chops programming for ARM
processors (and PowerPC beforehand), many have yet to dip their toes into the
growing RISC-V ecosystem. This talk will guide attendees through the RISC-V
architecture and some of its ISA extensions and then follow Ahmad's and
Rouven's journey in applying their ARM knowledge to porting the barebox
bootloader to the RISC-V-powered Beagle-V Starlight, while enjoying the fun and
woe of early-revision silicon.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/fpt2A36ML-c"></iframe>
</div>
</div>
<div class="section" id="building-open-hardware-with-open-software">
<h3>Building Open Hardware with Open Software</h3>
<p><strong>Michael Tretter</strong></p>
<p>Since their invention in the 80s, FPGAs are used in many domains of digital
electronics. Up until now they play a notable role in embedded system
development because they allow simultaneous development of system software and
hardware. Combined System-On-Chips and FPGAs in one package make offloading
realtime- or safety-critical processes to the FPGA even easier. Thanks to the
work of many open-source developers, we can now use tools like Yosys and
nextpnr to build FPGA bitstreams with a completely open-source toolchain, top
to bottom. With the recent rise of RISC-V there is even an open ISA, allowing
development of a multitude of compatible, open CPU cores. Designing systems
that contain FPGAs becomes more difficult, as they introduce additional
flexibility and, thus, complexity into systems. For example, which modules to
implement as gateware or as software is a critical decision. Moreover, the
software must be able to adapt to changing gateware, as it might change due to
system updates. This must be considered in the software and system architecture
as well. In this talk, Michael will present his experience with using the open
source FPGA tools. Furthermore, he will outline important aspects when
designing systems involving software, gateware, and actual hardware.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/HgRZpe702JM"></iframe>
</div>
</div>
<div class="section" id="automated-testing-for-embedded-development-next-generation-board-farming">
<h3>Automated Testing for Embedded Development: Next Generation Board Farming</h3>
<p><strong>Chris Fiege</strong></p>
<p>Board farming is an important topic for embedded Linux development: It allows
developers to share their hardware and lays the foundation for continuous
testing of BSPs and applications on real hardware. With this talk I want to
continue the discussion on how to control large numbers of Embedded Devices in
a lab. I will begin with a short introduction on how Pengutronix currently
operates their board farm: I will give you an overview on the hardware we use
and how we use labgrid to support interactive work and automated testing of our
devices under test. Afterwards I will give some insight of the everyday life
with 150+ slots in the Pengutronix lab and what the most annoying (and
expensive) problems are. To mitigate most of the problem my team and I are
currently working on a new way to organize our labs: we try to shift our labs
from a centralized architecture with many devices connected to a few control
servers to a distributed structure where every device under test is controlled
by its own test automation controller. I will conclude my talk with a
discussion of the pros and cons of this design that we already discovered.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/rfOe-se4zx0"></iframe>
</div>
</div>
</div>
<p>The sun is shining for the last days of summer 2021.
It doesn't only mean that autumn is coming, but also
that this year's ELC is in preparation.</p>2021-09-03T14:55:48+01:00tag:www.pengutronix.de,2021-08-30:/2021-08-25-update-des-remotelab-equipments.htmlUpdate of our Remotelab equipment2021-08-30T11:38:19+01:00Leonard Göhrs<div class="section" id="update-of-our-remotelab-equipment">
<blockquote>
"If it looks like a duck, swims like a duck, and quacks like a duck, then it
probably is a duck."</blockquote>
<p>If it looks like an advertising blogpost, reads like an advertising blogpost
... it probably is an advertising blogpost!
Nobody likes to read advertisements and we don't like to write them at all,
but like all proud parents, we would like to show you the new products that our
corporate subsidiary, <a href="https://linux-automation.com">Linux Automation GmbH</a>,
has freshly added to their store.
With these new products we, and maybe soon you, will complete (y)our
<a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-remote-working.html">Remotelab infrastructure</a>.</p>
<div class="section" id="lxa-iobus-4do-3di-3ai">
<h3>LXA IOBus 4DO-3DI-3AI</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3048x2281" href="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/can-io.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/can-io.thumb.f48a1a593abca3d310023d1cb347b9a5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>LXA IOBus 4DO-3DI-3AI</p>
</figcaption>
</figure>
</div><p>Not all projects boot from SD cards, sometimes boards are flashed via USB,
boot from an eMMC or even from NAND¹.
To switch the active boot mode in this case, you usually just have to
short-circuit two pins, or press a button. Since this quickly becomes tiring,
especially during constant tests, there is now an elegant technical solution:</p>
<p>The LXA IOBus 4DO-3DI-3AI allows to switch small electrical loads and thus e.g.
automatically, where otherwise jumpers would have to be set manually, to switch
between different boot modes or to trigger resets, which are otherwise
performed by pressing a button.
In addition, the 4DO' can be used to read supply voltages or collect digital
status feedback and feed it back into the test automation.</p>
</div>
<div class="section" id="candlelight">
<h3>candleLight</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1936x1936" href="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/candlelight.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/candlelight.thumb.acef1df8229a10138db5bab976812e64.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>CandleLight</p>
</figcaption>
</figure>
</div><p>In our blog post <a href="https://www.pengutronix.de/en/blog/2021-05-25_the_lxa_iobus.html">The LXA IOBus line of lab automation devices</a>
we already reported about the ideas to change our lab-internal communication
from USB to CAN.
A recurring problem with this: a consumer computer cannot do CAN.
In our lab servers we usually solve this problem with PCI-Express CAN cards,
but for developer laptops these cards are too clunky.</p>
<p>Instead, we like the open source
<a href="https://github.com/linux-automation/candleLight">candleLight project</a>
very much.
So well, in fact, that we decided to brand it with a Rocket Penguin logo and
<a href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00">add it as a product to the store</a>.</p>
</div>
<div class="section" id="rj45-matrix">
<h3>RJ45-Matrix</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="667x500" href="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/rj45-matrix.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-08-25_update-des-remotelab-equipments/rj45-matrix.thumb.7b369e0ff8130ea410674482cc8d3848.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>RJ45-Matrix</p>
</figcaption>
</figure>
</div><p>The <a href="https://shop.linux-automation.com/Accessories/lxa_tools-S02-R01-V01-C00">RJ45-Matrix</a>
is another small, but still very fine toy from the LXA-Tools series.
The RJ45-Matrix can be used to make connections between all lines of two RJ45
jacks via solder bridges or any 0402 SMD components.</p>
<p>What have we used the RJ45 matrix for so far?</p>
<ul class="simple">
<li>As a breakout board for RJ45 jacks on 2.54mm pin headers.</li>
<li>To swap Ethernet pairs between two Ethernet ports.</li>
<li>To couple two Ethernet devices via 0402 capacitors AC to feed PoE voltages
directly.</li>
</ul>
<p>What other uses could we think of?</p>
<ul class="simple">
<li>To create loopback connections, e.g. to test very long two-wire links over
much shorter eight-wire cables.</li>
<li>Generating defined cross talk by coupling the different pairs together.</li>
<li>Inserting e.g. resistive losses into a line.</li>
</ul>
<hr class="docutils"/>
<p>¹ What kinds of headaches NAND can create as a boot source would be a great
topic for another blog post. Until then, perhaps remember: "Avoid if possible!"</p>
</div>
</div><p>If it looks like an advertising blogpost, reads like an advertising blogpost
... it probably is an advertising blogpost!
Nobody likes to read advertisements and we don't like to write them at all,
but like all proud parents, we would like to show you the new products that our
corporate subsidiary, <a href="https://linux-automation.com">Linux Automation GmbH</a>,
has freshly added to their store.
With these new products we, and maybe soon you, will complete (y)our
{{ link(path='blog/2021/2021-02-21_showcase-remote-working/post_en.rst', name='Remotelab infrastructure', _content_path='blog/2021/2021-08-25_update-des-remotelab-equipments/post_en.rst', _content_lineno=7) }}.</p>2021-08-30T11:38:19+01:00tag:www.pengutronix.de,2021-06-18:/2021-06-18-smart-city.htmlSmart City - vom Rapid Prototyping bis zur Tragfähigen Infrastruktur2021-06-18T00:00:00+01:00Chris FiegeLeonard GöhrsRobert Schwebel<div class="section" id="smart-city-vom-rapid-prototyping-bis-zur-tragfahigen-infrastruktur">
<p>Wir wollen zum Bundesweiten Digitaltag am 18.6.2021 das Thema "Smarte
Städte" ein bisschen von der technischen Seite beleuchten, aber keine
Angst: es bleibt für alle verständlich.</p>
<p>Deshalb beleuchten wir im ersten Teil unseres Vortrags den Hintergrund:</p>
<ul class="simple">
<li>Was sind überhaupt "Smart Cities"?</li>
<li>Wie vernetzt man eine Stadt?</li>
<li>Und wer könnten die Nutzer sein?</li>
</ul>
<p>Weil das Mitmachen vieler Akteure in der Smarten Stadt über deren Erfolg
bestimmt, wollen wir zeigen, mit welchen einfachen Mitteln aus der
Maker-Szene man Informationen aus der realen Welt ins Netz bekommt: Am
Beispiel eines Feinstaub-Sensors zeigen wir "Hands On", wie man seine
Luftqualitätsmessung mit LoRAWAN für < 100 € und mit < 100 Zeilen
Python-Code ins Internet der Dinge bekommt.</p>
<p>Schließlich wagen wir einen Blick über den Tellerrand, auf kollaborative
Bürgernetze, offene Plattformen und nicht zuletzt die Frage, wie der Weg
vom Hacker-Sensor zu einer tragfähigen, professionellen Infrastruktur
aussehen kann.</p>
<p>Zum Abschluss wollen wir mit unseren Zuhörern diskutieren und mehr über
deren Ideen rund um die Smarte Stadt lernen.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4096x3072" href="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-gateway.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-gateway.thumb.be2a8a4ab542504e5963d60d702b541b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Unser LoRaWAN Gateway: Die offene Natur dieses Gerätes erlaubt es
uns einfach eigene Entwicklungen durchzuführen.
Aktuell befindet sich das Gateway oberhalb unserer Büros.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3704x2772" href="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-device.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-device.thumb.5d5936ce32aff5f317adbf95daf8787e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Mit frei verfügbarer Hardware lassen sich mit wenigen Zeilen Code
LoRaWAN-basierte Anwendungen umsetzen.
Hier präsentiert Chris Fiege einen sochen "LoPy**-Knoten in unserem
Elektroniklabor.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-node.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-06-18_smart-city-vom-rapid-prototyping-bis-zur-tragfaehigen-infrastruktur/ptx-smartcity-node.thumb.69fdfe6444ec1e711d0f14c899c17f69.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Um weitere Erfahrungen sammeln zu können betreiben wir einen
LoRaWAN-basierten Feinstaubsensor direkt an der Steuerwalder Str.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><div class="section" id="uber-pengutronix">
<h3>Über Pengutronix</h3>
<p>Seit 2001 unterstützt Pengutronix als Embedded Linux Spezialist Kunden
aus allen Bereichen der Industrie. Zu den Aufgaben gehört die Anpassung
von Linux an Kundenbedürfnisse ebenso wie Treiberentwicklung,
Echtzeitaufgaben, die Umsetzung von Grafik-, Video- und Netzwerkthemen
sowie Konzepte für die IT-Sicherheit und langfristige Wartbarkeit von
Geräten. Das 30-köpfige Team hat über 5.500 Änderungen zum Linux-Kernel
beigesteuert und gehört weltweit zu den führenden Experten in diesem
Bereich.</p>
</div>
<div class="section" id="aufzeichnung">
<h3>Aufzeichnung</h3>
<p>Die Aufzeichnung unseres Vortrags kann hier angesehen werden:</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/f5xDaSFZZBY"></iframe>
</div>
</div>
</div>
<p>Wir wollen zum Bundesweiten Digitaltag am 18.6.2021 das Thema "Smarte
Städte" ein bisschen von der technischen Seite beleuchten, aber keine
Angst: es bleibt für alle verständlich.</p>2021-06-18T00:00:00+01:00tag:www.pengutronix.de,2021-05-31:/2021-05-31-yocto-project-summit-2021.htmlYocto Project Virtual Summit 20212021-05-31T12:00:00+01:00Enrico Jörns<div class="section" id="yocto-project-virtual-summit-2021">
<p>On Tuesday, 25th and Wednesday, 26th, the 3rd edition of the Yocto Project
Virtual Summit took place on the internet.
With a fair ticket price of 40$ Pengutronix developers Jan Lübbe and Enrico
Jörns got a 2-day long wild ride through the latest features, workflows and
experiences with the Yocto Project in</p>
<ul class="simple">
<li>18 talks</li>
<li>The Open Embedded Developer Meeting</li>
<li>A Social Hour</li>
</ul>
<p>In parallel to the presentation track, there was also a training room with
interactive beginner and advanced sessions.
These were already full by the time we booked but could be watched for free
(without the material of course).</p>
<div class="ptx-sidebar">
<div class="title">
Conference Information
<div class="corner"></div>
</div>
<div class="body">
<p>Available on Pretalx: <a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/schedule/">Schedule</a></p>
<p>YouTube Playlist: <a class="reference external" href="https://www.youtube.com/watch?v=a2CNUtu7e6s&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ">Yocto Project Summit 2021</a></p>
</div>
</div>
<p>The conference was (again) held in Zoom with using Slack channels for the track
Q&A and general communication.
For people not willing or able to use Zoom, there was a parallel YouTube live
stream.
This entire setup really worked like a charm and made it easy to start short
technical and non-technical conversations.</p>
<div class="section" id="recommended-talks">
<h3>Recommended Talks</h3>
<p>Out of the entire pool of talks held during the two days, we would like to
recommend a few:</p>
<p>For those who find themselves in the situation of having to debug applications on
their target, two talks are worth a look:
In <a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/talk/WYGCNV/">"Leveraging the Yocto Project to debug an embedded Linux system"</a>
<a class="reference external" href="https://www.youtube.com/watch?v=1NqYrGY92rY&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ&index=8">[video]</a>
Sergio Prado demonstrates ways to make debug symbols available on
either the target or the host system and how to use them with gdb.
He also notes how other build parameters like optimization settings can affect
the debugability of a program.</p>
<p>Compared to this 'traditional' approach, a newer and very useful technique for
accessing debug symbols and sources was presented by Dorinda Bassey in her talk
<a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/talk/ADCYJ7/">"Using debuginfod with The Yocto Project"</a>
<a class="reference external" href="https://www.youtube.com/watch?v=S3QLr113mx8&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ&index=5">[video]</a>.
debuginfod provides a web server for finding and downloading debugging symbols
on-demand and is integrated into Yocto with the <tt class="docutils literal">debuginfod</tt>
<tt class="docutils literal">DISTRO_FEATURE</tt> for the target side and a helper script (<tt class="docutils literal"><span class="pre">oe-debuginfod</span></tt>)
for the host/server side.
A feature really worth being used!</p>
<p>In our personal experience, sooner or later, every Yocto user will run into
situations where the result of some variable manipulation results are not what
you expect.
Why things are how they are, what to keep in mind and how to debug when running
into certain issues, is all covered by Quenint Schulz' talk
<a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/talk/WTT3UV/">"Demystifying the OVERRIDES mechanism and Bitbake operators"</a>
<a class="reference external" href="https://www.youtube.com/watch?v=YbLe84JCSFg&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ&index=4">[video]</a>.
We recommend this to newbies as well as to more advanced bitbakers.
Or do you know exactly when <tt class="docutils literal">_remove</tt> will be evaluated and how to undo it?</p>
<p>An interesting quick introduction into both the rust language and the meta-rust
layer was presented by Steven Walter in
<a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/talk/YJYTVD/">"Using rust with bitbake and meta-rust"</a>
<a class="reference external" href="https://www.youtube.com/watch?v=xzM2GPLNvio&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ&index=12">[video]</a>.</p>
<p>From the <cite>Hands on Lab</cite> series, we especially recommend Joshua Watt's talk
<a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/talk/KFZKQF/">"Multiconfig Inception"</a>
<a class="reference external" href="https://www.youtube.com/watch?v=YvtlGjWrL-M&list=PLD4M5FoHz-TwWYbaJwduH8ZYNYvva76QQ&index=26">[video]</a>.
He demonstrates in detail how bitbake's multiconfig feature can be used to
build multiple different configurations (such as embedded Linux, Zephyr or
containers) in a single build run, saving time and reducing complexity.
Results from one configuration can then be combined seamlessly into a final
image.</p>
</div>
<div class="section" id="openembedded-developer-meeting">
<h3>OpenEmbedded Developer Meeting</h3>
<p>Being more of a co-located event than actually strictly belonging to the Summit
itself, the OpenEmbedded Developer Meeting (OEDVM) took place on the second
half of the first day.
It is a mix of recent and broader topics discussed by the core developers of
OpenEmbedded, the actual build system behind the Yocto Project.</p>
<p>For those interested in what is going on, there is a publicly available
topic collection in the OpenEmbedded
<a class="reference external" href="https://www.openembedded.org/wiki/OEDVM_2021">Wiki</a>.</p>
</div>
<div class="section" id="final-remarks">
<h3>Final Remarks</h3>
<p>We would like to say thanks to the Yocto Project organization committee that
made this event possible and to <a class="reference external" href="https://pretalx.com/yocto-project-summit-2021/speaker/QQZWAS/">Trevor Woerner</a> for
moderating the entire two days and having an 'amazing' for each and every talk.</p>
<p>According to his closing remarks, there were 366 people registered for the
entire event and thus way more than initially expected.
They split up into 51,9% for the presentation track and 48,1% for the beginner
class.</p>
<p>The next Summit will probably take place in September, maybe co-located to this
year's ELC.</p>
<p>A final very important take away of the two days that we cannot withhold (as it
was repeated so frequently):
There is a fan shop available, where you can buy all the T-shirts, stickers,
etc. you were not be able to collect from in-person events during Covid time!!:
<a class="reference external" href="https://shop.spreadshirt.com/the-yocto-project/">https://shop.spreadshirt.com/the-yocto-project/</a></p>
<p>See you in September, hopefully.</p>
</div>
</div>
On Tuesday, 25th and Wednesday, 26th, the 3rd edition of the Yocto Project Virtual Summit took place on the internet. With a fair ticket price of 40$ Pengutronix developers Jan Lübbe and Enrico Jörns got a 2-day long wild ride through the latest features, workflows and experiences with the Yocto Project.2021-05-31T12:00:00+01:00tag:www.pengutronix.de,2021-05-25:/2021-05-25_the_lxa_iobus.htmlThe LXA IOBus line of lab automation devices2021-05-25T09:05:00+01:00Leonard Göhrs<div class="section" id="the-lxa-iobus-line-of-lab-automation-devices">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2295x1848" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/4DO-3DI-3AI.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/4DO-3DI-3AI.thumb.055d5419e5a61cbfb8a2c6d605967540.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>I would like to present to you the LXA IOBus, a CAN-based
ecosystem consisting of a protocol, a gateway server and new
class of Linux Automation GmbH devices, including the Ethernet-Mux
and the 4DO-3DI-3AI input/output board.</p>
<p>We at Pengutronix use LXA IOBus devices when we want to automate low-bandwidth
interaction with devices under test (DUTs) in our Remotelabs.
Two examples for such devices are presented below, the Ethernet-Mux and the
4DO-3DI-3AI.</p>
<p>The Ethernet-Mux allow you to connect the DUT's Ethernet port with one
of two upstream Ethernet ports.</p>
<p>The 4DO-3DI-3AI allows the automation of button presses or setting/releasing
of a DUTs jumper connections. It also allows reading back digital and analog
voltage information from a DUT.</p>
<p>"What's a Remotelab?"
You may ask.
You may want to have a look at our blog post about our
<a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-remote-working.html">Remotelab infrastructure</a>.</p>
<div class="section" id="the-iobus-protocol">
<h3>The IOBus protocol</h3>
<p><em>Why build a custom protocol when USB, Ethernet, Modbus and 1-Wire are
already available?</em></p>
<ul>
<li><p class="first"><em>USB</em> - Our Remotelabs are equipped to connect up to 40 USB devices per rack.
Multiplying that by about eight full-scale Remotelabs currently in use at
Pengutronix means that we encounter even the rarest USB-related issues quite
regularly. This more often than not means losing contact to to all devices
connected to hub until it is manually power-cycled.
This quickly became a major time-sink and annoyance to our developers.</p>
<p>Don't get us wrong, we still like USB, whenever its high bandwidth capabilities
are required. We also continue to develop new products using USB, some of which
even speak <a class="reference external" href="https://www.linux-automation.com/en/products/usb-mux.html">USB on all of their ports</a>.
But that is a story for another time.</p>
</li>
<li><p class="first"><em>Modbus</em> - Modbus is widely used in industrial automation and there is a
selection of reasonably priced products from different manufacturers.
We did however not want to commit to it as a protocol for our own
hardware developments due to it's limited bandwidth and dated protocol.</p>
</li>
<li><p class="first"><em>Ethernet</em> - Ethernet requires point-to-point connections between devices
using rather clunky cabling, making it unwieldy when used for all devices
in our Remotelabs. There is also additional software complexity required
to implement the different protocol layers from Ethernet to TCP.
We are keeping an eye out for possible solutions to these issues,
like 10Base-T1S and CoAP, but it will take some time until they can be widely used.</p>
</li>
<li><p class="first"><em>1-Wire</em> - 1-Wire was our protocol of choice before we started developing
the LXA IOBus. The proprietary nature of the protocol coupled with the few
off-the-shelf tools did however lead to lots of hours spent debugging the setups.
The low maximum datarate is also a limiting factor when designing new products.</p>
</li>
</ul>
<p>The lessons learned from our experience with the protocols above led use to choosing
a CAN-based protocol for our future lab automation products. More specifically we
decided to base the LXA IOBus on CANopen, a device-abstraction layer on top of CAN.</p>
<p>CAN and CANopen have a couple of benefits:</p>
<ul class="simple">
<li><em>Rock solid</em> - CAN was designed with safety-critical systems, like cars, in mind.
While LXA IOBus devices are not used in safety-critical environments (please don't)
this is still a big plus for us. Automatic retransmits at the hardware layer and
the automatic disabling of misbehaving nodes means that a single broken device
or intermittent failure does not break the whole bus.</li>
<li><em>Tooling</em> - CAN is a first-class citizen in the Linux Kernel and there is a
large ecosystem around it. You can use Wireshark to debug CAN busses and can even
unpack CANopen with it.
There is also software to send and receive CAN packets included in most major distributions.</li>
<li><em>Multi-drop cabling</em> - CAN, at low datarates, is very forgiving when it comes to cabling.
A complete Remotelab can be wired using ribbon- and off-the-shelf D-Sub 9 cables
without requiring any hubs or switches. We use a single D-Sub 9 connector to supply
data and power to the device.</li>
<li><em>Automatic discovery</em> - CANopen allows hot-plugging and the automatic configuration
of connected devices.</li>
</ul>
<p>Please note that our LXA IOBus devices uses vendor-specific CANopen device profiles, so
integrating them into your elevator infrastructure or garbage truck electronics may
require some extra effort (feel free to contact as if you want to go that route though,
we would like to know).</p>
</div>
<div class="section" id="iobus-server">
<h3>IOBus Server</h3>
<p>The <a class="reference external" href="https://www.linux-automation.com/en/products/lxa-iobus.html">IOBus Server</a>
is the gateway between the IOBus and you. On one side it uses the
Linux SocketCAN interface to communicate with devices on the CAN bus, on the other
side it provides a HTTP-Server with an interactive web interface and scriptable
REST-API.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1020x350" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/iobus-server-node-list.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/iobus-server-node-list.thumb.b2b6341ec6df15725a8384081880d786.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>IOBus Server overview of the discovered nodes.
Clicking on a node in the list shows more information
about that node and allows interacting with it.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1020x503" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/iobus-server-node-detail.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/iobus-server-node-detail.thumb.35f48f3424804049adab927590e07f98.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Interactive view of a single node.
Clicking on an output button toggles it's state.
The name of the node and the corresponding output are
all that is required to control it via Labgrid.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>The IOBus Server is, and always will be, open source and is well integrated into the
<a class="reference external" href="https://www.pengutronix.de/en/software/labgrid.html">Labgrid</a>
lab automation framework.</p>
</div>
<div class="section" id="ethernet-mux">
<h3>Ethernet-Mux</h3>
<p>The <a class="reference external" href="https://www.linux-automation.com/en/products/ethernet-mux.html">Ethernet-Mux</a>
allows the multiplexing of two upstream Ethernet ports to one
downstream port (or vice versa). The connections are made using high-speed analog switches,
allowing you to use Ethernet at speeds up to 1000Base-T without the added latency
that would for example be added by a network-level Ethernet switch.</p>
<p>An example use case is a DUT that should be tested as part of a larger infrastructure,
but should also be able to connect to another network for software deployment or
remote access.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1633" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/ethmux-emi-1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/ethmux-emi-1.thumb.94b6025888ce4d235edcc7660b2cf119.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The Ethernet-Mux during EMI testing.
You can see the CAN based IOBus interface
and the three sockets for network cabling.
The sticky tape helps the Ethernet-Mux stay focussed
on the task at hand.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1633" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/ethmux-emi-2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/ethmux-emi-2.thumb.dd7c2fe975676fa0d237f1571b66ae81.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The Ethernet-Mux after passing the EMI tests.
Time to relax - no sticky tape required.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
<div class="section" id="do-3di-3ai">
<h3>4DO-3DI-3AI</h3>
<p>The <a class="reference external" href="https://www.linux-automation.com/en/products/lxa-iobus.html">LXA IOBus 4DO-3DI-3AI</a>
is our first device to break the cycle of LXA (Linux Automation GmbH)
devices called Something-Something-Mux, even though it could be used as
a GPIO-Mux. But let's not get into that.</p>
<p>The 4DO-3DI-3AI provides four digital outputs, three digital inputs and
three analog inputs.
The digital inputs and outputs are galvanically isolated and implemented
as solid state relays, allowing a lot of flexibility in their use.
The analog inputs are not isolated but can be used to measure voltages
up to 12V, allowing you to measure most supply rails of an embedded device.</p>
<p>The major use case for the 4DO-3DI-3AI is to programmatically bridge jumper
connections like boot mode selectors or reset pins, but it can also be used
to simulate button presses by soldering connections to said button.</p>
<p>The inputs can be used as a feedback source in automatic tests to determine
if a specific test ran successfully.</p>
<div class="ps-gallery single-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2295x1848" href="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/4DO-3DI-3AI.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-26_the_lxa_iobus/4DO-3DI-3AI.thumb.a025f7f4e27479cba03f05985deaa9ed.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 500px;
"></figcaption>
</figure>
</div></div>
</div><p>I would like to present to you the LXA IOBus, a CAN-based
ecosystem consisting of a protocol, a gateway server and new
class of Linux Automation GmbH devices, including the Ethernet-Mux
and the 4DO-3DI-3AI input/output board.</p>2021-05-25T09:05:00+01:00tag:www.pengutronix.de,2021-04-19:/2021-04-19-wie-man-kein-betriebssystem-fuer-produkte-baut.htmlWie man (k)ein Betriebssystem für Produkte baut2021-04-19T12:16:46+01:00Bastian Krause<div class="section" id="wie-man-k-ein-betriebssystem-fur-produkte-baut">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="
800x600
" href="https://www.pengutronix.de/media/blog/2021/2021-04-19_wie_man_kein_betriebssystem_fuer_produkte_baut/raspbian-vs-build-systeme.svg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-04-19_wie_man_kein_betriebssystem_fuer_produkte_baut/raspbian-vs-build-systeme.svg" style="
width: 450px;
"/>
</a><figcaption itemprop="caption description" style="
width: 450px;
"></figcaption>
</figure>
</div><p>Distributionen wie <em>Raspbian</em> lassen die passgenaue Zusammenstellung eines
Betriebssystems kinderleicht aussehen.
Image herunterladen, Pakete installieren, noch ein paar Änderungen - fertig.
Alles wie auf dem Laptop oder Server.
Warum ein Betriebssystem aus einer klassischen Distribution im Produkt-Kontext
zur Katastrophe führen kann, beleuchtet der Vortrag <strong>"Raspbian vs.
Build-Systeme: Das richtige Werkzeug für solide Produkte"</strong>.</p>
<p>Produktentwicklerinnen und Produktentwickler müssen sicherstellen, dass ihr
Gesamtsystem besondere Anforderungen erfüllt.
Dabei spielt nicht nur die korrekte Funktion, sondern auch langfristige Pflege
eine wichtige Rolle.
Große Stückzahlen und limitierte Testkapazitäten erfordern Image-basierte,
reproduzierbare Betriebssysteme, die nur per Build-System zu erreichen sind.</p>
<p>Doch wie finden Sie sich im breiten Feld der verschiedensten Build-Systeme zurecht?
Welches passt am besten zu Ihrem Produkt?
Der Vortrag stellt distributionsbasierte und source-basierte Build-Systeme
gegenüber.</p>
<p>Darüber hinaus beleuchtet der Vortrag noch weitere Herausforderungen, die Sie
im Produktlebenszyklus erwarten und wie Build-Systeme Ihnen auch hier das Leben
leichter machen.</p>
<p>Wir erarbeiten gerne mit Ihnen das passende Betriebssystem für Ihr Produkt.
Sprechen Sie uns an!</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/qU99-S_1ll4"></iframe>
</div>
<p><a href="https://pengutronix.de/20210325_raspbian-vs-build-systeme.pdf">Slides</a></p>
</div>
<p>Distributionen wie <em>Raspbian</em> lassen die passgenaue Zusammenstellung eines
Betriebssystems kinderleicht aussehen.
Image herunterladen, Pakete installieren, noch ein paar Änderungen - fertig.
Alles wie auf dem Laptop oder Server.
Warum ein Betriebssystem aus einer klassischen Distribution im Produkt-Kontext
zur Katastrophe führen kann, beleuchtet der Vortrag <strong>"Raspbian vs.
Build-Systeme: Das richtige Werkzeug für solide Produkte"</strong>.</p>2021-04-19T12:16:46+01:00tag:www.pengutronix.de,2021-03-01:/2021-03-01-mach-es-einfach-anders.htmlCLT-2021: Mach es einfach anders!2021-03-01T09:06:36+01:00Marie Mann<div class="section" id="clt-2021-mach-es-einfach-anders">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1847x656" href="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/logo_de.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/logo_de.thumb.ff7cbbc1f1c111f9c95451b4180ba01b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>"Mach es einfach anders!" - unter diesem Motto finden die <a href="https://chemnitzer.linux-tage.de/2021/de/">CLT</a> dieses Jahr im virtuellen Raum
statt.
Wie auch in den letzten Jahren ist Pengutronix als Sponsor dabei.
Anders ist, dass wir dieses Jahr unser eigenes kleines Programm mit spannenden
Kurzvorträgen und täglich zwei Quiz-Runden mit tollen Hauptgewinnen mitbringen.</p>
<br/><table border="1" class="docutils">
<colgroup>
<col width="7%"/>
<col width="44%"/>
<col width="49%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">Wann</th>
<th class="head">Samstag, 13. März</th>
<th class="head">Sonntag, 14. März</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>11:30</td>
<td>Let's talk about Embedded Rust (Leonard)</td>
<td>Let's talk about Emacs (and editors) (Rouven)</td>
</tr>
<tr><td>12:30</td>
<td>Let's talk about „Embedded“ (Holger)</td>
<td>Let's talk about systemd (Michael)</td>
</tr>
<tr><td>14:30</td>
<td>Pengutronix-Quiz</td>
<td>Pengutronix-Quiz</td>
</tr>
<tr><td>15:30</td>
<td>Let's talk about (my) .vimrc (Roland)</td>
<td>Let's talk about DNS & SSH (Björn)</td>
</tr>
<tr><td>16:30</td>
<td>Let's talk about git workflows (Rouven)</td>
<td>Let's talk about Security (Marc)</td>
</tr>
<tr><td>17:30</td>
<td>Pengutronix-Quiz</td>
<td>Pengutronix-Quiz</td>
</tr>
</tbody>
</table>
<div class="section" id="let-s-talk-about">
<h3>Let's talk about ...</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3735x3240" href="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/lets-talk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/lets-talk.thumb.b097c32efda682d1adc2e6a446459c12.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In unserer täglichen Arbeit bauen wir nicht nur maßgeschneiderte Betriebssysteme
für die Embedded-Boards unserer Kunden, optimieren die Bootzeit oder die
Grafikausgaben oder schreiben Linux-Kernel-Treiber, sondern kommen auch
mit allerhand allgemeinen Linux-Themen und Workflows in Berührung.</p>
<p>Wir wollen uns mit euch über Workflows, Tipps & Tricks austauschen.
Damit der Einstieg etwas leichter fällt, werden die Kollegen in kurzen
Vorträgen einen ersten Einblick in das Thema präsentieren.</p>
<div class="section" id="embedded-rust">
<h4>... Embedded Rust</h4>
<p>Die Programmiersprache Rust ist nicht nur der neue heiße Scheiß,
sondern eignet sich besonders gut für das Programmieren im Embedded-Kontext,</p>
<div class="ptx-sidebar">
<div class="title">
Trefft uns auf den CLT
<div class="corner"></div>
</div>
<div class="body">
<p>Für einen Schnack sind wir immer zu haben!
Schaut dafür einfach in unserem <a href="https://bbb.live.linux-tage.de/gl/clt-d8g-nfr-160">BigBlueButton Raum</a> vorbei.</p>
</div>
</div>
<p>da sie sich sowohl unter Linux, als auch auf Mikrocontrollern
ohne Betriebssystem einsetzen lässt.
Für den Einstieg bringt Leonard ein kleines Mikrocontroller-Projekt mit,
um mit euch über Herangehensweisen und Anwendungszwecke zu sprechen.</p>
</div>
<div class="section" id="embedded">
<h4>... Embedded</h4>
<p>In der Hobby- und Maker-Szene ist der Raspberry Pi eine beliebte Plattform
um eigenständige Anwendungen schnell umzusetzen.
Ein RaspberryPi OS (früher Raspbian) ist schnell aufgesetzt und schon
läuft der eigene Medienserver. Dann folgen die Ideen, wie das Projekt
erweitert werden könnte und damit wächst die Komplexität...
Auf einmal bietet es sich an, zu schauen, wie Profis an solche Projekte herangehen:
Holger stellt euch den Einsatz von Buildsystemen vor. Dabei wird er mit
euch über Workflows, Anwendungsfälle, sowie Vor- und Nachteile sprechen.</p>
</div>
<div class="section" id="my-vimrc">
<h4>... (my) .vimrc</h4>
<p>Vim ist ein mächtiger Editor, aber die Stärke spielt er erst durch die
richtige Konfiguration aus.
In diesem Slot stellt euch Roland seine .vimrc vor und verrät ein paar Tipps
& Tricks.</p>
</div>
<div class="section" id="git-workflows">
<h4>... git-Workflows</h4>
<p>Viele Wege führen nach Rom und ebenso viele Wege gibt es in git, um
ein Ziel zu erreichen. In diesem Slot bietet Rouven euch die
Möglichkeit eure Wege zu zeigen und ganz neue kennen zu lernen.</p>
</div>
<div class="section" id="emacs-and-editors">
<h4>... Emacs (and editors)</h4>
<p>Emacs ist das Multifunktionstool unter den Editoren, selbstdokumentierend und zu
großen Teilen in verständlichem Lisp geschrieben. Emacs-Distributionen sind sogar
in der Lage Emacs die Vim-Semantik des Editierens beizubringen, sodass auch für
begeisterte Vim-Jünger ein Blick lohnt. Auch andere Editoren sind mittlerweile
mit genügend Features für die Softwareentwicklung ausgerüstet, sodass unter
anderem auch Kate oder Gedit immer öfter für die kleinen (und großen!)
Programmieraufgaben eingesetzt werden können. In diesem Block soll es um alle
Editoren im Freien-Software-Universum gehen, Rouven fängt mit der kurzen
Vorstellung seines Editors (Doom Emacs) an und danach betrachten wir eure
Workflows, Plugins und Einstellungen.</p>
</div>
<div class="section" id="systemd">
<h4>... systemd</h4>
<p>In Linux Desktop Distributionen ist systemd mittlerweile allgegenwärtig. Im
Embedded Bereich wir systemd aber oft noch mit Skepsis betrachtet. Michael
wird einen kleinen Überblick geben wie man auf Embedded Systemen die
Stärken von systemd nutzen kann. Im Anschluss bleibt genug Zeit um über die
Vor- und Nachteile von systemd zu plaudern und hoffentlich dabei ein paar
Vorurteile aus dem Weg zu räumen.</p>
</div>
<div class="section" id="dns-ssh">
<h4>... DNS & SSH</h4>
<p>Für unsere Entwicklung und die aktuell nötige virtuelle Anwesenheit sind
wir sehr stark von remote Terminals abhängig. Um auf solche zuzugreifen,
benutzen wir OpenSSH. OpenSSH hat einige zu unrecht unbekannte Features.
Björn beleuchtet die Features rund um das Canonicalization und wie man mit
Unterstützung von CNAME-DNS-Einträgen die Konfiguration von ssh
komfortabel, flexibel und pflegeleicht gestaltet.</p>
</div>
<div class="section" id="security">
<h4>... Security</h4>
<p>Darüber, warum "Security" wichtig ist, müssen wir nicht reden! - Das sollte
selbstverständlich sein, aber warum ist es so wichtig "Security" von
Anfang an mit zu denken und wie macht man das am besten?</p>
</div>
</div>
<div class="section" id="pengutronix-quiz">
<h3>Pengutronix Quiz</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3824x2871" href="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/gewinne.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-03-01_mach-es-einfach-anders/gewinne.thumb.dcf130a4d36bc4b9b7f71ec28e310376.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Inspiriert vom traditionellen Closing Game der Embedded Linux Conference
(ELC-E) haben wir ein Quiz aufgesetzt, mit Fragen rund um Linux, dem Universum
und dem ganzen Rest.
Zwei mal am Tag (14:30 und 17:30) habt ihr die Chance, gegeneinander
Multiple-Choice-Fragen zu beantworten und Preise abzustauben.</p>
<p>Als Haupt-Gewinn gibt es in jeder Runde einen
<a href="https://shop.linux-automation.com/usb_sd_mux-D02-R01-V02-C00">USB-SD-Mux</a>
oder ein <a href="https://www.raspberrypi.org/products/raspberry-pi-4-model-b/">Raspberry Pi</a>.
Weitere Gewinne sind hochwertige Tux-Kaffeetassen, "Offline Notebooks"
(Notizblöcke), oder unsere schwarzen Bleistifte mit Kult-Status.
Keine Angst, ihr braucht nicht mit dem Rad her kommen:
Die Gewinne schicken wir euch selbstverständlich zu.</p>
</div>
</div>
<p>"Mach es einfach anders!" - unter diesem Motto finden die <a href="https://chemnitzer.linux-tage.de/2021/de/">CLT</a> dieses Jahr im virtuellen Raum
statt.
Wie auch in den letzten Jahren ist Pengutronix als Sponsor dabei.
Anders ist, dass wir dieses Jahr unser eigenes kleines Programm mit spannenden
Kurzvorträgen und täglich zwei Quiz-Runden mit tollen Hauptgewinnen mitbringen.</p>2021-03-01T09:06:36+01:00tag:www.pengutronix.de,2021-02-26:/2021-02-19-showcase-field-updating.htmlShowcase: Fail-Safe (OTA) Field Updating2021-02-26T15:00:00+01:00Enrico Jörns<div class="section" id="showcase-fail-safe-ota-field-updating">
<p>Being able to robustly and securely update embedded systems and IoT devices in
the field is a key requirement of every product today.
The update framework RAUC is the basis for a modern and future-proof solution.
In this showcase we present the basic principles of a fail-safe update system and
how Pengutronix can support you with implement this for your platform.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1825x987" href="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/ota-updates.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/ota-updates.thumb.553f50fe0538f943031bd657b8e2bc9f.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>Update artifacts are created, cryptographically signed, and
brought into the field over-the-air (OTA)</p>
</figcaption>
</figure>
</div><p>The basic requirements for an update in the field are clearly defined:
The update should be installed in a fail-safe manner (<strong>reliability</strong>), but the
device must remain protected from unauthorized access (<strong>security</strong>).
Depending on the field of application, the update comes from a local medium
(e.g. a USB stick) or should be rolled out fully automatically via the network
(<strong>deployment</strong>).</p>
<p>In addition to these obvious requirements, there is a whole range of other
considerations and decisions that should be made in the project phase as early
as possible and that have a major impact on the success or failure of the
project.
More on that later…</p>
<div class="section" id="atomic-updates-and-fallback">
<h3>Atomic Updates (and Fallback)</h3>
<p>The magic word for fail-safe updating of systems is <em>atomicity</em>. This means: It
must be ensured that an update has been successfully installed in full before
it is enabled for use.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2392x476" href="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/AtomicUpdates.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/AtomicUpdates.thumb.dd2af1e51b0109d23a57b73640d50b11.png"/>
</a><figcaption itemprop="caption description" style="
"><p>Switching between redundant (A + B) partitions allows atomic updates</p>
</figcaption>
</figure>
</div><p>To ensure this, redundant boot partitions are used (also called dual copy or A
+ B approach).
Two completely equivalent system partitions are used to perform updates on each
other.
The active partition gets written from to the inactive one, which is only switched to
be the new active partition after the write process has been successfully
completed.
Switching between the partitions takes place in the boot loader.
This also offers an advantage in terms of availability:
With this mechanism, the update can easily be carried out in the background of
the running application without interrupting it.</p>
<p>The use of redundant partitions then makes it possible optionally to fall back
on the inactive system even in the event of a fault in the active system, thus
significantly improving the availability of the platform.</p>
</div>
<div class="section" id="cryptographically-secured-updates">
<h3>Cryptographically Secured Updates</h3>
<p>Since the update system enables the system software to be exchanged, this is a
particularly critical area.
In order to deny unauthorized persons access to the system, the update must be
cryptographically signed when it is created and verified by the target system
before installation.
Asymmetric methods are ideal for this, as only the key for signing has to be
kept secret, while the key for verification can be stored on the device without
any further effort.</p>
<p>The use of common standards such as <a class="reference external" href="https://de.wikipedia.org/wiki/X.509">X.509</a> also allows more complex hierarchies
with development keys, per device keys, multiple signatures, etc.</p>
</div>
<div class="section" id="further-requirements">
<h3>Further Requirements</h3>
<p>The devil is often in the details, and so is the development of an update
strategy. The technical specifications such as processor type and memory
technology must be taken into account as well as the requirements of the
application and the ecosystem in which the device is integrated.</p>
<p>Typical further questions that then arise</p>
<ul class="simple">
<li>How do you separate data and logs from the operating system?</li>
<li>How do you migrate application data after an update?</li>
<li>What does a sensible partitioning of the memory look like?</li>
<li>Is it possible to safely update the bootloader?</li>
<li>How should the device behave in the event of an error?</li>
<li>How does the device reliably recognize that there is an error?</li>
</ul>
</div>
<div class="section" id="how-can-we-support-you">
<h3>How Can we Support You?</h3>
<p>Together with you, our integration team sheds light on the obvious and less
obvious questions and requirements for the update system and first develops a
basic update concept that can be refined in the further course of the project.</p>
<p>With <a class="reference external" href="https://rauc.io/">RAUC</a> there is already an update framework maintained
by Pengutronix and fully licensed as open source as a starting point.
This allows you to focus on the essentials without having to reinvent the
wheel.
Nevertheless, the coordination of the overall system to the specific
requirements of the customer and the operational environment is anything but
trivial and includes the configuration of various components that have to be
closely interlinked.</p>
<p>On the basis of your Board Support Package (BSP), our integration team
implements a redundant boot setup, configures all necessary system components
and prepares everything so that update artifacts can be generated and
installed.</p>
<p>If you need additional functionality that is not or not fully covered by the
existing components, we will be happy to expand this for you.
If possible, so that new features can flow back directly into the main
development branch of the projects and do not accumulate as a technical debt
in the project.</p>
<p>As part of the clarification of the requirement and the specific individual
setup of the basic update and boot loader configuration, Pengutronix supports
you with, among other things:</p>
<ul class="simple">
<li>Adaptation of the boot loader for redundant boot partitions (barebox, U-Boot, Grub, UEFI)</li>
<li>Initial configuration of RAUC in the BSP (Yocto, PTXdist, Buildroot)</li>
<li>Coordination of the watchdog behavior</li>
<li>Clarification of security / verification behavior</li>
<li>Clarification of related issues such as configuration management, data migration, etc.</li>
<li>Integration in customer application / connection to deployment infrastructure</li>
<li>Support in the further course</li>
</ul>
<p>The biggest mistakes in the design of a redundant booting system are often made
in the early phase of the project.
Pengutronix will be happy to evaluate for you on the basis of many years of
experience 'right from the start' whether the selected hardware and in
particular the storage technology used, the power management or the processor
pose risks.</p>
</div>
<div class="section" id="and-why-rauc">
<h3>And why RAUC?</h3>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> the 1.5.1 release of RAUC</p>
</div>
</div>
<p>RAUC is a modern open source update framework that offers a lean and
easy-to-maintain code base through efficient use of established libraries such
as glib, OpenSSL and curl. RAUC is divided into a service that runs on the
target platform and verifies the update artifacts there and installs them
atomically, and a host tool with which the update artifacts (bundles) are
generated.</p>
<p>With the reduction to the essentials and the provision of both a command line
tool and a D-Bus API, RAUC can be easily integrated into existing customer
applications.</p>
<p>One of the essential philosophies of RAUC is the description of the redundant
boot behavior via configuration file directly on the device.
This not only allows the system to be introspected, but also allows generic
update artifacts to be created.</p>
<p>Additional features such as <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#pkcs-11-support">PKCS#11 support</a> for
signing bundles, options for re-signing bundles or accommodating intermediate
certificates in bundles make it possible to meet the security requirements in a
professional environment.</p>
<p>For the boot loader updates, which are often underestimated in the field, but
often urgently required later, RAUC offers the option of performing them
completely <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader">atomically</a>
for many applications.</p>
</div>
<div class="section" id="how-can-ota-updates-be-implemented">
<h3>How Can OTA Updates be Implemented?</h3>
<p>If the company already has a deployment infrastructure or a hosted solution is
to be used, RAUC can be triggered with the help of a simple service that
accepts requests from the infrastructure and calls RAUC via D-Bus or the
command line.</p>
<p>The open source project <a class="reference external" href="https://www.eclipse.org/hawkbit/">hawkBit</a> is ideal
for OTA updates in your own (self-hosted) infrastructure.
This offers a highly configurable solution for device management, deployment
scheduling and feedback.</p>
<p>The connection to RAUC is quite easy to implement thanks to the existing
clients in the RAUC project.
With the <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a>, a solid client component
written in C is available that interacts with the Device (DDI) API from hawkBit
via REST and with RAUC via D-Bus.</p>
<div class="row"><div class="col-md-7">
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/SLX0Fd_y6Cc"></iframe>
</div>
<div class="clearfix"></div></div><div class="col-md-5">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="590x719" href="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/rauc-hawkbit-updater-scheme.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-19_showcase-field-updating/rauc-hawkbit-updater-scheme.thumb.68d72037b66c228cbb65c1a79b09df6c.png"/>
</a><figcaption itemprop="caption description" style="
width: 123px;
"><p>RAUC interfacing with hakwbit using the rauc-hawkbit-updater</p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div></div><strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i> Back to technical showcases
</a>
</strong></div>
</div>
<p>Being able to robustly and securely update embedded systems and IoT devices in
the field is a key requirement of every product today.
The update framework RAUC is the basis for a modern and future-proof solution.
In this showcase we present the basic principles of a fail-safe update system and
how Pengutronix can support you with implement this for your platform.</p>2021-02-26T15:00:00+01:00tag:www.pengutronix.de,2021-02-26:/2021-02-26-showcase-i-mx8mp.htmlShowcase: Graphics on i.MX8MP2021-02-26T13:56:37+01:00Lucas Stach<div class="section" id="showcase-graphics-on-i-mx8mp">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1012x608" href="https://www.pengutronix.de/media/blog/2021/2021-02-26_showcase-i-mx8mp/mx8mp-small.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-26_showcase-i-mx8mp/mx8mp-small.thumb.14831a20e4bba068ede450e2f39b8852.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Enabling the graphics output pipeline on the <em>i.MX8M Plus</em> (i.MX8MP for short),
is the most recent example on how open-source and upstream driver support for
GPU and display engines can reduce effort and risk in a new project.</p>
<div class="section" id="graphics-driver-background">
<h3>Graphics driver background</h3>
<p>Graphics support in embedded devices has changed quite a bit over the last few
years. Let's dive a bit into the history of graphics hardware and the
accompanying software support to set the scene.</p>
<p>Historically, embedded devices would only have very minimal graphics support,
if at all. They could drive simple LC displays and all the work of actually
producing the picture to show on the display had to be handled by the CPU,
with no hardware acceleration whatsoever. On one hand, this was convenient,
as the CPU is very flexible in what it can do and driver support for the simple
hardware units driving the displays didn't require much effort: all they needed
to do was to get a piece of bitmap memory filled by the CPU out on the display
data bus with the right timing. On the other hand, the limited processing
power available on the CPU set very strict bounds on what was possible to do
on the graphics side without impacting the primary use of the device, as most
devices are built to fulfill other jobs besides displaying pretty graphics.</p>
<p>Around 15 years ago Moore's law still progressed at full speed and it was
finally possible to fit real <em>Graphics Processing Units</em> (GPUs) into the
space, power and cost envelope required in the embedded space. With GPUs
taking over most of the actual work of drawing the content to show on the
display, the CPU was free again for other jobs and while at the same time
providing much richer user interfaces.</p>
<p>This however came with a new cost: the complexity of the software needed to
drive those GPUs is a huge step up from the simple drawing implementation on
the CPU. Also, the GPU marketing segment is very competitive, with multiple companies
trying to sell GPUs for use in embedded systems. In this environment, most of
those companies favored a closed-source approach for the driver software, in
order to not reveal any secrets that may set them apart from the competition.</p>
</div>
<div class="section" id="issues-with-closed-source-drivers-in-embedded-devices">
<h3>Issues with closed-source drivers in embedded devices</h3>
<p>Embedded systems have some unique requirements in that they are usually
designed to do a very specific task at the lowest possible price point. So
there is little room to compensate inefficiencies in the processing pipelines
with raw compute power. Thus the software has to be optimized to provide the most
efficient processing pipelines possible. Also, most of them are designed to be
used for a very long time. With more and more of those devices connected to the
network, this means it must be easy to update the software running on them
in order to be able to fix functional or security issues.</p>
<p>Both of those requirements are very hard to meet when depending on closed source
components that one has no direct control over. Even if the GPU vendor is able
and willing to provide support, changes to the driver software can take a very
long time, leading to failures to meet the window of opportunity where a
device can be brought into the market. Having to take into account the
requirements of the closed-source bits in the system may also prevent timely
updates. This may apply to new system components like kernel and base libraries
in the system when those components leave their support period.</p>
<p>Closed-source components might also bring in assumptions and dependencies
that severely limit the ability to alter the software stack later on in the
lifetime of the device.</p>
</div>
<div class="section" id="alternative-solutions">
<h3>Alternative solutions</h3>
<p>The <a href="https://www.pengutronix.de/en/services/open-source-multimedia.html">Pengutronix graphics team</a>
has an extensive track record in building open-source drivers for these hardware
units.</p>
<p>On the GPU side, this journey started when some of our customers were not
willing to accept the risk of having a third-party closed-source component at
the core of their product. They worked with Pengutronix to bring to life a open-source
alternative. The NXP i.MX line of SoCs is very popular in the industrial and medical
embedded ecosystems, as it ticks a lot of the required feature boxes.
Starting with the i.MX6 those SoCs include GPUs from VeriSilicon (formerly
Vivante). Some volunteers in the free software community had already started
a reverse-engineering effort targeting these GPUs, called
<a href="https://www.github.com/etnaviv">Etnaviv</a>. Pengutronix jumped on-board,
helped to get it into shape and provide a commercial quality open
alternative to the closed-source vendor driver.</p>
<!-- FIXME: Picture of i.MX8M video demo. -->
<p>Today the Etnaviv driver stack is in use in a breadth of embedded devices, from
medical appliances to in-flight entertainment systems to automotive and
industrial control systems. While Pengutronix, as a strong partner with a
really deep technical expertise in this area, is always standing by to help you
along if the need arises, all the components are available as open-source and
can be used, extended and improved by anyone, eliminating the risk of vendor
lock-in for this critical component.</p>
<p>The Etnaviv driver stack integrates in the upstream frameworks like DRM in the
Linux kernel and Mesa on the userspace side, so it's quite close in features
and behavior to the general Linux desktop graphics stack, making embedded
projects less special.</p>
</div>
<div class="section" id="i-mx8mp-gpu-enablement-with-upstream-drivers">
<h3>i.MX8MP GPU enablement with upstream drivers</h3>
<p>Recently, the Pengutronix graphics team was tasked with enabling the GPU on the
<a href="https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS">NXP i.MX8M Plus</a>,
which is currently in pre-production. This SoC is very interesting to many
industrial customers, as the i.MX8M line is a successor to the really popular
i.MX6 series. A lot of the software support, written and refined over the last
10 years, can be reused, significantly reducing the effort to get the basic
system functionality working. The i.MX8MP also packs some interesting features
like <em>CAN FD</em> and <em>TSN Ethernet</em>.</p>
<p>The GPU is a slightly different variant of the GC7000L, found in the already
supported i.MX8MQ SoC. While some <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255">small adaptions</a>
were needed to run the open-source driver stack on this specific GPU, it took
the Pengutronix graphics team less than a week total effort to get the GPU
up and running. Years of experience working on those parts of the software
stack really helped in getting this working quickly.</p>
<p>If you are planning to start a new project involving graphics input/output
support we are happy to talk to you!</p>
<!-- FIXME: picture/youtube video i.MX8MP -->
<strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Back to technical showcases
</a>
</strong></div>
</div><p>Enabling the graphics output pipeline on the <em>i.MX8M Plus</em> (i.MX8MP for short),
is the most recent example on how open-source and upstream driver support for
GPU and display engines can reduce effort and risk in a new project.</p>2021-02-26T13:56:37+01:00tag:www.pengutronix.de,2021-02-24:/2021-02-23-showcase-time-sensitive-network.htmlShowcase: Preempt RT and Time Sensitive Networking2021-02-24T11:30:00+01:00Holger Assmann<div class="section" id="showcase-preempt-rt-and-time-sensitive-networking">
<div class="ptx-sidebar">
<div class="title">
J. R. R. Tolkien already knew...
<div class="corner"></div>
</div>
<div class="body">
<p>"Real Time is never late, nor is it early, it arrives precisely when it means to."</p>
</div>
</div>
<p>Nowadays, even small and cheap microcontrollers offer enough calculation power
to perform time critical tasks within an industrial environment. However, as
soon as actors and sensors are spread over an entire facility and are to be
connected over Ethernet, the actual moment when a data packet will get
processed becomes very hard to predict. At this point, Linux running a
Preempt RT Kernel altogether with a network featuring <em>Time Sensitive
Networking</em> (TSN) capabilities can help.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/pQvtk6vEdrY"></iframe>
</div>
<p>When sending data it is likely that delays not only occur inside the
processing system, but also on the transmission path. As such, critical data
from multiple sources might arrive at the recipient at once. The more
modern embedded and connected devices allow for fast calculations and data
handling, the more the question arises not only if your system performs "<em>fast
enough</em>", but whether your results also arrive "<em>in time</em>".</p>
<p>The usage of complex network stacks based on standard Ethernet may be the
motivation to swap the microcontroller with a yet more capable soulution
based on a microprocessor running a proper Linux as operating system.
Here, Real Time features are implemented by the Preempt RT mechanism of the
Linux Kernel, and time critical data transfer also gets covered by more and
more TSN features being added over the time.</p>
<div class="section" id="tsn-demonstrator">
<h3>TSN Demonstrator</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1570" href="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/tsn-demonstrator.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/tsn-demonstrator.thumb.51be37c463962bf62bd0839624c0820d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 350px;
"><p>Construction with a floating ring of paper.</p>
</figcaption>
</figure>
</div><p>Being a very heterogenous topic, TSN for itself consists of a variety of
technologies: On one hand, not all standardized processes are already
available under Linux, while on the other hand not every implementation even
requires the full set of available features.</p>
<p>In order to gather further insights into the technical challenges that occur
during the development process we at Pengutronix have designed a TSN Demonstrator.</p>
<p>The "Floating Sphere" is a popular experiment where
the basic concept of a <a href="https://en.wikipedia.org/wiki/PID_controller">PID control loop</a> is demonstrated.
In that setup a magnet is attached to a lightweight object (e.g. a paper ring).
This shape is then made levitating in the field of an electromagnet: A sensor
detects the position of the ball and reports it to a controller, which in return
regulates the current through the electromagnet accordingly to a constant
distance from the sensor - when done right, the sphere keeps floating in an
equilibrium as long as the setup is powered.</p>
<p>To simulate a system that is connected via TSN Ethernet the sensor, actor and
controller were realized on single-board computers that are based on the
<a href="https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html">STM32MP1 microprocessor</a>
running the latest Linux Kernel (5.11) and Preempt RT. The boards are connected
over Ethernet and <em>Precision Time Protocol</em> is used to synchronize the clocks
of the participants.</p>
<div class="section" id="goals">
<h4>Goals</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="662x624" href="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/overview.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/overview.thumb.45b8ea2804c8148a453585019d4863f9.png"/>
</a><figcaption itemprop="caption description" style="
width: 360px;
"><p>Schematic drawing of the test setup</p>
</figcaption>
</figure>
</div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="300x300" href="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/floating.gif" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-23_showcase-time-sensitive-network/floating.thumb.98562e16bb9491f0afe22c3b7e08ab85.gif"/>
</a><figcaption itemprop="caption description" style="
width: 360px;
"><p>Demonstrator running</p>
</figcaption>
</figure>
</div><p>The Demonstrator setup inherits various latencies when the process of regulating
the paper ring's position takes place:</p>
<ul class="simple">
<li>The information gathered by the sensor has to be processed by the first
system.</li>
<li>The packet has then to find its way through the network and to the board with
the controller software.</li>
<li>The controller must calculate the electromagnet's next state whilst sharing
the board resources with other programs and services.</li>
<li>The resulting values again are to be sent over the network to finally reach
the actor's system to get applied at the right moment.</li>
</ul>
<p>With the system as a whole now being to slow to maintain a stable floating
position the individual components have now to be coordinated in real time.</p>
<p>Subsequently, we realized our PID-loop as follows:</p>
<ul class="simple">
<li>By using PTP (IEEE 802.1AS), the internal clocks of our boards were
synchronized within in the margin of less than a microsecond.</li>
<li>Critical latencies within the software environment were tracked down and
solved if necessary.</li>
<li>The positioning sensor is being read synchronous to the PTP timer and a
respective time stamp gets applied; the daten then needs about 600 µs from
sensor to actor.</li>
<li>The PID controller runs at a frequency of 1.25 kHz / 800 µs.</li>
<li>Lastly, the actor's software has to take care that the new sVtate of the
electromagnet is applied at the right time.</li>
</ul>
<p>The result can be seen in the accompanying pictures.</p>
</div>
<div class="section" id="next-steps">
<h4>Next steps</h4>
<p>The Demonstrator setup allows for first insights into the different
technologies around TSN under Linux. During the development a range of current
SoCs was evaluated regarding their TSN capabilities: Not all features are
available at every hardware, so the SoC has to be chosen specific to the task
at hand. Additional room for improvments also exists on the software-side -
many of the used technologies are still young and quickly evolve from Kernel
to Kernel. It is therefore recommended to always use a current version of
Linux.</p>
</div>
</div>
<div class="section" id="how-can-pengutronix-help-with-tsn-projects">
<h3>How can Pengutronix help with TSN projects?</h3>
<div class="ptx-sidebar">
<div class="title">
More about TSN and PTP
<div class="corner"></div>
</div>
<div class="body">
<p>Our friends at OSADL are constantly conducting measuring tasks regarding the
performance of Real-Time and TSN systems. If you are interested, you may
check out their article
"<em>Real-time Ethernet (TSN) synchronization analysis</em>".
(<a href="https://www.osadl.org/Real-time-Ethernet-PTP-TSN-synchroniza.qa-farm-rt-ptp-tsn-star-sync.0.html">osadl.org</a>)</p>
</div>
</div>
<p>The Pengutronix Kernel-Team can advise industrial customers on the development
of TSN systems as well as directly support them with development services. An
important task is the further development and adaption of the Linux Kernel to
the individual requirements of the customer's project, for example through new
drivers for switch chips and TSN features in network hardware.</p>
<strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Back to technical showcases
</a>
</strong></div>
</div>
<p>Nowadays, even small and cheap microcontrollers offer enough calculation power
to perform time critical tasks within an industrial environment. However, as
soon as actors and sensors are spread over an entire facility and are to be
connected over Ethernet, the actual moment when a data packet will get
processed becomes very hard to predict. At this point, Linux running a
Preempt RT Kernel altogether with a network featuring <em>Time Sensitive
Networking</em> (TSN) capabilities can help.</p>2021-02-24T11:30:00+01:00tag:www.pengutronix.de,2021-02-21:/2021-02-21-showcase-remote-working.htmlShowcase: Remote Working2021-02-21T15:00:00+01:00Leonard Göhrs<div class="section" id="showcase-remote-working">
<!-- .. youtube::[Video: Inbetriebnahme eines neuen Boards im Remotelab] -->
<p>Project work with our customers includes the handling of hardware prototypes.
Since work is generally done in parallel, on many project for many customers,
there is a constant flood of hardware prototypes accumulating on the desks
of our developers.
These accumulations of loose boards can become a problem.
This is especially the case when a number of people work on a prototype.
Another common annoyance occurs when a project has not been worked on for a
period of time, as this might involve moving the hardware from one desk (or
storage location) to another and setting it up again.
Right now, in a situation where working from home is more common and relevant
than ever, this has become even more of an issue. The distances
between desks and storage locations of our developers are now measured in
kilometers, rather than meters.</p>
<p>In this article we would like to present to you our Remotelab
infrastruture. It was initially developed for <em>Continuous Testing</em>,
but has now shown to be one of our main enablers for remote working,
allowing us to stay productive with less than a handful of colleagues
on-premise.</p>
<p>Our Remotelabs consist of racks housing embedded prototype boards by our
customers.
Additional infrastructure in our Remotelabs enables our developers to
remote control these boards (see below).
Once the hardware is located in our infrastructure, it can also be tested,
automatically and continuously.
This allows us to be alerted about any breaking changes affecting our
customers.</p>
<div class="section" id="a-few-words-about-continuous-testing">
<h3>A few words about continuous testing</h3>
<p>In fact, the ability to test permanently and automatically is one of the main
drivers for our ongoing development of labgrid (the software framework to
access the hardware) and the professionalization of our Remotelab infrastructure.</p>
<p>We would like to show you the advantages of continuous testing in our
<a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-continuous-testing.html">Showcase: Continuous Testing</a>.</p>
</div>
<div class="section" id="how-can-we-supoort-you">
<h3>How can we supoort you?</h3>
<p>As a service provider in the software development environment, we are not in the
position of selling you complete and ready-made Remotelab infrastructure, but we
would be happy to assist you in such projects:
Whether it is about integrating support for your test hardware in labgrid, working
out test strategies, developing tests, or integrating labgrid into your
processes – do not hesitate contacting us.</p>
<p>Even without investing in your own Remotelab, you can still benefit from our
Remotelab infrastructure, as our customers hardware is only a few keystrokes away
for our development team at any point in the product cycle.</p>
<p>In the last years we have constructed several Remotelabs and want to
share our design process with you.</p>
</div>
<div class="section" id="what-components-does-a-remotelab-consist-of">
<h3>What components does a Remotelab consist of?</h3>
<div class="section" id="rack">
<h4>19"-Rack</h4>
<p>The supporting component of our Remotelab: We use a 19" TE network cabinet from
Rittal. The transport rollers are a particularly useful feature. To protect the
hardware, each shelf is covered with an ESD shelf lining. In addition, cable
guide rails enable an (at least initially) tidy Remotelab. Two suitable sockets
for rack mounting provide the necessary power for the embedded boards.</p>
</div>
<div class="section" id="network-switch">
<h4>Network switch</h4>
<p>Our favorite in this category is the CBS350-24P-4G from Cicso, as it is
PoE capable, silent and managed. By using PoE we want to minimize the need
for individual power supplies in future in-house hardware developments.
The use of managed switches allows us to respond to any special
requirements the customer hardware may have for the network setup.</p>
<p>Quiet operation of the switches is important to us, as some of the
Remotelabs are located in the developer offices.</p>
</div>
<div class="section" id="small-server">
<h4>Small Server</h4>
<p>A small server is needed to manage each of the devices in the Remotelab.
The hardware requirements for this labgrid node are quite low,
aspects we pay attention to are:</p>
<ul class="simple">
<li><strong>Quiet operation</strong> -- Our Remotelab servers use PC Engines APU.2E4, allowing
fanless operation.</li>
<li><strong>Stable USB</strong> -- Large USB installations, such as our Remotelabs are, do,
in our experience, carry a lot of potential for frustration. The APU.2E4's internal
USB controllers and the EXSYS EX-49010-2 controllers installed in addition have proven
to be comparatively reliable in operation.</li>
<li><strong>CAN bus integration</strong> -- For communication with our own custom hardware
and for testing the embedded devices, we use CAN-FD capable miniPCIe cards
from Peak System, providing four independent CAN buses.</li>
</ul>
</div>
<div class="section" id="switchable-socket">
<h4>Switchable socket</h4>
<p><em>Have you tried turning it off and on again?</em> --
The easiest way to restart the hardware is to toggle the supply voltage, for
example via network-connected power strips, which can be controlled using
labgrid. As a low-cost alternative for smaller setups, we are also gaining
initial experience with individual sockets controllable via WiFi.</p>
<p>For use in the Remotelab, where many devices are to be controlled, we use GUDE 8080
socket strips, for individual devices we are experimenting with individual sockets from
the manufacturer SONOFF, which are flashed with the free Tasmota firmware.</p>
</div>
<div class="section" id="usb-hubs">
<h4>USB-Hubs</h4>
<p>USB is almost inevitable in embedded development, we use it to communicate with
the hardware and to upload the software. When looking for reliable USB hubs, it
is important to try products from different manufacturers. We have had good
experiences with the 10-port UA0096 hubs from LogiLink.</p>
<p>An interesting use case that is unfortunately not covered by these hubs is
switching the supply voltage of individual ports on and off using
<a class="reference external" href="https://github.com/mvp/uhubctl">uhubctl</a>.</p>
</div>
<div class="section" id="wifi-router">
<h4>WiFi router</h4>
<p>In order to be able to test Bluetooth and WiFi functionalities of the embedded
hardware, each remote lab has its own WiFi router, which has been flashed with
the free OpenWRT firmware. This router is not connected to the Internet or any
other network and is only used to test the connection setup in automatic tests.</p>
</div>
<div class="section" id="serial-console">
<h4>Serial console</h4>
<p>For the connection of the serial consoles of the embedded devices we use simple
USB-serial converters, on which preferably a CP210x chip from Silicon Labs is
used. This chip allows us to store a unique ID in each USB-serial
converter easily. We put a note containing this ID on any USB-serial converter,
helping us managing a few dozen converters per lab.</p>
</div>
<div class="section" id="remotely-setable-jumper-pins">
<h4>Remotely setable jumper pins</h4>
<p>In order to be able to set and release reset or boot option jumpers as flexibly
as possible, potential-free switches are helpful; here we rely on our own
developments connected via OneWire or CAN. Alternatively, USB-controlled relays
or professional Modbus devices are also available and usable in labgrid.</p>
</div>
</div>
<div class="section" id="access-from-remote-our-labgrid-integration">
<h3>Access from remote: Our labgrid Integration</h3>
<p>To be able to take full advantage of the Remotelab, the hardware alone is not enough.
For the control of the embedded boards from the developer PC and as a basis for
tests and development on real hardware, Pengutronix uses the open source tool
labgrid as an abstraction layer.</p>
<p>Labgrid provides for automated tests as well as for interactive work an
intuitive and at the same time versatile interface for working with Embdded
Linux devices.</p>
<div class="ptx-sidebar">
<div class="title">
More information about labgrid
<div class="corner"></div>
</div>
<div class="body">
<p>Our colleague Chris Fiege gave the talk <em>"About the joy and tears of testing
embedded devices"</em> at FOSDEM 2021 on the state of three years of experience
with labgrid testing.
(<a href="https://youtu.be/Uer9TpemmmE">Youtube</a>,
<a href="https://fosdem.org/2021/schedule/event/testing_embedded_devices/attachments/slides/4610/export/events/attachments/testing_embedded_devices/slides/4610/joy_and_tears_of_testing_embedded_devices.pdf">Slides</a>)</p>
</div>
</div>
<p>There are several ways to access embedded boards via labgrid, e.g.:</p>
<ul class="simple">
<li><strong>Serial console</strong> -- Almost always available, even early in the boot
process.</li>
<li><strong>Access via network and ssh</strong> -- More convenient especially later in the
development process.</li>
<li><strong>Camera stream of the display</strong> -- Relevant during driver development and
development of graphical applications.</li>
</ul>
<div class="section" id="how-does-the-software-get-onto-the-embedded-board">
<h4>How does the software get onto the embedded board?</h4>
<p>This depends on the corresponding hardware and what is to be tested. For
example, the bootloader can load the data via the network, a programming
adapter can be connected or the software gets loaded via USB. If possible, however,
we use the USB-SD-Mux, that allows switching a micro SD card between the
Remotelab server and the prototype hardware.</p>
<strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Back to technical showcases
</a>
</strong></div>
</div>
</div><p>Project work with our customers includes the handling of hardware prototypes.
Since work is generally done in parallel, on many project for many customers,
there is a constant flood of hardware prototypes accumulating on the desks
of our developers.
These accumulations of loose boards can become a problem.
This is especially the case when a number of people work on a prototype.
Another common annoyance occurs when a project has not been worked on for a
period of time, as this might involve moving the hardware from one desk (or
storage location) to another and setting it up again.
Right now, in a situation where working from home is more common and relevant
than ever, this has become even more of an issue. The distances
between desks and storage locations of our developers are now measured in
kilometers, rather than meters.</p>2021-02-21T15:00:00+01:00tag:www.pengutronix.de,2021-02-21:/2021-02-21-showcase-off-the-shelf-system.htmlShowcase: Embedded off-the-shelf2021-02-21T15:00:00+01:00Ahmad FatoumMarie Mann<div class="section" id="showcase-embedded-off-the-shelf">
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/8PP5L-qZaU4"></iframe>
</div>
<p>A firmware upgrade is due. A newly implemented feature needs to be rolled
out, a security issue patched or new hardware support added.
The software, while capable, is complex.
Pengutronix' strategy to handle this complexity is working on a version-
controlled <em>Board Support Package</em> (BSP) with continuous updates and tests
on the latest mainline Linux kernel.</p>
<p>But let's have a look on the complexity and customer needs first.</p>
<div class="section" id="once-upon-a-time">
<h3>Once Upon a Time</h3>
<p>Maybe you have heard of this following scenario, maybe you know it
all too well...</p>
<p>The schedule is tight and shortcuts are taken. On update, some components
collide with each other, some are fixed and some are left not upgraded.
Best case, some security issues are identified and fixes backported.
Another component was forked long ago to support a then new hardware feature,
but now years later these changes conflict with the upstream project's current
state and require much effort to reconcile. The bulk was provided by the vendor's
enablement Board Support Package, but now vendor interest is in future products
and attracting new customers. Personnel changes at the vendor and at one's own
company mean that knowledge of some of the arcane ways is lost and debugging
takes more and more time.</p>
<p>With the main stakeholder nearly absent, all past decisions burden those still
maintaining derivative software in the field. While their number still motivates
the hardware vendor to schedule production runs, the maintenance burden is still
carried by each on their own as problems are individually identified and patched.</p>
<p>As if this isn't enough, given a long enough product lifetime, sourcing hardware
component replacements becomes increasingly harder over time, which only compounds
the software maintenance overhead.</p>
<p>While the trend towards ever-increasing software complexity and demand for both
connectivity and security, makes this issue more acute, it's far from being a new
realization. The effect of technical debt is well known, but the consequences
of the balance struck between quick prototyping and doing things "right" are
usually felt only much later.</p>
</div>
<div class="section" id="how-can-we-support-you">
<h3>How can we support you?</h3>
<p>As an Embedded Linux Consultancy, Pengutronix has gained a lot of experience
helping customers restructure technical debt over the years.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="558x378" href="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-embedded-off-the-shelf/board.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-embedded-off-the-shelf/board.thumb.54c2eabd3b524c1b555b8c261e3dc86a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>We know, that a long-term maintainable product starts at the very
first ideas and decisions.
We also know that the development of hardware and software needs to get hand in
hand.
Therefore, we can to help you as early as possible on a project, which means
reviewing schematics and consulting on component decisions.</p>
<p>While the hardware department develops a prototype, the software architecture
needs to be designed as well.
We will help you build a Board Support Package that is exactly
tailored to your hardware and fits your needs.
We will add missing drivers and software components in test driven development
and ensure that your BSP is reproducible.</p>
<p>Once your product is released, we will help you to keep it maintained through
<a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-continuous-testing.html">continuous testing</a>
and secure updates.</p>
</div>
<div class="section" id="case-study-the-linux-automation-mc-1">
<h3>Case Study: The Linux Automation MC-1</h3>
<p>Our technical demonstrator is designed to fit a wide range of use cases:
It might be a control panel for monitoring your domestic infrastructure
(like your solar panels or door bells). It might be an information or
entertaining system within your vehicle or anything else you like to imagine.</p>
<p>Thus display support was a requirement, as well as a network link, since
all IoT-devices need a network connection ;-)
And if we have a network connection, we can use Power over Ethernet to
power the device.</p>
<p>One last requirement: The board shall be small enough to fit into the
backside of the display.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1441x1920" href="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-embedded-off-the-shelf/demo_stm32mp1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-embedded-off-the-shelf/demo_stm32mp1.thumb.b1c2f0a1aac1f649ce062f9690ed594c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Design for Mainline: STM32MP1 Demo with OSD32MP1 in the center of the
custom PCB below the display.</p>
</figcaption>
</figure>
</div><p>In cooperation with our spin-off <a href="https://linux-automation.com">Linux Automation GmbH</a> and our partners <a href="https://octavosystems.com/">Octavo Systems</a> and <a href="https://www.bopla.de/">Bopla</a> we
present a proof of concept for the <em>Design for Mainline</em> strategy.</p>
<p>The example board shown contains only off-the-shelf components that are
well-supported by mainline Linux drivers.</p>
<p>Therefore initial effort for designing the circuit for this prototype was about
two weeks and another week to bring up the entire software stack.
This was possible by a thoughtful selection of components, which we want
to present to you right know:</p>
<ul class="simple">
<li>Possible SoCs are not only evaluated by their feature set, price and
availability, but also by the openness of documentation and existing upstream
support. For this PoE powered display controller, the STM32MP1 checks all
boxes.</li>
<li>The <a class="reference external" href="https://octavosystems.com/octavo_products/osd32mp15x/">OSD32MP1x</a>
makes it easy to bridge IT to the physical world. With eMMC storage added,
one already has a full-fledged Linux Computer; on a low-layer-count PCB.</li>
<li>Upstream support for the board was contributed to the Linux Kernel, ARM
Trusted Firmware and barebox bootloader projects. No software components
need to be patched to get a Linux system running.</li>
<li>A BSP collects configuration parameters and definitive versions of all
software components used. Software releases can be reproduced years later.</li>
<li>The BSP builds on top of community efforts like Yocto or PTXdist where many
entities collaborate on updating the different components while maintaining
compatibility.</li>
<li>The graphic pipeline powered by Etnaviv, maintained by Pengutronix in the
Linux kernel, provides users with a familiar environment: Graphic Toolkits
akin to what you would do on a standard Linux desktop PC.</li>
<li>New software is <a href="https://www.pengutronix.de/en/blog/2021-02-21-showcase-continuous-testing.html">continuously deployed to the board and test suites</a> run to catch
regressions during development.</li>
<li>To give feedback on regressions as early as possible to kernel developers,
the board is <a class="reference external" href="https://git.lavasoftware.org/lava/lava/-/merge_requests/1438">being integrated into the KernelCI infrastructure</a>, which
notifies Linux Kernel Maintainers of breakages caused by new patches.</li>
</ul>
<strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Back to technical showcases
</a>
</strong></div>
</div><p>A firmware upgrade is due. A newly implemented feature needs to be rolled
out, a security issue patched or new hardware support added.
The software, while capable, is complex.
Pengutronix' strategy to handle this complexity is working on a version-
controlled <em>Board Support Package</em> (BSP) with continuous updates and tests
on the latest mainline Linux kernel.</p>2021-02-21T15:00:00+01:00tag:www.pengutronix.de,2021-02-21:/2021-02-21-showcase-continuous-testing.htmlShowcase: Continuous Testing2021-02-21T15:00:00+01:00Chris Fiege<div class="section" id="showcase-continuous-testing">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1264x948" href="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-continuous-testing/serverroom.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-continuous-testing/serverroom.thumb.3c52d1bb3cd012dadb693755d14046e8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Insight in our server room, where the tests are computed.</p>
</figcaption>
</figure>
</div><p>About 70,000 patches go into the Linux kernel every year, and many of them are
bug fixes.
The same applies to most other open source projects that are part of a modern
Linux system.
In order to benefit from the work in the community, the sensible strategy is to
constantly update to the latest software version and keep the system up to
date.
Of course, with this amount of changes, new bugs can be added or
incompatibilities can arise.</p>
<div class="section" id="how-can-we-support-you">
<h3>How can we support you?</h3>
<p>By using Continuous Testing (CT) on real hardware, we are able to detect and
fix occurring problems at an early stage.
Our development projects essentially consist of two phases:</p>
<div class="section" id="initial-product-development">
<h4>Initial Product Development</h4>
<p>Many projects start with an initial development phase:
In this phase we support you in commissioning your hardware, as well as
building a <em>Board Support Package</em> (BSP), which is exactly tailored to your
hardware.
In this phase we develop for example missing drivers, add missing functions to
software components or optimize the boot time of your device.
In this phase software components are usually constantly updated to the latest
versions.
At the same time we offer to develop tests for your hardware and your BSP.
These tests check the core functions of the system during development.
This phase usually ends with the release of your product.</p>
</div>
<div class="section" id="long-term-maintenance">
<h4>Long Term Maintenance</h4>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="924x650" href="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-continuous-testing/continuous-testing-cycle.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-02-21_showcase-continuous-testing/continuous-testing-cycle.thumb.3051ebda57c2957692ed968ae1bf4ec5.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>In addition, we offer you a permanent maintenance of your BSP:
We regularly (e.g. several times a year) update your system and ensure with
the tests that the functions are still given.</p>
<p>The subsequent maintenance provides you with significant advantages:
If a software component should cause an error in your product or a security gap
should occur, you will always have an up-to-date system at your disposal.
This enables you to have short release cycles.
At the same time, the changes from update to update are smaller, so that the
actual effort for maintenance is lower.</p>
<p>Please do not hesitate to contact us:
In combination with your product knowledge, we will come up with a development
and maintenance concept for your operating system components that is tailored
to your requirements.</p>
</div>
</div>
<div class="section" id="real-world-example">
<h3>Real World Example</h3>
<p>In the following example, a customer relies on <em>Verified Boot</em> for its product.
A chain of cryptographic operations ensures that only an operating system
signed by the manufacturer can be run on a device.
Each component (e.g. the boot loader) checks whether the next software
component to be loaded (e.g. the Linux kernel) has a valid signature.
Only if this is the case, the respective next component is executed.</p>
<div class="ptx-sidebar">
<div class="title">
Further Information on Verified Boot
<div class="corner"></div>
</div>
<div class="body">
<p>Our colleague Marc Kleine-Budde gave the overview talk "<em>Verified Boot: From
ROM to Userspace</em>" at ELC Europe 2016.
(<a href="https://www.youtube.com/watch?v=lkFKtCh2SaU">Youtube</a>,
<a href="https://elinux.org/images/f/f8/Verified_Boot.pdf">Slides</a>)</p>
</div>
</div>
<p>The Verified Boot chain, from the configuration of the ROM code of the
processor, over the boot loader, the Linux kernel up to the user space, were
integrated into the BSP and are still being maintained by Pengutronix.</p>
<div class="section" id="test-case">
<h4>Test Case</h4>
<p>To ensure that the verification of both the FIT image (including Linux kernel
and device tree) and the dm verity protected file system work, they are tested.
To do this, the FIT image is modified and an attempt is made to boot the
system.
In a different test, the file being executed as the init process in the
dm-verity-protected file system is modified.
Reading and executing this file is expected to fail, since the dm-verity hash
tree is corrupt.
In both scenarios, the boot attempt fails, thus Verified Boot works as expected.</p>
<p>During this test, various functions of the <a href="https://barebox.org">barebox</a> boot loader are tested as a side effect:
Images are copied between partitions, file systems are mounted and modified and
the triggering of the watchdog is tested.</p>
</div>
<div class="section" id="error-case">
<h4>Error Case</h4>
<p>During a maintenance update of the BSP, the boot loader has now been updated
and the previously discussed test cases failed.
The good news: Verified Boot still worked: The modified system was not
executed.</p>
<p>But: The test revealed two bugs in barebox: One bug occurred when copying to
POSIX device-files
(<a href="http://lists.infradead.org/pipermail/barebox/2020-August/033626.html">Fix by Sascha Hauer</a>).
The other bug concerns the watchdog
(<a href="http://lists.infradead.org/pipermail/barebox/2020-August/033645.html">Fix by Ahmad Fatoum</a>).
It is expected to reset the system after the Verified Boot chain was corrupted.</p>
<p>Both errors were uncovered by the test suite and the appropriate fixes
were integrated into the BSP before the new BSP version was delivered to the
customer.</p>
<strong>
<a href="https://www.pengutronix.de/en/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Back to technical showcases
</a>
</strong></div>
</div>
</div>
<p>About 70,000 patches go into the Linux kernel every year, and many of them are
bug fixes.
The same applies to most other open source projects that are part of a modern
Linux system.
In order to benefit from the work in the community, the sensible strategy is to
constantly update to the latest software version and keep the system up to
date.
Of course, with this amount of changes, new bugs can be added or
incompatibilities can arise.</p>2021-02-21T15:00:00+01:00tag:www.pengutronix.de,2021-02-09:/2021-02-09-optee-product.htmlUsing OP-TEE to Authenticate IoT Devices2021-02-09T00:00:00+01:00Rouven Czerwinski<div class="section" id="using-op-tee-to-authenticate-iot-devices">
<p>Deploying IoT devices into the field poses the question of how to authenticate
these devices against your own services. While software authentication of
bootloader, kernel, and filesystems ensures that only trusted software is run on
the device, preventing extraction of authentication data from the device
requires the use of a Trusted Platform Module (TPM) or equivalent mechanisms.
This blog post introduces OP-TEE and PKCS#11 as a software alternative.</p>
<p>Modern ARM processors also possess a feature named TrustZone, which
allows the split into a normal and a secure world. Using System on Chip (SoC)
specific mechanisms, this secure world can be used to store data securely
without employing a TPM module. The assurance guarantees by using the TrustZone
are even tighter, since usage of the stored data requires the device to be in a
trusted secured boot state, mitigating possible desoldering of chips on the
board. In case of the i.MX SoCs, the stored data is also bound to the single
processor it was stored with, mitigating possible eMMC read-out with a different
processor. This post will provide an intro into TrustZone and how OP-TEE (the
Open Portable Trusted Execution Environment) in conjunction with HAB can be used
to store authentication data in the form of certificates on i.MX6UL SoCs.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/I9C-8FCfgaE"></iframe>
</div>
<div class="section" id="fundamentals">
<h3>Fundamentals</h3>
<p>Here we introduce the basic concepts and building blocks of the system. This
includes the ARM TrustZone technology, OP-TEE, the PKCS#11 Trusted Application,
FIT and partition verification and encryption.</p>
<p><strong>TrustZone</strong> creates separate new execution states in the processor, where
secure states can not be inspected by normal states. In conjunction with memory
protection controllers such as the TrustZone Address Space Controller (TZASC),
the secure state can be used to run a lightweight Trusted Execution Environment
(TEE). The secure state is usually called "Secure World" and the normal state
"Normal World".</p>
<p><strong>OP-TEE</strong> is a BSD-3 clause licensed open source implementation of the GPD TEE
specification. The TEE specification describes an API that should be used to
provide cross-TEE compatibility for Trusted Applications (TAs). Trusted
Applications are meant to implement the security-sensitive part of an
application and, since they are executed within OP-TEE, run in the secure world.</p>
<p>The <strong>PKCS#11 Trusted Application</strong> implements a software HSM (in the Secure World)
which is used with a shared library (in the Normal World)
which implements the PKCS#11 API. Using the OpenSSL pkcs11 engine, it is
also possible to use this as the secret store for certificates. This way
client authentication using certificates on a TLS connection is possible,
without the private key ever leaving the device.</p>
<p><strong>Flattened Image Trees</strong> (FIT) are a storage format used to assemble the
different pieces required for a Linux boot into a single piece of data. They
also allow signing and authentication, enabling the build of a verified boot
process.</p>
<p>To minimize influences on the operating system, the root partition of the system
should be mounted in read-only mode. Using read-only mode also enables the use
of dm-verity for <strong>partition verification</strong>, which calculates the checksums of
each file during creation and lets the kernel ensure that none of the operating
system files have been modified.</p>
<p>To protect data generated and saved at runtime such as persistent logs and other
information, the data should be put into an encrypted partition. This is done by
using dm-crypt achieving <strong>partition encryption</strong>.</p>
</div>
<div class="section" id="secure-boot-mechanism">
<h3>Secure Boot Mechanism</h3>
<p>To ensure a verified system, the bootloader needs to be verified during bootup.
This is a vendor-specific implementation, each vendor has its own implementation
and tools to sign the bootloader. For the NXP i.MX6UL system, for example,
this mechanism is called High Assurance Boot (HAB).</p>
<div class="ps-gallery single-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="9375x3188" href="https://www.pengutronix.de/media/blog/2020/2020-11-11_optee_product/chain.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-11-11_optee_product/chain.thumb.5313510e6965adfb34e957d312d74adc.png"/>
</a><figcaption itemprop="caption description" style="
width: 441px;
"><p>Secure Boot Mechanism.
Blocks in green are executed in the Secure World. Blocks in blue are
executed in the Normal World.</p>
</figcaption>
</figure>
</div><p>After the introduction to the different technologies and security parts of the
used stack, lets start by looking at the security overview of the system.
HAB ROM code (ROM in the picture) starts in the secure world, indicated by the
green background. It loads and verifies the bootloader, which contains our
secure operating system, and passes execution to the bootloader.
The first part of the bootloader runs in the secure world, which does the initial
setup of the system and subsequently starts the secure world operating system in
the form of OP-TEE. OP-TEE returns the execution back to the bootloader, which
now runs in the normal world. The bootloader subsequently loads the FIT image,
which contains the kernel and device tree. During bootup the kernel will verify
the integrity of files on the filesystem, ensuring that none have been tampered
with.</p>
</div>
<div class="section" id="pkcs-11-hsm-trusted-application">
<h3>PKCS#11 HSM Trusted Application</h3>
<p>The PKCS#11 Trusted Application provides a software Hardware Secure Module (HSM).
This allows the generation and storage of trusted data within OP-TEE and
enforces that the trusted data can be used to sign or encrypt, but never be
extracted from OP-TEE. This effectively allows binding an identity to the
device, which is guaranteed to never leave the device.
This can be used to e.g. encrypt updates for a specific device or allow the device to
authenticate itself cryptographically to a cloud service.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5838x3188" href="https://www.pengutronix.de/media/blog/2020/2020-11-11_optee_product/ta_calling.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-11-11_optee_product/ta_calling.thumb.ea3069be2dfae655145ab4a1b9501b49.png"/>
</a><figcaption itemprop="caption description" style="
"><p>Software Stack for a software-HSM using a PKCS#11 TA and a PKCS#11 API
for a user-space application.</p>
</figcaption>
</figure>
</div><p>As shown in the picture above, the user application in the normal world
uses the PKCS#11 API to communicate with the TA. The API is implemented by a
shipped library which in turn communicates with the kernel API to send requests
to OP-TEE. OP-TEE than routes these requests to the correct TA.
The PKCS#11 TA was originally written by Etienne Carriere and is currently in the
process of being integrated into the main OP-TEE repository.</p>
</div>
<div class="section" id="securing-op-tee-on-i-mx6">
<h3>Securing OP-TEE on i.MX6</h3>
<p>Availability of the TA and setup of the secure boot mechanisms are steps which
are mostly solved today. However, securing OP-TEE for the individual SoCs is an
important step which has not been done for a lot of SoC families.
The SoCs usually differ in the following points:</p>
<ul class="simple">
<li>Access control to the RAM or availability of SRAM</li>
<li>Access permissions for components on the SoC (GPU, Audio, I2C, SPI,…)</li>
<li>Generation/Availability of a per-CPU secret which can be used to derive keys
for storage encryption</li>
</ul>
<p>For i.MX6UL a lot of the work has been done by Pengutronix and is included in
the latest OP-TEE 3.9 release. Due to SoC-specific constraints, real secure storage
is only available if HAB is enabled. Access permissions for the SoC components
should be correctly configured within the Central Security Unit (CSU) and RAM
access is also enforced.
The remaining problems are that the device key derivation can not be enabled by
default due to concurrent access problems with the Linux kernel. Additionally,
the RAM access control component needs to be enabled by the bootloader, which
can not be solved by OP-TEE.</p>
</div>
<div class="section" id="references">
<h3>References</h3>
<ul class="simple">
<li>Talk on securing OP-TEE on SoCs: <a class="reference external" href="https://fosdem.org/2020/schedule/event/optee/">https://fosdem.org/2020/schedule/event/optee/</a></li>
<li>Talk on authenticated and encrypted storage: <a class="reference external" href="https://www.youtube.com/watch?v=z_y84v9076c">https://www.youtube.com/watch?v=z_y84v9076c</a></li>
<li>Talk on OP-TEE for i.MX6 SoCs: <a class="reference external" href="https://www.youtube.com/watch?v=I9C-8FCfgaE">https://www.youtube.com/watch?v=I9C-8FCfgaE</a></li>
</ul>
</div>
</div>
<p>Deploying IoT devices into the field poses the question of how to authenticate
these devices against your own services. While software authentication of
bootloader, kernel, and filesystems ensures that only trusted software is run on
the device, preventing extraction of authentication data from the device
requires the use of a Trusted Platform Module (TPM) or equivalent mechanisms.
This blog post introduces OP-TEE and PKCS#11 as a software alternative.</p>2021-02-09T00:00:00+01:00tag:www.pengutronix.de,2021-01-28:/2021-01-28-pengutronix-at-fosdem-2021.htmlPengutronix at FOSDEM 20212021-01-28T10:41:39+01:00<div class="section" id="pengutronix-at-fosdem-2021">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="346x100" href="https://www.pengutronix.de/media/blog/2021/2021-01-28_pengutronix-at-fosdem-2021/fosdem-logo.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2021/2021-01-28_pengutronix-at-fosdem-2021/fosdem-logo.thumb.6ce5acac46902a90203574836eb5722d.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>FOSDEM Logo</p>
</figcaption>
</figure>
</div><p>"FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels.
In 2021, they will gather online." -- <a href="https://fosdem.org/2021/">FOSDEM</a></p>
<p>This year, we will gather at 6th and 7th February and members of Pengutronix
will contribute to FOSDEM with three talks.</p>
<p>So, grab your beer (what would a FOSDEM be, without beer?) and join us!</p>
<table border="1" class="docutils">
<colgroup>
<col width="4%"/>
<col width="96%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">Time</th>
<th class="head"><a href="https://fosdem.org/2021/schedule/track/testing_and_automation/">Testing and Automation devroom</a></th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Sa,
12:25</td>
<td><a href="https://fosdem.org/2021/schedule/event/testing_embedded_devices/">About the joy and tears of testing Embedded Devices (Chris Fiege)</a></td>
</tr>
</tbody>
</table>
<table border="1" class="docutils">
<colgroup>
<col width="4%"/>
<col width="96%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">Time</th>
<th class="head"><a href="https://fosdem.org/2021/schedule/track/embedded_mobile_and_automotive/">Embedded, Mobile and Automotive devroom</a></th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Sa,
13:00</td>
<td><a href="https://fosdem.org/2021/schedule/event/from_reset_vector_to_kernel/">From Reset Vector to Kernel: Navigating the ARM Matryoshka (Ahmad Fatoum)</a></td>
</tr>
<tr><td>Sa,
16:00</td>
<td><a href="https://fosdem.org/2021/schedule/event/mainline_zynqmp_vcu_driver/">The Road to the Mainline ZynqMP VCU Driver (Michael Tretter)</a></td>
</tr>
</tbody>
</table>
<div class="section" id="about-the-joy-and-tears-of-testing-embedded-devices-chris-fiege">
<h3>About the joy and tears of testing Embedded Devices (Chris Fiege)</h3>
<p>Embedded development is complex enough. By automating repetitive parts during
development and employing testing, a lot of time can be saved and human errors
avoided. Additionally, embedded development is usually a team effort: scarce
hardware must often be shared between developers and sometimes even with
automated testing. labgrid is an open source tool for remote control and
testing of Embedded Linux Devices in a distributed lab. In this talk the
presenter takes a look at how labgrid can be used in your Embedded lab and what
labgrid's developers have learned in over three years of using and developing
it.</p>
<p>At first the presenter takes a closer look at what is actually needed to fully
remote-control an Embedded Linux Device: What are the typical interfaces that
need to be covered? What remote-control hardware is commercially available?</p>
<p>Next the presenter will focus on the labgrid framework. Labgrid is an
embedded board control python library, with a focus on testing, development and
general automation. After a short overview of the key design-concepts the
presenter will discuss labgrid's architecture. This part finishes with a demo
of how interactive development with labgrid looks like and how tests are
implemented using pytest.</p>
<p>The talk will conclude with a lessons-learned with the joy and tears of over
three years of active labgrid development and use.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/Uer9TpemmmE"></iframe>
</div>
</div>
<div class="section" id="from-reset-vector-to-kernel-navigating-the-arm-matryoshka-ahmad-fatoum">
<h3>From Reset Vector to Kernel: Navigating the ARM Matryoshka (Ahmad Fatoum)</h3>
<p>Long gone are the times of executing the OS in-place from memory-mapped flash
upon reset. A modern SoC now comes with complex mask ROM firmware, with driver,
filesystem, protocol and crypto support for loading... yet another bootloader.</p>
<p>In his talk, Ahmad follows this chain of bootloaders until the kernel is
started, stopping along the way for RAM setup, peripherial initialization,
runtime services and other interesting sights.</p>
<p>Getting acquainted with the bootstrap process on a modern ARM-based SoC can be
an intimidating task: Documentation speaks of Boot ROM, blobs, SPL, secure
monitor, trusted execution environment, Open Firmware Device Trees all
interacting with each other and with a bootloader to facilitate kernel boot.</p>
<p>The talk intends to shed some light onto this. Starting with an overview of the
bare minimum needed to bootstrap an i.MX8M, it retraces the steps of the
barebox bootloader, and firmware loaded by it, until Linux eventually takes
over.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/-Ak9MWGxd7M"></iframe>
</div>
</div>
<div class="section" id="the-road-to-the-mainline-zynqmp-vcu-driver-michael-tretter">
<h3>The Road to the Mainline ZynqMP VCU Driver (Michael Tretter)</h3>
<p>The Xilinx ZynqMP SoC includes a powerful H.264/H.265 Video Codec Unit (VCU)
which Xilinx supports with an out-of-tree driver and user space library. The
allegro driver from mainline Linux allows to use the VCU using the standard
V4L2 encoder API without requiring any custom user space.</p>
<p>I will explain why I wrote the driver, show how the VCU is used from a driver
perspective, and present the current state of the driver and which features are
still missing.</p>
<p>The Zynq UltraScale+ MPSoC integrates several ARM cores and an FPGA into a
single chip. One variant of this SoC includes an H.264/H.265 Allegro DVT Video
Codec Unit (VCU).</p>
<p>Although Xilinx did a good job supporting the ZynqMP in mainline Linux, the VCU
was originally only supported via an out-of-tree driver. It consists of a user
space library and a firmware blob, which interact via a custom IOCTL interface.
Unfortunately, this has security implications as the user space handles
physical buffer addresses.</p>
<p>Fortunately, the V4L2 mem2mem device API for video codecs avoids this problem
by using abstract DMA buffers. Many applications already use these APIs, and
various drivers for hardware codecs already implement these APIs. Thus, a V4L2
driver for the VCU allows reusing existing applications such as FFmpeg and
GStreamer on the ZynqMP.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/wpaY7LiAKpg"></iframe>
</div>
</div>
</div>
<p>"FOSDEM is a free event for software developers to meet, share ideas and
collaborate. Every year, thousands of developers of free and open source
software from all over the world gather at the event in Brussels.
In 2021, they will gather online." -- <a href="https://fosdem.org/2021/">FOSDEM</a></p>2021-01-28T10:41:39+01:00tag:www.pengutronix.de,2020-12-21:/2020-12-21-rauc-v1-5-released.htmlRAUC v1.5 Released2020-12-21T00:00:00+01:00Jan LübbeEnrico Jörns<div class="section" id="rauc-v1-5-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.5 release of RAUC</p>
</div>
</div>
<p>This release fixes a vulnerability in RAUC that can be exploited under certain
circumstances to achieve a local privilege escalation.
It provides both a mitigation for the vulnerability when using the existing
bundle format as well as a new bundle format that uses dm-verity to continuously
authenticate the update data while it is installed.</p>
<p>In summary, the vulnerability is that the during installation, the RAUC bundle
signature is checked first and then the payload data is used for the installation.
If an attacker is able to change or replace the bundle file between the
signature check and the actual installation, he can inject his own data.</p>
<p>The vulnerability is tracked as <a class="reference external" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25860">CVE-2020-25860</a>.
Please read our <a class="reference external" href="https://github.com/rauc/rauc-1.5-integration/blob/master/CVE-2020-25860.md">security advisory</a>,
which contains the background information necessary to evaluate whether your
system is affected or not.</p>
<div class="section" id="security-fix">
<h3>Security Fix</h3>
<p>To protect against attempts to modify or replace the bundle during
installation, RAUC 1.5 takes ownership of bundle files if they are not
owned by root and removes write permissions.
RAUC then checks that no writable file descriptors are open for the bundle file
(using the <tt class="docutils literal">F_SETLEASE</tt> fcntl) and performs all further installation steps
using the single file descriptor.
This protects against file replacement and concurrent writes to the open bundle.</p>
<div class="ptx-sidebar">
<div class="title">
Integration
<div class="corner"></div>
</div>
<div class="body">
<p>The <a class="reference external" href="https://github.com/rauc/rauc-1.5-integration">rauc/rauc-1.5-integration</a>
repository contains examples to simplify integrating the RAUC update into
existing projects.
You can subscribe to <a class="reference external" href="https://github.com/rauc/rauc-1.5-integration/issues/1">this issue</a> to receive
notifications of important updates to this repository and of
integration into the upstream build systems.</p>
</div>
</div>
</div>
<div class="section" id="new-bundle-format">
<h3>New Bundle Format</h3>
<p>This version introduces the new <tt class="docutils literal">verity</tt> bundle format (the old format is
now called <tt class="docutils literal">plain</tt>).
The <tt class="docutils literal">verity</tt> format was added to prepare for future use cases (such as
network streaming and encryption), for better parallelization of installation
with hash verification and to detect modification of the bundle during
installation (CVE-2020-25860).
The bundle format is detected when reading a bundle and checked against the set
of allowed formats configured in the system.conf (see <a class="reference external" href="https://rauc.readthedocs.io/en/latest/reference.html#sec_ref_formats">here</a>).</p>
<p>See <a class="reference external" href="https://rauc.readthedocs.io/en/latest/integration.html#sec_int_migration">here</a>
for more details on how to switch to the <tt class="docutils literal">verity</tt> format.</p>
</div>
<div class="section" id="other-enhancements">
<h3>Other Enhancements</h3>
<ul class="simple">
<li>Support resolving the <tt class="docutils literal">root=PARTLABEL=xxx</tt> kernel command line option. (by
Gaël PORTAY)</li>
<li>Disable the unnecessary SMIMECapabilities information in the bundle
signature, saving ~100 bytes.</li>
<li>Remove redundant checksum verification for source images during installation.
The RAUC bundle is already verified at this point, so there is no need to
verify the checksum of each file individually. (by Bastian Krause)</li>
</ul>
</div>
<div class="section" id="bug-fixes">
<h3>Bug fixes</h3>
<ul class="simple">
<li>Fix install handler selection for <tt class="docutils literal">*.img</tt> files for <tt class="docutils literal"><span class="pre">boot-*</span></tt> slots when used with
casync. (by Martin Schwan)</li>
<li>Fix checking for unknown keys in the slot configuration.</li>
<li>Fix some corner cases related to stopping the D-Bus daemon.</li>
<li>Propagate error if unable to save manifest. (by Stefan Wahren)</li>
<li>Apply <tt class="docutils literal"><span class="pre">--handler-args</span></tt> only during installation (and not during bundle
creation).</li>
</ul>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li>v1.5 <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-5-released-dec-21-2020">changes list</a></li>
</ul>
</div>
</div>
</div>
<div class="section" id="code">
<h3>Code</h3>
<ul class="simple">
<li>Remove unused code for signed manifests (outside of a bundle).</li>
<li>Add <tt class="docutils literal">G_GNUC_WARN_UNUSED_RESULT</tt> to many functions to let the compiler verify
that the caller uses the functions return value (and thus checks for errors).</li>
</ul>
</div>
<div class="section" id="documentation">
<h3>Documentation</h3>
<p>Beside some smaller typo and errors fixes, mainly the u-boot integration documentation related to
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/integration.html#set-up-u-boot-boot-script-for-rauc">scripting</a>
and <a class="reference external" href="https://rauc.readthedocs.io/en/latest/integration.html#setting-up-the-fail-safe-u-boot-environment">(fail-save) environment storage</a>
was extended and clarified.</p>
<p>Again, thanks to all contributors since v1.4: Bastian Krause, Christoph
Steiger, Christopher Obbard, Enrico Jörns, Gaël PORTAY, Jan Lübbe, Martin
Schwan, Michael Heimpold, Stefan Wahren, Uwe Kleine-König</p>
</div>
</div>
<p>This release fixes a vulnerability in RAUC that can be exploited under certain
circumstances to achieve a local privilege escalation.
It provides both a mitigation for the vulnerability when using the existing
bundle format as well as a new bundle format that uses dm-verity to continuously
authenticate the update data while it is installed.</p>2020-12-21T00:00:00+01:00tag:www.pengutronix.de,2020-12-08:/2020-12-08-soldering-christmastree.htmlPengutronix Christmas Tree2020-12-08T15:52:53+01:00Holger AssmannLeonard GöhrsMarie Mann<div class="section" id="pengutronix-christmas-tree">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/01.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/01.thumb.047ba58f30e3f265ddee661985dca925.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>PTX Christmas Tree assembly kit</p>
</figcaption>
</figure>
</div><p>With the outside world getting colder and the days becoming shorter,
we at Pengutronix decided to bring a bit of light in these dark days
of the year.</p>
<p>Our small crafting project, called PTX Christmas Tree,
has thus been created and its <a href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/ptx-christmas-tree_laser.svg">template</a>
and <a href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/ptx-christmas-tree.pdf">a short description</a> is available for
download.</p>
<p>On this page, we will - in way to many words - guide you through the
process of building our little tree.</p>
<div><div class="clearfix"></div></div><p>For instructions you can either watch our video or continue reading.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/WMmLQDEd9fg"></iframe>
</div>
<div><div class="clearfix"></div></div><div class="section" id="preparations">
<h3>Preparations</h3>
<p>Regarding our template, you will need the following components:</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/02.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/02.thumb.cb69657f456b662112cc90d603bff006.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>PTX Christmas Tree parts</p>
</figcaption>
</figure>
</div><ul class="simple">
<li>2 LEDs, normal brightness, ⌀ = 5 mm</li>
<li>1 socket for CR2032 batteries, contacts at the side</li>
<li>1 CR2032 battery at 3 V</li>
</ul>
<p>We further recommend the following tools:</p>
<ul class="simple">
<li>soldering iron and solder</li>
<li>side cutter</li>
<li>tweezers</li>
<li>(double-sided) tape</li>
<li>helping hands (but keep your distance! ;-))</li>
</ul>
<p>Mental support may be accomplished by providing cookies and hot
chocolate; glogg or eggnog should be provided only for later relish.</p>
</div>
<div class="section" id="st-step-resistors">
<h3>1st Step: Resistors</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/03.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/03.thumb.86d922253c4f172766de489d64a93bea.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Bend the legs of the resistor</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/04.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/04.thumb.72adf91c351a7bf9067100ba525a88a6.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Stick the resistors through the holes</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/05.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/05.thumb.46179cb1a3a911cef8c25f9987160ff7.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Turn the Christmas Tree</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>The two resistors have first to be freed from their holding tape by
just pulling it straight off. Afterwards, the metal legs have to get
in shape in order to fit through the assigned holes in the tree. A
pencil of the right diameter might help to bend the legs in a right
angle. We can then stick the prepared resistors through the front of
our tree.</p>
</div>
<div class="section" id="nd-step-socket">
<h3>2nd Step: Socket</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/07.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/07.thumb.58cd843bf9980fea89c8b7610a900c8c.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Attach the socket, by using some double-sided tape</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/09.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/09.thumb.fcf3ff2e837c758e14179a3fdff62f85.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Bend the resistor's leg to the socket</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/10.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/10.thumb.d2170e294ed18ecb0d3f7dfbc3843d9f.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Solder and remove the waste material</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>We will use the socket as an anchor point for all our components. It
is therefore fixed at the backside somewhere at the trunk of the tree
using the double-sided tape. Now, for each resistor, we take the leg next to the
socket and bend it in its direction. The resistor at the top has
thereby to be connected with the sockets minus pol, whereas the other
resistor has to be connected to the plus pole.</p>
</div>
<div class="section" id="rd-step-leds">
<h3>3rd Step: LEDs</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/12.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/12.thumb.76c4c243b087059a48dd4a3340c15f73.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Christmas Tree and LEDs in circuit orientation</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/14.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/14.thumb.4f7797d7eb189e1ff9d3373b9d5126e9.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Stick the LEDs through the holes</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/15.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/15.thumb.16ff5e2ec3a3976edbab9896043c7461.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Bend the LEDs legs to the resistors and socket</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/16.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/16.thumb.fb57143664eca6ce9d18efe381007412.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Solder and remove the waste material</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>We treat the LEDs like the resistors and stick them right through the
holes at the tree's front. Since the LEDs' legs are already in the
right shape we do not have to perform any bending right now. However,
being semiconductors, the polarity is important. We therefore have to
take care that the longer leg (the anode) of the LED at the treetop
gets through the left whole, while the longer leg of the other LED has
to go through the lower hole.</p>
<p>Now on the back we orient the remaining resistor legs in parallel to
their next neighbouring LED legs and establish contact between their
surfaces.</p>
<p>The other leg of the LED next to the battery socket has now to be
connected to its plus pole. Finally, we can solder the last standing
leg of the upper LED to the resistor leg that goes right through the
center of our backside.</p>
<p>After having soldered all legs and contacts and removing any remaining
excess, we can now insert the battery in its socket.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1536x2048" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/17.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/17.thumb.139e9980745979afe1cba49a339e1deb.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Insert the battery into the socket</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1838x2048" href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/20a.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/20a.thumb.602c2422cb7121cddb26d1bcfff36d2c.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Shining PTX Christmas Tree</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>The remaining hole in the treetop qualifies our resulting little piece
of art to be put up in an accommodating scenery.</p>
</div>
</div>
<p>With the outside world getting colder and the days becoming shorter,
we at Pengutronix decided to bring a bit of light in these dark days
of the year.</p>2020-12-08T15:52:53+01:00tag:www.pengutronix.de,2020-11-19:/2020-11-19-pengutronix-at-lee.htmlPengutronix at Live Embedded Event2020-11-19T11:05:47+01:00<div class="section" id="pengutronix-at-live-embedded-event">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="200x200" href="https://www.pengutronix.de/media/blog/2020/2020-11-19_pengutronix-at-lee/0.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-11-19_pengutronix-at-lee/0.thumb.03ea35b8cef11ebffc65d56ec2461759.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p><a href="https://www.linkedin.com/events/virtuelembeddedevent6719161878678929408/">Live Embedded Event</a> All rights reserved</p>
</figcaption>
</figure>
</div><p>Now that, due to the COVID-19 pandemic, everyone has gotten used to
digitalisation and online conferences - it has never been easier to organise a
conference and bring together all experts and interested parties
for a few hours of intensive exchange of ideas on a certain topic.</p>
<p>Some French companies from the embedded industry had this idea and created the
<a href="https://liveembedded.virtualconference.com/#/event">Live Embedded Event</a>.</p>
<p>The Live Embedded Event will take place on Thursday, December 3rd and
participation is possible with a
<a href="https://liveembedded.virtualconference.com/#/register">free registration</a>.</p>
<p>Our colleague Chris Fiege will contribute to the event and explain the advantages of
test automation.</p>
<table border="1" class="docutils">
<colgroup>
<col width="8%"/>
<col width="92%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="2">Security, Safety, Update</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Do,
17:00</td>
<td><div class="first last line-block">
<div class="line">How Embedded Developers work from home, using labgrid (Chris Fiege)</div>
<div class="line"><a href="https://liveembedded.virtualconference.com/#/agenda">Conference Agenda</a></div>
</div>
</td>
</tr>
</tbody>
</table>
<div class="section" id="how-embedded-developers-work-from-home-using-labgrid">
<h3>How Embedded Developers work from home, using labgrid</h3>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/I1usshTn4RI"></iframe>
</div>
<p><em>Embedded development is complex enough. By automating repetitive parts during
development and employing testing, a lot of time can be saved and human errors
avoided.</em></p>
<p><em>Additionally with an ongoing global pandemic, working from the safety of your
home is a good idea. But since embedded development is usually a team effort,
scarce hardware must often be shared and can't be taken home.</em></p>
<p><em>At first the presenter takes a closer look at what is actually needed to fully
remote-control an Embedded Linux Device: What are the typical interfaces that
need to be covered? What remote-control hardware is commercially available?</em></p>
<p><em>Next the presenter will focus on the</em>
<a href="https://github.com/labgrid-project/labgrid">labgrid framework</a>.
<em>Labgrid is an embedded board control python library with a focus on testing,
development and general automation. After a short overview of labgrid's
architecture, the presenter will show how it can be used to remote-control
many Embedded Devices in a (distributed) lab infrastructure and which steps
are needed to get labgrid running in your lab.</em></p>
<p><em>The presentation will conclude with a short demo of how interactive development
with labgrid looks like and how tests are implemented using pytest.</em></p>
<div><div class="clearfix"></div></div></div>
</div>
<p>Now that, due to the COVID-19 pandemic, everyone has gotten used to
digitalisation and online conferences - it has never been easier to organise a
conference and bring together all experts and interested parties
for a few hours of intensive exchange of ideas on a certain topic.</p>2020-11-19T11:05:47+01:00tag:www.pengutronix.de,2020-11-19:/2020-11-19-pengutronix-auf-dem-ese-kongress.htmlPengutronix at ESE Kongress2020-11-19T08:30:58+01:00<div class="section" id="pengutronix-at-ese-kongress">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="879x307" href="https://www.pengutronix.de/media/blog/2020/2020-11-19_pengutronix-auf-dem-ese-kongress/ese_logo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-11-19_pengutronix-auf-dem-ese-kongress/ese_logo.thumb.d6cf6401cd26522ab8fe41af113785d2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>All rights reserved <a href="https://www.ese-kongress.de">ESE-Kongress</a></p>
</figcaption>
</figure>
</div><p>The <a href="https://www.ese-kongress.de">Embedded Software Engineering Kongress</a>
is also taking place online this
year and we would like to take the opportunity of easy participation to watch
the lectures, join in the discussions and get into conversation.</p>
<p>In order to get into a concrete conversation, we also use the digital
conference bag. We cannot distribute our well-known pencils, but our
Pengutronix News #30.1 is available for download :-)</p>
<p>Already on 27.11., there will be the
<a href="https://express.converia.de/frontend/index.php?page_id=16101">ESE Pre-Conference</a>,
which can be booked free of charge before the congress.
Robert Schwebel will explain how easy it can be to handle complex embedded
systems with Mainline Linux.</p>
<table border="1" class="docutils">
<colgroup>
<col width="5%"/>
<col width="95%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="2">Tipps, Tricks, Lösungen 2</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Fr,
15:45</td>
<td><div class="first last line-block">
<div class="line">Komplexe Embedded Systeme mit Mainline Linux beherrschen (Robert Schwebel)</div>
<div class="line"><a href="https://ese-kongress.de/frontend/index.php?page_id=13870&v=List&do=15&day=all&ses=14344">Conference Programme</a></div>
</div>
</td>
</tr>
</tbody>
</table>
<div class="section" id="komplexe-embedded-systeme-mit-mainline-linux-beherrschen">
<h3>Komplexe Embedded Systeme mit Mainline Linux beherrschen</h3>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/Shi0-McBQ18"></iframe>
</div>
<p><em>Wer kennt das nicht im Entwickler-Alltag: Wie so oft soll in der Industrie ein
Gerät gebaut werden, das man so in der Form noch nicht auf dem Markt kaufen
kann. Vernetzt soll es sein, bunte Grafik haben, natürlich eine Reihe von auf
die Anwendung zugeschnittenen I/Os bedienen. Die Werbung der SoC-Prozessoren
und Software-Frameworks verspricht, dass alles ganz einfach ist. Ein
Toolpartner- und Werkzeuge-Universum um den Hersteller soll die Entwickler
schnell ins Thema bringen. Und dann kommt die Realität.</em></p>
<p><em>Entwickler von Geräten in der Industrie kennen das Problem seit langem: Die
Komplexität der Technologie steigt immer weiter, und damit auch die Anzahl der
Projekte, die ihren Zeitplan und ihr Budget reißen. Dabei gibt es
vielversprechende Ansätze - zumindest wenn man langfristig denkt.</em></p>
<p><em>Als Embedded-Linux-Experten werden wir oft zu Projekten gerufen, in denen
"eigentlich" schon fast alles fertig ist; wo die zuständige Abteilung der
Kunden aber festgestellt hat, dass die "nur nochs" sich plötzlich zu handfesten
Problemen auswachsen und es absehbar oder schon eingetroffen ist, dass die
Zeit- und Budgetpläne gesprengt werden. Leider kann man da oft mit "ein
bisschen Drüberwischen" keine Wunder mehr vollbringen - die Fehler sind nicht
selten schon viel früher in den Projekten verortet. Oft ist die technologische
Basis wackelig und die vermeintlich schnellen Lösungen stellen sich als nicht
zu Ende gedacht heraus.</em></p>
</div>
</div>
<p>The <a href="https://www.ese-kongress.de">Embedded Software Engineering Kongress</a>
is also taking place online this
year and we would like to take the opportunity of easy participation to watch
the lectures, join in the discussions and get into conversation.</p>2020-11-19T08:30:58+01:00tag:www.pengutronix.de,2020-10-29:/2020-10-29-elce-2020-recommended-talks.htmlELCE 2020 - Recommended Talks2020-10-29T15:41:23+01:00Chris Fiege<div class="section" id="elce-2020-recommended-talks">
<p>The Embedded Linux Conference Europe (ELCE) is the one biggest meetup of Embedded Linux
developers in Europe.
As usual Pengutronix has attended this conference - but this year from the warmth of
our homes.</p>
<p>In this blog post some colleagues will recommend talks that you should not miss.</p>
<p>Recordings for most talks are not available yet.
We will update this blog post once they are available.</p>
<div class="section" id="talks-contributed-by-pengutronix">
<h3>Talks contributed by Pengutronix</h3>
<p>First some advertisement:
This year we were able to contribute four talks to the conference in which
we talked about our current work with barebox, OP-TEE, PTXdist and
systemd for boot time optimization.
An overview on our contributions is in <a href="https://www.pengutronix.de/en/blog/2020-09-07-pengutronix-at-the-embedded-linux-conference-europe.html">this blog post</a>.</p>
</div>
<div class="section" id="chris">
<h3>Chris</h3>
<p><em>Talks recommended by Chris Fiege, electronics hardware developer</em></p>
<div class="section" id="board-farm-apis-for-automated-testing-of-embedded-linux">
<h4>Board Farm APIs for Automated Testing of Embedded Linux</h4>
<p><a class="reference external" href="https://sched.co/eCBy">Schedule</a></p>
<p>In this talk Tim Bird and Harish Bansal reported on the state of their unified API for <em>Board Farming</em>.
The term <em>Board Farming</em> in Embedded Linux development describes the situation where you have
infrastructure to remote-control a lot of Embedded Linux devices in some sort of lab.
The basic idea behind a unified API for controlling of such a lab is simple:
In open source a problem usually has to be solved once.
Afterwards it's all about using or improving an existing solution.</p>
<p>This is not the case for testing of Embedded Devices.
There is a lot of fragmentation in how a lab is controlled and how tests are structured.
In consequence tests are rewritten all over the community - or some things may not be tested at all.</p>
<p>Tim and Harish present a the specification of a REST-API that tries to cover the most important
interfaces to control an Embedded Device in a lab.
With this specification it should be possible to add a thin adaption-layer on top of whatever
hardware abstraction is running a lab to allow third-party test suits to run on your
lab.
The REST-API specification is available on the
<a class="reference external" href="https://github.com/TimesysGit/board-farm-rest-api">Timesys Github</a>.</p>
</div>
<div class="section" id="tutorial-debugging-embedded-devices-using-gdb">
<h4>Tutorial: Debugging Embedded Devices using GDB</h4>
<p><a class="reference external" href="https://sched.co/eCDW">Schedule</a></p>
<p>For a lot of my colleagues in software development using GDB to remote debug software
on a <em>device under test</em> is a common case.
But even in hardware development I am often confronted with software problems - so adding
another tool to my toolbox sounds like a good idea.</p>
<p>In this tutorial Chris Simmonds gives a broad overview on how to remote debug
on a target using GDB.
Chris does a great job in giving a step-by-step introduction in how to set up
GBD and GBD-server and gives a lot of usability hints.
All resources (slides, Raspberry Pi Image, Yocto SDK and more) are available
on <a class="reference external" href="https://2net.co.uk/tutorial/debugging-with-gdb.html">2net.co.uk</a>.</p>
<p>Unfortunately I had no SD-Card for my Raspberry PI at hand.
Thus following all steps myself is still on my personal <em>TODO-list</em>.</p>
</div>
</div>
<div class="section" id="roland">
<h3>Roland</h3>
<div class="section" id="when-you-come-to-a-fork-in-the-road-take-it">
<h4>When You Come to a Fork in the Road, Take It</h4>
<p><a class="reference external" href="https://sched.co/eCK0">Schedule</a></p>
<p>Paul Gazillo views the Linux kernel from an academic perspective, and tries to
find minimal Kconfig settings that are necessary e.g. to trigger a certain bug,
or to test patches for their effectiveness.
In essence, it turns out, that this problem can be reduced to a boolean
satisfiability problem, and he also explains the tools he and his team wrote
for this purpose, and how they can help during kernel development.
Although (or because?) this is an academic talk, it was well structured and
explained the matter at hand very well.</p>
</div>
<div class="section" id="the-state-of-open-source-licensing-clarity-or-the-lack-thereof">
<h4>The State of Open Source Licensing Clarity (or the lack thereof)</h4>
<p><a class="reference external" href="https://sched.co/eCIt">Schedule</a></p>
<p>Of course, this talk is just another opportunity to talk about SPDX, right? :-)
But Philippe Ombredanne also shows the underlying problems with the licensing
situation in the current open source and free software world,
why "This code is GPL" is not enough as a software license,
and the ideal criteria that a software package should fulfill in terms of licensing.
After all – without licensing, there is no FOSS, and unclear licensing makes it
harder for everyone to build in top of existing software.
He also shows results from his own work analysing a large catalog of open
source software packages and assigning a "license clarity score" to them,
and proposes three solutions to improve the current situation.</p>
</div>
</div>
<div class="section" id="rouven">
<h3>Rouven</h3>
<div class="section" id="introducing-tpm-nv-storage-with-e-a-policies-and-tss-fapi">
<h4>Introducing TPM NV Storage with E/A Policies and TSS-FAPI</h4>
<p><a class="reference external" href="https://sched.co/eDO6">Schedule</a></p>
<p>Andreas presents an introduction into the non-volatile storage and policy
components of modern TPMs. He also presents usable examples from the
tpm2-software project on how to employ policies to create storage areas which
fulfill certain requirements, such as write once read many (WORM).
On the policy side, he offers a great explanation of the possible abstractions
to write policies in, either from a low-level or high-level point of view.
The presentation of TSS2-FAPI is especially interesting, since the modeling of
policies using JSON is much more approchable than writing low-level policies in
TSS2-ESYS.</p>
</div>
</div>
<div class="section" id="jan">
<h3>Jan</h3>
<p><em>Talk recommended by Jan Lübbe, co-author of RAUC and labgrid</em></p>
<div class="section" id="using-the-tpm-it-s-not-rocket-science-anymore">
<h4>Using the TPM - It's Not Rocket Science (Anymore)</h4>
<p><a class="reference external" href="https://sched.co/eCJc">Schedule</a></p>
<p>Johannes und Peter gave a comprehensive overview of TPMs, their APIs and why
one would want to use them.
They explained how the <a class="reference external" href="https://tpm2-software.github.io/">TPM2-Software Community</a> has improved the support of TPMs by
implementing the higher-level APIs, especially in the area of defining
policies.
As the TPM2 stack supports several alternative APIs (native SAPI/ESAPI/FAPI,
PKCS#11 or OpenSSL engine), it's possibly to let applications access
hardware protected keys even if they don't have explicit TPM support.
If you want to access the TPM directly, there are Python and Rust libraries in
addition to the classic C API.</p>
</div>
<div class="section" id="share-system-resources-on-multi-processor-system">
<h4>Share System Resources on Multi-Processor System</h4>
<p><a class="reference external" href="https://sched.co/eCID">Schedule</a></p>
<p>Lionel explained how the needed for coordinated access to resources (such as
clocks, resets and power) is growing with modern SoCs such as the STM32MP1:
CPU cores for different use cases (Cortex-A for Linux, Cortex-M for bare-metal
real-time and system management) share periperials, both statically and
dynamically.</p>
<p>He continued with the possible approaches to implement a system manager either
as a dedicated core or as high-priviledged software on a shared core.
For ARM CPUs, the SCMI standard defines transports and interfaces which can be
used by the different agents to request the resources they need.
Lionel reported that SCMI support is merged for release in OP-TEE, TF-A and
U-Boot which should make it possible to use this on the STM32MP1 with upstream
code soon.</p>
</div>
</div>
<div class="section" id="ahmad">
<h3>Ahmad</h3>
<div class="section" id="what-the-clock-linux-clock-subsystem-internals">
<h4>What the Clock! - Linux Clock Subsystem Internals</h4>
<p><a class="reference external" href="https://sched.co/eCJx">Schedule</a></p>
<p>The Linux common clock framework (not to be confused with POSIX clocks,
clocksource or clock events) <tt class="docutils literal">clk_</tt> family of functions is now a
prevalent sight in most SoC drivers. Niel talks about its beginnings
and how it fared so far mapping the physical reality of different clock
generators, PLLs, dividers, gates and muxes onto a uniform software
interface. Informative watch as introduction into what the framework
is supposed to do and how it does it.</p>
</div>
</div>
</div><p>The Embedded Linux Conference Europe (ELCE) is the one biggest meetup of Embedded Linux
developers in Europe.
As usual Pengutronix has attended this conference - but this year from the warmth of
our homes.</p>2020-10-29T15:41:23+01:00tag:www.pengutronix.de,2020-10-15:/2020-10-15-anpassen-einer-emmc.htmleMMC Hardware Partitioning2020-10-15T14:52:10+01:00Jürgen BorleisJan Lübbe<div class="section" id="emmc-hardware-partitioning">
<p>When designing an embedded system, one must consider both the application
and the underlying hardware in combination, if the intended long-term stability
is to be achieved.
While we discussed the necessity of software updates in previous posts, in this
article I describe a way to use a memory subsystem corresponding to its
physics to achieve the best retention and lifetime of the whole system.</p>
<p><em>Retention</em> keeps the ability of the system to boot the application always up to a
useful state.</p>
<p>The <em>lifetime</em> is important if the system continuously saves data to the memory
subsystem.</p>
<p>Both requirements don't need to conflict. But depending on the application they
often do and - more importantly - often do this unnoticed.</p>
<div class="section" id="emmc-what">
<h3>eMMC… What?</h3>
<p>Internally, an <em>eMMC</em> has a single pool of memory. Unlike its more common sister - the
SD card - the <em>eMMC</em> provides external access to the memory pool via so-called
<em>hardware partitions</em>.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2046x950" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/overview-eMMC.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/overview-eMMC.thumb.9e43b4a61b272c3136aa435148c973ed.png"/>
</a><figcaption itemprop="caption description" style="
width: 800px;
"><p>Overview about the hardware partition layout of the memory</p>
</figcaption>
</figure>
</div><p>The <em>hardware partitions</em> outlined here can be used independently when the Linux
system is up and running. The two <em>boot</em> hardware partitions are special and
play an important role when the bootloader is started. The CPU can access their
content in a simplified manner, which accelerates loading and running a
bootloader. Some <em>eMMC</em> devices allow to configure their size as well. The <em>RPMB</em>
hardware partitions (RPMB: <em>Replay Protected Memory Block</em>) in turn serve as
something completely different, and will be ignored in this article along with the
boot hardware partitions. At runtime, only the <em>User Data Area</em> hardware partition (<em>UDA</em>)
is used extensively in most systems. And this usage leads to limits for
the system requirements from the preamble.</p>
<p>Note: The term <em>hardware partition</em> should not be confused with the otherwise
more well known partitions in a partition table (like MBR or GPT), which can be created and managed with
the <tt class="docutils literal">fdisk</tt> command. The latter can be used <strong>in addition</strong> to the hardware partitions.</p>
</div>
<div class="section" id="a-common-scenario">
<h3>A Common Scenario</h3>
<p>In an embedded system an <em>eMMC</em> is used and both of the two requirements
<em>high retention when starting up the system</em> and <em>long lifetime when storing data</em>
must be achieved.</p>
<p>At runtime the hardware partitions of the <em>eMMC</em> are visible:</p>
<table border="1" class="docutils">
<colgroup>
<col width="38%"/>
<col width="62%"/>
</colgroup>
<tbody valign="top">
<tr><td><tt class="docutils literal">/dev/mmcblk0boot0</tt></td>
<td><em>Boot #0</em> Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0boot1</tt></td>
<td><em>Boot #1</em> Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0</tt></td>
<td><em>User Data Area</em> Hardware Partition</td>
</tr>
</tbody>
</table>
<p>Everyone already working with <em>eMMCs</em> knows these <em>device nodes</em>.</p>
</div>
<div class="section" id="first-approach">
<h3>First Approach</h3>
<p>To achieve the <em>high retention when starting up the system</em> requirement the system
starts its bootloader from one of the available <em>boot</em> hardware partitions. After
that, the bootloader loads a Linux kernel from the regular <em>UDA</em> hardware partition
and the Linux kernel in turn uses a part of the <em>UDA</em> hardware partition as its
root filesystem.</p>
<p>To ensure the system can always start up, the developer decides to divide the
<em>UDA</em> hardware partition into two parts: The first part should be the read-only
mounted root filesystem. The second part should be writeable to be able to store
config files and log files or all kind of other data. This partitioning is done
with the <tt class="docutils literal">fdisk</tt> command on top of the <em>UDA</em> hardware partition.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1046x511" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/ersteransatz.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/ersteransatz.thumb.0c2633f2cc42554fff082c8bf2970ce5.png"/>
</a><figcaption itemprop="caption description" style="
"><p>First approach to partitioning the <em>UDA</em> hardware partition</p>
</figcaption>
</figure>
</div><p>This leads to the following visible device nodes of the <em>eMMC</em> device:</p>
<table border="1" class="docutils">
<colgroup>
<col width="38%"/>
<col width="62%"/>
</colgroup>
<tbody valign="top">
<tr><td><tt class="docutils literal">/dev/mmcblk0</tt></td>
<td><em>User Data Area</em> Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p1</tt></td>
<td>Partition for the RootFS, read-only</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p2</tt></td>
<td>Partition for a writeable filesystem</td>
</tr>
</tbody>
</table>
<p>This approach sounds sensible but during the system's lifetime it still can
lead to a bricked system, as to the root filesystem might no longer be readable. The
reason is the underlying memory subsystem, which doesn't know anything about this
layout and a read-only and a writeable part. It still manages the whole
<em>UDA</em> hardware partition as one. Since we are talking about an <em>eMMC</em> device
here, we also talking about <em>flash</em> memory as the used technology. And these
kind of memories require wear leveling techniques to avoid early failures.</p>
<p>In this context, "wear" refers to many physical effects that arise from
repeated writing to the flash blocks.
Although the exact causes and effects are quite complex, a simplification is enough for us here:
After each additional write cycle, the individual memory cells lose their electrical charge more
quickly and at some point can no longer be written.
Depending on the NAND technology used, hundreds of thousands (SLC) or only a
few thousand (TLC / QLC) cycles can be achieved.
In addition to "wear leveling", other techniques are used to deal with these
effects. These include: error correction codes (ECC), regular corrections in
the background ("scrubbing") and a supply of reserve blocks.</p>
<p>The entire memory area is usually used for wear leveling, since the highest
number of write cycles can be achieved in this way.
The part actually intended as a read area for the root file system is shifted
over time to more heavily used blocks, indicated in the following figure by the
circular arrows.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1046x511" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/verschleissnivelierung.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/verschleissnivelierung.thumb.42a5f8b9ab49e37c99e9b86bb7ec82b0.png"/>
</a><figcaption itemprop="caption description" style="
"><p>Wear leveling of the whole memory</p>
</figcaption>
</figure>
</div><p>That's why effects caused by changes in the writeable part
can propagate to the part intended for the root filesystem. And that's
why neither the lifetime nor the retention of the root filesystem is ensured.</p>
<p>For example, a system that has written a comparatively large amount may no
longer be able to accumulated correct errors due to the accelerated loss of
charge if it remains switched off for a few months .
Thus, neither the desired service life nor the reliability for the root file
system is guaranteed.</p>
</div>
<div class="section" id="better-emmc-partitioning-based-approaches">
<h3>Better eMMC Partitioning-Based Approaches</h3>
<p>Besides the <em>boot</em> hardware partitions, <em>eMMC</em> devices provide
additional types of hardware partitions, which are always disabled on
delivery and need an additional configuration step to enable. However,
as this step cannot be reverted any more, special care and planning
should be taken before the actual change. A side effect of enabling
hardware partitions is the reduction of the overall capacity of the
<em>eMMC</em>. Details about this will follow later on.</p>
<p>The goal of this configuration is to inform the <em>eMMC</em> about its intended use.</p>
<p>To divide the available capacity, an <em>eMMC</em> offers several alternatives:</p>
<ul class="simple">
<li>Enhanced User Data Area (EUDA)</li>
<li>General Purpose Partitions (GPPs)<ul>
<li>default</li>
<li>enhanced</li>
<li>extended ("system code" or "non-persistent")</li>
</ul>
</li>
</ul>
<p>It should be noted that the <a class="reference external" href="http://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf">standard</a> does not
define the exact meaning of these attributes.
Improved reliability is given as an example for the <em>enhanced</em> mode.
In addition, it says "The definition of enhanced storage media should be
decided upon by each system manufacturer, and is outside the scope of this
standard."
In practice, <em>enhanced</em> often means that an SLC mode is used.
Ultimately, however, it depends on the respective manufacturer of the eMMC, so
it is worthwhile to study the relevant documentation.</p>
<div class="section" id="enhanced-user-data-area">
<h4>Enhanced User Data Area</h4>
<p>The <em>EUDA</em> leads into an internal change how to manage a part of the <em>UDA</em>.
From the user's point of view nothing else changes (except possibly the reduced
capcity).</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1046x562" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/euda_plus_uda.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/euda_plus_uda.thumb.1e7d9a14944ee64290071ca3f2b6cd2c.png"/>
</a><figcaption itemprop="caption description" style="
"><p>Configuring an EUDA part</p>
</figcaption>
</figure>
</div><p>From now, not only from the application's point of view, but also from the <em>eMMC</em>
point of view these two parts are separated and the <em>eMMC</em> manages both parts
differently. Since there is no noticeable change from the user's point of view,
it is important to align the filesystem's partitions according to the sizes of
both parts via <tt class="docutils literal">fdisk</tt>.</p>
<p>As mentioned before, there is no visible change when an <em>EUDA</em> is configured:</p>
<table border="1" class="docutils">
<colgroup>
<col width="29%"/>
<col width="71%"/>
</colgroup>
<tbody valign="top">
<tr><td><tt class="docutils literal">/dev/mmcblk0</tt></td>
<td><em>User Data Area</em> Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p1</tt></td>
<td>Partition for the RootFS, read-only (covers the EUDA)</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p2</tt></td>
<td>Partition for a writeable filesystem (UDA)</td>
</tr>
</tbody>
</table>
<p>For any given eMMC model, whether the wear leveling actually manages UDA and
EUDA separately, as indicated in the picture, can only be answered with the
appropriate documentation.</p>
</div>
<div class="section" id="general-purpose-partitions">
<h4>General Purpose Partitions</h4>
<p>In contrast to an <em>Enhanced User Data Area</em>, configuring a <em>General Purpose Partition</em>
leads to cutting off some of the <em>UDA</em> memory and offering it as an additional externally
visible device.
When creating the GPP, you can choose between the <em>default</em> or <em>enhanced</em> storage modes.
The meaning of <em>enhanced</em> does not have to be identical for UDA and GPPs.</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1106x520" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/gpp_plus_uda.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/gpp_plus_uda.thumb.d162fe413cbdaee562cb77898425b232.png"/>
</a><figcaption itemprop="caption description" style="
"><p>Configuring a <em>GPP</em></p>
</figcaption>
</figure>
</div><table border="1" class="docutils">
<colgroup>
<col width="38%"/>
<col width="62%"/>
</colgroup>
<tbody valign="top">
<tr><td><tt class="docutils literal">/dev/mmcblk0gpp0</tt></td>
<td>GPP #0 Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0</tt></td>
<td><em>User Data Area</em> Hardware Partition</td>
</tr>
</tbody>
</table>
<p>At this point support from the application is required in order to make use of
the <em>GPP</em>. The bootloaders barebox and U-Boot and the Linux kernel both have this support
already.</p>
<p>Under Linux, the <em>GPP</em> as <tt class="docutils literal">/dev/mmcblk0gpp0</tt> is now
a separate device and the <em>eMMC</em> manages it independently from the
<em>UDA</em> (which remains accessible as <tt class="docutils literal">/dev/mmcblk0</tt>). It makes no difference which one used. The <em>GPP</em> as well
can now be partitioned and formatted. Finally, at runtime the following list
of device nodes will exist:</p>
<table border="1" class="docutils">
<colgroup>
<col width="37%"/>
<col width="63%"/>
</colgroup>
<tbody valign="top">
<tr><td><tt class="docutils literal">/dev/mmcblk0gpp0</tt></td>
<td>GPP #0 Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0gpp0p1</tt></td>
<td>Partition for the RootFS, read-only</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0</tt></td>
<td><em>User Data Area</em> Hardware Partition</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p1</tt></td>
<td>Partition for a writeable filesystem</td>
</tr>
</tbody>
</table>
<p>Besides the configuration of its internal memory, the <em>eMMC</em> offers some more
options to specify the future use of each of the memory parts. This allows the
<em>eMMC</em> to adapt its strategy to manage its internal memory more closely
to the expected usage.</p>
<p>More about this in a future blog post.</p>
</div>
</div>
</div>
<p>When designing an embedded system, one must consider both the application
and the underlying hardware in combination, if the intended long-term stability
is to be achieved.
While we discussed the necessity of software updates in previous posts, in this
article I describe a way to use a memory subsystem corresponding to its
physics to achieve the best retention and lifetime of the whole system.</p>2020-10-15T14:52:10+01:00tag:www.pengutronix.de,2020-09-07:/2020-09-07-pengutronix-at-the-embedded-linux-conference-europe.htmlPengutronix at the Embedded Linux Conference Europe2020-09-07T16:46:04+01:00Chris Fiege<div class="section" id="pengutronix-at-the-embedded-linux-conference-europe">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="417x152" href="https://www.pengutronix.de/media/blog/2020/2020-09-07_pengutronix-at-the-embedded-linux-conference-europe/LF-Event-Logo-_ELC-EU-White-01-01.svg.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-09-07_pengutronix-at-the-embedded-linux-conference-europe/LF-Event-Logo-_ELC-EU-White-01-01.svg.thumb.bf9acdd43423c520b9e7f1ee2c2f4859.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/program/schedule/">schedule</a>
for this year's Embedded Linux Conference Europe (ELCE) has just been
released.
As in the last years Pengutronix contributes talks to current topics around
Embedded Linux.</p>
<p>The ELCE is not going to be held in Dublin as announced last year.
Instead it will be held as a virtual conference.
This makes it especially easy for Embedded Linux newcomers to take a look at
this conference.
The <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/register/">registration</a>
is still possible.</p>
<p>The following submissions by Pengutronix have made it into the program:</p>
<div class="section" id="beyond-just-booting-barebox-bells-and-whistles-ahmad-fatoum">
<h3>Beyond "Just" Booting: Barebox Bells and Whistles (Ahmad Fatoum)</h3>
<p>Monday, 26.10.2020 13:00-13:50 (GMT+1)
(<a href="https://osseu2020.sched.com/event/eCBp/beyond-just-booting-barebox-bells-and-whistles-ahmad-fatoum-pengutronix?iframe=no&w=100%&sidebar=yes&bg=no">Link to Schedule</a>)</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/Oj7lKbFtyM0"></iframe>
</div>
<p>Your bootloader can boot into Linux, what else could you possibly need?
Originally started as a more structured U-Boot fork with a driver model,
<a href="https://barebox.org/">barebox</a> has since grown into a versatile Swiss Army Knife for bootstrap,
hardware bring-up and development of Linux-based systems.</p>
<p>In his talk, Ahmad will show you how to get barebox running on your board and
along the way explain barebox' design choices, from multi-image support to
virtual file systems, POSIX/Linux API, fail-safe updates, boot fall-back
mechanisms, customizability and more.</p>
</div>
<div class="section" id="boot-time-optimization-for-the-real-world-michael-olbrich">
<h3>Boot-Time Optimization for the Real World (Michael Olbrich)</h3>
<p>Monday, 26.10.2020 14:00-14:50 (GMT+1)
(<a href="https://osseu2020.sched.com/event/eCCA/boot-time-optimization-for-the-real-world-michael-olbrich-pengutronix-ek?iframe=no&w=100%&sidebar=yes&bg=no">Link to Schedule</a>)</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/Um7jlqNzjL8"></iframe>
</div>
<p>There have been many talks about boot-time optimization in the past.
For the most part, the only goal was a minimum boot-time.
It's a good way to show the optimization techniques and gives a nice wow effect.
But the end result is rarely usable in real world projects.
So instead of looking for new ways to reduce the boot-time just a little bit more,
this talk will look at boot-time optimization in a larger context.</p>
<p>"The device needs to boot faster" is often stated but the actual requirements
behind this are often more complex.
We will look at typical requirements and possible solutions beyond general
boot-time optimization.
And while booting as fast as possible is nice, in most cases there are other
more important requirements, which are often related to security or reliability.
This talk will look at possible optimizations in this context.
What are the consequences of an optimization and what trade-offs are possible?</p>
<p>And last but not least, let's talk about the hardware.
The choices made while designing a device can have a big impact on the boot-time.
Therefore this talk will end with advices for hardware design criteria and
component decisions to keep in mind to boot fast.</p>
</div>
<div class="section" id="op-tee-is-ready-let-s-use-it-rouven-czerwinski">
<h3>OP-TEE is Ready: Let's Use It! (Rouven Czerwinski)</h3>
<p>Tuesday, 27.10.2020 19:30-20:20 (GMT+1)
(<a href="https://osseu2020.sched.com/event/eCGo/op-tee-is-ready-lets-use-it-rouven-czerwinski-pengutronix-ek?iframe=no&w=100%&sidebar=yes&bg=no">Link to Schedule</a>)</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/I9C-8FCfgaE"></iframe>
</div>
<p>OP-TEE for i.MX6 SoCs is production ready, so we finally have a fully mainline
way to use TrustZone on a widely available platform.
So what are the scenarios where it can increase security or allow new features?
This talk will present the current state of OP-TEE from an upstream perspective
on i.MX6 SoCs and show two different Trusted Applications (TAs) which provide
secure data storage or TPM functionality.</p>
<p>One of the presented applications will be the PKCS#11 TA, which is currently
being upstreamed into the mainline OP-TEE project.
In conjunction with the OpenSSL PKCS#11 engine, it can be used to store client
certificate data which can not be extracted from the device.
The other application will be the Microsoft firmware TPM, which is provided as
an out-of-tree TA with an upstream Linux kernel driver.
It is meant as a replacement for conventional hardware TPMs and provides a
tighter coupling to the chosen SoC.</p>
<p>Furthermore this talk will highlight the necessary steps to actually
secure OP-TEE on your chosen SoC, using the i.MX6 platform as an example.</p>
</div>
<div class="section" id="the-state-of-ptxdist-roland-hieber">
<h3>The State of PTXdist (Roland Hieber)</h3>
<p>Wednesday, 28.10.2020 18:15-19:05 (GMT+1)
(<a href="https://osseu2020.sched.com/event/eCIw/the-state-of-ptxdist-roland-hieber-pengutronix?iframe=no&w=100%&sidebar=yes&bg=no">Link to Schedule</a>)</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/9AoFufw4BCI"></iframe>
</div>
<p><a href="https://ptxdist.org/">PTXdist</a> has been around as a build tool for Embedded Linux systems for more
than 16 years now.
During its monthly release cycle, besides the usual maintenance tasks, useful
features are continuously being added.
In the last years, these included support for kconfig deltas and layered BSPs,
infrastructure for cryptographic code signing and license compliance, support
for reproducible builds, and online reference documentation.
With its configuration menu for selecting the software packages for your
target system, and a template wizard for creating new packaging rules,
PTXdist makes it possible to get a booting BSP in almost no time.
Advanced users will feel familiar with PTXdist's makefiles, and can profit
from fast edit-compile-run cycles by using nfsroot and cross-gdb integration.</p>
<p>This talk gives an overview over the core concepts and the current feature set
of PTXdist, and is intended for new as well as old users.</p>
</div>
</div>
<p>The <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/program/schedule/">schedule</a>
for this year's Embedded Linux Conference Europe (ELCE) has just been
released.
As in the last years Pengutronix contributes talks to current topics around
Embedded Linux.</p>2020-09-07T16:46:04+01:00tag:www.pengutronix.de,2020-08-10:/2020-08-10-rauc-v1-4-released.htmlRAUC v1.4 Released2020-08-10T00:00:00+01:00Enrico Jörns<div class="section" id="rauc-v1-4-released">
<p>It's been 3 weeks ago now since the tag for RAUC 1.4 was created.
But it is vacation time and so we have a good excuse for communicating things
with some delay.
Fortunately, the media team is back now and so also those of you who haven't
noticed the new release yet will be informed about notable changes.</p>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.4 release of RAUC</p>
</div>
</div>
<p>Beside several minor memory leakage fixes, this release comes with number of
stricter checks for parsing the slot selection to help users to identify
potential misconfiguration much earlier than before.</p>
<p>The release now also allows and visibly encourages to explicitly decide between
a central (single) or per-slot RAUC status files with <tt class="docutils literal"><span class="pre">statusfile=<path>/per-slot</span></tt>.
Where possible (e.g. if one has a shared data partition anyway),
one should prefer a central status file as this allows RAUC to also store
the status of raw partitions and avoids having to write to readonly-mounted
ones.</p>
<div class="section" id="facing-the-future">
<h3>Facing the Future</h3>
<p>Or at least the year 2038 when the 32 bit UNIX timestamp overflows.
As <tt class="docutils literal">mkfs.ext4</tt> still defaults to 128 byte inodes with 32 bit time stamps for
smaller file systems (<512MiB), this will trigger the kernel warning:</p>
<pre class="literal-block">
ext4 filesystem being mounted at /foo supports timestamps until 2038
</pre>
<p>With RAUC you will pretty sure update the filesystem several times before 2038
but to act early and to avoid the warning, RAUC now always enforces 256 byte
inodes when creating file systems.</p>
</div>
<div class="section" id="custom-bootloader-slot-selection">
<h3>Custom Bootloader (Slot selection)</h3>
<p>For very special use cases where the default or currently available bootloader
backends do not apply for redundant slot switching, RAUC now also supports
implementing a custom logic.
This feature was requested again and again in the past and then implemented by
Christian Bräuner Sørensen.
The documentation added by Andreas Schmidt then finally allowed us to merge it
for the 1.4 release.</p>
<p>Below you see a short usage example:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[system]</span>
<span class="na">…</span>
<span class="na">bootloader</span><span class="o">=</span><span class="s">custom</span>
<span class="k">[handlers]</span>
<span class="na">bootloader-custom-backend</span><span class="o">=</span><span class="s">custom-bootloader-script</span>
</pre></div>
</div><p>The interface between RAUC and the custom boot selection script / binary
consists of simple commandline arguments, echo to stdout and return values
documented
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/integration.html#custom-bootloader-backend-interface">here</a>.
A manual invocation of this script / binary would look like:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">$ </span>./custom-bootloader-script<span class="w"> </span>get-primary
<span class="go">A</span>
<span class="gp">$ </span>./custom-bootloader-script<span class="w"> </span>get-state<span class="w"> </span>A
<span class="go">bad</span>
<span class="gp">$ </span>./custom-bootloader-script<span class="w"> </span>set-state<span class="w"> </span>A<span class="w"> </span>good
</pre></div>
</div></div>
<div class="section" id="atomic-updates-for-bootloaders-in-a-gpt-partition">
<h3>Atomic Updates for Bootloaders in a GPT Partition</h3>
<p>If your SoC does not support atomic bootloader updates by itself but allows
loading the bootloader from a GPT partition, the new RAUC slot type
<tt class="docutils literal"><span class="pre">boot-gpt-switch</span></tt> now supports updating the GPT partition atomically.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[slot.bootloader.0]</span>
<span class="na">device</span><span class="o">=</span><span class="s">/dev/sda</span>
<span class="na">type</span><span class="o">=</span><span class="s">boot-gpt-switch</span>
<span class="na">region-start</span><span class="o">=</span><span class="s">1M</span>
<span class="na">region-size</span><span class="o">=</span><span class="s">32M</span>
</pre></div>
</div><p>This is similar to the already-existing support for MBR partitions and works by
defining a disk region with twice the size of the actual partition contents.
RAUC then writes a new bootloader image to the inactive region and modifies the
GPT entry afterwards to point to this newly written region.</p>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li>v1.4 <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-4-released-jul-20-2020">changes list</a></li>
</ul>
</div>
</div>
</div>
<div class="section" id="testing">
<h3>Testing</h3>
<p>We put some effort in enhancing the tests and the test coverage of RAUC.
The new qemu-based testing environment introduced in v1.3 was now extended to
also support testing of UBIFS and NAND slot types.
We also better test the non-service configuration case (and fixed some
convenience issues in this area) that is still of interest for very constrained
devices or other special use cases where D-Bus is inappropriate.</p>
<p>Again, thanks to all contributors since v1.3: Andreas Schmidt, Bastian Krause,
Christian Bräuner Sørensen, Dan Callaghan, Enrico Jörns, Jan Lübbe, Michael
Heimpold, Tobias Junghans, Uwe Kleine-König</p>
</div>
</div>
<p>It's been 3 weeks ago now since the tag for RAUC 1.4 was created.
But it is vacation time and so we have a good excuse for communicating things
with some delay.
Fortunately, the media team is back now and so also those of you who haven't
noticed the new release yet will be informed about notable changes.</p>2020-08-10T00:00:00+01:00tag:www.pengutronix.de,2020-07-05:/2020-07-05-elc-na-2020-a-virtual-experience.htmlELC-NA 2020 - A Virtual Experience2020-07-05T00:00:00+01:00Enrico JörnsJan Lübbe<div class="section" id="elc-na-2020-a-virtual-experience">
<p>In 2020, things tend to be a bit different from what we had before.
This is also true for this year's Embedded Linux Conference in North America.
The need for keeping physical distance required the Linux Foundation to switch
form a real conference to a fully virtual one.</p>
<p>The main advantage, both for Pengutronix and many others too, was that it was
the first chance to easily participate in the North America version of the ELC.
What would have required lots of time and money for booking flight, hotels, the
conference, and actually traveling to the US boiled down to pay 50$ for the
online access and have some extra coffees to manage the time shift.</p>
<div class="section" id="the-experience">
<h3>The Experience</h3>
<p>Just to let you know up front: This worked much better we would have thought at
first, and it was already announced that some parts of this format will
potentially survive the 'virtual-only era'.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1995x1208" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-lobby.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-lobby.thumb.71007cc253a63cecd17c2b1655238204.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The virtual event's lobby</p>
</figcaption>
</figure>
</div><p>The virtual experience was driven by a neat integration between a set of online
services:</p>
<p>With onlinexperiences.com, a general landing page for the event was
created that also attempted to give the visual impression of being in an actual
event location.
This site was also where the sponsor booth could be visited to see video
recording, marketing material or chat with them.</p>
<p>The main conversation moved from normal floor meetings to a Slack instance.
They provided a dedicated channel for each track, a general one, a helpdesk,
and some others.
This indeed was one of the best innovations brought to the experience as at
least the Embedded and the Yocto channel were quite popular (~800 and ~300
participants) and allowed to talk about the missing buffet as well as about
technical details and upcoming ideas.</p>
<p>The big constant in terms of websites was <a class="reference external" href="https://sched.com">sched.com</a> that (as also the
years before) provided a good overview over the entire schedule of key-notes,
talks, events, mini-summits, etc.
With the main difference that each entry now had a <em>Watch now</em> link that
directly took you to the talks live video.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1536x1213" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_theater.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_theater.thumb.39fc6ea382db0549cbab689eb394b9e6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1152x968" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-qa.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-qa.thumb.2b271e9f0a613a6446977b27a1f13b05.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1152x968" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-zen.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_virtual-zen.thumb.57b37a534adcbc47f83e9a20148c2631.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1536x1403" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_slack.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_slack.thumb.7c524fed4cf3e4d8df6bcd01f944dbdc.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div><p>Talks themself then again took place on onlineexperiences.com. Some were live,
some pre-recorded.
The latter gave the speaker the great opportunity to answer incoming questions
live in the Q&A interface while the talk was still running.
A great technical team in the background ensured that hardly any issues
appeared during presentation.</p>
<p>For the BoFs they used another service called <em>Airmeet</em>.
This provides a slightly more interactive platform allowing for example to let
participants answer questions in video, chat with each other and post or vote
for questions.
Unfortunately, this platform turned out to have some limitations and conceptual
issues that prevented a fully flexible interaction between attendees.</p>
<p>And, despite official lunch and coffee breaks were quite short, at least
compared to a real conference, there was one major advantage that shouldn't be
left unmentioned:
There was coffee available! All the time, even during talks. Really! Amazing...</p>
</div>
<div class="section" id="the-talks">
<h3>The Talks</h3>
<p>Here we would like to share some of the talks we've been attending and found
either quite interesting, entertaining or instructive.</p>
<p><strong>Invest in Mainline Linux: Choose Your Own Adventure - Dexter Travis, Precision Planting</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3SA/invest-in-mainline-linux-choose-your-own-adventure-dexter-travis-precision-planting">on sched.com</a></p>
<p>This talk will tell you why a <em>super tux</em> Kernel turned out to actually be
an <em>old man tux</em> Kernel and how that made a company use the actual <em>tux</em>
Kernel.
Divided into several 'levels', this journey is a great war story from a small
company that began to learn and love the benefits of mainline Linux,
including many of the same arguments and tradeoffs that convince our customers
as well.</p>
<p><strong>Yocto Project LTS Releases - Nicolas Dechesne, Linaro & David Reyna, Wind River</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3SS/yocto-project-lts-releases-nicolas-dechesne-linaro-david-reyna-wind-river">on sched.com</a></p>
<p>An overview about the motivation behind the Yocto LTS release project, what it
intends to provide and what not, and how it will be maintained.
This is worth having a look at for everyone having to decide what Yocto
releases to pick and when to migrate.</p>
<p><strong>Kernel Coding the Upstream Way - Tim Bird, Sony</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3Pe/kernel-coding-the-upstream-way-tim-bird-sony">on sched.com</a></p>
<p>A great and quite entertaining talk about some good and bad practices for
writing code in the Linux kernel, but (partly) also applicable to other
projects using C.
From proper NULL pointer checks and 'goto' usage over efficiency and code
optimization considerations to the usage and demystification of several kernel
macros this talk uses many real world examples and isn't just targeted at
kernel gurus.</p>
<p><strong>Introduction to Embedded Linux Security - Sergio Prado, Embedded Labworks</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3XR/introduction-to-embedded-linux-security-sergio-prado-embedded-labworks">on sched.com</a></p>
<p>This talk from Sergio gives a comprehensive overview about the different
aspects of securing Embedded Linux system, mainly recommended to those who
are new to these topics.
Starting with some general considerations and the advice to do proper threat
modeling to know what one actually needs protect against, Sergio describes the
basics of ensuring integrity of the base system with a secure boot and lists
options to encrypt the data in different use-cases.
The talk also quickly touches secure coding practices, program access
limitations and system updates.
Note that the slides actually contain even more infos than the time allowed to
share.</p>
<p><strong>Reproducible Builds and Hash Equivalence in the Yocto Project - Joshua Watt, Garmin</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3R9/reproducible-builds-and-hash-equivalence-in-the-yocto-project-joshua-watt-garmin">on sched.com</a></p>
<p>Joshua presents two of the most notable developments of the Yocto Project in
the recent releases: The first one is hash equivalence detection which allows
better usage of the Yocto shared state cache.
He points out how recipe changes not affecting the actual recipe output are
detected and how this prevents unnecessary rebuilds of dependant packages.
In the second part of his talk he gives a close look at what the Yocto project
does to ensure binary reproducibility of package builds, together with some
insights on how the related QA tests work, how they could be improved further
and what else one can expect to come up.</p>
<p><strong>PipeWire: The New Multimedia Service, Now Ready for Automotive - Julian Bouzas, Collabora</strong></p>
<p><a href="https://ossna2020.sched.com/event/c3TN/pipewire-the-new-multimedia-service-now-ready-for-automotive-julian-bouzas-collabora">on sched.com</a></p>
<p>Julian described how PipeWire is getting closer to replace PulseAudio and JACK.
From the embedded perspective, especially the lower CPU usage and more flexible
control via the session manager API is interesting.
In addition to audio, PipeWire also supports video, making it much easier to
build complex use-cases, where video needs to be passed between multiple
processes.</p>
<p>The goal is to replace PulseAudio in Fedora soon, which will hopefully lead to
fixes for any corner-case issues that have not been exposed so far.</p>
<p><strong>10 Years of Linux Security - A Report Card - Bradley Spengler, Open Source Security, Inc.</strong></p>
<p><a href="https://ossna2020.sched.com/event/ckp9/10-years-of-linux-security-a-report-card-bradley-spengler-open-source-security-inc">on sched.com</a>
<a href="https://www.youtube.com/watch?v=F_Kza6fdkSU">on youtube.com</a></p>
<p>Bradley, as the author of the grsecurity patch set, gave an overview of the
enhancements to Linux security over the last 10 year.
The most interesting part was an analysis of the shortcomings of the current
processes centered around addition new features (such as user namespaces),
vulnerability tracking and backporting to stable kernels.
It seems that more effort needs to be focused on the thankless but important
work of stable kernel maintenance.</p>
<p>His talk triggered a follow-up discussion on the state of the LinuxFoundation's
<a class="reference external" href="https://www.coreinfrastructure.org/">Core Infrastructure Project</a> on Slack.
Although the website is somewhat outdated, they have published a
<a class="reference external" href="https://www.coreinfrastructure.org/programs/census-program-ii/">new report on the Census Program</a>
and started a
<a class="reference external" href="https://www.linuxfoundation.org/blog/2020/06/linux-foundation-harvard-announce-free-libre-and-open-source-software-foss-contributor-survey/">survey for contributers to FOSS</a>.
The goal is to understand which projects are critical to the whole community
and are most at risk via a thorough analysis.</p>
</div>
<div class="section" id="closing-game-and-remarks">
<h3>Closing Game and Remarks</h3>
<p>An ELC is not an ELC without the famous closing game hosted by Tim Bird every
year since ages.
But how would the "red green game" and rock-paper-scissors translate into the
virtual world?</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1152x971" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_intro.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_intro.thumb.68512ea5a42979c3ff8eb8ca61369402.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Time announces that the closing game will likely fail</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="768x800" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_goto.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_goto.thumb.12206c88d6606975dcf64dd3d6e4c4f5.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Closing game goto question</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="768x800" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_linelength.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_linelength.thumb.422cd96342b74698adfa814a7ac4a96e.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Closing game line length limit question</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="768x800" href="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_rock-paper-scissors.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-07-03_elc-na-2020-a-virtual-experience/elce-na_closing-game_rock-paper-scissors.thumb.15a0a5013aad857fe35c13644862296e.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Closing game rock-paper-scissors</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Luckily, Tim Bird is also a great entertainer from his home office, promising
that all games are totally unfair and that the web server for the games he
wrote in the afternoon is sure to fail.
That turned out not to be the case (apart from some minor glitches) and at the
end there was, as always, a group of lucky winners, including us, yeah!</p>
<p>The ELC ended with some final notes about the future that we would also like to
share:</p>
<p>This year's ELC Europe 2020, supposed to take place in Dublin, will also be
virtual and a new attempt for an in-person meeting in Dublin will be made in
October 2021.</p>
<p>Stay healthy! And see you!</p>
</div>
</div>
<p>In 2020, things tend to be a bit different from what we had before.
This is also true for this year's Embedded Linux Conference in North America.
The need for keeping physical distance required the Linux Foundation to switch
form a real conference to a fully virtual one.</p>2020-07-05T00:00:00+01:00tag:www.pengutronix.de,2020-04-23:/2020-04-23-rauc-v1-3-released.htmlRAUC v1.3 Released2020-04-23T00:00:00+01:00Enrico Jörns<div class="section" id="rauc-v1-3-released">
<p>Here it is, commit number 1700, 291 commits after the v1.2 tag:
The v1.3 release of RAUC is out in the wild and adds a lot of new and useful
features together with some fixes.</p>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.3 release of RAUC</p>
</div>
</div>
<p>We start with the most 'visible' feature: When invoking the command line tool
<tt class="docutils literal">rauc status</tt> you will notice a reorganized output.
This provides a colored output (with optional UTF-8 character support) along
with a changed layout that should make it easier to identify the system status.</p>
<div><div class="clearfix"></div></div><div class="row"><div class="col-md-4">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x585" href="https://www.pengutronix.de/media/blog/2020/2020-04-23_rauc-v1-3-released/rauc_status_1.3.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-04-23_rauc-v1-3-released/rauc_status_1.3.thumb.6594aaaefbfbd5527aafcef5662fbdee.png"/>
</a><figcaption itemprop="caption description" style="
width: 256px;
"><p>'rauc status' output (RAUC v1.3)</p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div><div class="col-md-8">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="911x405" href="https://www.pengutronix.de/media/blog/2020/2020-04-23_rauc-v1-3-released/rauc_status_1.2.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-04-23_rauc-v1-3-released/rauc_status_1.2.thumb.aef01327f99c79ae3fc76de057335e47.png"/>
</a><figcaption itemprop="caption description" style="
width: 562px;
"><p>For comparison: 'rauc status' output of RAUC v1.2</p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div></div><p>With a new D-Bus API method for starting an installation, we have eliminated a
significant drawback of the initial API design that made it impossible to pass
optional arguments when installing.
For example, this now makes the long-existing <tt class="docutils literal"><span class="pre">--ignore-compatible</span></tt> option
available in all scenarios but will also enable potential new install options like
a <tt class="docutils literal"><span class="pre">--dry-run</span></tt> in the future.</p>
<div class="section" id="bundle-signatures">
<h3>Bundle Signatures</h3>
<p>A few notable improvements to bundle signing landed in RAUC 1.3.
By default, RAUC does not check the certificate's
<a class="reference external" href="https://tools.ietf.org/html/rfc5280#section-4.2.1.3">key usage</a> attributes.
When the bundle signing certificates are part of a larger, shared PKI, RAUC can
now require specific purposes like <em>codeSigning</em>, thereby allowing better
policy enforcement via the PKI.
Checking of key usage attributes can be enabled with the <tt class="docutils literal"><span class="pre">check-purpose</span></tt>
configuration option:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[keyring]</span>
<span class="na">path</span><span class="o">=</span><span class="s">/path/to/ca.cert</span>
<span class="na">check-purpose</span><span class="o">=</span><span class="s">codesign</span>
</pre></div>
</div><p>Also, you can now require checking of CRLs during installation (which is
disabled by default in OpenSSL).
Setting the <tt class="docutils literal"><span class="pre">check-crl</span></tt> configuration option changes this:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[keyring]</span>
<span class="na">path</span><span class="o">=</span><span class="s">/path/to/ca.cert-with-crl</span>
<span class="na">check-crl</span><span class="o">=</span><span class="s">true</span>
</pre></div>
</div><p>If the keyring already contains a CRL, but checking is not enabled, a warning
will now be printed.</p>
<p>For bundles with expired certificates, you can now use the <tt class="docutils literal"><span class="pre">--no-verifiy</span></tt>
option for <tt class="docutils literal">rauc resign</tt> to easily create a fresh signature.</p>
<p>As the OpenSSL project dropped support for all version before 1.1.1, we have
now removed support for those as well.
If you still use a deprecated and thus insecure OpenSSL version, this is the
time to upgrade!</p>
</div>
<div class="section" id="further-enhancements">
<h3>Further Enhancements</h3>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li>v1.3 <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-3-released-apr-23-2020">changes list</a></li>
</ul>
</div>
</div>
<p>A couple of limitations in bundle and image size handling RAUC had when running
on a 32 bit system were removed.</p>
<p>For those running on very constrained systems, some options for reducing the
size of the RAUC binary were added.</p>
<p>If you want to customize bundle creation, this version adds some options for
that:
<tt class="docutils literal"><span class="pre">--mksquashfs-args="-option-to-add"</span></tt> for mksquashfs, and
<tt class="docutils literal"><span class="pre">--casync-args="--another-option"</span></tt> for casync.</p>
<p>A couple of minor bugs and memory leaks were fixed, especially an error
reporting bug that may have triggered during bundle verification if an invalid
keyring was configured which lead to a non-intuitive error message
"<tt class="docutils literal"><span class="pre">rauc-ERROR</span> **: Not enough substeps: check_bundle</tt>".</p>
</div>
<div class="section" id="testing">
<h3>Testing</h3>
<p>The main test suite was previously run in UML (User Mode Linux), but this
turned out to be difficult to support in the various build environments.
This was now replaced by running a normal kernel in QEMU to better decouple it
from the host system and kernel while preparing CI testing of more areas, like
NAND writing support via the kernel's nandsim module.</p>
<p>Thanks to all contributors since v1.2:
Arnaud Rebillout, Christopher Obbard, Enrico Jörns, Jan Kundrát, Jan Lübbe,
Louis des Landes, Marco Felsch, Martin Hundebøll, Michael Heimpold, Michael
Tretter, Rasmus Villemoes, Rouven Czerwinski, Trent Piepho, Ulrich Ölmann</p>
</div>
</div>
<p>Here it is, commit number 1700, 291 commits after the v1.2 tag:
The v1.3 release of RAUC is out in the wild and adds a lot of new and useful
features together with some fixes.</p>2020-04-23T00:00:00+01:00tag:www.pengutronix.de,2020-03-30:/2020-03-30-flattenthecurve-introducing-our-remote-setup.html#FlattenTheCurve – Introducing Our Remote Setup2020-03-30T00:00:00+01:00Enrico JörnsMarie Mann<div class="section" id="flattenthecurve-introducing-our-remote-setup">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3456x4608" href="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/isolated_tux.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/isolated_tux.thumb.64fbd6bb5214602c2ae3d89e4e4b3855.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Even Tux helps to flatten the curve</p>
</figcaption>
</figure>
</div><p>The Corona crisis is a challenge that has hit many people as well as most companies
quite unexpectedly. The entire team of Pengutronix wants to thank those that
currently ensure our essential supplies, health system and civil
infrastructure!</p>
<p>But, there will also be a time after the crisis and people and economy will
recover. Thus stopping our work was never an option, but we need to ensure
that we operate in responsibility for our employees and our fellow people.</p>
<p>Two weeks ago, we introduced our strategy for protecting our staff, doing our
part to flatten the COVID-19 curve and slow down the pandemic by switching to
remote work.</p>
<p>Despite already having a few full-time remote workers at our company, most of
our employees work at the main office. In normal times we are used to meeting
at our coffee bar to chat, discuss recent topics and share ideas.
So, being isolated is a new situation to most of us, too.
However, extending our distributed infrastructure to serve all colleagues
(and not only a handful remote workers) was managed in half a day and all
colleagues were able to seamlessly continue working.</p>
<p>Luckily, we are able to automate most of the things that need to happen for
embedded development, but for the few tasks that cannot be done remotely (like
receiving parcels, switching cables on local hardware, etc.), there is always
one colleague present at our local office.</p>
<p>Due to our normal workflow most of the required infrastructure was already in
place, but we also had to extend it here and there to face the additional
challenges of being all remote now.</p>
<p>We like to share recent experiences with our remote environment, that helps us to
keep physical distance without social distancing:</p>
<div class="section" id="working-remotely-on-software">
<h3>Working Remotely on Software</h3>
<p>For doing our everyday work, we have an extended server infrastructure to manage
all our developing projects in Git repositories. Compiling code and building
Board Support Packages needs lots of CPU power, so we have our
<a href="https://www.pengutronix.de/en/blog/2018-09-13-fixing_icecc.html">ICECC</a> compiling
cluster and remote server access via SSH. We have been
using this infrastructure for decades, but in this case it helped our colleagues
to set up their working places at home in little to no time and continue their work
as usual.</p>
<div class="ptx-sidebar">
<div class="title">
Recommended Talk
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="https://chemnitzer.linux-tage.de/2018/de/programm/beitrag/328">Open SSH für Anfänger und Fortgeschritene [de]</a></p>
</div>
</div>
</div>
<div class="section" id="remote-conversation">
<h3>Remote Conversation</h3>
<div class="section" id="chatting-like-always-irc">
<h4>Chatting like always – IRC</h4>
<p>IRC and e-mail still are our main communication tools.</p>
<p>In times of all kinds of new instant messengers flying around, IRC seems to be
a bit dusty – you might think. But it perfectly fits our communication
use case, with the advantage of minimal disturbances: You are not cluttered with
unrelated pictures and this “messenger” is really running on our own server
infrastructure. Also, most of our developers already follow various OSS
projects' IRC channels, so IRC puts itself forward for this job.</p>
<p>Our communication via mailing lists is still unrestricted and working as usual.</p>
</div>
<div class="section" id="still-talking-to-each-other-mumble">
<h4>Still Talking to Each Other – Mumble</h4>
<blockquote>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1024" href="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/mumble.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/mumble.thumb.19c9dc2f041d41581a6cc81250f1786c.png"/>
</a><figcaption itemprop="caption description" style="
width: 50px;
"><p><a class="reference external" href="http://mumble.git.sourceforge.net/git/gitweb-index.cgi">Logo Mumble</a></p>
</figcaption>
</figure>
</div></blockquote>
<p>While we have been using <a class="reference external" href="https://www.mumble.info/">Mumble</a>,
an open source VoIP chat server, for a long time for talking to our
remote-working colleagues, this voice chat has now become a coffee bar replacement.
It also allows us to continue our biweekly stand-up meeting,
as well as discussing topics in small groups by joining a conference channel.</p>
<p><strong>The most important advice</strong> for your personal setup - no matter which
VoIP-tool you are using: Configure your setting to usage of PushToTalk.
Your colleagues will thank you.</p>
</div>
<div class="section" id="show-and-tell-jitsi">
<h4>Show and Tell – Jitsi</h4>
<blockquote>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="800x1131" href="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/jitsi.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/jitsi.thumb.0af9064be40e6c2d635591bf9756331b.png"/>
</a><figcaption itemprop="caption description" style="
width: 50px;
"><p><a class="reference external" href="http://jitsi.org/">Logo jitsi</a></p>
</figcaption>
</figure>
</div></blockquote>
<p>Sometimes talking to each other is not enough and it's actually helpful to
share a screen, look at a piece of hardware together or just talk face to face.
For these cases our admins set up a <a class="reference external" href="https://jitsi.org/">Jitsi server</a>
for video conferencing in the browser.
From first experiences it works quite well, even in long-lasting conferences
with a handful of clients and on a small bandwidth.
We are planning to do some performance test in the next few days.</p>
<p>The fact that Jitsi doesn't need any clients suits our “no corporate desktop”
policy well.</p>
<div><div class="clearfix"></div></div></div>
</div>
<div class="section" id="working-remotely-on-hardware">
<h3>Working Remotely on Hardware</h3>
<p>The main difference between Pengutronix and most other software companies is
that we are working directly on hardware (e.g. for developing and testing
kernel drivers). This means that our colleagues need access to custom boards.</p>
<p>What we can benefit from during this crisis is that fully working remotely
actually is not that much different from what we usually do in our daily
business already. After initial bring up, most of the customers' hardware we
work on is installed in one of our several remote testing and development labs.
This way, our developers can work with the hardware from their office desk and
are able to automatically switch power, get a serial console, have network
access, etc.</p>
<div class="section" id="our-remote-setup">
<h4>Our Remote Setup</h4>
<p>We've worked a lot on both hardware and software tools that enable working
remotely on hardware during the past years; and we'd like to give a short
insight into our setup in order to possibly also inspire others:</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3456x4608" href="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/remotelab.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/remotelab.thumb.24f8fb509711f2465f722f09b9b9e1be.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Power Switch at a Remotelabs</p>
</figcaption>
</figure>
</div><p>Each remote lab consists of the following core components:</p>
<ul class="simple">
<li>a network controllable (Gude or netio) power switch</li>
<li>a network controllable serial server (accessible over the <a class="reference external" href="https://tools.ietf.org/html/rfc2217">RFC 2217</a> protocol)</li>
<li>a network switch</li>
<li>a small server</li>
</ul>
<p>Some of them are also equipped with</p>
<ul class="simple">
<li>CAN infrastructure for IO switching</li>
<li>USB hubs for controlling USB devices</li>
</ul>
<p>Our open source hardware automation tool <a href="https://www.pengutronix.de/en/software/labgrid.html">labgrid</a>
then brings these physical resources to the developer's desk.</p>
<p>Each remote lab then runs
a labgrid exporter instance that automatically provides labgrid “resources” for
the available remote hardware. A resource can be for example a power switch, a
serial console, a USB device, or a CAN remote IO.</p>
<p>These resources can be grouped to places, which allows grouping resources with
a similar purpose, and controlling them by a simple abstract place name like
“my-devboard”.</p>
<p>Then each developer has a local instance of the labgrid client running that
allows him to lock places, switch power, get a serial console, etc.</p>
<p>Finally, a central labgrid coordinator instance runs in a VM, coordinating
access between the labgrid exporters and the clients.</p>
<p>This setup works both on local office desks as well as from home connected
through SSH.</p>
</div>
<div class="section" id="helpful-tools">
<h4>Helpful Tools</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="938x938" href="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/usb-sd-mux.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-03-26_flattenthecurve-introducing-our-remote-setup/usb-sd-mux.thumb.d11e4c4382c95966cb49dbbf2390d342.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>USB-SD-Mux</p>
</figcaption>
</figure>
</div><p>But, there are still things left that one can find hard to automate, like
populating SD cards with a disk image and plugging it back into the device.
For this purpose, our partner company <a class="reference external" href="https://linux-automation.com">Linux Automation GmbH</a> brought up the <a class="reference external" href="https://shop.linux-automation.com/index.php?route=product/product&product_id=50">USB-SD-Mux</a>.
This device consists of a small PCB with one end formed like a µSD card that
you can put into your board's µSD slot instead of the physical µSD card. The
physical µSD card is then put into the USB-SD-Mux instead. Connected over USB
to a host computer it then allows us to switch the SD card between the host and
the device under test, and re flash the SD card from the host like a standard
USB mass storage.</p>
<p>We also have similar hardware in the pipeline or in the final test phase for
Ethernet switching (like actually plugging cables in and out) and for USB
switching (e.g. to simulate plugging of an USB stick).
Stay tuned to find out about those :-)</p>
<p>We hope, you'll find our experiences helpful.
Even though our remote setup works very well, we are looking forward to an
end of this crisis and meeting each other in person again.</p>
</div>
</div>
</div><p>The Corona crisis is a challenge that has hit many people as well as most companies
quite unexpectedly. The entire team of Pengutronix wants to thank those that
currently ensure our essential supplies, health system and civil
infrastructure!</p>2020-03-30T00:00:00+01:00tag:www.pengutronix.de,2020-02-26:/2020-02-26-embedded_world_2020.htmlPengutronix at Embedded World 20202020-02-26T00:00:00+01:00Marie MannChris FiegeEnrico Jörns<div class="section" id="pengutronix-at-embedded-world-2020">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_ptx_booth.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_ptx_booth.thumb.39d4cb7f2e366833f4b08ea51f0c6512.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>A rather empty Pengutronix booth early this morning.</p>
</figcaption>
</figure>
</div><p>Yesterday, Embedded World started, in normal times one of the largest trade shows for
embedded development in Europe.
While many exhibitors (and thus maybe also lots of visitors) have canceled their presence due to
the coronavirus, we present
<a class="reference external" href="https://www.embedded-world.de/de/ausstellerprodukte/embwld20/aussteller-46601541/pengutronix-e-k">our booth</a>
and our demo show cases as usual.</p>
<p>For online booth visitors or those that simply want to save trees, our well-known Pengutronix News No. 30 can be found
<a class="reference external" href="https://www.pengutronix.de/Pengutronix-News-30.pdf">here</a>.</p>
<p>But here we go for our demo showcases:</p>
<div class="section" id="design-for-mainline">
<h3>Design for Mainline</h3>
<p>In cooperation with our spin-off <a class="reference external" href="https://linux-automation.com">Linux Automation GmbH</a> and our partners
<a class="reference external" href="https://octavosystems.com/">Octavo Systems</a> and <a class="reference external" href="https://www.bopla.de/">Bopla</a>
we present our "Design for Mainline" strategy.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_stm32mp1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_stm32mp1.thumb.2828ec57c23a54c7a935f02aaa156411.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Right: STM32MP1 Demo with OSD32MP1 in the center of the custom PCB below the display.</p>
</figcaption>
</figure>
</div><p>The example board shown contains only off-the-shelf components
that are well-supported by mainline Linux (and barebox) drivers.</p>
<p>Here is the recipe how Linux Automation GmbH creates your own, customized HMI board:</p>
<ul class="simple">
<li>select a System-in-Package Chip like the <a class="reference external" href="https://octavosystems.com/octavo_products/osd32mp15x/">OSD32MP1x</a> by Octavo Systems to drastically reduce hardware design effort and risk</li>
<li>add reliable and easy to use storage (eMMC)</li>
<li>seamlessly integrate an off-the-shelf display and touch unit like the <a class="reference external" href="https://www.bopla.de/gehaeusetechnik/product/botouch/botouch-kunststoff/btk-70-starter-kit.html">BoTouch</a> by Bopla</li>
<li>add your own preferred interfaces (i.e. PoE on our demo board, CAN, SPI, ...)</li>
<li>add graphics acceleration using open source drivers (Etnaviv), MESA (OpenGL) and Qt Quick or web browser</li>
<li>create a reproducible and open source software stack by providing a (Yocto/PTXdist) Board Support Package (BSP)
with a current mainline kernel</li>
<li>optional: long term maintenance with scheduled update intervals to lower security risks and fight technical debt</li>
</ul>
</div>
<div class="section" id="can-j1939-in-linux-mainline">
<h3>CAN - J1939 in Linux Mainline</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_j1939.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_j1939.thumb.2864c93afa650564ba7051d9b8445a10.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The dial knob on the left can be used to control the game.
The terminals on the right contain additional information on the current state of J1939.</p>
</figcaption>
</figure>
</div><p>This is probably the most attractive demo to our visitors.
You will be able to spend your time on our booth while playing Tetris, using a tractor control stick
or (if you prefer) an ordinary keyboard.</p>
<p>If you choose the tractor control stick, your actions are transferred via the CAN-based communication
protocol <a class="reference external" href="https://en.wikipedia.org/wiki/SAE_J1939">J1939</a>.</p>
<p>Kurt van Dijck has created an in-kernel implementation for J1939 years ago.
But he never made the effort to bring it into the mainline kernel.
This year a customer contracted Pengutronix to bring Kurt's implementation into the upstream kernel.
This happened with the Linux kernel 5.4.</p>
<p>When J1939 went mainline these things happened:</p>
<ul class="simple">
<li>The protocol is no longer part of the userspace, but
part of the kernel and therefore just another socket interface for
all applications.
Our customer was able to shrink his application code by 50%,
which reduces the maintenance workload.</li>
<li>Since the initial set of patches the implementation gained some attention from
other companies in this industry and new use cases came up that we hadn't had
in mind before.</li>
<li>With our implementation of J1939 available as Open Source vendors can now
concentrate on fixing bugs and add new features to this implementation
instead of working around the quirks of the closed source stacks.</li>
</ul>
<p>One part of doing things right is to test the code in kernel CI labs.</p>
<p>So far we got reports from different companies involved into industrial, automotive and security development.
For example:</p>
<ul class="simple">
<li>Google started security and stability test of the J1939 stack to avoid possible vulnerabilities.
So far Google detected and reported about 10 issues, which have now been fixed by us.</li>
<li>We got reports about implementation of Eclipse Titan tests (an industry grade protocol testing framework initially developed by Ericsson)</li>
<li>Other companies started testing and using the stack.
We're looking forward for new use cases, test patterns and bugs :)</li>
</ul>
<p>This is another proof, that our philosophy can't be too wrong:
even a protocol, which appears to be very specific and has it's own niche can
benefit from the community.</p>
</div>
<div class="section" id="open-source-graphics-on-i-mx8m">
<h3>Open Source Graphics on i.MX8M</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_imx8m_4video.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_imx8m_4video.thumb.13f3e60a7df38484e8d9047e43e7ad81.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>4-Video Demo - as usual in flight-ready hardware.</p>
</figcaption>
</figure>
</div><p>Maybe the first thing you will notice is that our well-known video demonstrator features four new videos.
What you won't notice is the low CPU load as the QML application is now able to make use of the Hantro hardware video decoder that is found in the i.MX8M.
Using hardware acceleration for video decoding is necessary to decode videos in an acceptable resolution for the 4k display.</p>
<p>This demonstrator shows the current feature set that you can get by using mainline Linux, GStreamer, Mesa, and Etnaviv on the i.MX8M.</p>
<p>As in previous years, the hardware is a state-of-the-art in-flight entertainment system.
Thus, maybe you will watch videos on this generation of hardware using mainline Linux during one of your next long distance flights.</p>
</div>
<div class="section" id="automated-testing-of-embedded-devices">
<h3>Automated Testing of Embedded Devices</h3>
<p>One important aspect of an efficient and reliable platform maintenance workflow
is having tests for the requirements that the system needs to satisfy
and being able to automate the testing process.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_labgrid.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_labgrid.thumb.8ab001e08830a277d9690612729c326f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The Labgrid Demonstrator contains all components a real lab at Pengutronix contains.</p>
</figcaption>
</figure>
</div><p>This is where our open source Python-based hardware abstraction framework <a class="reference external" href="https://labgrid.org">labgrid</a> comes into play by driving
professional testing equipment.</p>
<p>The demo shows one example on how to fully automate test cases: the device under test (DUT) is
a <a class="reference external" href="https://beagleboard.org/black">Beagle Bone Black</a> with a speed-controlled motor as demo use case.
The Micro SD-Card carrying the BSP is inserted into one of our
<a class="reference external" href="https://shop.linux-automation.com/index.php?route=product/product&product_id=50">USB-SD-Muxes</a>.
This tool makes it possible to change the contents of the plugged SD card from the test server.
The serial port of the DUT is connected to the test server.
Additionally, the power of the DUT can be switched using a CAN-Open based switch.</p>
<p>With a hardware setup like this and labgrid as a hardware abstraction layer on top,
embedded system testing feels like pure software testing:
Test suites can be written in <a class="reference external" href="https://pytest.org">pytest</a> and can be executed by continuous integration systems
or can be controlled from virtually everywhere using remote access via SSH.</p>
</div>
<div class="section" id="fail-safe-update-for-embedded-devices">
<h3>Fail-Safe Update for Embedded Devices</h3>
<p>Performing authenticated and fail-safe updates of devices in the field is
a topic of ongoing importance and interest.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_rauc_hawkbit.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-25_embedded-world/2020-02-25_demo_rauc_hawkbit.thumb.b22564eaa47a6e3d01a98b359c819bf2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The RAUC-Demo: the 6 Raspberry Pis mimic our fleet of devices.</p>
</figcaption>
</figure>
</div><p>Our <a class="reference external" href="https://rauc.io">RAUC</a> updating demonstrator with 6 Raspberry Pis is known to those
who visited the Pengutronix booth during the last years but has since received
ongoing technology improvements.</p>
<p>In barebox <a class="reference external" href="http://lists.infradead.org/pipermail/barebox/2020-February/040898.html">2020.02.0</a>,
for example, the full support for the
Raspberry Pi platform went mainline and thus also enables makers to use
RAUC for their home automation, video box, or anything else.</p>
<p>The Demo not only shows fail-safe upgrades of devices in the field using
the RAUC update framework but also sketches a full rollout scenario by
making use of the open source deployment server <a class="reference external" href="https://www.eclipse.org/hawkbit/">hawkBit</a>.</p>
<p>For interfacing with RAUC via D-Bus on one side and hawkBit via its
DDI API on the other side, we use the simple Python-based example application
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit">rauc-hawkbit</a>
that also had a new <a class="reference external" href="https://github.com/rauc/rauc-hawkbit/releases/tag/v0.2.0">release</a>
during the demo preparation.</p>
<p>While the Python implementation is meant for evaluation purposes, thanks to the guys from Prevas DK,
there is now also a glib-based C implementation available, called
<a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a>.</p>
<p>At out booth you can also lean more about other current and useful features as</p>
<ul class="simple">
<li>SmartCard/HSM (PKCS#11) support</li>
<li>delta updates with <a class="reference external" href="http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html">casync</a></li>
</ul>
</div>
</div>
<p>Yesterday, Embedded World started, in normal times one of the largest trade shows for
embedded development in Europe.
While many exhibitors (and thus maybe also lots of visitors) have canceled their presence due to
the coronavirus, we present
<a class="reference external" href="https://www.embedded-world.de/de/ausstellerprodukte/embwld20/aussteller-46601541/pengutronix-e-k">our booth</a>
and our demo show cases as usual.</p>2020-02-26T00:00:00+01:00tag:www.pengutronix.de,2020-02-25:/2020-02-25-ptxdist_license-report.htmlLicense management with the ptxdist make license-report2020-02-25T00:00:00+01:00Felicitas Jung<div class="section" id="license-management-with-the-ptxdist-make-license-report">
<div class="alert alert-warning" role="alert">
this blogpost is targeted at people who have yet little knowledge of open
source software.
It is kept as simple as possible and desires to give an overview of licensing
and usage of the command line.
Even though we use the automatically generated ptxdist license-report, we also
look into the licenses manually to get a better picture.
</div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="567x283" href="https://www.pengutronix.de/media/blog/2020/2020-02-11_ptxdist-license-report/PTXdist_Logo_RGB.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-11_ptxdist-license-report/PTXdist_Logo_RGB.thumb.5aff5fbac961e57001016715abbbca27.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>PTXdist comes with a tool to make license management more simple, namely the
command:
<tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>.
This tool generates a license report in pdf format, which filters the used BSP
for all known licenses.
To generate and comply with the license report should be seen as minimum standard,
exceeding efforts should, if possible, be done.</p>
<div class="section" id="generate-the-license-report">
<h3>Generate the license report</h3>
<p>First we need to change into the root directory of the BSP, in our case
<tt class="docutils literal">~/DistroKit</tt>.
We can check if we are in the correct directory by checking if the symlinks
<tt class="docutils literal">selected_platformconfig</tt> and <tt class="docutils literal">selected_ptxconfig</tt> can be found.
If the symlinks don't exist, is PTXdist also able to look for them in the
/configs-directory.
Only if no information to platform and no PTXconfig can be found there either,
the <cite>make license-report`</cite>
command will fail.
Assuming everything is fine, we then execute the <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>
command.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit $ ptxdist make license-report
</pre></div>
</div><p>In my case I had to first install the packages <tt class="docutils literal">graphviz</tt>, <tt class="docutils literal">dot2tex</tt> and
<tt class="docutils literal"><span class="pre">texlive-xetex</span></tt>.
If all necessities are given, PTXdist will then collect all the licensing
information found in the packages used in the BSP.
These information are the variables <tt class="docutils literal"><PKG>_LICENSE</tt> and <tt class="docutils literal"><PKG>_LICENSE_FILES</tt>
which can be found in each package definition, that is either used locally in the
BSP or in the PTXdist installation directory <tt class="docutils literal"><span class="pre">rules/<pkg>.make</span></tt>.
Finally it will respond with</p>
<div class="code-block">
<div class="highlight"><pre><span></span>) [375] (./license-report-tools.aux) )
(see the transcript file for additional information)
Output written on license-report-tools.pdf (375 pages).
Transcript written on license-report-tools.log.
finished target license-report-tools.pdf
</pre></div>
</div><p>The generated license report is stored in the sub-directory of the used platform
in the directory <tt class="docutils literal">report</tt>, so we change into that directory.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit $ cd platform-v7a/report/
</pre></div>
</div><p>We are only interested in the license-report.pdf for now (the report for the
tools is not interesting for the ready-built BSP, in which the tools are not used
anymore as they are only needed for building), so we look into it:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit/platform-v7a/report $ evince license-report.pdf
</pre></div>
</div><p>Please always pay attention to the disclaimer found on the first page:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>!Attention!
This list of licenses is automatically generated and asserts no claims to
completeness or correctness. It is not legally binding, and comes without
warranty of any kind. We advise a manual counter-check before publication or
legal use.
</pre></div>
</div></div>
<div class="section" id="using-the-license-report">
<h3>Using the License Report</h3>
<p>Let's take a peek at the package BusyBox:</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="200x182" href="https://www.pengutronix.de/media/blog/2020/2020-02-11_ptxdist-license-report/2020-02-11_ptxdist_license-report_busybox.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-11_ptxdist-license-report/2020-02-11_ptxdist_license-report_busybox.thumb.07d979438e02d01ca3ebb2ae8b8a73fa.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>The license report reports, that BusyBox is licensed under GPLv2-only.
This means, that for being allowed to use BusyBox, the conditions of the GPLv2
must be met.
Because of the -only appendix, it is not allowed to fulfill the conditions of a
later version of the GPL instead.
If one constantly meets the conditions of the GPLv2, the work for this package
is already done.</p>
<p>Now we take a look at the package systemd:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>License: GPL-2.0-or-later AND LGPL-2.1-only
</pre></div>
</div><p>The license report found components of systemd, which are licensed under GPLv2+,
but also components, which are licensed under LGPLv2-only.
If the desired usage of systemd is compliant with both licenses anyway, then
our work is done already as well.
This would be the desired state.</p>
<p>In the other case you have to check, if you can leave out the components licensed
under the license that you don't want to or cannot comply with.</p>
</div>
<div class="section" id="analysing-the-respective-component-by-hand">
<h3>Analysing the respective component by hand</h3>
<p>For example, have a look at the components of systemd used in your BSP:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit $ cd platform-v7a/build-target/systemd-243-51-gfab6f010ac6c
</pre></div>
</div><p>Use the tabulator key to complete the command after typing the first characters
each.</p>
<p>In each component of systemd found in the systemd-directory of the relevant
platform is a license header included, which describes, what license applies to
the corresponding component.
For example you <em>could</em> use your BSP without the systemd file <tt class="docutils literal">.mkosi/mkosi.debian</tt>.
Let's just assume, for the sake of explaining, that would be something you want
to do.
If you then leave out this file while creating the BSP, you do not need to meet
the conditions of its license.
Of course this would not change much regarding the license management, as the
other .mkosi-files are licensed under LGPLv2 as well.
To avoid the LGPL you would have to leave out all of the <tt class="docutils literal">.mkosi</tt> components.
And of course there is even more LGPL in systemd to find and - if desired - avoid.
You may want to have a look:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R
</pre></div>
</div><p>This greps for <tt class="docutils literal">LGPL</tt> recursively.
Careful, grep is case sensitive.
Because the letters <tt class="docutils literal">LGPL</tt> are generally only used for the license identifier, you
get a good overview over what components are licensed under some version of the
LGPL.
Or grep for a special version of the LGPL if you are only interested in that,
e.g. try <tt class="docutils literal"><span class="pre">LGPL-v2</span></tt>.
Be aware though, that not all programmers use the same syntax, e.g. <tt class="docutils literal">LGPL v2.1</tt>
(without the hyphen connecting <tt class="docutils literal">L</tt> with <tt class="docutils literal">v</tt>) is mentioned in systemd's
<tt class="docutils literal">src/udev/ata_id/ata:id.c</tt>.
For the plain LGPL this is, as expected, a lot.
Only the last few findings:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>test/create-sys-script.py:# SPDX-License-Identifier: LGPL-2.1+
sysctl.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/80-container-host0.network:# SPDX-License-Identifier: LGPL-2.1+
network/meson.build:# SPDX-License-Identifier: LGPL-2.1+
network/99-default.link:# SPDX-License-Identifier: LGPL-2.1+
network/80-container-ve.network:# SPDX-License-Identifier: LGPL-2.1+
network/80-container-vz.network:# SPDX-License-Identifier: LGPL-2.1+
sysusers.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/meson.build:# SPDX-License-Identifier: LGPL-2.1+
tmpfiles.d/portables.conf:# SPDX-License-Identifier: LGPL-2.1+
</pre></div>
</div><p>Maybe you want to know the exact amount of findings, e.g. to calculate how many
workhours you will need:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep LGPL -R | wc -l
</pre></div>
</div><p>In my case a whopping:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>2162
</pre></div>
</div><p>Or you grep for the letters <tt class="docutils literal">GPL</tt>, which also includes <tt class="docutils literal">LGPL</tt>.
If you want to grep only for the GPL, you have to to some RegExp magic:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>grep '^GPL\|[^L]GPL' -R
</pre></div>
</div><p>Or grep for the license identifiers:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit/platform-v7a/build-target/systemd-243-51-gfab6f010ac6c $ grep License-Identifier -R
</pre></div>
</div><p>A wordcount gives out a total of <tt class="docutils literal">2224</tt> (registered) license identifiers for
the version of systemd used in my BSP, though some files might not include the
letters <tt class="docutils literal">License Identifier</tt>.</p>
<p>This work is done by the command <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt> to give you a
good overview of the licenses of the used components, including the license text
of any known open source license.
It is quite comfortable to have a nicely readable pdf-file, which tells you what
program used in the BSP involves what licenses.
It allows you to concentrate on problematic parts then.
The license report relies on correct information though and cannot replace the
individual license compliance done by a human.</p>
<p>If for an existing BSP you have to or want to avoid a certain license, you can
use the license report as a starting point.</p>
</div>
</div>
<p>PTXdist comes with a tool to make license management more simple, namely the
command:
<tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>.
This tool generates a license report in pdf format, which filters the used BSP
for all known licenses.
To generate and comply with the license report should be seen as minimum standard,
exceeding efforts should, if possible, be done.</p>2020-02-25T00:00:00+01:00tag:www.pengutronix.de,2020-02-25:/2020-02-25-open-source101.htmlDon't fear the open source - 101 of license management2020-02-25T00:00:00+01:00Felicitas Jung<div class="section" id="don-t-fear-the-open-source-101-of-license-management">
<div class="alert alert-warning" role="alert"><p>This blog post is targeted at people, who have yet little knowledge of Open
Source and Free Software.
Minor inaccuracy might occur due to simplification.
Experience in Open Source automatically brings about a more accurate
understanding.
This blogpost focuses on German Law.</p>
<p>I will use the word <tt class="docutils literal">copyright</tt> for the text to be internationally
understandable, but please be aware, that the German "Copyright" is deeply
different from the anglo-american Copyright and Patent Right.
The consquences, licenses, are handled in a similar way though, so German and
non-German software can be treated in the same way.</p>
</div><div class="section" id="why-do-licenses-exist-at-all">
<h3>Why do licenses exist at all?</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1203x1061" href="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_justicia-tux.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_justicia-tux.thumb.864cdb48bfdee1829f4425002451fbf3.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Tux as Justicia with blindfold and sword</p>
</figcaption>
</figure>
</div><p>Computer programs and code can be protected by copyright law.
In Germany this protection cannot be removed.
The German Copyright (German: Urheberrecht) grants all right to whoever created
the work.
Following only this general rule, only the developer could use, modify, share the
code he wrote.</p>
<p>This patent right (German: Verwertungsrecht), which the creator of a work holds
automatically with creation, can be transferred to other persons as a whole or
partially, for example a developer might transfer his patent right to his
employer.
Therefore the creator of a work and the holder of the patent right can be
different persons.</p>
<p>The German Copyright has a quite strict understanding of who has and has not the
right to use, modify and share the work.
To transfer these rights, normally an individual contract was needed.
Some people desired code to be free and modifiable by everyone, without the need
to individually transfer the rights to the code.
Quite like you could buy a bike and then also inspect and modify it, without
having to ask the manufacturer first.</p>
<p>Because in German Copyright one can not simply decide to not have the patent
right for the work one has created, people used the tool of the copyright, namely
licenses, to offer the right to the work to everyone (Free Software).
To use the right to share and modify, first the code had to be published: open
sourcing the code is the answer.</p>
</div>
<div class="section" id="free-and-open-source-software">
<h3>Free and Open Source Software</h3>
<p>Open source literally only means to make the code available to the public.
This does not necessarily have to be done with a version control tool, though
this is quite popular, even providing the code on individual request can be
understood as open source.
If the code is publicly available, many eyes with knowledge of many different
fields check on it, vulnerabilities and need for general improvement are noticed
quickly.</p>
<p>While information about need for improvement on proprietary code by external
persons often lead to legal consequences against those who speak out, evidently
interfering with finding and closing of vulnerabilities, open sourcing can lead
to an improvement of the code, both security-wise and usability-wise.</p>
<p>Open Source also encourages the permission to everyone to modify the code, unlike
code-available programs.
It is self-evident though, that the original open sourced code may not be
tempered with, unless permission individually granted.
If someone wants to make a modification, he may fork the original code and then,
on his own fork, apply the modification.</p>
<p>Free Software on the other side strongly emphasizes the freedom of the user,
which, more as a side effect, is only possible if the code is generally
accessible.
A developer of Free Software does not primarily open source his programs due to
the technical and economical advantages, but wants to actively shape the
society towards a higher standard of freedom of the individual.
For the resulting program there is hardly any difference though.</p>
<p>In a nutshell you can roughly put it, that Open Source is a description of
software, namely that the source code is accessible and modifiable, and Free
Software is the ethical framework of freedom, which may or may not be the reason
for open sourcing.
To have an unifying term, <tt class="docutils literal">FOSS</tt> can be used, which stands for <tt class="docutils literal">Free and Open
Source Software</tt>, or <tt class="docutils literal">FLOSS</tt>, which adds <tt class="docutils literal">Libre</tt>.
For the user of FOSS-programs, the distinctions in the definitions don't result
in any real difference.</p>
<p>For a FOSS-license to be effective, it has to be issued by the holder of the
patent right.
A program, which is open sourced by breaching its proprietary license, is not a
FOSS program and is therefore not legally usable by the public, and a "license"
attached by the illegally releasing person is not binding in the way, that the
program would somehow be free to use.
Just like a proprietary license remains effective even after illegal release of
the code, a FOSS license remains effective even when e.g. maintenance is
suspended.
An amendment to the license or change of license is possible, but the former
legal use of the software does not retroactively breach the new license terms.
An amendment to the license only becomes effective from the day of the amendment
onwards.</p>
</div>
<div class="section" id="embedded-linux">
<h3>Embedded Linux</h3>
<p>Embedded Linux is an Embedded Operating System, which is based on the Linux
kernel.
There are in general three layers of the system:</p>
<ul class="simple">
<li>the hardware</li>
<li>the kernel and the basic operating system</li>
<li>the individual applications</li>
</ul>
<p>The Linux kernel is Open Source (GPL-v2) and therefore accessible, modifiable,
shareable.
FOSS embedded systems have the advantage of being flexible and can therefore be
tailored to the exact needs, may therefore be lighter and faster, and involve
a multitude of intellectual resources worldwide.
With regular updates an Open Source System in generally more secure than a
comparable proprietary system.</p>
<p>Especially in the commercial environment it may be noted, that with open source
software there exists no vendor-lock-in and with time and practice even a
complete in-house support and maintenance is possible.
Nevertheless, open source systems may still be vulnerable infrastructure, so
support and maintenance by a specialized service provider is recommended.
Just like everybody could build or modify a bike, but only skilled professionals
know, which component is useful for what usecase and how to assemble it, so that
the bike is suitable or the intended usecases.</p>
</div>
<div class="section" id="license-management">
<h3>License management</h3>
<blockquote>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="799x190" href="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_open-source101_schema.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_open-source101_schema.thumb.ec7f1655a4498160445fb191fc3d0e73.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Models of licensing from all rights granted to all rights reserved</p>
</figcaption>
</figure>
</div></blockquote>
<p>With accessible sourcecode there is another characteristic to open source
software: several licenses, which conditions need to be met.
While proprietary software includes licenses as well, it normally is already
cleared during acquisition that the software may be used in the intended way and
only afterwards one gets to check on the program.</p>
<p>It is different for Open Source Software though, as everything lies open from
the start and could be, hypothetically speaking, used by everyone.
If one is allowed to use a program though, that's a different story - the license.
For open source software there often is no vendor to contact and ask, if the
software may be used in the intended way.
Instead, openly accessible licenses are included in the software for the
potential user to read.</p>
<p>There are a handful of widely spread licenses out there, of which the license
terms become well known to every considerate user just by using FOSS-programs.
One could for example name the GPL-v2 and GPL-v3, the LGPL, the BSD-License,
and some more.
But the patent right holder is not bound to these licenses, of course he can just
as fine invent an own license.
That is why one can always encounter code, which is not licensed under some well-
known license, but some quite unique conditions.
Just like with widespread licenses one has also to comply with rather exotic
licenses, if one wants to use the program which is licensed under it.</p>
<p>The most common ways to include a license in a program is either a license-file
(also called copying-file), or a license-header in every file of the program.
It is vital to check on the license conditions for every program one wants to use
and, at least for licenses one is not familiar with, check for compatibility with
the intended use and also with modifications one maybe wants to add the the
existing code.
A breach of license conditions is a violation of the patent right, as in order to
use the program one has to first consent to the license terms.
Therefore the consent to the license terms is implied by use.
If the efforts to a good license management are evident, the reactions to minor
inaccuracies are in general rather clement.
License management should, as always when working with IT, be well documented.
This not only sheds light on what parts still need more care, but also makes
work for a successor or newcomer in the compliance team easier.</p>
<p>Out there are many individuals as well as companies, who have decades of know-how
in license management and who developed some good tools to make the life of the
compliance team easier.
For users of PTXdist there is among others the
<a class="reference external" href="https://www.pengutronix.de/en/blog/2020-02-25-ptxdist_license-report.html">command</a>
<tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>
which gives out pdf-file of the licenses, including license text if traceable, of
all programs used in the BSP.</p>
<blockquote>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="796x463" href="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_open-source101_license-report.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-11_open-source-101/2020-02-11_open-source101_license-report.thumb.d81991a1273d4b89cb9fe765dbc3b033.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>ptxdist make license-report in the directory of the BSP</p>
</figcaption>
</figure>
</div></blockquote>
<p>Generating the license report helps with license management, as it is a quick
(and readable by lawyer) overview, from which one has a good start.
If a license is only stated with its name or if questions regarding compatibility
remain, <a class="reference external" href="https://spdx.org">SPDX</a> (Software Package Data Exchange) is helpful,
as all common licenses are listed there with their respective conditions.</p>
<p>Many developers use scripts to compare license texts, therefore it is strongly
recommended to use the same wording for the same matter.
As there already are many licenses out there, there is for almost every need an
existing license.
Try for example <a class="reference external" href="https://choosealicense.com/">choosealicense</a>.
Whenever possible, one should choose a pre-existing license.
If absolutely required to have an individual license, writing an own license text
should at least not be the time to shine with originality regarding the wording.</p>
</div>
<div class="section" id="so-what-are-the-consequences">
<h3>so what are the consequences?</h3>
<p>FOSS programs and all of their advantages are strictly tied to the compliance of
their respective licenses.
This is simply the state of our legal system, in which all creative work belongs
to the creator.
It falls to the creator of the work, to allow individuals or the general public
to use it.
If a creative work does not state a license, the creator holds all the rights to
it - it is not usable by anyone else.</p>
<p>On the other side there are also some licenses which go even further by
setting additional conditions.
Quite common is the condition that binds the derivative work to the same (or
pre-defined similar) terms that the original work is licensed under.
I'd like to point out the so-called Copyleft licenses, which demand that a
derivative work of a copylefted original work shall be copylefted as well.
This means, that the derivative work needs to be open sourced according to the
respective terms and must include a Copyleft notice, so that derivative work of
the derivative work shall also be licensed under a Copyleft license.
If it excludes commercial use or not is subject to the respective Copyleft
license.
This is called Copyleft Effect.</p>
<p>It is like the Copyleft is playing a trick to Copyright: using the tools of the
Copyright, which were originally meant to exclude to public from using the work,
to instead make it publicly accessible.
Just as we think of hacking as creative handling of technology, Copyleft is to
some extent creative handling of law: one digs deep into the possibilities of the
Copyright and absolutely perfectly uses them to achieve a goal not intended by
legislature, which nevertheless is without doubt legal.</p>
<p>The advantage of this kind of license is the continuous spread of Open Source
Software, so that the society may profit from the growing number of programs.
The apparent disadvantage is, that developers of proprietary code don't get to
profit from that.
The Copyleft effect is to be respected when using copyleft FOSS programs.</p>
<table border="1" class="docutils">
<colgroup>
<col width="12%"/>
<col width="25%"/>
<col width="14%"/>
<col width="18%"/>
<col width="17%"/>
<col width="15%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head"> </th>
<th class="head">Public-Domain related</th>
<th class="head">Permissive license</th>
<th class="head">Copyleft (protective license)</th>
<th class="head">Noncommercial license</th>
<th class="head">Proprietary license</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Description</td>
<td>intellectual property rights not existing,
either due to waiving, expiration or work
not licensable</td>
<td>all rights granted
(including right to
commercial use;
including right to use
different license for
derivative work)</td>
<td>all usage rights granted, but
provisions regarding licensing
of derivative work</td>
<td>grants only rights for
non-commercial usage;
can be combined with
Copyleft</td>
<td>only execution
permitted, possibly
against payment;
no further usage granted</td>
</tr>
<tr><td>Software</td>
<td>Public Domain, Creative-Commons-0 (CC0)</td>
<td>MIT, Apache, MPL</td>
<td>GPL, AGPL</td>
<td>JRL, AFPL</td>
<td>traditional Copyright</td>
</tr>
<tr><td>other creative works</td>
<td>Public Domain, CC0</td>
<td>CC-BY, others</td>
<td>CC-BY-SA, others</td>
<td>CC-BY-NC/CC-BY-NC-SA, others</td>
<td>traditional Copyright</td>
</tr>
</tbody>
</table>
<p>The above listed licenses are to be seen as an incomplete example.</p>
<p>Creative Commons licenses could be used for software, or a software license for
other creative work.
But because these are pre-defined licenses, there might exist problems which
are not typical for the intended usecase of the license.</p>
<p>Copylefted programs are not necessarily a problem when developing proprietary
software, as only derivative works are governed by the license of the original
code.
A creative work is considered derivative according to German Copyright, when the
original work gets mixed up with some new work.
For programs this means, that when creating a joint process, the emerging new
program is a derivative work - the Copyleft of the original program applies.
But when two programs run independently of each other, even on the same system,
they both are considered original works of their own - the Copyleft of
one of the programs does not govern over the other program.
The same applies to incompatible licenses in general.
For embedded-systems using FOSS components it is therefore very important, that
proprietary software runs on the highest layer, which is left out when releasing,
and that the system runs fine even without that part.
Both PTXdist and Yocto contain this layering option.
Developers should ensure that the layering is correctly done.
In no case should the release of the open source components and their derivative
work be withheld to protect the proprietary components.
This would be a breach of license and moreover can be easily avoided.</p>
<p>While licenses are very prominent in the FOSS universe, they are no singularity
of Free and Open Source Software.
Licenses and the consequential license management are always inevitable, to
be permitted to profit from external code at all, be it proprietary or open
sourced code.
License management and Compliance must therefore ensure the compatibility of the
license terms of the programs used, regarding both the compatibility of the used
programs to each other and towards the final product.
But in the end, and maybe with a little help of some already existing tools,
that's not rocket science at all.</p>
</div>
</div>
<p>Computer programs and code can be protected by copyright law.
In Germany this protection cannot be removed.
The German Copyright (German: Urheberrecht) grants all right to whoever created
the work.
Following only this general rule, only the developer could use, modify, share the
code he wrote.</p>
2020-02-25T00:00:00+01:00tag:www.pengutronix.de,2020-02-24:/2020-02-24-blog-license.htmlNow with Creative Commons!2020-02-24T00:00:00+01:00Felicitas Jung<div class="section" id="now-with-creative-commons">
<p>Maybe you already noticed: we now have a footer, which only appears in our blog.
This is because, until now, we released our blog content without licensing, which
means that nobody could use the texts and other information given.</p>
<p>As an open source company this was not our intention!
That is why we now license our blogposts as <a class="reference external" href="https://creativecommons.org/licenses/by-sa/4.0/">CC-BY-SA Version 4.0</a>, also for the past. For code
examples <a class="reference external" href="https://spdx.org/licenses/0BSD.html#licenseText">0BSD-License</a> applies.</p>
<p>You may therefore use and modify all texts, graphics and photos used in our blog,
as long as you comply with attribution and copyleft effect.
Exceptions will be clearly stated.</p>
<p>Have fun and happy hacking!</p>
</div>
<p>Maybe you already noticed: we now have a footer, which only appears in our blog.
This is because, until now, we released our blog content without licensing, which
means that nobody could use the texts and other information given.</p>2020-02-24T00:00:00+01:00tag:www.pengutronix.de,2020-02-19:/2020-02-19-fosdem_2020.htmlFOSDEM 2020 – Recommended Talks2020-02-19T00:00:00+01:00Enrico JörnsChris Fiege<div class="section" id="fosdem-2020-recommended-talks">
<p><a class="reference external" href="https://fosdem.org/2020/">FOSDEM</a> is one of the biggest Open Source
community meetings in Europe and takes place in Brussels at the
<a class="reference external" href="https://www.ulb.be/">Université Libre de Bruxelles</a> every year in
February.
For Pengutronix this is always a good chance to meet developers, discuss
current topics and enjoy some Belgian beer and food.
This year we attended FOSDEM with 15 colleagues.
Here are some talks our colleagues recommend you to see.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1024" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_cover.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_cover.thumb.5a453f99e78de3772ebd67b2ffabfbbb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"><p>You have to get some Belgian food when you go to Brussels.
These waffles with vanilla ice cream were especially tasty!</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_must_eat.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_must_eat.thumb.237fd8334870e5e8ebc2073747ea4ff4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>You can also opt for the more portable waffle-to-go.</p>
<p>BTW: the elevator in the back (Ascenseur des Marolles / Lift van de
Marollen, next to Poelaert square) brings locals and tourists
roughly 20 meters up for a great view over the city - a nice
alternative to a stairway.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="952x1270" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_mall.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_mall.thumb.a65219308681afed9ab9e49fb33226a4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 112px;
"><p>A look into the Royal Saint-Hubert Galleries, a luxuriously
equipped shopping arcade</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><div class="section" id="enrico">
<h3>Enrico</h3>
<p><em>Talks recommended by Enrico Jörns, system integrator co-author of RAUC</em></p>
<div class="section" id="building-iot-solutions-with-eclipse-iot-technology">
<h4><em>Building IoT solutions with Eclipse IoT technology</em></h4>
<p>The talk <em>Building IoT solutions with Eclipse IoT technology</em>
by Sven Erik Jeroschewski did not go into excessive detail
but provided a good overview about what the Eclipse IoT project currently
provides as an open source toolbox for managing IoT (or embedded as some may
call it) devices.</p>
<p>Eclipse <a class="reference external" href="https://www.eclipse.org/hono/">Hono</a> and
Eclipse <a class="reference external" href="https://www.eclipse.org/ditto/">Ditto</a> allow building infrastructure
for communication and interaction between
a large set of heterogenous nodes and gateways together with a generic service
abstraction model.
For deploying and managing the software running on the individual nodes Eclipse
<a class="reference external" href="https://www.eclipse.org/hawkbit/">hawkBit</a> provides sophisticated device and
rollout management to safely deploy updates to a large set of devices.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/ioteclipse/">Schedule and Recording</a></p>
</div>
<div class="section" id="wolfboot">
<h4><em>WolfBoot</em></h4>
<p>As the co-author of the RAUC update framework where I have a lot to do with
bootloaders, atomic system switching and artifact verification, this talk caught
my attention as it implements most of these techniques for non-linux
microcontrollers by using the embedded SSL framework
<a class="reference external" href="https://www.wolfssl.com/">WolfSSL</a>.</p>
<p><a class="reference external" href="https://github.com/wolfSSL/wolfBoot">WolfBoot</a> supports having a
dual-partition setup for microcontroller firmware with a 'swap' partition for
storing some state information.
With its digest and public key cryptography algorithms WolfBoot verifies update
artifacts on the target before installing them.
Together with some extra features, this seems to make it a good choice for
verified and fail-safe updating on microcontrollers that are too constrained to
run a full Linux system.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/iotwolfboot/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="ahmad">
<h3>Ahmad</h3>
<p><em>Talk recommended by kernel hacker Ahmad Fatoum</em></p>
<div class="section" id="howto-build-a-product-with-op-tee">
<h4><em>HOWTO build a product with OP-TEE</em></h4>
<p>During his talk, my colleague Rouven Czerwinski, provides a high level view on his journey to run as much
as possible of his i.MX6 software stack outside the ARM TrustZone secure world, so that even a compromised kernel may
not access system secrets.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_optee.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_optee.thumb.4251d65e2b82d74d6957feb7a026621d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Rouven in front of his slides, talking about CSA SA register settings for i.MX6UL</p>
</figcaption>
</figure>
</div><p>He starts by detailing the ARMv7 Trustzone processor states and how the secure monitor enables communication
between the normal and secure world. He then goes on to describe the OP-TEE secure monitor and his quest
for better i.MX6 upstream support. The goal, per the problem statement in the talk, is to give
system integrators the insight, which side channels they need to secure in order to put upstream
OP-TEE into production.</p>
<p>A slide neatly sums up what needs to be done on bootup: RNG-seeding and trusted OP-TEE loading
and what isolation needs to be maintained going forward: secure RAM, the hardware unique key, secure peripherals
and optionally rollback protection.</p>
<p>Rouven expends some time explaining each of these aspects: the threat model, how to address them,
the concrete hardware facilities offered by the i.MX6, and often the patches he brought upstream
to make it work.</p>
<p>The talk ended with a wish list what he would like to see in future to improve the developer experience
with OP-TEE.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/optee/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="chris">
<h3>Chris</h3>
<p><em>Talks recommended by Chris Fiege, electronics hardware developer</em></p>
<div class="section" id="kicad-an-unusual-state-of-the-union-talk">
<h4><em>KiCAD: an unusual “state of the union”-talk</em></h4>
<p>As in the last years there was a
<a class="reference external" href="https://fosdem.org/2020/schedule/track/open_source_computer_aided_modeling_and_design/">Computer Aided Design devroom</a>
at FOSDEM. Many CAD projects gave some insight into their recent developments and roadmaps.
And so did <a class="reference external" href="https://github.com/stambaughw">Wayne Stambaugh</a> with his talk
<a class="reference external" href="https://fosdem.org/2020/schedule/event/kicad/">KiCAD: Back to the future</a>.</p>
<p>This years talk was special as he laid his focus on KiCADs role for the
Open Hardware movement.
His thesis is that Open Hardware is currently gaining more and more attention
and that KiCAD
will be an important part of this change.
He assumes that KiCAD will gain a bigger share of the market with every new
feature that is added.
And of course Wayne closed the talk with a short outlook on the KiCAD 6 roadmap.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/kicad/">Schedule and Recording</a></p>
</div>
<div class="section" id="the-state-of-ptxdist">
<h4><em>The state of PTXdist</em></h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_ptxdist.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_ptxdist.thumb.b4df37df28394a7af7013fe8e07716ef.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Roland in front of his slides, giving the audience a first look on 'ptxdist menuconfig'</p>
</figcaption>
</figure>
</div><p>In the embedded track on Saturday, Pengutronix embedded artist Roland Hieber
presented us “The State of PTXdist”, starting from the basic principles and user
experience behind <a class="reference external" href="https://ptxdist.org/">PTXdist</a> until ending up with the very latest and useful features.
He gave some useful hints about how to decouple things like board support from
the base system or project-specific from generic changes by
introducing the several 'layering' techniques that PTXdist provided in the past
and got as new features in the latest releases.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/ema_ptxdist/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="jan">
<h3>Jan</h3>
<p><em>Talk recommended by Jan Lübbe, co-author of RAUC and labgrid</em></p>
<div class="section" id="lazy-distribution-of-container-images">
<h4><em>Lazy distribution of container images</em></h4>
<p>While Akihiro Suda's talk focused on how to reduce startup time of containers
caused by having to download the full image (.tar.gz) before starting it,
it also had interesting ideas from my embedded perspective.
By modifying how the tar archives are compressed, they can offer efficient
random access without breaking compatibility with the existing implementations.
The <a class="reference external" href="https://github.com/google/crfs">stargz format</a> starts a new gzip stream
for every tar entry and appends an index entry.
As authentication seems to be out of scope for their use-case
(in large data centers), we can't reuse it unmodified for our use-cases,
but it's a clever hack nevertheless.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/containers_lazy_image_distribution/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="marian">
<h3>Marian</h3>
<p><em>Talks recommended by graphics infrastructure developer Marian Cichy</em></p>
<div class="section" id="reinventing-home-directories">
<h4><em>Reinventing home directories</em></h4>
<p>Talk about the upcoming systemd-homed which aims to manage home directories in a
complete new way. home-directories are a rather out-dated concept which did not
change in the past ~40 years.
The systemd developers argue that home is too much entangled with the rest of
the system, e.g. encryption and decryption is done by the system and not by the user.
The badly designed entanglement can also be seen by /etc/passwd and /etc/shadow,
which should belong to the home-directories, not to the system. A better
encapsulation of the home-directories will also give the possibility to transfer
homes via thumb stick between different computers.
Whether or not the systemd-developers are on the right track, I do not dare to
say yet, but it is interesting to think about the architectural design of
essential linux components and how these may be changed in the future.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/rhdlp/">Schedule and Recording</a></p>
</div>
<div class="section" id="software-distribution-new-points-of-failure-in-a-censored-world">
<h4><em>Software distribution: new points of failure in a censored world</em></h4>
<p>This talk is about software distribution systems like package managers,
language-specific modules like npm or pip, git, flatpak
and so on.
A new hazardous problem is the censorship of said distribution systems or
specific servers. E.g. by blocking npm, as done in China, developers will move
to unofficial repos, raising availability and integrity concerns.
An even more devastating example was an inofficial distribution of xcode, which
included malware that actually integrated itself in every app that was compiled
by this xcode-version.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/sdnpof/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="rouven">
<h3>Rouven</h3>
<p><em>Talk recommended by Rouven Czerwinski, co-author of labgrid</em></p>
<div class="section" id="libliftoff-status-update">
<h4><em>libliftoff status update</em></h4>
<p>In the current DRM ecosystem, only the weston reference compositor employs DRM
planes to provide power savings
and efficient hardware use to wayland clients. Libliftoff intends to unify the
allocation and usage of planes
across different DRM drivers and is intended to be used by wayland compositors.
The talk outlines the currently working features, a roadmap ahead and the
differences between hardware devices used to implement DRM planes.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/kms_planes/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="felicitas">
<h3>Felicitas</h3>
<p><em>Talks recommended by legal trainee Felicitas Jung</em></p>
<div class="section" id="debate-should-foss-licenses-be-enforced-at-all-what-means-are-acceptable-if-so">
<h4><em>Debate: should FOSS licenses be enforced at all? What means are acceptable if so?</em></h4>
<p>The prepared debate was about enforcement of FOSS licenses focused on both
ethical and practical arguments.
The special characteristic of this format is that there are no slides and no
single lecturer.
The speaker represent either a pro or con point-of-view (that is not necessarily their own)
and keep that for the debate.</p>
<p>It included, as against enforcement, that litigation is expensive and
time-consuming and, as software becomes way more crucial, also not necessary
for open source to prevail.
Also most peoples jobs in open source rely on not enforcing, as mistakes happen
and if every mistake would cause financial losses, companies would turn away
from investing in open source.
As pro enforcement the speakers stated, that enforcement does not necessarily
equals lawsuit and more so not criminal prosecution.
As contracts, and therefore licenses, are enforceable, people simply do have
the possibility to enforce.
To me, the most important argument for enforcement is: we should not leave this
field to license trolls.
And against enforcement: judges and lawyers are often not well enough educated
in technical aspects, therefore the outcome is unpredictable and could easily
harm open source licenses.
An interesting, but not unresolvable, point: civil litigation is based on
financial compensation, which can be understood as a personal profit and
therefore would go against non-profit ideal of some notable licenses.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/debate_enforce_licenses/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="michael">
<h3>Michael</h3>
<p><em>Talks recommended by Michael Tretter, kernel hacker and graphics specialist</em></p>
<div class="section" id="the-gdb-text-user-interface">
<h4><em>The GDB text user interface</em></h4>
<p>Tom Tromey gave an update on recent changes to the GDB text user interface.
Most of the session consisted of Tom live-demoing all the cool new features in
a terminal running the TUI.</p>
<p>He started with stating that the code of the TUI was merged in the late
nineties and basically not touched since then. Over the last few years the
code has improved a lot due to almost a rewrite. Also while the TUI was pretty
much static and only extensible by adding code to GDB the situation has
changed dramatically and the TUI now provides more features that you expect
from a modern debugger.</p>
<p>He was especially happy about the ability to add colors to the layouts and
have syntax highlighting for the code window, which improves readability a
lot. Furthermore, he showed how one can add his own layouts to the TUI and
even create new windows in Python. The latter, he demonstrated with a cow
window that lets a cow tell you the current value of a variable which is
implemented in a handful lines of python.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/debugging_gdb_tui/">Schedule and Recording</a></p>
</div>
<div class="section" id="postmodern-strace">
<h4><em>Postmodern strace</em></h4>
<p>Dmitry Levin showed all the new features of <a class="reference external" href="https://strace.io/">strace</a>
since his last presentation at FOSDEM'18.</p>
<p>The main focus of the talk was the new PTRACE_GET_SYSCALL_INFO request for the
ptrace syscall. This request enables strace to retrieve information about the
syscall that caused the stop. One example is the use of 32 bit syscalls on
x86-64 systems, which produced garbled and random tracing output. This is now
working properly. He further showed how to filter syscalls by return status
and how to print stack traces on syscall.</p>
<p>In the end he peeked on upcoming strace features and plans. For one, there are
plans to extend the use BPF for filtering which should make strace a lot
faster. Furthermore, there are plans to make strace output structured output,
e.g., json, which he immediately used to void all questions about improvements
to the strace output like coloring or indentation.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/debugging_strace_modern/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="jonas">
<h3>Jonas</h3>
<p><em>Talks recommended by Jonas Martin, electronics hardware developer</em></p>
<div class="section" id="openwifi-open-source-wi-fi-chip-design-and-linux-driver">
<h4><em>openwifi – Open Source “Wi-Fi chip design” and Linux driver</em></h4>
<p>The openwifi project implements an Open Source FPGA-based SDR (software defined
radio) stack for 802.11a/g and soon n.
It is currently implemented in an FPGA SoC (Zync) with an external RF front end
and is compatible with the mac80211 Linux driver.</p>
<p>Beside providing an interesting insight into the complexity of WiFi the speaker
also asked tough questions like “Should I use this?” which he answered
himself with “No”.</p>
<p>Even if openwifi implements a working WiFi stack it is missing many of the
advanced features like MIMO (multiple input multiple output).
But it is a great tool to understand WiFi better and allows for researchers to
try new ideas.</p>
<p>Beside the interesting topic the talk was also well structured and kept me
quite entertained.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/fsr_openwifi/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="marco">
<h3>Marco</h3>
<p><em>Talks recommended by Marco Felsch, kernel hacker and graphics specialist</em></p>
<div class="section" id="hawktracer-low-end-platform-profiling">
<h4>HawkTracer: low-end platform profiling</h4>
<p>Debugging performance regressions can be hard. It gets even harder if we can't control the
runtime environment, e.g. if you are an app developer. Amazon was faced with the same problem
for their PrimeVideo application which can be deployed on several targets: SmartTVs,
game consoles or FireTV sticks.</p>
<p>The solution for their problem is the in-house developed and now open sourced HawkTracer library.
The library can be easily integrated into C/C++ projects and provides bindings for Python and Rust.
Traces are stored locally or can be streamed to the network. The project provides a tool to convert
the trace events into JSON format so they can be displayed on the host using the
ChromeTracing view, FlameGraph view or by a self-defined viewer.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/debugging_hawktrace/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="michael-1">
<h3>Michael</h3>
<p><em>Talks recommended by Michael Olbrich, maintainer of the PTXdist build system</em></p>
<div class="section" id="gdb-pipelines-convenience-iteration-over-inferior-data-structures">
<h4><em>GDB pipelines – convenience iteration over inferior data structures</em></h4>
<p>I spend a lot of time staring at GDB output and navigating complex data
structures on the GDB command line. So this talk caught my interest.</p>
<p>In his talk “GDB pipelines – convenience iteration over inferior data
structures” Matthew Malcomson introduced “gdb-pipe”, a GDB plugin that
makes it easy to iterate over complex data structures. The talk is a fast
paced overview of all the features and possible use cases. It is a good
starting point before diving in and using gdb-pipe.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/debugging_gdb_pipelines/">Schedule and Recording</a></p>
</div>
</div>
<div class="section" id="philipp">
<h3>Philipp</h3>
<p><em>Talks recommended by Philipp Zabel, Pengutronix graphics and kernel specialist</em></p>
<div class="section" id="the-ttm-memory-manager">
<h4><em>The TTM memory manager</em></h4>
<p>As embedded developers we mostly deal with systems that have a unified memory
architecture, where CPU and GPUs share the same system memory. Therefore,
Christian König's talk about “The TTM memory manager”, which gave a general
overview how kernel graphics memory is managed for GPUs with dedicated video
memory, was new and interesting to me. The talk detailed the current state of
the TTM memory manager, which is used by drivers such as AMDGPU, Nouveau, and
Radeon to determine how video buffers migrate between the memory domains (VRAM,
system RAM, swap) when required, shining a light on its past and current
shortcomings both in architecture and function, as well as pointing out how
those issues have been or will be fixed.</p>
<p><a class="reference external" href="https://fosdem.org/2020/schedule/event/ttm/">Schedule and Recording</a></p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_blinken_lights.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_blinken_lights.thumb.7ca9a1d04392d948b56b13e3817e8124.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Hackers love blinken lights!</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_decoration2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_decoration2.thumb.9af1fec75d975cfce81f8a657a68ceaa.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Brussels has lots of small shops where you can find nearly everything
you need (or don't need) – like these Chanel Pacman figurines.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x766" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_decoration.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_decoration.thumb.7954871792616f94c7f449d8f72936f9.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>I mean, who does not need a fluffy sheep table?</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="952x1270" href="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_grand_place.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-19_fosdem/2020-02-19_fosdem_2020_grand_place.thumb.f97ff167eb11b1c24f2013dce280c90d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 112px;
"><p>Mandatory tourist picture at the Grand Place.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
</div>
<p><a class="reference external" href="https://fosdem.org/2020/">FOSDEM</a> is one of the biggest Open Source
community meetings in Europe and takes place in Brussels at the
<a class="reference external" href="https://www.ulb.be/">Université Libre de Bruxelles</a> every year in
February.
For Pengutronix this is always a good chance to meet developers, discuss
current topics and enjoy some Belgian beer and food.
This year we attended FOSDEM with 15 colleagues.
Here are some talks our colleagues recommend you to see.</p>2020-02-19T00:00:00+01:00tag:www.pengutronix.de,2020-02-05:/2020-02-05-oe_workshop_2020.htmlOpenEmbedded Workshop 20202020-02-05T00:00:00+01:00Enrico Jörns<div class="section" id="openembedded-workshop-2020">
<p>This year, co-located to the <a class="reference external" href="https://fosdem.org/2020/">FOSDEM</a> in Brussels,
the first OpenEmbedded workshop was held.
About 30 OpenEmbedded (and Yocto Project) enthusiasts - from the developers of
the first hour to those still collecting their first experiences - got together
at the <a class="reference external" href="https://digityser.org/">DigitYser</a> tech hub in Brussels.
Pengutronix attended with their two developers most involved in OpenEmbedded:
Jan Lübbe and Enrico Jörns.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_digityser.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_digityser.thumb.3d852cc1aa0f753d5540697983617171.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The <a class="reference external" href="https://pretalx.com/oe-workshop-2020/schedule">schedule</a> for this day, introduced
together with some warm welcoming words by Philip (crofton) Ballister,
announced a bunch of promising talks with a slight focus on container and BSP
topics.</p>
<p>Two longer coffee and one lunch break with sponsored food left enough time for
socializing and discussing topics of interest.</p>
<p>One of this day's talks worthy of special mention is Bruce Ashfield's
"<em>CNCF on the edge: containers++</em>" where he pointed out the entire scale of
containers from the early beginnings of simple chroots to
cloud native while keeping the focus on showing what of this is already
provided by the OpenEmbedded ecosystem, e.g. with
<a class="reference external" href="http://layers.openembedded.org/layerindex/branch/master/layer/meta-virtualization/">meta-virtualization</a>
or the container-based distribution <a class="reference external" href="https://www.toganlabs.com/oryx-linux/">OryxOS</a>.
But he also noted possible pitfalls of this world, like lock-in by relying too
much on a specific runtime.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_csi_talk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_csi_talk.thumb.709d3701f80346772cbc14bd33274783.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>How to actually use OpenEmbedded to build container-based systems of different
complexity was demonstrated by Scott Murray in "<em>Building Containers with
OpenEmbedded: Current State of the Art</em>".
He also sketched how bitbake's multiconfig capabilities can be used to generate
a host system with built-in (generated) container images from a single bitbake
run.</p>
<p>With "<em>How to write a really good BSP layer</em>" Chris Simmonds contributed one of
his famous talks about technology basics where he pointed out the trinity of
<em>distro</em>, <em>machine</em>, and <em>image</em> whose separation is one of the core powers of
the OpenEmbedded build system. He sharpened the mindset and emphasised some
practical guidelines to write a good and minimalistic BSP layer.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_jlu_talk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-02-05_openembedded-workshop-2020/2020-02-05_oe_workshop_2020_jlu_talk.thumb.bb08397d0c728636541ec3cfd8976a2a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Last but not least, Pengutronix CTO Jan Lübbe's talk
<a class="reference external" href="https://pengutronix.de/2020-02-05_oe_workshop_oe-pkcs11_jan_luebbe.pdf">A Common Infrastructure for PKCS#11-Based Code Signing</a>
gave some technical insights in Pengutronix' recent developments to ease the
more and more relevant topic of code-signing with OpenEmbedded.
Code-signing is a key requirement to ensure deployed systems run the expected
software and can be recovered from runtime compromise.
With the classes and helper tools currently being developed in <a class="reference external" href="https://github.com/jluebbe/meta-code-signing">meta-code-signing</a> one can access
keys via PKCS#11 URIs from a crypto token to sign the (barebox) bootloader, FIT
images or RAUC update bundles.</p>
<p>We would like to say many thanks to Philip (crofton) Ballister and the
OpenEmbedded board for organizing this event!</p>
</div>
<p>This year, co-located to the <a class="reference external" href="https://fosdem.org/2020/">FOSDEM</a> in Brussels,
the first OpenEmbedded workshop was held.
About 30 OpenEmbedded (and Yocto Project) enthusiasts - from the developers of
the first hour to those still collecting their first experiences - got together
at the <a class="reference external" href="https://digityser.org/">DigitYser</a> tech hub in Brussels.
Pengutronix attended with their two developers most involved in OpenEmbedded:
Jan Lübbe and Enrico Jörns.</p>2020-02-05T00:00:00+01:00tag:www.pengutronix.de,2019-11-22:/2019-11-22-gstreamerconf.htmlGStreamer Conference 20192019-11-22T00:00:00+01:00Michael Tretter<div class="section" id="gstreamer-conference-2019">
<p>As in the previous year, this year's <a class="reference external" href="https://gstreamer.freedesktop.org/conference/2019/">GStreamer Conference</a> took place in the same
city as the ELC-E. Therefore, Michael Olbrich and Michael Tretter of the
Pengutronix Graphics Team used the opportunity of already being in Lyon to
also attend this conference.</p>
<p>While there were a <a class="reference external" href="https://gstreamer.freedesktop.org/conference/2019/schedule.html">lot of interesting talks</a>, I still
want to point out a few notable talks.</p>
<div class="section" id="gstreamer-state-of-the-union">
<h3>GStreamer State of the Union</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_title.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_title.thumb.224feea27cb8f0c61e3a0519a9f86930.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>Wim Taymans prenting an old draft for a GStreamer logo</p>
</figcaption>
</figure>
</div><p>As last year, the conference was opened by Tim-Philipp Müllers <a class="reference external" href="https://gstconf.ubicast.tv/videos/gstreamer-state-of-the-union_81677/">State of the
Union</a> talk
about recent developments in the GStreamer universe.</p>
<p>The most prominent changes in the last year were the move from Bugzilla to
GitLab including a major rework of the CI infrastructure, the move from
autotools to Meson, which resulted in various improvements to the Meson build
system, and the move from gtk-doc to hotdoc for generating the documentation.</p>
<p>Apart from that, Tim very quickly went across many other changes in the
plugins.</p>
</div>
<div class="section" id="validate-flow">
<h3>Validate-Flow</h3>
<p>Alicia Boya García presented the <a class="reference external" href="https://gstconf.ubicast.tv/videos/introduction-to-validateflow/">validateflow plugin</a> that
allows to record the output of gst-validate-1.0 pipelines on their first run
and compare subsequent runs against the recording. This relieves test authors
from the burden to manually code the expected test output. Instead they can
just verify the output of the first run and compare subsequent runs to the
golden run.</p>
<p>The test author writes the gst-validate pipelines as usual and registers the
validateflow plugin at a pad in the pipeline.</p>
</div>
<div class="section" id="hdr-seeing-the-world-as-it-is">
<h3>HDR: Seeing the World As It Is.</h3>
<p>Another highlight was Edward Hervey's talk on <a class="reference external" href="https://gstconf.ubicast.tv/videos/hdr-seeing-the-world-as-it-is/">HDR video</a>. After
explaining the basics of how colors are represented in computer systems and
why the presentable colors only covers a small part of what the human eye can
actually perceive, he explained how the situation is totally changed by the BT
2020/2100 standards and Wide Color Gamut and Higher Dynamic Range.</p>
<p>However, the technology has not yet reached practice, because of hardware
limitations and incompatibilities. For examples, because of physical limits,
displays cannot show everything that is represented in the Standard and try to
show as much as they can.</p>
<p>He finished that HDR in software is mostly about correctly conveying the used
colorspace, but as HDR is not universally supported yet, there are a lot of
ugly details that must be handled.</p>
</div>
<div class="section" id="pipewire">
<h3>PipeWire</h3>
<p>Wim Taymans gave an update on the recent development on the <a class="reference external" href="https://gstconf.ubicast.tv/videos/pipewire_27214/">PipeWire daemon</a>, especially from a users
perspective. He showed the interaction with Jack applications and Pulseaudio
and presented features that he wants to implement like transports for
controls, MIDI and video processing with Vulkan.</p>
<p>At Pengutronix, we are using Pipewire for sharing video between client
applications and for streaming Weston output via the network. Thus we are
looking forward to the further development of Pipewire.</p>
</div>
<div class="section" id="years-of-gstreamer">
<h3>20 Years of GStreamer</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_ligo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_ligo.thumb.0921c75e7dd55d6a19c1385dcd357645.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>Wim Taymans showing the GStreamer pipeline used in LIGO. The large
image is actually the box in the left image.</p>
</figcaption>
</figure>
</div><p>Wim Taymans also started Friday with a history lesson about the last <a class="reference external" href="https://gstconf.ubicast.tv/videos/20-years-of-gstreamer_78528/">20 years
of GStreamer</a>.</p>
<p>He told the story of GStreamer, how people founded companies around GStreamer
or stopped working on GStreamer at all, how Gnome and Nokia funded GStreamer
and put pressure to stabilize and release versions. Furthermore, he affirms
all of his claims with e-mails of significant events in the GStreamer history.
The highlight of the talk is a dump of the GStreamer pipeline that was used in
the <a class="reference external" href="https://www.ligo.caltech.edu/">LIGO Project</a>.</p>
<p>As a cherry on the cake, the talk ended with a Skype call with Erik
Walthinsen, the founder of GStreamer.</p>
</div>
<div class="section" id="which-network-streaming-protocol-should-i-pick">
<h3>Which Network Streaming Protocol Should I Pick?</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2448x3264" href="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_lunch.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_lunch.thumb.06a0bf085aa66cae0ac1f6ef2178590a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Obligatory picture of the lunch buffet</p>
</figcaption>
</figure>
</div><p>If you want to know more about the entire zoo of <a class="reference external" href="https://gstconf.ubicast.tv/videos/which-network-streaming-protocol-should-i-pick/">streaming protocols</a>,
you should look at Olivier Crête's talk.</p>
<p>He presents the use of every streaming protocol that is supported in GStreamer
and explains their use cases and origins. If you ever wondered about things
like SDI, RTP, SRT, RIST, SIP, WebRTC, HLS, RTSP, and others, just get
enlightened by this talk.</p>
</div>
<div class="section" id="enabling-a-different-piece-of-hardware-a-story">
<h3>Enabling a Different Piece of Hardware, a Story</h3>
<p>Guillaume Desmottes presented Collabora's work on the <a class="reference external" href="https://gstconf.ubicast.tv/videos/enabling-a-different-piece-of-hardware-a-story/">Xilinx Zynq UltraScale+</a>,
which is able to transcode multiple 4k streams at 60 frames per second in
parallel.</p>
<p>They are using Xilinx's downstream driver which exposes the pretty much dead
OpenMAX API to GStreamer. On top of this interface they build the
infrastructure for sub-frame latency using slices, alternate interlacing and
pushing packets before the encoding is done and zero-copy dma bufs.</p>
<p>It would be interesting to see the features as well on the mainline Allegro
V4L2 driver for the encoder.</p>
</div>
<div class="section" id="home-automation-with-gstreamer">
<h3>Home Automation with GStreamer</h3>
<p>Jan Schmidt closed the conference by presenting his ongoing work on his <a class="reference external" href="https://gstconf.ubicast.tv/videos/home-automation-with-gstreamer/">home
automation system</a> that he
is working on for several years now. While he already has multi-room audio in
place, he wants to also control the system by voice. Especially, the system
shall be able to locate the speaker in the house to properly react on
commands.</p>
<p>While his previous experiments did not work out, microphone arrays are freely
available now and he showed the ODAS tool for detecting the speaker and how he
uses libquiet to calibrate the positions of the microphone arrays with respect
to each other.</p>
</div>
<div class="section" id="wrap-up">
<h3>Wrap Up</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_ship.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-22_gstreamerconf/2019-11-22_gstreamerconf_ship.thumb.9cda4cded05c3bda642e4ec9e05814e9.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>A ship in front of L'embarcadere (you don't say)</p>
</figcaption>
</figure>
</div><p>The major topic in the GStreamer universe were fundamental changes to
infrastructure. The move from Bugzilla to GitLab and the GitLab build and test
infrastructure caused a few ruptures, but overall most people seem pretty
content with the move. While the change was pretty straightforward for Linux,
making the Windows builds work was rather complicated which showed up in a few
talks in this years conference.</p>
<p>The attendees at the conference indicate that GStreamer has really arrived in
the professional industry. The various technologies that are used, e.g. <a class="reference external" href="https://gstconf.ubicast.tv/videos/low-latency-in-video-surveillance-system-with-srt/">SRT (secure reliable transport)</a>,
SDI (serial digital interface), and <a class="reference external" href="https://gstconf.ubicast.tv/videos/tv-broadcast-compliant-mpeg-ts/">standard conforming MPEG-TS streams</a>
indicate that the classic broadcast industry is switching to GStreamer and is
preparing it for production use. Further the talks about <a class="reference external" href="https://gstconf.ubicast.tv/videos/pipewire-in-the-automotive-industry/">Pipewire in Automotive</a>
and using <a class="reference external" href="https://gstconf.ubicast.tv/videos/audiovideo-bridging-avb-support-in-gstreamer/">AudioVideo Bridging in Automotive</a>
show that also the automotive industry looks into GStreamer and related
technologies for their use cases.</p>
</div>
</div>
<p>As in the previous year, this year's <a class="reference external" href="https://gstreamer.freedesktop.org/conference/2019/">GStreamer Conference</a> took place in the same
city as the ELC-E. Therefore, Michael Olbrich and Michael Tretter of the
Pengutronix Graphics Team used the opportunity of already being in Lyon to
also attend this conference.</p>2019-11-22T00:00:00+01:00tag:www.pengutronix.de,2019-11-01:/2019-11-01-ats.htmlAutomated Testing Summit 20192019-11-01T00:00:00+01:00Chris FiegeJan Lübbe<div class="section" id="automated-testing-summit-2019">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1368" href="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_embedded.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_embedded.thumb.6187d9ac15a5795dcebfee12acf52fdc.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Hardware for the Live-Demo</p>
</figcaption>
</figure>
</div><p>Jan, Rouven and Chris attended the
<a class="reference external" href="https://events19.linuxfoundation.org/events/ats-2019/">Automated Testing Summit 2019</a>
at the ELC-E in Lyon.
The Summit began with Lightning Tasks on the progress in some projects.
One highlight was Kevin Hilman's talk:
"the bugs are too fast - and why we can't catch them."</p>
<p>He supported his statement with numbers from the syzbot project:
The project currently finds about 3 bugs/day - and the project currently
achieves only 7% code coverage.
Using number of commits and the lines of code in a Linux release he estimated
that we currently have up to 20.000 bugs in every release!</p>
<div class="section" id="real-world-examples-with-labgrid">
<h3>Real World Examples with Labgrid</h3>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x766" href="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_problems.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_problems.thumb.267c90e647474cbbb339795c54f6920c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Jan, Rouven and technicians debugging issues with the projector.</p>
</figcaption>
</figure>
</div><p>After the lightning talks the Summit split up in two tracks.
Pengutronix was able to contribute two presentations:</p>
<p>First
<a class="reference external" href="https://ats19.sched.com/speaker/j.luebbe">Jan</a> and
<a class="reference external" href="https://ats19.sched.com/speaker/r.czerwinski">Rouven</a> showed a few
<a class="reference external" href="https://ats19.sched.com/event/UvpM/labgrid-real-world-examples-jan-lubbe-rouven-czerwinski-pengutronix-ek">Real-world Examples</a>
with Labgrid.
Their presentation started with a short introduction into Labgrid's architecture.
Afterwards they used the venue's WiFi to remote control am Embedded Linux Board
connected to another board in the room to introduce Labgrid's remote infrastructure.
They closed their presentation with demonstrations of test written in pytest
and how Labgrid can be used to interface hardware like USB-Webcams,
Power Supplies and oscilloscopes.</p>
<p>Unfortunately Jan and Rouven had to rush through their presentation after the
projector caused a 15 minute delay.</p>
</div>
<div class="section" id="improving-embedded-testing">
<h3>Improving Embedded Testing</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x766" href="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_chris.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_chris.thumb.a7bb1f5543e6e52c9cbbf6cec9e068e4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Chris during his talk</p>
</figcaption>
</figure>
</div><p>Afterwards Chris continued with his presentation
<a class="reference external" href="https://ats19.sched.com/event/Uvpk/new-ways-out-of-the-struggle-of-testing-embedded-devices-chris-fiege-pengutronix-ek">New Ways Out of the Struggle of Testing Embedded Devices</a>.
In this presentation he showed the current structure of the Embedded Devices
Lab at Pengutronix and what causes the most problems in this lab.
He assumes that automated testing and interactive work at Pengutronix will
increase over time.</p>
<p>He concluded that it is necessary to increase the reliability of the overall
infrastructure to keep costs low and the satisfaction of his fellow developers high.
Chris presented a solution where every Device under Test is controlled by an
individual test controller - a design that has already been implemented by the
<a class="reference external" href="https://wiki.tizen.org/MuxPi">MuxPi</a> and the OpenTAC.
This mostly aims add reducing the error domains and reduce the number of
USB devices used in the lab.</p>
<p>Chris' slides are available in the
<a class="reference external" href="https://elinux.org/File:ATS2019-cfi-embedded-testing_handout.pdf">eLinux Wiki</a>.</p>
</div>
<div class="section" id="wrap-up">
<h3>Wrap Up</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x766" href="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_tim.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-11-01_automated-testing-summit/2019-11-01_ats_tim.thumb.16a4cd79185f973a5692eada36090925.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Tim Bird writing down actions points for the eLinux Wiki</p>
</figcaption>
</figure>
</div><p>The summit was concluded by a panel discussion of Jan,
<a class="reference external" href="https://ats19.sched.com/speaker/pawiecz">Pawel</a> and
<a class="reference external" href="https://ats19.sched.com/speaker/tim.bird2">Tim</a>.
The participants on the summit were happy to identity some consensus in the
community:</p>
<ul class="simple">
<li>At last years ATS the participants agreed to use
<a class="reference external" href="https://github.com/pdudaemon/pdudaemon">pdudaemon</a> as a common layer
to control power switches.
On time for this year's ATS there was a new
<a class="reference external" href="https://github.com/pdudaemon/pdudaemon/releases/tag/0.0.8">release</a>.
This release includes (besides other features)
a direct (aka. <em>daemonless</em>) mode that allows
other tools to use pdudaemon as a library without the need to have an
additional daemon.</li>
<li>It seems like the testing community agreed on the Kernel CI Database
(<a class="reference external" href="https://github.com/kernelci/kcidb">kcidb</a>) as common way to store
test results.</li>
<li>It also seems like the Linux Testing Project (LTP) Metadata-Format
is a good candidate for a common way to describe test-metadata.</li>
<li>We agreed that we want to continue to use the
<a class="reference external" href="https://lists.yoctoproject.org/listinfo/automated-testing">automated-testing mailinglist</a>
provided by the Yocto Project.</li>
<li>Jan encouraged the participants to collect handy hardware used in board farms
around the world in the <a class="reference external" href="https://elinux.org/Board_Farm">eLinux Wiki</a>.</li>
<li>Chris will continue to collect facts on how to design Embedded Devices in a
way that automated testing of this device is possible.
His documentation is available at
<a class="reference external" href="https://github.com/SmithChart/Designing-for-Automated-Testing/">Github</a>.
A readable version is available at
<a class="reference external" href="https://designing-for-automated-testing.readthedocs.io/en/latest/">ReadTheDocs</a>.</li>
</ul>
<p>The participants agreed to upload their slides to the
<a class="reference external" href="https://elinux.org/Automated_Testing_Summit_2019">eLinux Wiki</a>
- as of today the first PDFs are online.</p>
</div>
<div class="section" id="next-meetings">
<h3>Next Meetings</h3>
<p>The last topic was how to continue the Automated Testing Summit.
The participants agreed that a more <em>hackfest</em>-like approach would be
best at the moment.
It was suggested to meet at the Plumbers Conference
(August 25-27, 2020, Halifax, Nova Scotia) for this purpose.
Additionally there will be a
<a class="reference external" href="https://fosdem.org/2020/schedule/track/testing_and_automation/">Testing and Automation Track</a>
at <a class="reference external" href="https://fosdem.org/2020/">FOSDEM 2020</a> in Brussels.</p>
</div>
</div>
<p>Jan, Rouven and Chris attended the
<a class="reference external" href="https://events19.linuxfoundation.org/events/ats-2019/">Automated Testing Summit 2019</a>
at the ELC-E in Lyon.
The Summit began with Lightning Tasks on the progress in some projects.
One highlight was Kevin Hilman's talk:
"the bugs are too fast - and why we can't catch them."</p>2019-11-01T00:00:00+01:00tag:www.pengutronix.de,2019-10-30:/2019-10-30-elce_day3.htmlrsc's Diary: ELC-E 2019 - Day 32019-10-30T00:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2019-day-3">
<p>Day 3 at ELC-E started slowly, almost no interesting talks in the morning,
so after a long evening with community networking, I had some time to
keep up with my blog post. But finally, here is day 3 of my report from
europe's largest embedded linux conference...</p>
<div class="section" id="home-multimedia-and-automation-systems">
<h3>Home Multimedia and Automation Systems</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_multimedia.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_multimedia.thumb.0b928b928d4e186f3ab8a2cb46468663.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>My first talk of the day was Jan Schmidt talking about home automation.
As he is working on GStreamer topics during his daytime job, he looked
at which home multimedia solutions are around that work with GStreamer.</p>
<p>One thing to look at is distributed speakers. In order to synchronize
sound on the speakers, you need precisely synchronized clocks. GStreamer
has a proprietary protocol for that, but there are also NTP and PTP
around for a more standardized mechanism. An open source project using
GStreamer is <a class="reference external" href="https://github.com/thaytan/aurena">Aurena</a>,
synchronizing the different outputs to something below 1 ms. In addition
to audio, it can synchronize video as well, and with that
synchronization accuracy, it is frame synchronized.</p>
<p>The next thing he looked at is cameras: you can basically take Raspberry
Pis or any kind of RTSP based cameras, so this part is easy.</p>
<p>A more challenging task was to use different synchronized microphone
arrays to find out the location of audio sources (realtime microphone
array processing). After some experiments with Android devices, he also
went to a GStreamer based variant, by wrapping some GStreamer code
around the <a class="reference external" href="https://github.com/introlab/odas">ODAS project</a>.</p>
</div>
<div class="section" id="integrate-ros-into-edgex">
<h3>Integrate ROS into EdgeX</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_ros.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_ros.thumb.3bed79b5a272b384da74ea959eca5a06.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>ROS, the Robot Operating System, is an interesting technology if you
have an automation background, however, so far we didn't do much with it
(basically due to cross compiling issues because of their crappy build
system), but it is always a good idea to see what people are doing with
it, so I joined Tejun Chen's talk.</p>
<p>He gave a short introduction into ROS and the EdgeX project, which is a
Linux Foundation project to create an IoT edge platform based on a set
of REST services. They are building quite a large infrastructure, and
one of the goals is to bridge data from ROS into the cloud and use
machine learning and AI techniques on top of that. However, my
impression is not that this project is of any real help for our work on
industrial devices...</p>
</div>
<div class="section" id="running-linux-on-constrained-iot-devices">
<h3>Running Linux on Constrained IoT Devices</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_tinyfication.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_tinyfication.thumb.4c1b34e169ec77b8e5871e24b39e9e57.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Rui Miguel Silva then talked about their activities to create a
reference platform for constrained devices/rich IoT devices. The
motivation for their work is that Linux has a robust networking stack
with wide application support - something that is not necessarily true
with microcontroller stacks. The hardware they are working on is either
standalone Cortex-M style devices or coprocessors in larger systems,
operated with OpenAMP.</p>
<p>One interesting target is the new Cortex-M32, which is used to bring IoT
data to the Microsoft Azure cloud, using enhanced security features.
The team is using Yocto (poky-tiny) and OpenEmbedded for their
tinification activities, currently their CramFS-XIP is about 8 MB. The
read/write filesystem on SPI-NOR flash uses LittleFS, a block-pair
filesystem which is currently being ported to Linux.</p>
<p>In his demo, he showed the boot of a corstone 700 system which basically
boots instantaneously. Currently, there are no SoCs available, just FPGA
based reference platforms.</p>
<p>Taken that Pengutronix has mainlined Cortex-M support several years ago,
it's interesting to see that people actually make use of it - at the
time we mainlined the code, we didn't even have hardware available where
it would have made sense commercially. However, back at that time, the
expectation was that some day there would be hardware capable of running
Linux on controller style hardware and making use of the high quality of
the kernel even on low-end hardware; this is obviously what happens now.</p>
</div>
<div class="section" id="offloading-network-traffic-classification-to-hardware">
<h3>Offloading Network Traffic Classification to Hardware</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_switch.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_switch.thumb.7ec4e9a711817ff56334e726d8b059bb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Maxime Chevallier reported about his activities. He explained how
packages do normally move from the network hardware through the
networking stack up to the applications. However, the preprocessing
steps take a lot of CPU time and can be offloaded into hardware.</p>
<p>In order to offload things, the kernel looks at <em>flows</em> - a group of
packets that have a common source and destination. TC (traffic control)
is the tool to configure traffic shaping, scheduling, policing and
filtering; 'tc flower' can operate on ingress filters and can either use
hardware or software. The main interface to interact with the drivers is
ethtool, and in the future, offloading will also be possible with
netfilter. When offloading flows to hardware, the kernel might not see
any packets any more, so special care needs to be taken that it doesn't
miss important information. Offloading works by classifying traffic in
the switch and then moving it into the right queues. The actual matching
happens on-die; the parsing and classifying against some rules create
the necessary information to decide what finally happens with the
packet. With receive side scaling (RSS), the traffic can be spread
across multiple CPUs, but one needs to make sure the same flow ends up
on the same CPU.</p>
<p>Maxime is working with PPv2, on Marvell SoCs such as Armada 70xx and
80xx. However, it turned out that parts of the classification engines
are so complex that you cannot represent everything with the existing
userspace interfaces, but within the given constraints, many
classification steps can be offloaded to hardware.</p>
</div>
<div class="section" id="authenticated-and-encrypted-storage-on-embedded-linux">
<h3>Authenticated and Encrypted Storage on Embedded Linux</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_cryptostore1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_cryptostore1.thumb.f797537a3073a5b0474a0148f6ce6904.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>In the last slot of the day, Jan Lübbe talked about possibilities for
authenticated and encrypted storage on embedded Linux systems. There are
basically two lowlevel mechanisms that can be used for storing things:
block devices and MTD devices (NAND). On top of that, several mechanisms
exist to authenticate/encrypt things. In all variants, authentication,
encryption and authenticated encryption are necessary; Jan then
explained the different variants that exist in Linux:</p>
<p>dm-verity works between the filesystem and the block layer; it is
read-only and is for example used by Chrome OS and Android for the
rootfs and can be combined with ext4, SquashFS or EROFS. dm-verity works
fine for read-only data (such as the root filesystem).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_cryptostore2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_cryptostore2.thumb.b2c9fc52f9d74aec8c560d0623b885f3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>At the same layer in devicemapper, there is dm-integrity. For each block
of data, there is an additional block of data where the integrity data
can be stored, so the mechanism allows read/write access.</p>
<p>dm-crypt makes use of sector based encryption on block devices. The
mechanism does only crypt, not authenticate, because that would need
additional space. This makes the mechanism the best choice on read/write
block devices (such as laptops). Recently, a mechanism that combines
dm-integrity and dm-crypt was added and makes it possible to also
authenticate the encrypted data. However, unfortunately the mechanism is
not secure against replay attacks, as you can inject an old block.</p>
<p>On filesystem layer, there is fs-verity ("dm-verity for files"); the
system makes sure that every time a file is accessed, it is unmodified.
The main user is Android, for .apk authentication. The mechanism could
be integrated with IMA/EVM to improve performance. Also on filesystem
layer, fscrypt does file-based encryption and allows different keys for
multiple users. There is no authentication and files can be removed
without the key.</p>
<p>On NAND, Pengutronix recently implemented UBIFS Authentication; it makes
use of copy-on-write, which is necessary on NAND ("wandering tree"). The
mechanism currently provides the only fs which authenticates full data
and metadata.</p>
<p>IMA/EVM is there since 2009/2011 and is a layer on top of the
filesystem. It is a mechanism used to make remote attestation possible,
so a remote machine can make sure a device is running the intended
software. However, it is possible to for example overwrite /sbin/init
with /bin/sh (which is also integer)...</p>
<p>One important question is where to store keys in a secure way, so an
attacker does not get access. While this is easy on laptops (where the
user can enter the password), it is more difficult on embedded systems.
Modern hardware often has hardware to wrap keys with fixed per-device
keys or store the key in trusted execution environments on on a TPM.</p>
<p>For developers, it is important to think about the case that locked down
systems have to be debugged somehow; a possible way to do this is to
have a field return mode that implements an authenticated method to
erase the keys for private data and disable verified boot.</p>
<p>As locked down devices tend to become really, really complex, a good
advise is to avoid as much complexity as possible and only select the
necessary components.</p>
</div>
<div class="section" id="end-game-party">
<h3>End Game & Party</h3>
<p>Thanks to Tim Bird, ELC-E always ends with the famous end game, and
afterwards many of the attendees met at the party on a boat on Rhône
river.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_endgame.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_endgame.thumb.5631f2ae0c702acb597407e44b16984a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party1.thumb.20bca325c42d885c05fe781cbad4dcef.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party2.thumb.5cd442b270b8bffa6fad8b4560b20c26.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party3.thumb.6e7d2fe2af955f5e1c31e81cb3c6280d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party4.thumb.7fe9aacc45c1c0a012c4975a302519da.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party5.thumb.08b0fe404e477e97054f127f6af7ae6a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x1600" href="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-30_elce-day-3/2019-10-30_elce_day3_party6.thumb.150fd8527e2d6d518ced85be505a1928.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>Day 3 at ELC-E started slowly, almost no interesting talks in the morning,
so after a long evening with community networking, I had some time to
keep up with my blog post. But finally, here is day 3 of my report from
europe's largest embedded linux conference...</p>2019-10-30T00:00:00+01:00tag:www.pengutronix.de,2019-10-29:/2019-10-29-elce_day2.htmlrsc's Diary: ELC-E 2019 - Day 22019-10-29T00:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2019-day-2">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_linus.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_linus.thumb.e4bf3674798ac6528499066010c5ff7f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>The 2nd day at ELC-E started again with lots of keynotes, so I took the
time to meet people at the sponsor showcase area. It's impressive to see
that more and more of our industry customers come to these community
conferences as well! A better integration of corporate developers with
the Embedded Linux community is definitely a good move.</p>
<div class="section" id="we-need-to-talk-about-systemd">
<h3>We Need to Talk about systemd</h3>
<p>My first talk of the day was Chris Simmonds talking about boot time
optimization for systemd. Chris talked about boot time in the past, but
that time he focused on the bootloader and the kernel. This time he had
a look at systemd ("it is not just an init daemon - it is a way of
life") and started explaining how systemd works, what its units,
services and targets are and how to interact with them.</p>
<p>Boot time optimization means to optimize the time from power-on to the
critical application. You basically do that by making the config of a
generic system less generic: leave out tasks that you don't need, change
the order of tasks. A useful tool to analyze what's going on is
systemd-analyze, which can be used to find out the order of start-up
time and print a tree of the time-critical chain from startup to the
final target.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_systemd.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_systemd.thumb.9e92b7d103d066b758f27394a2c01428.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>The example system he optimized was a PocketBeagle running Debian
Stretch: unoptimized, the system took 1m6.597s to boot up. Using
"systemd-analyze critical-chain" he found out that one of the biggest
delays came from a service waiting for a non-existing serial device,
which took 47s. Changing from graphical to multiuser target and removing
other services that didn't make sense brought the time down to 29.255s,
which was already a reduction by 35s.</p>
<p>Chris outlined that the watchdog is another interesting feature for
embedded usecases (a feature my colleague Michael Olbrich implemented
some years ago at Pengutronix). Being able to resource limit
applications via systemd is also pretty useful for keeping system
stability up.</p>
<p>While Chris definitely does an excellent job when it comes to
introduction level talks, my impression is that boot time optimization
actually starts where his talk ended, so it definitely stayed a little
bit behind my expectations.</p>
</div>
<div class="section" id="socketcan-and-j1939">
<h3>SocketCAN and J1939</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2220x2960" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_marc_oleksij.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_marc_oleksij.thumb.bdad6cf7848ec76c9ee1cf3112a9710b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Marc Kleine-Budde and Ojeksij Rempel from Pengutronix Kernel Team
recently brought J1939 into the Linux kernel - a protocol based on CAN
which is used to control heavy duty vehicles. Marc started with a little
overview of the kernel's CAN support, which is part of the network
stack. Before SocketCAN was there, people had lots of different CAN
interfaces, so several years ago, SocketCAN was started to bring a
unified CAN layer into the kernel.</p>
<p>While the same technology is also used on marine and military
applications, our focus is mainly on agricultural applications (J1939
and ISOBUS). J1939 offers an addressing scheme via "PGNs" and several
other mechanisms useful for transporting engine status information. As
CAN has only a message size of 8 bytes, J1939 offers a way of doing
higher level things, transporting bigger messages (up to 112 MiB with
the Extended Transport Protocol).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_packets.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_packets.thumb.12114d3fa7f92e43578cdc8ccdcaa622.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>The implementation in the kernel was challenging: before we started, the
situation was similar to when SocketCAN was started back in 2006: there
were several incompatible userspace implementations. The userspace
implementations had a lot of overhead, leading to lots of problems
especially with low end embedded ARM processors. There were all kind of
different approaches, from multi process daemons, libraries up to stacks
integrated into the applications with all of the usual maintenance and
overhead issues. The most often seen case have been all-in-one
applications, which have an insufficient separation of infrastructure
and application parts.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_mainline.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_j1939_mainline.thumb.3451402053a5568995304aeff8c9ac77.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>After giving an overview, Oleksij gave an insight into how to write your
J1939 code in a C userspace application and had a short demo that
transferred a 100 kB file over J1939.</p>
<p>The code is already accepted for the 5.4 mainline kernel in the
meantime, and the kernel does also contain some documentation. However,
some challenges stay, like for instance the export of the address
claiming cache to the userspace, a method to handle quirky busses and of
course a lot of test automation.</p>
</div>
<div class="section" id="gardena-iot-gateway">
<h3>GARDENA IoT Gateway</h3>
<p>Andreas Müller and Reto Schneider gave a war story of how they
established an open source setup inside a gardening company: when they
started, Gardena didn't have any experience with electronics and
software at all. Products were developed, and when they were finished,
they were finished. In that situation, they started to develop a gateway
to network their water distribution devices; their challenges were to do
that with a distributed part time team, with a short timeline of one
year from project start to sale.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_gardena.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_gardena.thumb.7739bb42573a158c8d7a5b83aabb162e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Their gateway is based on a Mediatek MT8688 SoC, with 580 MHz MIPS,
integrated WiFi, 128 MB DDR2 RAM and 8 MB NOR and 128 MB SPI NAND Flash,
with a sub-GHz transceiver to the devices. To update the system, they
have split the available space into two slots plus an overlay.</p>
<p>When they started, it happened that someone wanted to get GPL software
for their previous-generation software and failed; then they started
talking to their management; when McHardy started to sue people out
there, the information helped them a lot to speed up proper compliance
processes in the company.</p>
<p>Being open source guys themselves, they started to establish a real open
source policy at Gardena, in the sense that the customers really own the
devices they buy. Before they came into the company, they had a more
closed policy, but it didn't really help, because people just reverse
engineered the devices at that time. There was a long journey until they
convinced everyone in the company to for example make it possible to give
customers open access to the root console on the local serial port.</p>
<p>Regarding mainline status, there was no real support for their device in
U-Boot and Linux. They hired experienced upstream developers to write
proper U-Boot support and to add the missing drivers to the Linux kernel
(such as SPI NAND); then they had to hire the mt76 WiFi maintainer as
well (due to bad test results), but the issues were solved more or less
over a weekend. Finally at the beginning of the gardening season 2019,
they had 4.19 LTS support. Moving to that kernel did also solve some
hard NAND/UBI issues...</p>
<p>Now in October 2019, they are more or less upstream in U-Boot and Linux
and just have a handful of patches left.</p>
<p>Analyzing the project from today's perspective, they found out that the
mainlining cost was less than 10% of the project budget, while greatly
reducing the risk. "Being faster" and "lower risk" were also very
convincing arguments for keeping the management on track :-)</p>
</div>
<div class="section" id="rauc-behind-the-scenes-of-an-update-framework">
<h3>RAUC - Behind the Scenes of an Update Framework</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_intro.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_intro.thumb.4bc3515a39234805b4425eeca4c91911.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Enrico Jörns started his RAUC talk about field upgrading with an
overview about the common setups: typically, our customers at
Pengutronix have a set of embedded devices which either have to be
updated over a network or even manually by USB.</p>
<p>One challenge when updating devices is fail safety: embedded devices
don't have any kind of operator, so after an update, a system usually is
either fully updated or fully bricked, and there is nothing in between.
To avoid bricking of the device, RAUC makes use of redundancy.</p>
<p>RAUC is an image based update system. It started back in 2015 when we
noticed at Pengutronix that each customer started to reinvent updating
over and over again, so we had the impression that that there really was
a demand for a framework. Two days before, we have released version 1.2,
and the project attracted a community of about 50 contributors so far.</p>
<p>The standard case for RAUC is an A+B setup, but for resource
constrained devices there is also A+recovery. RAUC was designed with
security in mind, so all update bundles are signed. It consists of a
host tool (for creating bundles and signing it) and a device side for
actually installing update bundles into the device. There is a D-Bus
interface to communicate with RAUC and to integrate it into
applications, and also an command line interface.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_bootloader.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_bootloader.thumb.801b1baeba1872fb8631b688efe2d89a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>RAUC has a semantics of "update slots", which is everything you can put
an update into. Slots can not only contain root filesystems, but also
for example bootloaders. Images specify what kind of slots they are made
for. The bundles itself are SquashFS, so they are compressed and you can
mount them. You can append information, and we append X.509 (CMS)
signatures. For actually writing an update into a slot, RAUC has update
handlers to deal with the different types of slots. There needs to be a
certain common understanding between RAUC and the bootloader in order to
mark a slot good or bad. Interaction with the bootloader currently works
with Barebox, U-Boot, Grub, UEFI and even custom bootloaders.</p>
<p>Signing bundles and having them checked on the device is a complex story
of its own: RAUC supports even corner cases like resigning of singed
bundles (in case keys reach their lifetime), intermediate certificates in
bundles, multiple signers and hardware security modules (via PKCS#11).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_bundle.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rauc_bundle.thumb.bd3a7f0848345b8c309b03300a2d62c0.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Finally, RAUC has quite many customisation options to support even
exotic special update cases. In order to make sure that only the "right"
firmware is updated into the system, it is possible to use RAUC with
verified boot, with dm-verity and dm-integrity.</p>
<p>A critical operation is updating the bootloader; with RAUC, we currently
support two variants of updating the bootloader in an atomic way, one
on eMMCs and one specifically on NAND on i.MX6.</p>
<p>As a server component, hawkbit can be used to provide bundles to an
embedded device, which will be shown later today at the technical
showcase.</p>
</div>
<div class="section" id="rpmsg">
<h3>RPMsg</h3>
<p>Arnaud Pouliquen then talked about RPMsg to accelerate transition
between multi-SoC and multi-processor SoC solutions. Arnaud works on
STM32MP1, especially on audio and the coprocessor subsystem. The topic
caught my interest, as we are working on MP1 as well recently, and the
coprocessor subsystem offers interesting new options to offload time
sensitive tasks.</p>
<p>While previous generations of hardware had different CPUs communicate
over serial links, I2C or SPI, the MP1 team is using VirtIO, RPMsg and
the OpenAMP framework to talk to the in-SoC coprocessor. On the
coprocessor side, one can use proprietary code as well as open source
operating systems. The team has implemented rpmsg_tty, rpmsg_i2c and
rpmsg_spi drivers which tunnel the respective interfaces via rpmsg into
the Linux system on the Cortex-A inside MP1. On Linux, the RPMsg serdev
drivers are already finished, but I2C/SPI are still missing. The plan is
to upstream the Linux RPMsg client drivers and serial drivers next and
support the coprocessor side in OpenAMP. In addition, they want to
support the virtual serial drivers in Zephyr and MBed.</p>
</div>
<div class="section" id="customize-real-time-linux-for-rocket-flight-control-system">
<h3>Customize Real-Time Linux for Rocket Flight Control System</h3>
<p>In the last talk of the day, George Kang explained how they are using
Linux for flight control for the guidance/navigation/control units in
their rockets.</p>
<p>The controller they built to control the rocket is using an AM43xx CPU
and PREEMPT_RT, and the actual sensor subsystem is operated by a set of
redundant PRUs, each connected to a separate sensor. Data processed by
the PRUs is stored in a piece of shared memory mmapped to the userspace.</p>
<p>The computing model does the sensor flaw reduction, transforms
coordinates and takes the measurements of different sensors into account
in order to increase accuracy. Based on the processed sensor data and
guidance data, the rocket status is manipulated by sending control
commands.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rocket.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_rocket.thumb.f761f8f1277bbb0b4e4a8cefb5beaec5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>They use <a class="reference external" href="https://github.com/nasa/cFS">NASA's core flight system</a>
(cFS), which is used as a base for their control core; it is released as
open source and contains an OS abstraction layer, a core flight
executive unit (cFE) and is based on POSIX. cFS takes care of all the
memory handling and inter process communication (based on message
queues) in a realtime capable way.</p>
<p>Part of their control system is precise time synchronisation, both to
trac mission elapsed time (MET) and to correlate to ground epoch (STCF).</p>
<p>Their realtime I/O bus is EtherCAT, with a cycle time of < 100 µs and a
jitter of < 1 µs, using IgH's Etherlab master library and SDO/PDO
services to communicate process data.</p>
<p>The whole system cannot only operate on a real rocket, but also be
simulated, using hardware-in-the-loop, software-in-the-loop and
process-in-the-loop techniques.</p>
<p>The actual rocket they are building will be started in 2021, so we are
looking forward to how Linux will work in space!</p>
</div>
<div class="section" id="technical-showcase">
<h3>Technical Showcase</h3>
<p>The day ended with the Technical Showcase, and we had a desk were we
demonstrated some of our community projects (RAUC & Etnaviv). Like every
year, it was a good opportunity to get in touch with the attendees and
talk about all kinds of interesting topics!</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase4.thumb.44c8ad5d0588f6a313b099b0b17fc223.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase1.thumb.7fad9fb6f56277b675713148435ffb39.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase3.thumb.9b45455c2b3872670ac9172a24bc9e70.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-29_elce-day-2/2019-10-29_elce_day2_showcase5.thumb.30a66c6ee6b0778893f7add20d8b1e58.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>The 2nd day at ELC-E started again with lots of keynotes, so I took the
time to meet people at the sponsor showcase area. It's impressive to see
that more and more of our industry customers come to these community
conferences as well! A better integration of corporate developers with
the Embedded Linux community is definitely a good move.</p>2019-10-29T00:00:00+01:00tag:www.pengutronix.de,2019-10-28:/2019-10-28-elce_day1.htmlrsc's Diary: ELC-E 2019 - Day 12019-10-28T00:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2019-day-1">
<p>Day 1 at ELC-E started with Kernel-CI being a Linux Foundation project
now. Read more about the talks I heard today in Lyon below...</p>
<div class="section" id="kernel-ci">
<h3>Kernel-CI</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1991x1494" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kevin_greg.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kevin_greg.thumb.51ef117a4681dad359164ed3efbffe39.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>I'm usually not too excited by listening to keynotes at LF events, but
my first talk at this year's ELC-E was the announcement of Kernel-CI
being a LF project now, and they'll sponsor the kernel testing effort
with $500.000 per year.</p>
<p>Testing is an important topic and it is definitely a good move; however,
is it just me who is pretty unhappy with the LF's attitude of "until now
there was a variety of test projects out there, but now community knows
which project to choose"? People have quite different reasons for
testing, and (at least from our perspective having done Linux testing
for 1.5 decades now) experience has shown that it is pretty difficult to
squash all these different perspectives into one framework.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1824x1368" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kernelci.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kernelci.thumb.150534ee13349ee01fe5a1f7fb343bb7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>One of the really good things in open source is diversity: there are
different OSS projects to choose from, and you can learn about their
perspective on the actual problem and make your own choices. Open Source
is about a marketplace where all the good ideas out there can compete
against each other, isn't it?</p>
<p>However, let's see how things will turn out in reality. Having more
focus and resources on testing is a good thing, taken that today's
systems are becoming more and more complex. The <em>real</em> challenge will
be to find enough smart people who actually fix the bugs unveiled by the
testing efforts.</p>
</div>
<div class="section" id="long-term-maintenance-with-yocto-debian">
<h3>Long-Term Maintenance with Yocto + Debian</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_cip.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_cip.thumb.2262ac17478b9d40a7ac0dc79e161fd2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Jan Kiszka and Kazuhiro Hayashi talked about how to long-term maintain
Linux systems for industrial applications and the Civil Infrastructure
Platform. As they are aiming for 10 years of support, one of the
concerns they have about updating to new versions is to get regressions.
They want to have an Open Source Base Layer (OSBL) they can support for
10+ years - this is what the CIP Core group is working on: they have to
care about a SLTC kernel, realtime, security issues, and they have to do
continuous testing on reference hardware. Their concept is based on
Debian, as it has proven to provide a good overall software quality and
stability over a long time.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="960x1280" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kekse1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kekse1.thumb.9365857f548f9221a8523ee51b549ac8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>For the generic profile, they use the tool "Isar", for a tiny profile
"Deby" as a build tool. Deby uses the Debian source packages and uses
Yocto to build a system out of that code base; with that approach, their
minimal system has a footprint of about 2 MB. The meta-debian layer
provides mechanisms to cross build code from the Debian code base.
Currently, they are using the Morty release of Yocto. On the other hand,
"Isar" re-bundles binary components from Debian. The build times for
Isar based systems are around 10 minutes, while Deby builds need about
an hour, but obviously have a broader configurability.</p>
<p>The results of the builds have to be tested. They use GitLab, with build
runners on AWS, and a LAVA instance pulls the results into a testlab and
tests on hardware.</p>
<p>The teams are now focussing on more project-ready features, from
software update to security hardening.</p>
<p>It is interesting for us to see that Debian based build workflows are
recently gaining more speed; besides the variants discussed in this talk,
there is also the Apertis approach out there; however, CIP seems to
actually have already solved some of the customisation problems that turn
up in a project being based on a general-purpose distribution.</p>
</div>
<div class="section" id="fully-automated-power-measurement-solution">
<h3>Fully Automated Power Measurement Solution</h3>
<p>Jerome Neanne and Pascal Mareau then talked about thermo regulated power
management platform (TPMP), a mechanism to control all parameters of a
device-under-test, repeat the test and collect data offline.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_tpmp.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_tpmp.thumb.8ade2210b979de2226fb621c01928fdf.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Their test setup consists of a thermo regulation part with a peltier
element (controlled by a TEC-1091 thermoelectric controller) and a fan,
and a regulator and measurement part based on BayLibre's ACME cape that
offers connections for 8 probes. The whole thing is connected to a host
PC by USB. BayLibre also has HE-10 power probes and other test
equipment.</p>
<p>In contrast to more complex thermal controlling solutions such as
thermal chambers or thermo streams, TPMP is much more desktop and budget
friendly.</p>
<p>Jerome and Pascal showed the influence of the temperature on several
physical parameters of the chip. They found out that the temperature has
a significant impact for example on the power dissipation of the MX8M
they are playing with. The device could be helpful for chip
characterisation, aging tests or general power ci.</p>
<p>On the software side, they have python scripts that can be used to
control for instance the die temperature of the DUT. Currently, the team
is looking into replacing the homebrewn test framework by the ARM
Workload Automation framework and to integrate with LAVA.</p>
<p>During Q&A it turned out that people working on devices would be more
interested on heating the whole device, not only the die. It turned out
that this stays a task for a thermo chamber...</p>
</div>
<div class="section" id="low-latency-deterministic-networking-with-xdp">
<h3>Low Latency Deterministic Networking with XDP</h3>
<p>Markus Karlsson and Björn Tölpel talked about XDP, a mechanism in the
kernel since 4.18 that makes it possible to do socket communication with
high throughput, low latency and determinism. This is interesting for
TSN (time sensitive networking), so interesting for our industrial
activities.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_xdp.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_xdp.thumb.0861f4c44b501215e8cfb2d412ec0962.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Creating an XDP socket is simple: just use PF_XDP on socket(), allocate
buffers and setup a memory mapped ring buffer with a set of socket
options. For each XDP socket, there is at least four ring buffers: Rx,
Tx, Fill and Completion that handle the access to memory between the
kernel and the userspace. As there is direct access to the memory, the
application can process packages without too many unnecessary system
calls. However, with this kind of control over the packets, applications
need to be careful with actually handling them, otherwise it is easy to
make the packet flow stop if the userspace doesn't do the processing
right.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_xdp2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_xdp2.thumb.31d50d7573facb2aaf75765b3af5a31a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>In order to provide XDP support, drivers need to take care of certain
things (such as using NAPI and softirqs to have the kernel and userspace
processing on different CPUs). There is a standard hook directly after
receiving the SKB, but that's just the fallback slow path. If a driver
wants not only to work but to perform, it needs to implement zero copy
mechanisms. Currently, not that many drivers do already support XDP;
most of them are intel drivers; Mellanox and Broadcom are working on it.</p>
<p>Performance measurements show a performance improvement of more than
factor 10...20 in terms of packets/s. Latencies go down from 16 ms to
about 100 µs worst case.</p>
</div>
<div class="section" id="safety-vs-security">
<h3>Safety vs. Security</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_safesecure.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_safesecure.thumb.8bddb40100999a3d5cff130f0308d851.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Jeremy Rosen then reported about his experiences from a project that has
both, safety and security requirements. This is a topic that touches our
customer projects as well, so I joined in order to learn more about how
others tackle this: experience shows that safety experience is to test a
system extensively and then never update again, while security
experience shows that systems need to be updated constantly in order to
avoid security risks.</p>
<p>The focus of safety is to prove that systems are "correct" - however,
you cannot prove that with today's hard- and software (i.e. caches
change behaviour). In the end, every change to the system leads to a
re-certification and a lot of effort. On the other hand, for tackling
down security issues, speed is everything: if a security flaw happens,
you need to be fast to close the issue. So after all, there are
contradicting requirements which cannot be resolved.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kekse2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_kekse2.thumb.9bfdee6248bf99465ec08e749c7ad0cb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Another challenge comes from the fact that it is extraordinarily
difficult to actually update a system in the field, because if something
goes wrong, the device is a brick. You have to deal with devices that
don't have network connectivity, you have to take care of bad blocks,
kernel updates and configuration updates over a long time. There are
even systems that are not allowed to even stop for an update. And,
finally, there are old hardware variants out there that have to be
supported for decades. And as devices are in the hands of someone else,
it might be necessary to crypto-lockdown the devices. Finally, people
are starting to add computers to devices, having no idea how to deal
about all this over a long time.</p>
<p>His conclusion is that you have to choose: Bricked or Pwned? He told
that to his customers, and they have no idea what to do (well, why does
all this sound very familiar to me...?)</p>
<p>One question that needs to be solved is how often to update. If one for
example chooses one update per month, it contradicts with systems that
have 6 months of certification time.</p>
<p>Is there a solution? Probably not, but there are variants to mitigate
the issue:</p>
<ul class="simple">
<li>not all products are safety critical, but all connected products have
to care about security</li>
<li>you need a robust update system</li>
<li>automated testing for re-certification</li>
<li>you should minimize your safety critical perimeter and update it
separately</li>
<li>you could separate safety and security (containers, hypervisors,
hardware separation)</li>
<li>have a plan for security updates, with a maintenance process and a
documented end of life for your product that you communicate to your
customers</li>
</ul>
<p>Finally, I cannot agree more. The talk concluded exactly with what we
tell customers every day...</p>
</div>
<div class="section" id="building-a-network-operating-system-using-linux-and-yocto">
<h3>Building a Network Operating System using Linux and Yocto</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_netos.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_netos.thumb.b492c210f4c0033e2eeca26dfcda2ccf.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>In the last regular talk of the day, John Mehaffey talked about how
Aruba builds ArubaOS-CX (code name "Halon"), based on OpenSwitch and
OPX, the Linux Foundation's network operating system.</p>
<p>The team started small, uses Yocto to integrate platform dependent
features and bases its system on BusyBox in the standard configuration.
They found that updating the kernel provides critical updates, but also
provides a convenient excuse for problems. When updating from 4.4 to
4.9, they found 18 kernel bugs, but it turned out that 9 were actually
design flaws and not something to blame the kernel for. While it was
difficult to convince management about kernel updates in the beginning,
it went more smoothly once people got used to it. Currently they are
using two architectures and 6 variants. As they are addressing modular
rack switches, they have to make sure that the PCI bus stays operable
during CPUs switching their role and switching from an active to a
passive role.</p>
<p>The talk didn't go into the details of how they handled the actual
switch, but it seems like they are doing all that in userspace using a
big set of blob code instead of making use of the kernel infrastructure.</p>
</div>
<div class="section" id="bof-low-spec-devices">
<h3>BoF: Low Spec Devices</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1280x960" href="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_lowspec_bof.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-28_elce-day-1/2019-10-28_elce_day1_lowspec_bof.thumb.5652ce40960cdf4a633fdb6d4908a59f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>My day was concluded with a BoF talking about low spec embedded Linux
devices: they run on just a few megabytes of RAM. What's the reason for
people choosing this kind of low end hardware? There seem to be two:
cost (for very high quantity projects) and ultra low power. The crowd
discussed what the smallest system running Linux is, and it turned out
that a well maintained one in mainline is the STM32F4 with 2 MB onchip
SRAM. Microchip last week released a brand new ARM926 chip with 8 MB
internal SRAM, which is very, very cheap. However, it stays unclear what
you can do with such a system.</p>
<p>One interesting question from the audience was: why should one use Linux
on that low end hardware? It turned out that Linux drivers for
filesystems and networking have lots of corner cases covered, but other
than that, the value of the low spec systems stayed a bit in the dark.</p>
</div>
</div>
<p>Day 1 at ELC-E started with Kernel-CI being a Linux Foundation project
now. Read more about the talks I heard today in Lyon below...</p>2019-10-28T00:00:00+01:00tag:www.pengutronix.de,2019-10-27:/2019-10-27-RAUC-1.2.htmlRAUC v1.2 Released2019-10-27T22:46:00+01:00Enrico Jörns<div class="section" id="rauc-v1-2-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.2 release of RAUC</p>
</div>
</div>
<p>Right before the ELC-E starts tomorrow, we used the time in the hotel to
bake a brand new RAUC release for you (and your embedded devices)!
Well, here it is: RAUC v1.2</p>
<p><a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.2">https://github.com/rauc/rauc/releases/tag/v1.2</a></p>
<p>Are there any good reasons for updating to it? Of course!
As always there is a good mix of bug fixes and new features your
setups will benefit from:</p>
<p>We fixed some leaking file descriptors that may have caused RAUC to be
killed with ‘Too many open files’ errors when executing a significant
number of 'rauc status' or 'rauc install' actions without reboot.</p>
<p>RAUC now also will abort earlier in case of errors that are detectable
before actually entering the atomic region and writing slots. This
allows RAUC to fail earlier without leaving behind a disabled slot group
with incomplete contents.</p>
<p>Another noteworthy change is that we changed the default of one of
RAUC's most discussed optimization features: The skipping of slot
updates where the intended and the current slots hash matches exactly.
The past showed that this behaviour was often perceived as 'unexpected'.
It is now disabled by default but may be explicitly enabled with
<tt class="docutils literal"><span class="pre">install-same=false</span></tt>.</p>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li>v1.2 <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-2-released-oct-27-2019">changes list</a></li>
</ul>
</div>
</div>
<p>The command line interface received some new features and polishing so
that we now have a more structured status output and an optional
installation progress, activatable with <tt class="docutils literal">rauc install <span class="pre">--progress</span> <span class="pre">[...]</span></tt>.</p>
<p>For devices that boot from the first MBR partition, RAUC now also
supports atomic bootloader updates by manipulating the MBR to switch
between redundant partition regions.</p>
<p>Thanks to all contributors since v1.1: Bastian Krause, Ellie Reeves, Enrico
Jörns, Fabian Knapp, Gaël PORTAY, Jan Lübbe, Leif Middelschulte, Michael
Heimpold , Stephan Michaelsen , Thomas Hämmerle, Thorsten Scherer, Tobias
Junghans, Uwe Kleine-König</p>
</div>
<p>Right before the ELC-E starts tomorrow, we used the time in the hotel to
bake a brand new RAUC release for you (and your embedded devices)!
Well, here it is: RAUC v1.2</p>2019-10-27T22:46:00+01:00tag:www.pengutronix.de,2019-10-27:/2019-10-27-elce_announce.htmlELC-E 20192019-10-27T00:00:00+01:00Robert Schwebel<div class="section" id="elc-e-2019">
<p>Tomorrow, Embedded Linux Conference Europe 2019 starts in Lyon, france,
and as every year, Pengutronix crew uses this opportunity to present our
recent open source activities and to meet other Linux and OSS
developers. Here's the list of our talks during the next days:</p>
<div class="section" id="embedded-linux-conference-europe-talks">
<h3>Embedded Linux Conference Europe Talks</h3>
<ul class="simple">
<li><a class="reference external" href="https://osseu19.sched.com/event/TLNC/introduction-to-the-j1939-kernel-stack-marc-kleine-budde-pengutronix?iframe=no&w=100%&sidebar=yes&bg=no">Introduction to the J1939 Kernel Stack:</a>
Marc Kleine-Budde and Oleksij Rempel talk about our recent activities
to make Linux handle CAN communication on tractors and other heavy
duty vehicles (Tue, Oct 29 2019, 12:20, Forum 1)</li>
<li><a class="reference external" href="https://osseu19.sched.com/event/TLHy/behind-the-scenes-of-an-update-framework-rauc-enrico-jorns-pengutronix-ek?iframe=no&w=100%&sidebar=yes&bg=no">Behind the scenes of an update framework: RAUC:</a>
Enrico Jörns will discuss the main design decisions in RAUC and the
latest activities to robustly update Linux systems in the field
(Tue, Oct 29 2019, 15:15, Forum 3)</li>
<li><a class="reference external" href="https://osseu19.sched.com/event/TLL1/authenticated-and-encrypted-storage-on-embedded-linux-jan-lubbe-pengutronix-ek?iframe=no&w=100%&sidebar=yes&bg=no">Authenticated and encrypted storage on embedded linux:</a>
Linux provides many building blocks for authenticating and/or
encrypting data and code on storage devices. In his talk, Jan Lübbe
discusses the different variants for embedded usecases
(Wed, Oct 30 2019, 16:15, Forum 1)</li>
<li><a class="reference external" href="https://events19.linuxfoundation.org/events/embedded-linux-conference-europe-2019/features-add-ons/technical-showcase/">Technical Showcase:</a>
On Tuesday evening, there is the Technical Showcase and we
demonstrate the latest activities of RAUC (robust field
upgrade) and Etnaviv (open source 3D graphics on i.MX8M).</li>
</ul>
</div>
<div class="section" id="automated-testing-summit-talks">
<h3>Automated Testing Summit Talks</h3>
<ul class="simple">
<li><strong>Labgrid: Real World Examples:</strong>
Rouven Czervinski and Jan Lübbe demonstrate how we control embedded
boards in our automated testlab at Pengutronix
(Thu, Oct 31 2019, 11:00, Rhone 3AB)</li>
<li><strong>New Ways out of the struggle of testing embedded devices:</strong>
Chris Fiege will discuss the hardware control side of our testlab
at Pengutronix and talks about our experiences
(Thu, Oct 31 2019, 11:50, Rhone 3AB)</li>
</ul>
</div>
</div>
<p>Tomorrow, Embedded Linux Conference Europe 2019 starts in Lyon, france,
and as every year, Pengutronix crew uses this opportunity to present our
recent open source activities and to meet other Linux and OSS
developers. Here's the list of our talks during the next days:</p>2019-10-27T00:00:00+01:00tag:www.pengutronix.de,2019-10-25:/2019-10-25-launch-linux-automation.htmlLaunch of Linux Automation GmbH2019-10-25T00:00:00+01:00Chris Fiege<div class="section" id="launch-of-linux-automation-gmbh">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2329x2619" href="https://www.pengutronix.de/media/blog/2019/2019-10-25_linux-automation-launch/2019-10-25_linux-automation-rocket.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-25_linux-automation-launch/2019-10-25_linux-automation-rocket.thumb.3f850eb06eba957453267d1ac066916c.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>The brand new Linux Automation logo - off to new Horizons ;)</p>
</figcaption>
</figure>
</div><p>We proudly present our new spin-off
<a class="reference external" href="https://linux-automation.com">Linux Automation GmbH</a>
for selling hardware products, like
<a class="reference external" href="https://www.pengutronix.de/en/blog/2017-10-23-usb-sd-mux_Intro.html">USB-SD-Mux</a>.</p>
<p>As you know, Pengutronix has always been a software company dedicated to
bringing high-quality mainline kernel and userspace code to our customers.</p>
<p>But we also operate on bare PCBs every day, and there was always this recurring
impulse to develop some hardware we wished for in our daily work
- especially when it comes to automating tests on hardware.
Wouldn't it be nice
to automatically switch µSD-Cards, USB-ports, network interfaces?
And surely we aren't the only ones who need those tools?</p>
<p>When we announced the USB-SD-Mux back in 2017, the feedback was overwhelming
and lots of people contacted us wanting to know how to purchase one.
With this in mind <em>Linux Automation GmbH</em> was founded.</p>
<p>We are aware that you waited for this moment as much as we did, and now
the first batch of USB-SD-Muxes is finally ready for shipping.</p>
<p>Don't hesitate, register in our <a class="reference external" href="https://shop.linux-automation.com">shop</a>
and be one of the first to get one from the initial (limited) batch! ;)</p>
<p>Don't forget to subscribe to the RSS feed over at <a class="reference external" href="https://www.linux-automation.com">www.linux-automation.com</a>
and to follow our <a class="reference external" href="https://twitter.com/AutomationLinux">Twitter</a>
to stay up to date with new developments.</p>
</div>
<p>We proudly present our new spin-off
<a class="reference external" href="https://linux-automation.com">Linux Automation GmbH</a>
for selling hardware products, like
<a class="reference external" href="https://www.pengutronix.de/en/blog/2017-10-23-usb-sd-mux_Intro.html">USB-SD-Mux</a>.</p>2019-10-25T00:00:00+01:00tag:www.pengutronix.de,2019-10-18:/2019-10-18-tig-completion.htmlOptimising tig's bash completion by a factor of 10002019-10-18T00:00:00+01:00Roland Hieber<div class="section" id="optimising-tig-s-bash-completion-by-a-factor-of-1000">
<p>Has this ever happened to you?</p>
<pre class="literal-block">
~/linux.git (master) $ tig log v5.4-<tab>
[swearing]
[fetching another cup of tea]
[some more swearing]
[coworkers looking funny at you]
[1 minute later]
~/linux.git (master) $ tig log v5.4-rc1
</pre>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1923x1081" href="https://www.pengutronix.de/media/blog/2019/2019-10-18_tig-completion/2019-10-18-tig-all.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-10-18_tig-completion/2019-10-18-tig-all.thumb.f7814fc85bfe6a5f9872e7a6854f4b6a.png"/>
</a><figcaption itemprop="caption description" style="
width: 350px;
"><p>tig, the ncurses labyrinth generator</p>
</figcaption>
</figure>
</div><p>Until yesterday, the bash completion for <a class="reference external" href="https://jonas.github.io/tig/">tig</a>,
the ncurses git viewer, was horribly slow in large Git repositories.
This mostly stemmed from the fact that it was forked off from the upstream git
bash completion a few years ago, and never updated since.
Back then, the git bash completion itself was slow in those cases,
but since then upstream had more eyeballs and people power to optimise its
completion for those large repos, like the linux repo.</p>
<p>The problem gets worse once you consider that bash completions can not be
aborted by a Ctrl-C, which means that your current shell is basically unusable
for a minute while you wait for the completion to complete.
On a heavily loaded build server, the runtime can easily exceed 2 minutes.
Add to that the frustration when you realise you shouldn't have accidentally
pressed Tab…</p>
<p>The corresponding <a class="reference external" href="https://github.com/jonas/tig/issues/795">bug report for tig</a>
has been existing since March 2018, and that tab has been open in my browser for
some time now… so let's see how to solve this.
(A quick look on the <a class="reference external" href="https://xkcd.com/1205/">corresponding xkcd</a> shows I can
spend about 4 hours on that topic… :-))</p>
<p>A preliminary evaluation already shows how much faster we can be.
Compare the runtime of tig's file completion function with the one from git:</p>
<pre class="literal-block">
linux.git (master) $ time __tig_complete_file
real 0m29.363s
user 0m27.805s
sys 0m1.600s
linux.git (master) $ time __git_complete_file
real 0m0.063s
user 0m0.051s
sys 0m0.012s
</pre>
<p>Holy cow, that's already a factor of 466!
And these times are mostly reproducible, so caching issues can be ruled out.</p>
<p>Since tig takes basically the same command line options as git-log and
git-diff, the easiest solution is to reuse git's own completion here,
so that's what I did in <a class="reference external" href="https://github.com/jonas/tig/pull/960">Pull Request #960</a>.
With that, we also don't need to fix tig's completion whenever git commands get
shiny new options, and we also pull in all other optimisations from git's
completion.</p>
<p>That being said, here is a comparison of the old and new version of the full
completion function in an extreme case, showing a speedup of 1863:</p>
<pre class="literal-block">
linux.git (master) $ uptime
16:45:52 up 36 days, 3:33, 224 users, load average: 24.17, 38.87, 31.21
# The old completion:
linux.git (master) $ time COMP_WORDS=("tig log") COMP_CWORD=2 _tig
real 2m1.145s
user 1m40.379s
sys 0m1.347s
# The new completion:
linux.git (master) $ time COMP_WORDS=("tig log") COMP_CWORD=2 __git_wrap_tig
real 0m0.127s
user 0m0.085s
sys 0m0.024s
</pre>
</div>
<p>Has this ever happened to you?</p>2019-10-18T00:00:00+01:00tag:www.pengutronix.de,2019-08-16:/2019-08-16-rauc_maintenance.htmlSafe and Secure Field Updates of Embedded Linux Systems2019-08-16T00:00:00+01:00Enrico Jörns<div class="section" id="safe-and-secure-field-updates-of-embedded-linux-systems">
<p>In this blog post I would like to address the challenges of performing
unattended and verified updates of embedded Linux systems in the field using
open source software and workflows.
While updating is not a end in itself, a second part of my
considerations goes even further and also works out the necessities and
possible workflows for keeping the software stack of a project up to date and
thus either preventing security issues or at least enabling a short reaction
time in case of severe CVE'S discovered.</p>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_rauc_maintenance_EW2019_slides.pdf">Talk slides</a></p>
</div>
</div>
<p>This blog post is mainly based on a talk and paper I prepared for the Embeeded
World Conference 2019 in Nürnberg.</p>
<div class="section" id="introduction">
<h3>Introduction</h3>
<p>The ability to deploy software updates is an indispensable requirement for a
modern state-of-the-art embedded platform. Regardless of whether due to
critical CVEs, functional bugs, adaption to new requirements or for adding new
features to stay competitive on the market, the software of these systems needs
to be constantly adjusted.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1825x987" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_ota-updates.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_ota-updates.thumb.9d721c3d593503f29a0391a2a9fbfdfd.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>However, having an update service running on a device also adds both a new
attack vector as well as a risk for bricking the device during or after an
update. Thus implementing it needs certain care to make it robust and secure.</p>
<p>Nowadays the availability of several open source update tools has finally
overcome the times of immature and semi-secure hand-coded scripts and allows to
focus also on more advanced topics. But, it is also still essential to know and
understand the basic requirements and possible pitfalls very well to make the
right decisions regarding the overall platform and workflow design.</p>
<p>This paper first addresses the principles of redundant image-based update
concepts followed by fundamentals of fail-safe updating and runtime handling.
Then it shows how to deal with security-related questions as authentication and
strategies and workflows for preventing and quickly fixing CVEs in the field.
Finally it provides a short overview over RAUC as one possible available open
source implementation of an update framework.</p>
</div>
<div class="section" id="image-based-updating">
<h3>Image-Based Updating</h3>
<p>Updating the software of an embedded system differs significantly from updating
a server or a PC. Embedded devices often allow none or only fairly limited user
interaction, making them unsuitable for package-based updates as one would use
on a PC or a server. Package-based updates can lead to conflicts or
inconsistent states that require human intervention. But the most relevant
drawback of conventional package-based updates is that these can lead to
combinations of libraries and applications on the target that were never tested
before and thus are likely to fail.</p>
<p>The decision about which alternative method to choose for performing updates
also depends on the considerations which kinds of failures one expects and
needs to protect against and which parts one expects to need to be updated.
Container-based updates for example would allow to flexibly exchange the upper
layers of a system, but prevent one from being able to fix bugs in the host
system or the kernel. Additionally, this assumes that the underlying file
system never becomes corrupted, which also is a critical risk for file-tree
based update mechanisms.</p>
<p>Thus, the only way allowing to fully replace the old system with a well-defined
new software state while being almost immune against file system corruption
etc. is to use full image-based updates. This means that one always installs
the entire root file system and kernel of the new Linux system. This can either
be done by writing a pre-generated file system image to the device or by
formatting the device and unpacking the content of an archive to a newly
initialized filesystem.</p>
<p>In the following descriptions we will consider image-based updates only.</p>
</div>
<div class="section" id="redundancy-and-atomicity">
<h3>Redundancy and Atomicity</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1097x1143" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_rauc_maintenance-atomicity-redundancy-seq1-4.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_rauc_maintenance-atomicity-redundancy-seq1-4.thumb.1e253cb49667fd0bf4214e46a0e28a5a.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Flow for atomic update with redundant partitions (A/B update)</p>
</figcaption>
</figure>
</div><p>For being fail-safe the update process must be atomic. This means that an
update is either considered fully installed or not, independent of possible
interruptions. There must not be a critical phase in which e.g. a sudden power
loss will lead to a bricked device. This means, that if anything goes wrong
during the processing and writing of the update, the currently running system
must remain unaffected.</p>
<p>The implication on such a system is that it must be designed to be redundant;
either by having one dedicated update/recovery partition and one system
partition (A/recovery scenario) or by using a fully-redundant set of system
partitions (A/B scenario).</p>
<p>The A/B case nowadays is the default on systems that are not storage-limited as
it adds multiple benefits; a) an update can be performed entirely in the
background while the main application proceeds; and b) in case of a failure in
the currently running system one has the option to fall back to an older system
state on the other partition to guarantee service availability. In addition to
these 'standard' cases also more advanced configurations such as A/B/recovery
or combining the redundant system partition with a separate but linked
redundant application partition are possible.</p>
<p>Updating redundant partitions atomically requires the system to have a single
dedicated switching point that allows moving from the updating system to the
updated one at the very end of the update process.</p>
<p>For image-based updates, this switching is normally done in the bootloader and
must itself be atomic. This is why the bootloader plays an important role in a
redundant update concept and must be chosen and configured carefully.</p>
<p>Although the bootloader is normally the only component of such a system that is
not fully redundant, one may also come in situation where a bootloader update
cannot be avoided. Assuming the bootloader was well-tested before, the most
critical point for a bootloader update is the step of actually writing the
bootloader which is often vulnerable to power loss.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2564x1205" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_emmc-bootloader-update.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_emmc-bootloader-update.thumb.59ae6c0a53967e7e4b6c8631a0686fad.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"><p>eMMC-enabled atomic bootloader updates</p>
</figcaption>
</figure>
</div><p>An update design always also depends on the abilities and limitations set by
the used hardware. The bootloader update scenario is a fitting example how a
good hardware design can improve or simplify the update design. When using an
eMMC as storage it is possible to also perform bootloader updates atomically:
An eMMC provides two dedicated built-in boot partitions boot0 and boot1 that
are selected (by supporting ROM loaders) depending on a switchable flag in the
eMMC's extCSD register. Thus when having boot0 partition active, one can safely
write the updated bootloader to the boot1 partition and switch it to be the
active boot partition only after successful writing. If writing fails or is
interrupted, the ROM loader will continue to boot from the valid boot0
partition.</p>
<p>Using eMMC in general adds several benefits to embedded systems compared to raw
NAND. Its full abstraction as a simple block device hides all internal quirks
for the flash and allows using well-proven standard Linux file systems such as
ext4 without having to care about wear leveling, etc.</p>
</div>
<div class="section" id="detecting-and-handling-runtime-failures">
<h3>Detecting and Handling Runtime Failures</h3>
<p>As important as making the update process itself robust is to also prepare the
system for being fail-safe against runtime issues. Regardless of how
intensively a new software state was tested, it may nevertheless trigger errors
in the field that were not covered by testing, e.g. because of specific
environmental conditions.</p>
<p>The most frequent class of potential failures is that the device hangs during
the boot process or that a software component in the running system exits or
hangs. These hangs can be detected and handled by using hardware and software
watchdogs. A watchdog is like a simple timer that must periodically be
triggered. If the system or a systems component hangs and the watchdog is not
triggered anymore for a defined period of time, the watchdog will force the
entire system to be reset and booted again.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1754x600" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_failure-detection-watchdog2.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_failure-detection-watchdog2.thumb.b78dd33cb2f12d71e1bf23ff96e60eca.png"/>
</a><figcaption itemprop="caption description" style="
width: 400px;
"></figcaption>
</figure>
</div><p>In a redundancy boot setup this reset also allows to perform a fallback to the
old system in case of too many failures in the new one. Bootloaders normally
can maintain some kind of an attempts counter for this that will be decremented
on each boot and reset only when the system was booted successfully. If the
system failed booting several times, this counter will become zero and the
bootloader switches to boot the fallback system. While most bootloaders require
scripting for this, the barebox bootloader provides a dedicated redundancy boot
framework called
<a class="reference external" href="https://barebox.org/doc/latest/user/bootchooser.html">bootchooser</a>
backed by a storage backend that allows to
atomically change one or several variables. A similar mechanism is also
provided by <a class="reference external" href="https://github.com/systemd/systemd/pull/9437">systemd-boot</a> and
U-Boot provides a simple boot counter.</p>
<p>For detecting and handling process hangs and failures in the running system,
the systemd init system, which is nowadays standard on most Linux
distributions, provides a huge and powerful set of tools to decide on when and
how to restart services or applications. It also provides a
<a class="reference external" href="http://0pointer.de/blog/projects/watchdog.html">watchdog multiplexer</a>
that allows to have unlimited software watchdogs backed by only
a single hardware watchdog allowing to monitor all safety-critical
applications.</p>
</div>
<div class="section" id="authentication">
<h3>Authentication</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1235x1404" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_authentification-transport-vs-artifact.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_authentification-transport-vs-artifact.thumb.b8863d94df571542390e7f17d9258228.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Transport authentication vs. artifact authentication</p>
</figcaption>
</figure>
</div><p>Having the ability to update the entire system to a desired software state also
enforces to prevent unauthorized persons from accidentally or intentionally
deploying wrong or malicious software to the device. While the first case is
mainly a safety issue and can be prevented by simple mechanisms as comparing an
identifier that must match between the target and the update preventing
unauthorized access is quite more complex.</p>
<p>Authentication always requires well-proven security implementation and
knowledge of the possible scenarios one needs to protect against to also use it
properly. What is true for most parts of a system is the most important for
security: one should not implement cryptography on one's own as this is highly
prone to introducing mistakes. Instead one should use well-proven standard
libraries such as OpenSSL.</p>
<p>Despite more and more systems becoming connected over networks, the classical
USB stick update case is still a very common scenario. Allowing to provide
verification for both network and USB case one cannot rely on encryption
protocols like TLS. A proper solution to this can be to use X.509 cryptography
(which is also the base for TLS) in the form of CMS (Cryptographic Message
Syntax) as signature format and directly sign the update artifact.</p>
<p>With X.509 cryptography one gains the flexibility to cover a wide range of
requirements, from a simple self-signed certificate to advanced public key
infrastructures (PKI) with multiple signers, certificate revocations lists
(CRLs) and much more. Some base considerations targeting this topic are
differentiation between development and release key, the usage of per-device
keys, etc.</p>
</div>
<div class="section" id="software-maintenance-cycle">
<h3>Software Maintenance Cycle</h3>
<p>When thinking about security, one has to have in mind that one of the most
important aspects to keep the system secure is the presence of the update
solution itself. It allows to deploy fixed software and thus lowers the risk of
the device being compromised. But, this is only true if one is also able to
deliver updates quickly if required.</p>
<p>By using Linux, most of the software on the platform will be open source. And
thus, most of the fixes for CVEs and other bugs will not be provided by the
platform developer but are contributed continuously to the different upstream
projects by the open source community.</p>
<p>Having a maintenance strategy that follows these upstream projects in regular
intervals and encourages submitting modifications made to software components
back to the upstream projects as early as possible will keep the custom stack
of modifications small and assures these roundtrips can be performed with
manageable effort each. This strategy both ensures collecting existing bugfixes
as well as enables to apply future urgent bug fixes within a minimum amount of
time and effort. Embedded Linux build systems such as Yocto, PTXdist or
Buildroot already do most of this version bumping work so that following their
releases will already do 90% of the job. Together with an appropriate revision
control system, such as Git, these build systems also enable to fully persist
and rebuild any software state. Reproducability is a key requirement for
debugging issues that arose in the field for a specific software version.</p>
<p>If one instead picks a fixed software state in an early project phase and
continues developing on this same state several years until finally deploying
it into the field this results in the software being already quite obsoleted at
that point. Despite most projects provide stable and also long term stable
(LTS) updates, one has to bear in mind that these periods are usually much
shorter than the sum of development plus product life time. Thus updates will
not be available anymore soon after deploying the software. Another important
aspect is that most of the bugfixes that are part of an LTS were discovered and
fixed from a much more recent software version where they have far better test
coverage by people that use it. Thus backporting patches to an older software
state does not automatically mean more stability!</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3108x1647" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_ci-testing-deploy-reproduce.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_ci-testing-deploy-reproduce.thumb.47cc2cde08728e117ac25d7f59dcaeca.png"/>
</a><figcaption itemprop="caption description" style="
width: 500px;
"></figcaption>
</figure>
</div><p>A good advice is to keep the entire software stack up-to-date during the
development phase of the project, where minor issues still can be quickly fixed
without a larger impact. This ensures having a recent software stack when
releasing the embedded Linux platform.</p>
<p>Another important aspect for easing maintenance cycles is to have an automatic
CI-like full system test setup driven by automation servers like Jenkins1 and
hardware control frameworks such as lava2 or labgrid3. This allows to detect
potential issues during platform upgrades quite quickly and also lowers the
probability of missing bugs that first appear in the field where it is more
expensive to fix them.</p>
</div>
<div class="section" id="data-handling">
<h3>Data Handling</h3>
<p>An important aspect to also think about when designing a redundant update
system is on how and where to store application and configuration data. Many
systems use a dedicated data partition separate from the root file system for
storing all or parts of this information. This can either be one single
partition for both A and B systems or it can itself be redundant with a fixed
allocation of each data partition to either belong to the A or B system.
However, in both cases one might need to migrate data from one to the other
system and application version. For the redundant case it must be defined if it
is valid to operate on old data or not, etc. The actual decisions that are
required in that context are always highly use case-specific.</p>
</div>
<div class="section" id="open-source-update-frameworks-rauc">
<h3>Open Source Update Frameworks: RAUC</h3>
<p>Over the last years different open source update frameworks came up, each with
slightly different focus and capabilities. The most visible ones are mender,
swupdate and RAUC. These framework do most of the basic work like bootloader
interaction, redundancy handling, signing and verification. But using them
still requires proper integration into a (complex) overall system where all the
different components must be well configured to properly interact to ensure
robust and fail-safe handling as pointed out in the previous sections.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1408x889" href="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_RAUC_scheme.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-16_rauc-maintenance/2019-08-16_RAUC_scheme.thumb.8a4ffe9d92a0304632faa11c6b922ea1.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>RAUC scheme</p>
</figcaption>
</figure>
</div><p><a class="reference external" href="https://rauc.readthedocs.io/en/latest/">RAUC</a> for example is a flexible
update framework supporting a variety of platforms, storage types, file systems
and bootloaders, including GRUB, barebox, U-Boot and UEFI.</p>
<p>A simple ini-style config file placed on the target system maps the existing
partitions to a number of so-called 'slots' that are assigned to different
classes based on their purpose and grouped with other slots to form
sophisticated redundancy scenarios.</p>
<p>On the host system RAUC allows to create and install compressed and signed
so-called 'bundles'. These bundles contain the actual images and other
artifacts to install together with a manifest file describing which image is
intended for which slot class as defined in the system configuration of the
target. It also provides global and per-slot configuration options and
extension by hook scripts for fine-tuning and customizing the actual
installation behavior to match the individual project's needs.</p>
<p>While RAUC provides a full-featured command-line interface that allows
installing bundles and inspecting the system state, RAUC is primarily designed
to be integrated in existing applications and thus can be fully controlled
using its D-Bus interface. This is a deliberate design decisions as normally
the main application running on an embedded systems needs to keep control over
triggering or monitoring the update process.</p>
<p>RAUC uses the CMS standard (X.509) for signing and bundle verification with
some useful features such as resigning bundles when moving from development to
production or support for PKCS#11 (SmartCards).</p>
<p>Although RAUC is an image-based updater it also allows installing images
via tar archives to be independent from the actual storage media size. RAUC
also supports binary delta-like streaming of updates by making use of the
<a class="reference external" href="https://github.com/systemd/casync">casync</a> data chunking tool.</p>
<p>RAUC is purely written in C using the GLib library which allows to have a small
footprint and prevents from reinventing the wheel. For cryptography it uses the
OpenSSL library and the curl library for network transport protocol
functionality. It is licensed under LGPL2.1.</p>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
<p>Open source update frameworks play an important role when designing a redundant
update concept for an embedded (Linux) platform. They solve the basic
challenges like atomicity, redundancy, verification and bootloader interaction
and avoid reinventing the wheel in each project. Considering safe and secure
updates necessarily also involves keeping the project's and the target's
software stack up-to-date to prevent attacks and enable quick reaction in case
of severe issues. Understanding and making use of the communities and work
flows of open source software can safe a lot of effort during a device's
development and lifetime.</p>
</div>
</div>
<p>In this blog post I would like to address the challenges of performing
unattended and verified updates of embedded Linux systems in the field using
open source software and workflows.
While updating is not a end in itself, a second part of my
considerations goes even further and also works out the necessities and
possible workflows for keeping the software stack of a project up to date and
thus either preventing security issues or at least enabling a short reaction
time in case of severe CVE'S discovered.</p>2019-08-16T00:00:00+01:00tag:www.pengutronix.de,2019-08-14:/2019-08-14-15_years_of_imx_in_mainline.html15 Years of i.MX in Mainline Linux2019-08-14T00:00:00+01:00Robert Schwebel<div class="section" id="years-of-i-mx-in-mainline-linux">
<p>Today it has been 15 years since we mainlined support for
Freescale/NXP's i.MX architecture in the Linux kernel! That was one
small step for [a] man, one giant leap for (industrial Linux users')
mankind :-) Here is some background about why it happened and what you
might want to learn from history for your next embedded Linux project.</p>
<div class="section" id="how-to-react-to-risk">
<h3>How to react to risk?</h3>
<p>Back in 2004, Pengutronix was contacted by a customer who developed a
medical device: they had selected a nice CPU for their new hardware, all
relevant peripherals matched the requirements and the chip manufacturer
promised 14 years of device availability for that shiny MX1. In fact,
MX1 was the first ARM based processor from Freescale, still labeled as
"DragonBall" at that time (which was the marketing name of the previous
series of M68k based devices), contained a 200 MHz ARM920T core and
looked like a perfect choice for the job. Marketing material had a check
mark at "Linux Support", so what could possibly go wrong...</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="427x357" href="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_spirograph.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_spirograph.thumb.d526b4639f4409a1d9acb0b7d30cf571.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Medical device based on i.MX1 (photo courtesy of Viasys Healthcare)</p>
</figcaption>
</figure>
</div><p>At the time we got contacted, someone had asked Freescale if they also
provide reliable operating system software support for those 14 years,
and it quickly turned out that the Linux port was an "Enablement BSP",
made to show that the hardware was operable. However, as a medical
device manufacturer, there are strong regulatory processes in place
which in fact makes it absolutely necessary that you are able to react
if some kind of risk turns up. So what do you do if, for instance, a
security flaw in the kernel is found during that 14 years? You could
port the i.MX1 patches forward to a newer kernel that contains fixes,
but this plan quickly turned out to be impossible. Hundreds of patches
had been stacked to an already old kernel at that time, with less than
optimal topic separation and documentation, so the effort for even
understanding what had to be done was unacceptable. Even worse, like
almost all vendor code at that time, the kernel port had been made
without talking to the community or reviewing the patches due to
confidentiality reasons.</p>
<p>So what should our customer do? Everyone was absolutely convinced that
it would be impossible for a small project team to make a mainline port,
taken that obviously not even a big chip manufacturer was in a position
to do that.</p>
<p>So we sat in the office and thought: Challenge accepted!</p>
</div>
<div class="section" id="taking-back-control-with-the-power-of-open-source">
<h3>Taking back control with the power of Open Source</h3>
<p>When we were asked for assistance, we quickly found out that, while
there was a lot of code for all the many peripherals in i.MX1, our
customer fortunately only used a small subset for his actual project. We
analyzed the patches carefully, ripped them apart, sorted them into
interesting and non-interesting pieces, modified the better ones and
rewrote other parts of the port and moved all that on top of the latest
mainline kernel. It took us about 6 weeks to have a first mainline based
kernel. Linux code is licensed under the terms of the <a class="reference external" href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.html">GPLv2</a>, so
modifying other people's kernel code was always legally possible, so
even we as just-a-few-random-hackers were allowed to just do what was
necessary without lengthy discussions with the legal teams of big
companies. After the six weeks, we had a port that was good enough to
actually work for the customer, and even good enough to be posted on the
Linux ARM Kernel Mailing List (LAKML). Patches were discussed, reviewed
by other kernel hackers, improvements had been added, and finally we
proposed the patch stack to be included in the mainline kernel.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="744x545" href="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_patch.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_patch.thumb.2f38e8e6c3c09303ca997aefcbc7a8d4.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Submission of i.MX1 support for the mainline kernel (<a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=9c496bde802b19db40325bbde356be62e66dc125">Commit in the kernel history git</a>)</p>
</figcaption>
</figure>
</div><p>After some time, we were asked if Sascha Hauer would be interested in
being the official i.MX maintainer, we agreed and during the next years
all the i.MX patches went through our hands. MX27, MX31, MX25, MX51 and
finally MX53 brought us many new industrial projects: the word spread
quickly in the industrial community that this mainline port was of high
software quality. In fact, it was not <em>us</em> being some magic genius, but
simply because of the development process of the Linux kernel that makes
best use of the community's technology-focussed quality process and
involves many, many smart people out there to focus all that expertise
in one mainline kernel.</p>
</div>
<div class="section" id="happy-birthday-i-mx-mainline-port">
<h3>Happy birthday, i.MX Mainline Port!</h3>
<p>Many industrial device manufacturers based their product development on
mainline since then - with and without our help. After a while,
Freescale joined the community and let many of their developers
contribute to the mainline kernel and even to the maintenance effort.</p>
<p>The community grew, i.MX6 got a big success story in the industry. With
Etnaviv and the VPU drivers, open source support for the 3D GPU and the
video encoders/decoders were added, and today we are working on mainline
support for i.MX8M.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="858x882" href="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_bootlog.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/2019-08-14_15_years_of_imx_in_mainline_bootlog.thumb.cb2515e6a54a0d4176bc2e4b8375c84a.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Finally, even today, 15 years after the first port, a top-of-tree 5.3-rc
kernel is still able to boot on i.MX1 with only minor modifications (see
a screencast of a boot from today below)</p>
<p>Happy birthday, i.MX!</p>
<div><div class="clearfix"></div></div></div>
<div class="section" id="screencast">
<h3>Screencast</h3>
<asciinema-player poster="npt:0:01" preload="True" src="https://www.pengutronix.de/media/blog/2019/2019-08-14_15-years-of-imx-in-mainline/293571.cast">
</asciinema-player></div>
</div>
<p>Today it has been 15 years since we mainlined support for
Freescale/NXP's i.MX architecture in the Linux kernel! That was one
small step for [a] man, one giant leap for (industrial Linux users')
mankind :-) Here is some background about why it happened and what you
might want to learn from history for your next embedded Linux project.</p>2019-08-14T00:00:00+01:00tag:www.pengutronix.de,2019-08-12:/2019-08-12-froscon_14.htmlFrOSCon 142019-08-12T00:00:00+01:00Chris Fiege<div class="section" id="froscon-14">
<p>Pengutronix has been to <a class="reference external" href="https://www.froscon.de/">FrOSCon</a> at the
University of Applied Sciences Bonn-Rhein-Sieg.
This year we had a booth where we presented our Open Source activities and
were able to contribute three talks.
A booth at an Open Source conference like FrOSCon always opens doors to a
lot of interesting conversations with new faces, old friends and colleagues.</p>
<p>This blog post will tell our story from the beginning…</p>
<div class="section" id="day-0">
<h3>Day 0</h3>
<p>This year six Pengutronix colleagues took the opportunity to visit
FrOSCon 14.
We arrived on Friday afternoon. We voted that we would build up our booth
on Saturday morning (and to get up a little earlier).
That gave us the evening to get some food and local beer.</p>
<p>St. Augustin was giving us the cold shoulder and welcomed us with lots of rain.
But hey, we did not travel there for the landscape anyway.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_beer.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_beer.thumb.e0748c4574794f4db2467c11f12d7274.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Local Beer</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_burger.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_burger.thumb.02346c7e409ea27a147091ddb9d9cb19.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Burgers</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_desert.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_desert.thumb.3596bfd68e7a41c66133b43fae341edb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Desert: Vanilla Crêpes with parfait</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
<div class="section" id="day-1">
<h3>Day 1</h3>
<p>Saturday started like the Friday ended – without rain (yay!) but with even more
food.
Our small hotel presented us an overwhelming breakfast.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_cfi_booth.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_cfi_booth.thumb.40f06cd275aed3ac75a20460b3b954d4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Chris behind the 4-Video Demo</p>
</figcaption>
</figure>
</div>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_hiring.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_hiring.thumb.16faa262eb7f7b40d8c946798bad1254.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Of course: Such a conference is also a chance to present ourselves to
possible new colleagues.</p>
</figcaption>
</figure>
</div><p>We went to the venue and started to decorate our booth.
This year we brought two demos:</p>
<div class="section" id="video-demo">
<h4>4-Video Demo</h4>
<p>The 4-Video Demo is an oldie in our zoo of demos.
This is an in-flight entertainment system build around an NXP i.MX6
generously provided by a customer.
In this demo four videos are played back simultaneously using the hardware
decoder in the CPU.</p>
<p>Since hardware like this flies on real planes, it is a great showcase for what
open source systems allow you to do:</p>
<ul class="simple">
<li>The demo is 100% open source – there is no vendor proprietary driver or
software in this system.
This gives us full control over the system and allows us to address bugs
in every subsystem as they emerge.
There is no need to wait for weeks for a silicon manufacturer to take a
look at your support case!</li>
<li>All software is up to date.
Since we are using the <cite>mainline</cite> versions of the software, we usually have
no or only little patches in our BSP.
That makes updating especially easy.</li>
</ul>
</div>
<div class="section" id="flamingo-static-site-generator">
<h4>Flamingo – Static site generator</h4>
<p>FrOSCon is the first time we present the <a class="reference external" href="https://flamingo-web.org">Flamingo</a>
static site generator to the public.
A static site generator is a piece of software that converts input files like
<cite>reStructured text</cite> or <cite>Markdown</cite> into a website.
Since all needed files are generated during build, there is no need for
a CMS – the only software needed is a webserver like <cite>Apache2</cite> or <cite>nginx</cite>.</p>
<p>Flamingo has been used to build this website for about a year now.
Florian also did a talk the next day about Flamingo and the decisions that lead us to build
our own static site generator.</p>
</div>
<div class="section" id="talk-build-your-own-phone-system-with-asterisk">
<h4>Talk: Build your own phone system with Asterisk</h4>
<p>In the afternoon Florian and Chris told the story of how they got to build
the new phone system for Pengutronix using Asterisk and Django.</p>
<div class="ptx-sidebar">
<div class="title">
Mit Asterisk und Django zur eigenen Telefonanlage
<div class="corner"></div>
</div>
<div class="body">
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x576" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_asterisk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_asterisk.thumb.cfd6ac3b89b2e18e27091ddcd6b1d21e.jpg"/>
</a><figcaption itemprop="caption description" style="
"><p>Chris and Florian during the talk</p>
</figcaption>
</figure>
</div><ul class="simple">
<li><a class="reference external" href="https://media.ccc.de/v/froscon2019-2367-mit_asterisk_und_django_zur_eigenen_telefonanlage">Recording at media.ccc.de (German only)</a></li>
<li><a class="reference external" href="https://programm.froscon.de/2019/events/2367.html">Slides</a></li>
</ul>
</div>
</div>
<p>Last year we decided that it's time to replace our
Alcatel OmniPCX-based phone system with something more modern.
We needed more DECT phones, DECT on multiple sites, and we wanted a nicer
management interface (Windows XP VMs with a GUI-based tool are so 2000s!).</p>
<p>Florian and Chris built their phone system around an Asterisk as call router
and a Django application for the user interface and the configuration.</p>
<p>In the talk they presented how they built an unconventional interface between
Asterisk and the Python world.</p>
</div>
<div class="section" id="social-event">
<h4>Social Event</h4>
<p>This day ended like the last one: food and beer.</p>
<p>FrOSCon always has an open-to-all social event.
Since it's open to everyone it is not free – but it is definitely worth
the price!
This year the caterer presented pulled beef and pulled pork, grilled potatoes,
and a huge variety of salads.</p>
</div>
</div>
<div class="section" id="day-2">
<h3>Day 2</h3>
<div class="ptx-sidebar">
<div class="title">
Managementwerkzeuge aus der Open-Source-Entwicklung
<div class="corner"></div>
</div>
<div class="body">
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x769" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_mcm.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_mcm.thumb.62ebf3925b2071e1a6d0f419ee9eb0df.jpg"/>
</a><figcaption itemprop="caption description" style="
"><p>Marie talking about open source process manuals</p>
</figcaption>
</figure>
</div><ul class="simple">
<li><a class="reference external" href="https://media.ccc.de/v/froscon2019-2332-managementwerkzeuge_aus_der_open-source-entwicklung">Recording at media.ccc.de (German only)</a></li>
<li><a class="reference external" href="https://programm.froscon.de/2019/events/2332.html">Slides</a></li>
</ul>
</div>
</div>
<p>Day one started with a surprise: The tram that should bring us to the venue
was canceled.
We called it a blessing in disguise and took the chance to take a short (3 km)
walk instead.
At least the sun was shining and we still had plenty of time to arrive
for Marie's and Florian's talks.</p>
<div class="section" id="talk-management-tools-in-open-source-development">
<h4>Talk: Management tools in open source development</h4>
<p>Marie talked about how she implemented a new business process manual at
Pengutronix.</p>
<p>In her talk Marie showed us that she deliberately used hacker-compatible tools
like</p>
<ul class="simple">
<li>Git for version control,</li>
<li>Sphinx for document management,</li>
<li>and Jenkins for continuous testing and continuous deployment.</li>
</ul>
<p>This way she wanted to lower the barriers for all other employees to participate
in the development of the process manual and thus make it a useful tool for
the daily work in our company.</p>
<p>Marie encouraged the audience to choose the tools that fit the employees
best – even if they are unconventional for that particular use case.</p>
</div>
<div class="section" id="talk-why-flamingos-are-the-better-pelicans">
<h4>Talk: Why flamingos are the better pelicans</h4>
<div class="ptx-sidebar">
<div class="title">
Warum Flamingos die besseren Pelicane sind
<div class="corner"></div>
</div>
<div class="body">
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_fsc.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_fsc.thumb.8ecfce1830d04acece21c468816b9b47.jpg"/>
</a><figcaption itemprop="caption description" style="
"><p>Florian talking about Flamingo</p>
</figcaption>
</figure>
</div><ul class="simple">
<li><a class="reference external" href="https://media.ccc.de/v/froscon2019-2368-warum_flamingos_die_besseren_pelicane_sind">Recording at media.ccc.de (German only)</a></li>
<li><a class="reference external" href="https://programm.froscon.de/2019/events/2368.html">Slides</a></li>
</ul>
</div>
</div>
<p>At the same time as Marie held her talk, Florian was talking about the reasons
that made him start to develop Flamingo.</p>
<p>Florian started with a brief tour through the history of pengutronix.de.
In the early 2000s we started with a WML-based website.
We used that technology until just a few years ago: With a new corporate
design we launched a new website based on the static site generator
<a class="reference external" href="https://blog.getpelican.com/">Pelican</a>.</p>
<p>It took Florian quite some effort until our website looked the way we wanted.
But in the end it worked somehow…
We weren't able to update to newer Pelican
versions – but it's just generating a static site.
Thus this is, at least, not a security concern.</p>
<p>Just a few years later we wanted to launch a new website based on the same
software stack.
After a short evaluation we came to the conclusion that this was not feasible
using the Pelican-based system.
The idea to build
<a class="reference external" href="https://flamingo-web.org">Flaming</a>
was born.</p>
</div>
</div>
<div class="section" id="wrapping-it-up">
<h3>Wrapping it up</h3>
<p>FrOSCon 14 has been a great conference.
It brings together a good mix of developers, users and newbies and it provides
everybody a welcoming and safe environment.</p>
<p>I am always pleased to see how such an event is organized and carried out
by so many caring volunteers.
And I really appreciate the professionalism, efficiency and kindness all
the trades show during the event.</p>
<p>I send a big <em>Thank you!</em> to the
<a class="reference external" href="https://www.froscon.de/">organizers</a>,
the <a class="reference external" href="https://c3voc.de/">VOC</a>,
<a class="reference external" href="https://eventphone.de/">Eventphone</a>,
all the volunteers and speakers
and of course everybody I have failed to mention.
You did a great job!</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_hangelar.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_hangelar.thumb.f8d477b8268f96cba454f784d42ba837.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Tram station "Hangelar Mitte"</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_booth_all.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_booth_all.thumb.0b582e892ad77789d40e12f1f7addb83.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Pengutronix booth at FrOSCon</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_booth_smile.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_froscon_booth_smile.thumb.5c9ebb5f8ebeee8dabc8707ee8a66917.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Ulrich sitting with a big smile behind the desk at our booth</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1024" href="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_square.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-08-12_froscon-14/2019-08-12_FrOSCon_square.thumb.08ac0e5189b61723f86b2b2ef636b885.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>A FrOSCon banner</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>Pengutronix has been to <a class="reference external" href="https://www.froscon.de/">FrOSCon</a> at the
University of Applied Sciences Bonn-Rhein-Sieg.
This year we had a booth where we presented our Open Source activities and
were able to contribute three talks.
A booth at an Open Source conference like FrOSCon always opens doors to a
lot of interesting conversations with new faces, old friends and colleagues.</p>2019-08-12T00:00:00+01:00tag:www.pengutronix.de,2019-07-09:/2019-07-09-volatile_var-2019.htmlStatic Filesystem2019-07-09T00:00:00+01:00Jürgen Borleis<div class="section" id="static-filesystem">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="500x301" href="https://www.pengutronix.de/media/blog/2019/2019-07-09_volatile-var/2019-07-09_coffee_improves.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-07-09_volatile-var/2019-07-09_coffee_improves.thumb.39dc49e52630145a5f8cce9c292a3887.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Whenever it is a requirement to be able to switch off an embedded device without
any previous preparation, the next question is about the consistence of the
used filesystem. If this filesystem is used to be written with new content
and this new/changed data hasn't done it's way to the persistent media when the
power is cut, this new/changed data is lost.</p>
<p>On the following system start most of the time the filesystem itself can be
repaired and be consistent again, but the new/changed data from the last run
is still lost. And sometimes it even happens not only the data the filesystem
manages is inconsistent, its own management information can be broken as well.
If this happens, the whole filesystem is broken and the system stops working.
There are many filesystems out which tries to deal with such failures in any
circumstances. But from time to time we even see a loss, where every
last resort seems to fail.</p>
<p>One way out of this dilemma is the use of the filesystem in a read-only manner.
Its content will be completely defined at build-time and does not need any
further change at run-time - it is fully static.</p>
<p>But there are many applications and tools which still expect to be able to write
to the filesystem hierarchy, maybe simply for their logging information. In most
cases this is valid at least for the filesystem hierarchy below <cite>/var</cite>.</p>
<p>Until now PTXdist used a very simple approach as a solution: at run-time it
locates three RAM disks in <cite>/var/lock</cite>, <cite>/var/log</cite> and <cite>/var/tmp</cite> to provide
write support at these specific locations. Even if this approach is simple and
very optimistic, it yet worked for surprisingly many use cases.</p>
<p>One essential assumption for this approach is, the data written to these
locations must not be persistent across reboots.</p>
<p>But more and more applications and tools have new requirements to the filesystem
hierarchy below <cite>/var</cite> and the approach used until now is ways to inflexible and
thus isn't able to solve the issue anymore.</p>
<p>For this reason the PTXdist July release provides an additional (configurable)
approach to have the filesystem hierarchy below <cite>var</cite> writable: "overlay
filesystem". This is a Linux kernel filesystem which supports to overlay a
static filesystem by a different writable filesystem.</p>
<p>The most simple overlaying writable filesystem is a RAM disk and it is from the
beginning initially empty. In this case read accesses provides the content from
the underlying static filesystem. That means after the system comes up, the
content is always in an initial state.
If data gets written to this filesystem hierarchy it is stored in the writable
filesystem instead. The next read access to it will then be served by the
writable filesystem instead and no longer by the underlying static filesystem.</p>
<p>Making use of this new PTXdist feature is very simple: one requirement is the
overlay filesystem feature from the Linux kernel at run-time. It must be enabled
first (CONFIG_OVERLAY_FS=y). Additionally in the PTXdist configuration menu
the "overlay <cite>/var</cite> with RAM disk" must be enabled (symbol
ROOTFS_VAR_OVERLAYFS=y). After that, the root filesystem image must be created
and used at the target system.</p>
<p>At run-time this new configuration can be checked by running the "mount" command:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>$ mount
[...]
/dev/root on / type ext4 (ro,relatime,errors=remount-ro)
[...]
overlay on /var type overlay
(rw,relatime,lowerdir=/var,upperdir=/run/varoverlayfs/upper,workdir=/run/varoverlayfs/work)
[...]
</pre></div>
</div><p>The root filesystem is mounted "ro" ("read-only") and the "overlay filesystem"
is mounted on top of the <cite>/var</cite> directory.</p>
<p>It is now possible to make use of commands likes "mkdir" and "touch" in a
usual manner in all directories below the <cite>/var</cite> hierarchy.</p>
<p>Detail: by the way the used RAM disk isn't part of the mount's command output.
After mounting it with the "overly filesystem" it will unmounted again
immediately and intentionally. Due to this it is invisible, but still existent
and used by the "overlay filesystem". When the "overlay filesystem" gets
unmounted, this invisible RAM disk gets freed as well.</p>
</div>
<p>Whenever it is a requirement to be able to switch off an embedded device without
any previous preparation, the next question is about the consistence of the
used filesystem. If this filesystem is used to be written with new content
and this new/changed data hasn't done it's way to the persistent media when the
power is cut, this new/changed data is lost.</p>2019-07-09T00:00:00+01:00tag:www.pengutronix.de,2019-07-03:/2019-07-03-CERT_at_VDE.htmlCERT@VDE Innovation Workshop2019-07-03T13:00:00+01:00Enrico Jörns<div class="section" id="cert-vde-innovation-workshop">
<div class="section" id="today-s-security-challenges-of-embedded-systems-and-solutions">
<h3>"Today's security challenges of embedded systems and solutions"</h3>
<p>On June, 27th, while the sun was relentlessly heating up Germany as hardly
every before, above 50 employees from many companies came together in
a well air-conditioned room in the TP ConferenceCenter in Heidelberg.
All operating in different fields of application but all involved in embedded
systems and all interested to learn something new about security and deploying
software updates.</p>
<p>What led them there was the CERT@VDE Innovation Workshop <a class="reference external" href="https://www.osadl.org/?id=3112">"Today's security
challenges of embedded systems and solutions"</a>
organized in cooperation of <a class="reference external" href="http://osadl.org/">OSADL</a> and
<a class="reference external" href="https://www.vde.com/topics-de/cyber-security/cert-vde">CERT@VDE</a>.</p>
<p>What led <em>me</em> there was the invitation to give the audience in-depth
information about how to perform fail-safe and authenticated updates on
embedded devices and also present a little demo of the open source update
system RAUC operating on a Raspberry Pi.</p>
<p>But first of all, the day started with a warm welcome from Carsten Emde, head
of OSADL, and a short but quite interesting introduction round where each member
shortly introduced themselves, their company and their motivation for attending.
The motivation description varied from very enthusiastic statement of what
was expected from this workshop or how their company is moving towards
connected devices up to a simple 'what he said' in case of multiple attendees
per company.</p>
<p>The topics of the following talks were quite diverse and covered many
aspects of security.</p>
<p>Andreas Harner from CERT@VDE described what a CERT (short for 'Computer
Emergency Response Team') actually is, what they care for and how to benefit
from this. He also presented some entertaining war stories.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_boris_cipot.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_boris_cipot.thumb.b2f5d5cb2985132d04170220eba814fa.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Boris Cipot showing statistics</p>
</figcaption>
</figure>
</div><p>The next presentation was by Tim Hemel.
Based on the example of an update system he pointed out different
use case analysis and thread modeling techniques on different abstraction
levels to find parts of specification that were not covered yet, as well as
potential risks.
He also noted the importance of explicitly deciding whether to address a known
potential attack method because of risk vs. cost trade-off considerations.</p>
<p>The first block before lunch was then rounded out by a talk held by <em>Synopsis</em>
(which recently bought <em>Black Duck</em>) employee Boris Cipot who described
himself as actually being a comedian that somehow turned into a software
developer.
In his vivid presentation style he gave some impressive insights about how much
open source software is actually used in modern projects and products and
finally touched the topic of code scanning.</p>
<p>After the lunch break, where we all had the chance to replenish our energy
reserves with tasty food and deserts, Anne Borcherding from the Fraunhofer IOSB
cared for the knowledge input again.
As a 'real security researcher' as she titled herself, she introduced the
different analysis techniques they use for finding vulnerabilities in code
and protocols, such as black box testing, or fuzzing.
With a study where they attacked 6 Profinet bus couplers from different
manufacturers, she showed some real-world statistics about vulnerabilities of
devices out in the field.</p>
<p>To also cover the legal site of security, Dr. Dennis-Kenji Kipker, Legal
Advisor at CERT@VDE, gave a quick overview over the planned German IT law
(2.0) and how the ministry of the interior could declare IT products as
infrastructure-critical in the future to require special security-related
processes and know-how. He also noted their plans to introduce a volunteer
'cyber-approved' mark for digital products...</p>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a href="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_System_Update_slides.pdf">System update talk slides</a></p>
</div>
</div>
<p>This was the right time to move back to some more technical presentation and
for me the sign to start with my talk about fail-safe and secure update
systems.
The ability to safely deploy updates in the field is a key requirement for
fixing bugs in the field and thus for reacting on CVE's etc.
I first made a quick rush through the basic concepts of redundancy,
atomicity and verification to then emphasize the importance of using open source
update frameworks.
After a short overview over tools like <a class="reference external" href="https://mender.io">mender</a>,
<a class="reference external" href="https://github.com/sbabic/swupdate">swupdate</a> and <a class="reference external" href="https://rauc.io">RAUC</a>,
I used RAUC as an example to give a slightly more in-depth view of what an
update framework provides and how to handle the requirements of robustness and
security.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_rpi_demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_rpi_demo.thumb.9aa21a9885b112972f32717a81a9a76e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>RPI Demo setup shown during workshop</p>
</figcaption>
</figure>
</div><p>The coffee break gave the others the time to take a deep breath from the load
of information received up to now (and taste the great cakes!) and gave Carsten
Emde and me the time required to set up our demos.</p>
<p>After the break, I first showed the practical usage of RAUC and how to handle
certificates, signing, etc. on the command line of a Raspberry PI.
Then Carsten showed the bootstrapping process of mender server and how to
actually update a Raspberry PI after having set up everything correctly.
The demos showed the wide range between the full all-in-one solution of mender
on one side and the highly configurable and adaptable client-only solution like
RAUC on the other side.</p>
<p>The workshop track was then completed by Markus Hölscher from HENSOLDT Cyber
GmbH who presented their formally verified micro kernel.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_cert_ejo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-07-03_cert-at-vde/2019-07-03_CERT_at_VDE_cert_ejo.thumb.07336c08d6c3e36ec0edde302c6e98e9.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Certificate of attendance</p>
</figcaption>
</figure>
</div><p>I would like to say many thanks to Carsten Emde and the entire team from OSADL
for organizing this great workshop, and thanks for the little present I got. :)</p>
<p>As all other participants I received a certificate of participation in this
workshop and then finally headed back towards home.</p>
</div>
</div>
2019-07-03T13:00:00+01:00tag:www.pengutronix.de,2019-07-03:/2019-07-03-barebox-mvebu.htmlFoster mvebu Support in barebox2019-07-03T11:00:00+01:00Uwe Kleine-König<div class="section" id="foster-mvebu-support-in-barebox">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="702x796" href="https://www.pengutronix.de/media/blog/2019/2019-07-03_barebox-mvebu/2019-07-03_barebox-mvebu.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-07-03_barebox-mvebu/2019-07-03_barebox-mvebu.thumb.584583298542f21432275d46021490d7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 190px;
"><p>Debugging Turris Omnia Hardware</p>
</figcaption>
</figure>
</div><p><a class="reference external" href="https://barebox.org/">barebox</a> works great on NXP's i.MX platforms. While
there is some support for Marvell's mvebu platform, it is not even near being
complete. The main limitation is in my eyes that there is no code to initialize
RAM settings on these machines.</p>
<p>On mvebu the native bootable image consists of (usually) two parts. A
so-called binary header and a main image. The first one is responsible to setup
RAM and after that the boot ROM copies the main image to RAM and jumps into it.
Up to now (as of barebox 2019.06.0) you have to dissect a working "vendor
image" (usually U-Boot), get the binary header from it and reuse this for
barebox. This is ugly for several reasons: It complicates compilation and
license conformance and so lacks all the nice properties of open source software.</p>
<p>During the annual <a class="reference external" href="https://www.pengutronix.de/en/blog/2019-06-11-techweek-2019.html">Pengutronix Techweek</a> I resolved to work on this
shortcoming. My plan was to borrow the code to setup RAM from vanilla
<a class="reference external" href="https://www.denx.de/wiki/U-Boot">U-Boot</a>
to get my
<a class="reference external" href="https://www.turris.cz/en/omnia/">Turris Omnia</a>
run barebox. Back in 2017 I already worked on this machine and was able to
chain load barebox from U-Boot which is a good condition to work on native
booting.</p>
<p>In the end there were too many obstacles however and I ended up doing
preparatory work only:</p>
<ul class="simple">
<li>debug and repair second stage booting (<a class="reference external" href="https://git.pengutronix.de/cgit/barebox/commit/?h=master&id=62260d6b6df4f4e36955279e1891e3e5a2fd8414">commit 1</a>,
<a class="reference external" href="https://git.pengutronix.de/cgit/barebox/commit/?h=master&id=2ee5b0aa94b16961423dcf5c383034abf3e1c048">commit 2</a>)</li>
<li>rewrite mvebu image tool to take all relevant parameters via the command line (<a class="reference external" href="https://git.pengutronix.de/cgit/barebox/commit/?h=next&id=98723024413d745d6c053cd6823ebe426d8b04dc">commit</a>)</li>
<li>fix barebox' build system to rebuild the final image when the binary header changed (<a class="reference external" href="https://git.pengutronix.de/cgit/barebox/commit/?h=next&id=a040f79300139caec375e8125810ddc92316972e">commit</a>)</li>
<li>some research why booting via UART is not as reliable as it should be.</li>
</ul>
<p>Even when I come around to port the RAM init sequence to barebox there is still
much to do to make barebox useful on Turris Omnia. Fixing networking, access to
SATA and flash and adding support for btrfs (which is used in the vendor
firmware) will keep me busy for some time.</p>
</div>
<p><a class="reference external" href="https://barebox.org/">barebox</a> works great on NXP's i.MX platforms. While
there is some support for Marvell's mvebu platform, it is not even near being
complete. The main limitation is in my eyes that there is no code to initialize
RAM settings on these machines.</p>2019-07-03T11:00:00+01:00tag:www.pengutronix.de,2019-06-20:/2019-06-20-techweek_arria10.htmlBootstrapping Arria10 with OpenOCD and barebox2019-06-20T00:00:00+01:00Steffen Trumtrar<div class="section" id="bootstrapping-arria10-with-openocd-and-barebox">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1600x1200" href="https://www.pengutronix.de/media/blog/2019/2019-06-20_techweek-arria10/2019-06-20_techweek_arria10_bsel.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-20_techweek-arria10/2019-06-20_techweek_arria10_bsel.thumb.ca8c71c06191c990d5f6c17365ca7965.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>The Arria10 SoCFPGA can boot from multiple sources: SD Card, NAND flash, QSPI
flash and eMMC, that can be selected via the <em>BSEL</em> pins.
If the bootrom can not find a valid
bootloader on that medium, it will fall back to JTAG. So for developing and
testing, the BSEL pins can just be set to a medium that is non-existent. In
case of bootstrapping, the bootrom falls back to JTAG anyway, as there is no
valid bootloader, yet.</p>
<p>Okay, so how to get the bootloader loaded via JTAG? That is where OpenOCD comes
into play.
OpenOCD has had support for the Cyclone5-based SoCFPGA family for
multiple years now.
Not so for Arria10.
The necessary <a class="reference external" href="https://repo.or.cz/openocd.git/commit/c8c778882570c36ff51b83b9c7d1e575566bc4ce">patches</a>
where created by Oleksij Rempel and got included last year.</p>
<p>The problematic part of the Arria10 is the SDRAM controller.
For some reason, it was decided, that it is a good idea to not include a hard IP core into the
SoC, but put it into the FPGA portion.
So, to do anything useful in the bootloader, the FPGA has to be programmed first.
As it turned out, before the FPGA can be programmed some setup has to be done
or the SoC behaves strangely in different ways.
That is why we have to use a two-stage boot approach with OpenOCD.</p>
<p>First, start up barebox and let it setup the clocks and pins:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="nv">halt</span>
<span class="nv">load_image</span><span class="w"> </span>barebox-bringup<span class="w"> </span><span class="nv">$OCRAM</span><span class="w"> </span>bin<span class="w"> </span><span class="nv">$OCRAM</span><span class="w"> </span><span class="nv">$OCRAM_SIZE</span>
<span class="nv">resume</span><span class="w"> </span><span class="nv">$OCRAM</span>
</pre></div>
</div><p><cite>load_image</cite> is an OpenOCD TCL command to load a file to an address. Remember,
that the SDRAM can not be used yet.
So, the image must be loaded to the 256KB On-Chip RAM. After the image is
transfered, <cite>resume</cite> from the address we just loaded barebox to.
So, barebox does its thing and sets up the clocks and pins and then loops on
the FPGA usermode bit.
This bit will be set to 1, once the FPGA is loaded successfully and enters user
mode, i.e. it can be used.</p>
<p>Next, program the FPGA:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>svf -tap $_CHIPNAME.fpga.tap bitstream progress
</pre></div>
</div><p><cite>svf</cite> can load FPGA bitstreams that are formatted in the serial vector format.
These can be generated with the Altera Quartus tool.
Once this is done, barebox can continue with its normal boot process: setting
up hardware and boot linux.</p>
<p>Once we are in the userspace, barebox can be written to the boot medium, so we
don't have to always boot from JTAG if we don't want to.
In our case, we partition the eMMC and write barebox to the first partition and
the FPGA bitstream, this time formatted in raw binary file format, to the
second partition.
Now, after powerup, barebox programs the FPGA itself and boots just like on
other hardware.</p>
</div>
<p>The Arria10 SoCFPGA can boot from multiple sources: SD Card, NAND flash, QSPI
flash and eMMC, that can be selected via the <em>BSEL</em> pins.
If the bootrom can not find a valid
bootloader on that medium, it will fall back to JTAG. So for developing and
testing, the BSEL pins can just be set to a medium that is non-existent. In
case of bootstrapping, the bootrom falls back to JTAG anyway, as there is no
valid bootloader, yet.</p>2019-06-20T00:00:00+01:00tag:www.pengutronix.de,2019-06-18:/2019-06-18-DistroKitLayer.htmlJump Start your BSP using DistroKit and PTXdist Layers2019-06-18T00:00:00+01:00Chris FiegeRoland Hieber<div class="section" id="jump-start-your-bsp-using-distrokit-and-ptxdist-layers">
<p>A BSP (Board Support Package) in Embedded Software is the layer of software that
lets you run your application on a specific hardware.
For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a
userspace.
DistroKit is our Demo-BSP that supports a variety of common evaluation boards.
DistroKit gives you a head start if you want to develop an application on top
of such an evaluation board with most of the hard problems already solved.</p>
<p>Some years ago Robert wrote about how you can use
<a class="reference external" href="https://git.pengutronix.de/cgit/DistroKit/">DistroKit</a>
as an example of PTXdist and it's features.
Generally his
<a class="reference external" href="https://www.pengutronix.de/de/blog/2017-08-28-DistroKit_Intro.html">blog post</a>
is still valid – but I want to introduce a new way to use DistroKit.</p>
<p>Don't be shocked by all the code snippets in here:
This blog post is written as a step-by-step walkthrough on how to create a
DistroKit based layered BSP and how to migrate it to a new DistroKit revision.</p>
<div class="section" id="layers-everywhere">
<h3>Layers everywhere</h3>
<p>In modern times things must have layers:
<a class="reference external" href="http://quotegeek.com/quotes-from-movies/shrek/7316/">Ogres</a>,
Onions, and also
<a class="reference external" href="https://www.ptxdist.org/doc/dev_manual.html#layers-in-ptxdist">PTXdist</a>.</p>
<p>In short: PTXdist layers give you the possibility to stack multiple
<em>PTXdist configurations</em> on top of each other,
each representing a diff to the previous one.</p>
<p>The classical way to use DistroKit was to take the
<a class="reference external" href="https://www.pengutronix.de/de/software/distrokit.html">upstream BSP</a>
and stack your changes on top of that in the same git.
PTXdist keeps its configuration inside a
<a class="reference external" href="https://en.wikipedia.org/wiki/Menuconfig">Kconfig</a> file.
An update to a new DistroKit version now means to rebase your changes
on top of the upstream, or merge the upstream.
You easily end up with in a <em>rebase hell</em> or a <em>merge hell</em>.
For an inexperienced user it is hard to make a reproducible
merge.</p>
<p>My suggestion is to use DistroKit as a base layer for your own BSP.
Using layers you gain more separation between DistroKit and your own changes, but
you are still able to gain the comfort of a preconfigured BSP.</p>
</div>
<div class="section" id="a-working-environment">
<h3>A working environment</h3>
<p>Before we can go any deeper I assume that you have a working environment
where you can compile a bare DistroKit.</p>
<p>Robert has done a good job describing the necessary steps in his
<a class="reference external" href="https://www.pengutronix.de/de/blog/2017-08-28-DistroKit_Intro.html">blog post</a>.
The original PTXdist documentation provides some further reading on
<a class="reference external" href="https://www.ptxdist.org/doc/environment.html">how to get a working environment</a>.</p>
</div>
<div class="section" id="create-a-layer">
<h3>Create a layer</h3>
<p>For our new BSP let's start with an empty git:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte$ </span>mkdir<span class="w"> </span>my-fancy-layer-bsp
<span class="gp">chris@dauntless:~/Projekte$ </span><span class="nb">cd</span><span class="w"> </span>my-fancy-layer-bsp
<span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>git<span class="w"> </span>init
<span class="go">Initialized empty Git repository in /home/chris/Projekte/my-fancy-layer-bsp/.git/</span>
</pre></div>
</div><p>Let's now add DistroKit as the underlying layer.
This layer is called <em>base</em> in PTXdist.
<em>base</em> can be symlink to a DistroKit checkout.
But in this case you would not be able to store the state of your underlying
layer alongside with your BSP.
Thus I suggest to add <em>base</em> as a git submodule:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>git<span class="w"> </span>submodule<span class="w"> </span>init
<span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>git<span class="w"> </span>submodule<span class="w"> </span>add<span class="w"> </span>https://git.pengutronix.de/git/DistroKit<span class="w"> </span>base
<span class="go">Cloning into '/home/chris/Projekte/my-fancy-layer-bsp/base'...</span>
<span class="go">remote: Counting objects: 3163, done.</span>
<span class="go">remote: Compressing objects: 100% (2209/2209), done.</span>
<span class="go">remote: Total 3163 (delta 2203), reused 1268 (delta 814)</span>
<span class="go">Receiving objects: 100% (3163/3163), 10.88 MiB | 5.35 MiB/s, done.</span>
<span class="go">Resolving deltas: 100% (2203/2203), done.</span>
</pre></div>
</div><p>Let's assume we want to build a BSP for the v7a platform.
This means that we will end up with images for
the BeagleBone,
the Raspberry Pi 2 and
the RIoTboard.</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>ptxdist-2019.06.0<span class="w"> </span>platform<span class="w"> </span>base/configs/platform-v7a/platformconfig
<span class="go">info: selected platformconfig:</span>
<span class="go"> 'base/configs/platform-v7a/platformconfig'</span>
<span class="go">found and using toolchain:</span>
<span class="go">'/opt/OSELAS.Toolchain-2018.12.0/arm-v7a-linux-gnueabihf/gcc-8.2.1-glibc-2.28-binutils-2.31.1-kernel-4.19-sanitized/bin'</span>
</pre></div>
</div><p>(Note: Due to a bug in the auto-version detection in PTXdist 2019.06.0, we have
to call <tt class="docutils literal"><span class="pre">ptxdist-2019.06.0</span></tt> explicitely here.
In other versions, you can just use <tt class="docutils literal">ptxdist</tt> instead as usual.)</p>
<p>After this step you can – in general – build your BSP. You would end up with
an unaltered DistroKit.</p>
</div>
<div class="section" id="customising-your-layer">
<h3>Customising your layer</h3>
<p>At this point you can use PTXdist to configure your BSP to your needs.
One of the easiest steps is to set the name of your project. Run:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>ptxdist<span class="w"> </span>menuconfig
</pre></div>
</div><p>This command opens the PTXdist <em>menuconfig</em> interface.
Navigate to <em>Project Name & Version</em> and change the entries for <em>Vendor Name</em>
and <em>Project Name</em>.
Quit menuconfig saving your settings.</p>
<p>PTXdist will now write your new configuration into your layer.
To store your configuration PTXdist will create a new folder <em>config</em>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>ptxdist<span class="w"> </span>menuconfig
<span class="gp">#</span>
<span class="gp"># </span>configuration<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>.config
<span class="gp">#</span>
<span class="go">configuration written to .config</span>
<span class="go">*** End of the configuration.</span>
<span class="go">*** Execute 'ptxdist go' to build the project or try 'ptxdist help'.</span>
<span class="go">Saving 'my-fancy-layer-bsp/configs/ptxconfig'.</span>
<span class="go">Saving 'my-fancy-layer-bsp/configs/ptxconfig.diff'.</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>ls
<span class="go">base configs platform-v7a selected_platformconfig selected_toolchain</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>tree<span class="w"> </span>configs/
<span class="go">configs/</span>
<span class="go">├── ptxconfig</span>
<span class="go">├── ptxconfig.diff</span>
<span class="go">├── ptxconfig.diff.old</span>
<span class="go">└── ptxconfig.old</span>
<span class="go">0 directories, 4 files</span>
</pre></div>
</div><p>If you have look into the <em>ptxconfig.diff</em>, you will see that PTXdist uses this
file to store the difference to the configuration of the base layer:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>cat<span class="w"> </span>configs/ptxconfig.diff
<span class="go">a002d2d0d014be35adb806a041ab77a4</span>
<span class="go">PTXCONF_PROJECT="Really Cool Project"</span>
<span class="go">PTXCONF_PROJECT_VENDOR="My Fancy Company"</span>
</pre></div>
</div><p>You also see the MD5 checksum at the beginning of the file,
which pins down the state of the upstream configuration file,
so PTXdist can detect when the config diff is out of date.</p>
<p>The <em>ptxconfig</em> file is still a full PTXdist configuration. But since we are
using layers it also has all option of the lower layers enabled/disabled:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-layer-bsp$ </span>cat<span class="w"> </span>configs/ptxconfig<span class="w"> </span><span class="p">|</span><span class="w"> </span>head
<span class="gp">#</span>
<span class="gp"># </span>Automatically<span class="w"> </span>generated<span class="w"> </span>file<span class="p">;</span><span class="w"> </span>DO<span class="w"> </span>NOT<span class="w"> </span>EDIT.
<span class="gp"># </span>PTXdist<span class="w"> </span><span class="m">2019</span>.06.0
<span class="gp">#</span>
<span class="go">PTXCONF_DATAPARTITION=y</span>
<span class="gp">#</span>
<span class="gp"># </span>------------------------------------
<span class="gp">#</span>
</pre></div>
</div></div>
<div class="section" id="update-distrokit">
<h3>Update DistroKit</h3>
<p>Let's assume we have started our BSP using an older version of DistroKit that
was based on an older version of PTXdist.
I will construct this case by checking out an older revision of DistroKit.
In fact the version that I use will be the last commit that was based on
<em>ptxdist-2019.05.0</em>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte$ </span>mkdir<span class="w"> </span>my-fancy-legacy-layer-bsp
<span class="gp">chris@dauntless:~/Projekte$ </span><span class="nb">cd</span><span class="w"> </span>my-fancy-legacy-layer-bsp
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>git<span class="w"> </span>init
<span class="go">Initialized empty Git repository in /home/chris/Projekte/my-fancy-legacy-layer-bsp/.git/</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>git<span class="w"> </span>submodule<span class="w"> </span>init
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>git<span class="w"> </span>submodule<span class="w"> </span>add<span class="w"> </span>https://git.pengutronix.de/git/DistroKit<span class="w"> </span>base
<span class="go">Cloning into '/home/chris/Projekte/my-fancy-legacy-layer-bsp/base'...</span>
<span class="go">remote: Counting objects: 3163, done.</span>
<span class="go">remote: Compressing objects: 100% (2209/2209), done.</span>
<span class="go">remote: Total 3163 (delta 2202), reused 1268 (delta 814)</span>
<span class="go">Receiving objects: 100% (3163/3163), 10.88 MiB | 5.45 MiB/s, done.</span>
<span class="go">Resolving deltas: 100% (2202/2202), done.</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span><span class="nb">cd</span><span class="w"> </span>base/
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp/base$ </span>git<span class="w"> </span>checkout<span class="w"> </span>b26440afd8a94982bde54a8e801577ff4a7c78e4
<span class="go">Note: checking out 'b26440afd8a94982bde54a8e801577ff4a7c78e4'.</span>
<span class="go">HEAD is now at b26440a platform-v7a, platform-rpi: enable ARM unwinder</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp/base$ </span><span class="nb">cd</span><span class="w"> </span>..
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>ptxdist-2019.05.0<span class="w"> </span>platform<span class="w"> </span>base/configs/platform-v7a/platformconfig
<span class="go">info: selected platformconfig:</span>
<span class="go"> 'base/configs/platform-v7a/platformconfig'</span>
<span class="go">found and using toolchain:</span>
<span class="go">'/opt/OSELAS.Toolchain-2018.12.0/arm-v7a-linux-gnueabihf/gcc-8.2.1-glibc-2.28-binutils-2.31.1-kernel-4.19-sanitized/bin'</span>
</pre></div>
</div><p>In the next step we will do some modifications to our layer:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>ptxdist<span class="w"> </span>menuconfig
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>grep<span class="w"> </span><span class="s2">"2019.05.0"</span><span class="w"> </span>configs/ptxconfig
<span class="gp"># </span>PTXdist<span class="w"> </span><span class="m">2019</span>.05.0
<span class="go">PTXCONF_CONFIGFILE_VERSION="2019.05.0"</span>
</pre></div>
</div><p>Note that PTXdist stores its version inside the config file.</p>
<p>In the next step we will update our base-layer to a newer version.
At the time of writing <em>master</em> is based on <em>ptxdist-2019.06.0</em>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span><span class="nb">cd</span><span class="w"> </span>base/
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp/base$ </span>git<span class="w"> </span>checkout<span class="w"> </span>master
<span class="go">Previous HEAD position was b26440a platform-v7a, platform-rpi: enable ARM unwinder</span>
<span class="go">Switched to branch 'master'</span>
<span class="go">Your branch is up to date with 'origin/master'.</span>
<span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp/base$ </span><span class="nb">cd</span><span class="w"> </span>..
</pre></div>
</div><p>Updating our layer to the new DistroKit
(that is based on a new PTXdist release!)
is now just a matter of calling the correct version of <em>ptxdist migrate</em>:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>ptxdist-2019.06.0<span class="w"> </span>migrate
<span class="go">Updating 'my-fancy-legacy-layer-bsp/base/configs/ptxconfig'...</span>
<span class="gp">#</span>
<span class="gp"># </span>configuration<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>.config
<span class="gp">#</span>
<span class="go">Updating 'my-fancy-legacy-layer-bsp/configs/ptxconfig'...</span>
<span class="go">Outdated diff, forcing config update...</span>
<span class="gp">#</span>
<span class="gp"># </span>configuration<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>.config
<span class="gp">#</span>
<span class="go">Saving 'my-fancy-legacy-layer-bsp/configs/ptxconfig'.</span>
<span class="go">Saving 'my-fancy-legacy-layer-bsp/configs/ptxconfig.diff'.</span>
<span class="go">Updating 'my-fancy-legacy-layer-bsp/base/configs/platform-v7a/platformconfig'...</span>
<span class="gp">#</span>
<span class="gp"># </span>configuration<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>.config
<span class="gp">#</span>
<span class="go">Updating 'my-fancy-legacy-layer-bsp/configs/platform-v7a/platformconfig'...</span>
<span class="gp">#</span>
<span class="gp"># </span>configuration<span class="w"> </span>written<span class="w"> </span>to<span class="w"> </span>.config
<span class="gp">#</span>
<span class="go">Empty diff. Skipping 'my-fancy-legacy-layer-bsp/configs/platform-v7a/platformconfig'.</span>
</pre></div>
</div><p><em>Et voilà</em>, our layer has been automatically migrated to a new DistroKit version
and a new PTXdist release:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="gp">chris@dauntless:~/Projekte/my-fancy-legacy-layer-bsp$ </span>grep<span class="w"> </span><span class="s2">"2019.06.0"</span><span class="w"> </span>configs/ptxconfig
<span class="gp"># </span>PTXdist<span class="w"> </span><span class="m">2019</span>.06.0
<span class="go">PTXCONF_CONFIGFILE_VERSION="2019.06.0"</span>
</pre></div>
</div></div>
</div>
<p>A BSP (Board Support Package) in Embedded Software is the layer of software that
lets you run your application on a specific hardware.
For Pengutronix a BSP usually contains a bootloader, Linux Kernel and a
userspace.
DistroKit is our Demo-BSP that supports a variety of common evaluation boards.
DistroKit gives you a head start if you want to develop an application on top
of such an evaluation board with most of the hard problems already solved.</p>2019-06-18T00:00:00+01:00tag:www.pengutronix.de,2019-06-11:/2019-06-11-techweek-2019.htmlTechweek 20192019-06-11T00:00:00+01:00Chris FiegeMarie Mann<div class="section" id="techweek-2019">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x767" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_morning.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_morning.thumb.569ddfa9cf78079bd1a34fb7129cc959.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Morning mood above our techweek location</p>
</figcaption>
</figure>
</div><p>In a place, far, far away, where no customer could
find us, the Pengutronix team met for the annual Techweek.</p>
<p>The <em>Techweek</em> is a week full of tasty meals, hacking and discussions:
we are using the opportunity to talk about the big picture, focus on development
of long-lasting or new projects and getting ideas for Linux World Domination.</p>
<p>To give you an impression of some of the work, here is a selection:</p>
<ul class="simple">
<li><a class="reference external" href="https://www.pengutronix.de/en/blog/2019-06-05-RAUC-1.1.html">RAUC v1.1</a> was
released.</li>
<li>One of our colleagues packetized barebox for Arch Linux ARM,</li>
<li>some colleagues worked on debugging options using OpenOCD,</li>
<li>our graphics team thought on a test suite for their area of expertise</li>
<li>and we will be able to set up barebox on a system quite easily.</li>
</ul>
<p>But this is just a teaser and more information will follow...</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1152x1152" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_cake.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_cake.thumb.316f00196843e7a80a4b62a6d0e09105.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Cake</p>
</figcaption>
</figure>
</div><p>Besides inventing new technologies and hacking the cool stuff, the Techweek
shall be also an opportunity for having a chat and fun together.
Therefore we always have a collaborative event.</p>
<div class="section" id="amateur-radio-direction-finding">
<h3>Amateur Radio Direction Finding</h3>
<p>This year we did the fun version of
<a class="reference external" href="https://en.wikipedia.org/wiki/Amateur_radio_direction_finding">ARDF</a>.
The idea behind ADRF (which is sometimes also called "<em>fox hunting</em>")
is to find a transmitter using a direction finder.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_fuchs.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_fuchs.thumb.561fd8a121895343b9ea23f7633cc8a1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Transmitter in rain protection.
The antenna is not shown, but reaches about 5 meters high.</p>
</figcaption>
</figure>
</div><p>Two of our colleagues, who are HAM operators, used the break after lunch
to hide two transmitters (transmitting on 3.1MHz) in the nearby landscape.
The transmitters send their callsigns as morse code (usually <em>MO</em> "-- ---").
Since we did the fun version of ARDF, both transmitters were active all the time
and operated on different frequencies.
(The sport version of ARDF would be that both transmitters would transmit only
every few minutes and would send their callsign only once.)</p>
<p>We formed groups by drawing lots, equipped every group with a direction
finder and wished them good luck.
The direction finders are portable receivers that work on both, the H- and
E-field component.
Using both modes allows an operator to point the direction of the source of
the signal by observing the volume level of the signal in the earpiece.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2762x1024" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_sanatorium.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_sanatorium.thumb.b313de5e4128a31b3502e3d572630758.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Königsberg Sanatorium</p>
</figcaption>
</figure>
</div><p>The first transmitter was placed near an easy to reach parking lot.
This location wasn't that spectacular.
The second transmitter was hidden inside the area of an
<a class="reference external" href="http://www.koenigsberg-sanatorium.de/">old sanatorium</a> that
burned down a few years ago.
This spot gave us an exciting view on the old site and over the
nearby <a class="reference external" href="https://de.wikipedia.org/wiki/Granetalsperre">artificial lake</a>.</p>
</div>
<div class="section" id="infrastructure-review">
<h3>Infrastructure Review</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_room.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_room.thumb.b128beaaf776fe86fa672f5aec14dc83.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Our main room during the techweek.</p>
</figcaption>
</figure>
</div><p>Traveling with 28 hackers makes high demands on the available bandwidth and
latency of the internet connection.
Additionally for Embedded Development we need local services like a
TFTP and NFS server.
This means that all-in-all we need something like 100 or more DHCP leases and
lots of Ethernet ports (and WiFi connectivity)!</p>
<p>Some of our hackers are active in the local branch of the Freifunk Initiative
<a class="reference external" href="https://freifunk-bs.de">Freifunk Braunschweig</a>.
This year those colleagues used the
<a class="reference external" href="https://freifunk-bs.de/event.html">mobile WiFi equipment</a> to provide us
with WiFi coverage and a multi-path uplink into the internet.
Since those colleagues used the Pengutronix staff as lab mice to improve
their tooling, we think this is a fair deal.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_switch.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-06-11_techweek/2019-06-11_techweek_switch.thumb.2bcc8e615e334416ffee06b35df491a3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Some random switch from Freifunk Braunschweig.</p>
</figcaption>
</figure>
</div><p>The multi-path uplink uses up to three different wireguard tunnels to a
server on the internet.
On top of the tunnels OSPF is used to route the actual traffic from the clients to
the internet.
This allowed us to plug-and-play new uplinks.</p>
<p>Using this we combined two LTE uplinks (on different carriers) and the
landline DSL of our event location.
After just a few hours we ditched the DSL uplink:
a 6000kBit/s DSL just isn't state-of-the-art anymore.</p>
<p>During the week we generated up to 170 GB of traffic via LTE.
If this sounds little:
keep in mind that German mobile contracts usually come with less than 10 GB
per month!</p>
</div>
</div>
<p>In a place, far, far away, where no customer could
find us, the Pengutronix team met for the annual Techweek.</p>2019-06-11T00:00:00+01:00tag:www.pengutronix.de,2019-06-05:/2019-06-05-RAUC-1.1.htmlRAUC v1.1 Released2019-06-05T19:44:00+01:00Enrico Jörns<div class="section" id="rauc-v1-1-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p><a class="reference external" href="http://rauc.io/pages/download.html">Download</a> v1.1 release of RAUC</p>
</div>
</div>
<p>Just before the beautiful shine of the new has fully disappeared from
RAUC 1.0, it is now time to bring out a new release: v1.1.</p>
<p><a class="reference external" href="https://github.com/rauc/rauc/releases/tag/v1.1">https://github.com/rauc/rauc/releases/tag/v1.1</a></p>
<p>This release comes with some remarkable memory leakage fixes you should
not miss.</p>
<p>As new features, we now have full support for reading GRUB2
status like we had for the other bootloader implementations already.</p>
<p>A minor feature but quite useful for debugging certificate issues is the
new ability to use <tt class="docutils literal"><span class="pre">--dump-cert</span></tt> without requiring successful verification.</p>
<p>Especially system integrators may like the support for using multiple
keyring certificates from a directory. This will avoid conflicts when
installing multiple certificates from different build system packages.</p>
<p>As a result of various community feedback and discussion, this release
adds a bunch of documentation updates targeting potential
misunderstandings and explains some unclear topics in more detail.</p>
<p>We would like to say thank you to everyone who tested for v1.1,
reported issues or contributed new features!</p>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li>v1.1 <a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-1-released-jun-5-2019">changes list</a></li>
</ul>
</div>
</div>
<p>For those using <em>A+B+recovery</em> setups where <em>A+B</em> are controlled via the default
boot selection logic and <em>recovery</em> is booted as fallback without this mechanism,
RAUC also allows specifying the booted slot's name (not only the bootname) via
commandline (e.g. <tt class="docutils literal">rauc.slot=recovery.0</tt>).</p>
<p>Thanks to all contributors since v1.0: Angus Lees, Arnaud Rebillout, Beralt
Meppelink, Enrico Jörns, Evan Edstrom, Ian Abbott, Jan Lübbe, Michael Heimpold,
Rasmus Villemoes, Ulrich Ölmann, Vitaly Ogoltsov</p>
</div>
<p>Just before the beautiful shine of the new has fully disappeared from
RAUC 1.0, it is now time to bring out a new release: v1.1.</p>2019-06-05T19:44:00+01:00tag:www.pengutronix.de,2019-05-25:/2019-05-25-ripe78.htmlbbu's Diary: RIPE78 - Reykjavík2019-05-25T18:00:00+01:00Bjørn Bürger<div class="section" id="bbu-s-diary-ripe78-reykjavik">
<p>Bear and Penguin live a happy life until curiosity attracts them to a journey: to Reykjavík, a place of dreams, with the splendid smell of tomato infused coffee...</p>
<div class="section" id="penguins-and-bears">
<h3>Penguins and Bears</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x800" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_bbu_wtu.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_bbu_wtu.thumb.9726d13c41c98e0661ba1f1d17c2075f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>"Iceland! We are going to Iceland! Geysirs, Waterfalls, Datacentres and IPv6 everywhere!"
My fellow Linux Penguin was overly excited, and to be honest, so was I.
We had heard so many nice things about this country and its modern, state of the art internet infrastructure. Luckily, the first RIPE Meeting of 2019 took place in Reykjavík, Iceland from 20 to 24 May 2019,
so we could check it out. Here's our report :-)</p>
</div>
<div class="section" id="blocked-pipes-and-iot">
<h3>Blocked Pipes and IoT</h3>
<p>In memory of last years flight chaos, we decided to start our journey early on saturday morning. This turned out to be a brilliant idea, as it left room for some sightseeing prior the RIPE Meeting. We started with the "Golden Circle Tour", passing some of the natural wonders and other attractions around Reykjavík.
Some of our expectations might have been a little exaggerated, as <a class="reference external" href="https://ipv6-test.com/stats/country/IS">some statistics see</a> Icelands v6 adoption rate at only ~50% right now and the big Stóri Geysir has been inactive for several years due to some silicate depositions in it's pipes. But you can't have it all at once, so we enjoyed our ride and watched the smaller Strokkur Geysir, erupting once every ~10 minutes.</p>
<p>At <a class="reference external" href="https://fridheimar.is/">Friðheimar</a>, we learned a lot about sustainable cultivation of tomatoes and fruits under artificial lighting in greenhouses. With the help of heating and electric energy from geothermal springs, tomatoes can be cultivated around the year despite Iceland’s long and dark winters. Not to forget the mighty dutch bumblebees, who are busy pollinating the tomato plants. The IoT (Internet of Tomatoes, as they call it here), controlls temperature, humidity, carbon dioxide and lighting, providing information to it's owners Knútur and Helena, wherever they are. The internet is an amazing thing, isn't it? If you ever visit Friðheimar, try the tomato infused coffee (or one of the other tomato based dishes they serve in the small restaurant inside one of the greenhouses).</p>
</div>
<div class="section" id="monday">
<h3>Monday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x637" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_monday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_monday.thumb.f7bf6a4ee45f2fa24918430a174f18b2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Monday morning started with tutorials on RPKI, IPv6 and OSS for model driven network programming. Roughly 600 attendees from 58 countries checked in, more than a quarter of them beeing newcomers. Thankfully, Hans Petter Holen could resist and didn't spoil the day with <a class="reference external" href="https://photos.app.goo.gl/8PnTDm8jR5oBhEbA7">GoT details</a> (Penguin and Bear didn't have the chance to see the last episode yet) and Ólafur Guðmundsson could resist talking in icelandic all the way through his talk (although it really is a nice language). He provided some interesting insights about classification and reputation of ip addresses.
The rest of the day was filled with good coffee, provided by a local islandic roastery, several talks about EU roaming, streaming telemetry, network monitoring and measuring DNS "without breaking anything". Thanks for that, although I'd personally doubt that anyone would notice. The DNS system has been broken for quite some time and it seems to get worse with every attempt to fix it. Maybe we need some really new ideas in this field.</p>
</div>
<div class="section" id="tuesday">
<h3>Tuesday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x598" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_tuesday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_tuesday.thumb.515f8eb8c6f0c4f500dee265c6049edc.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Unlike the previous days, tuesday started with a little bit of rain. The second day of plenaries circled around
DDoS attacks, the DNS root, KSK rollover and related stuff, followed by some rather disturbing topics like
Open Source Software for lawful interception and the renewed russian internet regulation. I wonder, where the
penguin went ... he left the room mumbling about end-to-end encryption, privacy, Stasi 2.0 and Horst Seehofer.</p>
<p>We met again at "Whales of Iceland", where our tuesday social event took place and the Penguin
introduced me to the wonders of the <a class="reference external" href="http://valdis.is">ice cream parlor</a> around the corner :-)</p>
<p>The <a class="reference external" href="https://www.whalesoficeland.is/">Whales of Iceland exhibition</a> is really worth a visit: 23 man-made life size models
of various icelandic whales are populating a large hall. It's almost like beeing under water and watching these beautiful
creatures in their natural habitat. And you can even touch them :-D</p>
</div>
<div class="section" id="wednesday">
<h3>Wednesday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x800" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_wednesday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_wednesday.thumb.6647fbffce6974eb8862878299af7fe4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>As usual, wednesday started with working groups. The Penguin rolled his big eyes and went of to see the <a class="reference external" href="http://thepunkmuseum.is/">Icelandic Punk Museum</a>, while the rest of us had to endure endless policy duscussions around the distribution of some last IPv4-breadcrumbs to IXPs. Lucky penguin. Nikolas Pediaditis noted that the IPv4 pool might not last beyond RIPE 79 in
Rotterdam. So, the <a class="reference external" href="https://www.youtube.com/watch?v=hUJoR4vlIIs">end is neigh</a> and the four riders of the apocylpse are sliding gratiously through the clouds (most of the current IPv4 transfers appear to have been driven by cloud providers, which might explain a lot about the missing IPv6 Support in most of their services. The funny part: RIPE NCC may be the first RIR to upgrade to another /12 from IANA/PTI. Wait. What? IPv6 is depleted as well? <a class="reference external" href="https://bl.ocks.org/vasturiano/raw/ba0bdc27ddc2b13012e85b2a0b7a1c43/">Nope, not quite</a>.</p>
<p>In the open source wg, Wolfgang Tremmel and Sander Steffann presented their respective works on using virtualization frameworks
and containers for the ad hoc creation of routing labs for education. Max Rottenkolber talked about "Vita", a high performance site-to-site encryption implemented in snabb and lua on X86_64. We are living in an interesting world, that's for sure. And last, but not least, Mirjam Kühne and Charles Eckel talked about hackathons, organized by RIPE and IETF.</p>
<p>Meanwhile, the penguin had returned and followed some of the discussions about hate speech and mitigation thereof, practical implications for corporate censorship, etc in the cooperation working group. Since he had covered this rather political part of the evening, I joined a tech-meeting at <a class="reference external" href="https://nautholsvik.is/en/">Nauthólsvík Geothermal Beach</a> to improve my networking skills. The geothermal beach offers 39°C geothermal water and swimming in the North Atlantic at 8°C - side by side - accompanied by lots of discussions about IXPs, PNIs, BGP, etc.</p>
</div>
<div class="section" id="thursday">
<h3>Thursday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_thursday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_thursday.thumb.09b5f2b144b87edb8c60b2539b5d4b8e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>While the penguin followed the Anti-Abuse, Routing and Database Workinggroups, I decided to entertain some IPv6 and IoT topics instead:
Geoff Huston presented his findings regarding IPv6 reliability and came to a simliar realization as Enno Rey, who
shed some light to the current status of IPv6-only Wi-Fi networks. Summary: FOSDEM does it with thousands of
participants, Troopers and other conferences do it (and you should just try it as well). With 464XLAT, IPv6-only
is as usable as any legacy NATed Network, but you get rid of the maintenance burden for dualstack networks and
their bugs. Wifi-Networks are really easy in this regard, as most mobile devices supoort 464XLAT out of the box.
More than that: As Geoff Huston points out: Those Networks which have successfully deployed NAT64 and 464XLAT, succeed,
whereas dualstack will only carry you half way and happy eyeballs is covering up for it...</p>
<p>In the IoT Workinggroup, Mirjam Kühne presented about ethical, security and legal aspects of running an IoT network like the RIPE Atlas System. <a class="reference external" href="https://atlas.ripe.net/docs/">RIPE Atlas</a> is a fine example, how IoT devices in the field can be managed successfully and responsibly. It is well structured and has been maintained for years. I wonder, if projects like <a class="reference external" href="https://www.barebox.org/">the Barebox Bootloader</a>, <a class="reference external" href="https://www.ptxdist.org/">PTXdist</a>, the lightweight <a class="reference external" href="https://www.rauc.io">RAUC Remote Updating Framework</a> or the Testlab Automation with <a class="reference external" href="https://www.pengutronix.de/de/software/labgrid.html">Labgrid</a> could contribute to further development of the RIPE Atlas Ecosystem.</p>
<p>Matthias Wählisch gave a short report for the <a class="reference external" href="https://labs.ripe.net/Members/martine_sophie_lenders/riot-in-amsterdam">2018 RIOT summit in Amsterdam</a> and Jan Žorž asked: "Building a Smart House and You Want to Do It Yourself?", presenting his home as playground for all the IoT stuff you might want to have...but then you learn about the cold truth: The IOT world is a wild west and most of it is based on legacy stuff, so Jan decided to develop and build his own POE powered IPv6 sensor. That's the spirit!</p>
<p>And then ... there was Ice and the RIPE Dinner.</p>
</div>
<div class="section" id="friday">
<h3>Friday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_weekend.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-05-25_ripe78/2019-05-25_ripe78_weekend.thumb.01c0040344bf3ec38a8e9174f84297d8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>An update on the IANA Review Committee followed by an update from the ASO Address Council followed by an update by ... I honestly forgot.
Did you know how hard it is to keep track of day and night considering the midnight sun in iceland? There was <a class="reference external" href="https://ripe78.ripe.net/presentations/145-20190524-RIPE-78-Ziggy.pdf">the nice RPKI Waybackmachine</a>, The <a class="reference external" href="https://www.ripe.net/participate/meetings/gm/meetings/may-2019/presentations/results-of-voting-ripe-ncc-gm-may-2019.pdf">General Meeting voting results</a> and some talk about good peering. I can relate to that ;-)</p>
<p>Thanks for all the interesting conversations about IoT (be it the Internet of "Things", "Tomatoes" or "Tux"). Although the RIPE community may not be the right place to discuss some of the regulatory issues, the IoT is definitely of operational concern and the networking community needs to be involved in any solution to the raising problem of untrusted or outdated devices with direct or indirect internet access.
At RIPE76 and RIPE78, we have seen some approaches to mitigate DDOS Attacks by automatically quarantaining possibly compromised customer devices on the provider side, effectiveley taking the customer offline.
But this is only a reaction to the imminent thread of high-volume DDOS Attacks, run by a growing army of well-connected, but outdated devices. We need to think way beyond the current thread structure, as quarantaining remote controllable devices may render whole industrial infrastructures useless: You don't want to quarantaine an industrial customer, causing effective DOS, just because the customers traffic pattern changed suddenly. Instead, the coming IoT infrastructure needs to be built on reliable, public reviewed open source software. We can <a class="reference external" href="https://www.pengutronix.de/en/services/embedded-linux-consulting.html">help you with that</a>.</p>
<p>Waiting for your flight back is hard. This country is so boooo... OH! Wait! A lava tunnel! ... And a geothermal RIVER :-) ... And these beaches filled with black <a class="reference external" href="https://hekla.openlab.pengutronix.de/">lava</a> stones. I am in heaven!</p>
<p>Thanks to everyone for making RIPE78 such a great meeting!</p>
</div>
</div>
<p>Bear and Penguin live a happy life until curiosity attracts them to a journey: to Reykjavík, a place of dreams, with the splendid smell of tomato infused coffee...</p>2019-05-25T18:00:00+01:00tag:www.pengutronix.de,2019-05-14:/2019-05-14-barebox_ccimx6ulsbcpro.htmlPorting Barebox to the Digi CC-IMX6UL SBC Pro2019-05-14T00:00:00+01:00Rouven Czerwinski<div class="section" id="porting-barebox-to-the-digi-cc-imx6ul-sbc-pro">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2184x1638" href="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_som.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_som.thumb.2ae38482da38aa799b21e79428e90b77.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Close-up shot of the CC-IMX6-UL SOM on the SBC Pro board.</p>
</figcaption>
</figure>
</div><p>One of our projects required the addition of board support for the <a class="reference external" href="https://www.digi.com/products/models/cc-sbp-wmx-jn58">Digi
ConnectCore 6UL SBC Pro</a>
to the <a class="reference external" href="https://www.barebox.org">Barebox bootloader</a>.
This article outlines the used development setup and required additions to the
bootloader to support a board with a well supported processor.
Development of the board support was done live during the monthly talks at
<a class="reference external" href="https://stratum0.org">Stratum 0</a>, the hackerspace in Braunschweig. The video
(in German) is embedded at the end of the article.</p>
<div class="section" id="development-setup">
<h3>Development Setup</h3>
<p>For the development setup several items are required:</p>
<ol class="arabic simple">
<li>The evaluation board in question</li>
<li>Support for console access to the board</li>
<li>A way to load the bootloader onto the board</li>
<li>Optionally: a switchable power source</li>
</ol>
<p>While the first and second item are self-explanatory, the third requires some
context. Processors of the i.MX family support a boot mode where they wait for
the upload of a binary to the bootloader, which is then loaded into RAM and
executed. For the Digi board, this mode is enabled at boot time by shorting the
<cite>BOOT</cite> pin header on the board. Thereafter the board does not boot from internal
NAND flash and instead waits for the bootloader upload.
The upload is done by using the <a class="reference external" href="https://barebox.org/doc/latest/boards/imx.html?highlight=imx%20usb%20loader#usb-boot">imx-usb-loader</a>
tool which can be enabled in the barebox menu configuration.
The switchable power source during development of the board support was a
switchable externally powered USB hub.
To connect USB power to the barrel connector of the board, an adapter cable was used.
The board was shipped with a console adapter cable, and a standard Micro-USB
cable was used to connect to the Micro-USB port on the board.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3373x2529" href="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_usb.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_usb.thumb.91fca15428702b52d654a1d03fd6e3b3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>The ethernet, USB and audio ports on the SBC Pro board. Under the USB-A
ports, the Micro-USB-B port can be seen. This port is used for imx-usb-loader.</p>
</figcaption>
</figure>
</div></div>
<div class="section" id="porting-barebox">
<h3>Porting Barebox</h3>
<p>Porting barebox to the new board requires several distinct steps:</p>
<ul class="simple">
<li>First a new board folder is created and added to the board directory's Makefile.
This new Makefile already uses the new Kconfig symbol for the board.</li>
<li>The Kconfig symbol is added to the correct Kconfig file for the board's architecture.</li>
<li>Next we enable the device tree support for the board and create a Makefile entry
for it as well.</li>
<li>The used i.MX architecture requires the DCD table entries for the initialization
done during the boot ROM.
We acquire these from the downstream U-Boot Digi repository.</li>
<li>Finally, the new image is added to the appropriate image Makefile.</li>
</ul>
<div class="section" id="board-files">
<h4>Board Files</h4>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4187x3140" href="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_console.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-16_barebox-ccimx6ulsbcpro/2019-04-16_barebox_ccimx6ulsbcpro_console.thumb.301d39b484418d3a08c354372cd1e1ed.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Console access port on the Digi board. The board is shipped with the USB
cable, the TTL-UART-to-USB converter is contained in the USB connector.</p>
</figcaption>
</figure>
</div><p>The port is started by copying the board files from a similar board which is
already supported by barebox.
The PICO Hobbit with a <a class="reference external" href="https://www.technexion.com/products/system-on-modules/pico/pico-compute-modules/detail/PICO-IMX6UL">PICO-IMX6UL SoM</a>
in <tt class="docutils literal"><span class="pre">arch/arm/boards/technexion-pico-hobbit</span></tt> provides a good starting point for the Digi board.
That board folder is copied to a new folder named <cite>digi-ccimx6ulsbcpro</cite>.
The folder itself contains several files:</p>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">flash-header.imxcfg</span></tt> files which contain the DCD table entries</li>
<li>C files for board and lowlevel support</li>
<li>a Makefile describing the different objects for prebootloader and barebox</li>
</ul>
<p>The flash header files can safely be deleted and the Makefile can remain
untouched.
The files <tt class="docutils literal">board.c</tt> and <tt class="docutils literal">lowlevel.c</tt> require changes for the new board.
The PICO Hobbit SoM has multiple memory variants, but our first port for the
Digi board will only support one variant.
Furthermore, the new Digi board uses a different UART as the main console, this
needs to be adjusted in the lowlevel file.
The new board folder also needs to be added to <tt class="docutils literal">arch/arm/boards/Makefile</tt>.</p>
</div>
<div class="section" id="kconfig-symbol">
<h4>Kconfig Symbol</h4>
<p>Since the Digi board uses an i.MX6UL, the board needs to be added to the
<tt class="docutils literal"><span class="pre">mach-imx</span></tt> architecture Kconfig file:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">config</span><span class="w"> </span>MACH_DIGI_CCIMX6ULSBCPRO
<span class="w"> </span><span class="nb">bool</span><span class="w"> </span><span class="s2">"Digi International CC-IMX6UL SBC Pro"</span>
<span class="w"> </span><span class="k">select</span><span class="w"> </span>ARCH_IMX6
<span class="w"> </span><span class="k">select</span><span class="w"> </span>ARCH_IMX6UL
<span class="w"> </span><span class="k">select</span><span class="w"> </span>ARM_USE_COMPRESSED_DTB
</pre></div>
</div></div>
<div class="section" id="device-tree-support">
<h4>Device Tree Support</h4>
<p>Barebox already periodically synchronizes the upstream device trees from the
Linux kernel. All which has to be done is to add the barebox specific device
nodes to the device tree which will be compiled into our barebox binary.
In case of the Digi board, the barebox specific entry is the <em>chosen</em> node for the
stdout of barebox:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="cm">/* include the upstream device tree from /dts/src/arm/ */</span>
<span class="cp">#include</span><span class="cm"> </span><span class="cpf"><arm/imx6ul-ccimx6ulsbcpro.dts></span>
<span class="nf">/</span><span class="p">{</span>
<span class="w"> </span><span class="nf">chosen</span><span class="cm"> </span><span class="p">{</span>
<span class="w"> </span><span class="n">stdout-path</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">&</span><span class="n">uart5</span><span class="p">;</span>
<span class="w"> </span><span class="p">};</span>
<span class="p">};</span>
</pre></div>
</div></div>
<div class="section" id="dcd-table-entries">
<h4>DCD table entries</h4>
<p>The DCD tables entries are important for the initialization of the DDR memory
controller. The downstream U-Boot of Digi International provides the values for
the CC-IMX6UL SoM <a class="reference external" href="https://github.com/digi-embedded/u-boot/blob/v2018.03/maint/board/digi/ccimx6ul/imximage.cfg">here</a>.
The important parts for the barebox flash header begin with the <cite>DATA 4</cite>
entries.
These entries are copied from the U-Boot configuration file.
Then the <cite>DATA 4</cite> directives are replaced with <cite>wm 32</cite> directives, since the
barebox DCD interpreter uses different directives than U-Boot.
Additionally, a barebox specific header has to be added:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="n">loadaddr</span><span class="w"> </span><span class="mh">0x80000000</span>
<span class="n">soc</span><span class="w"> </span><span class="n">mx6</span>
<span class="n">dcdofs</span><span class="w"> </span><span class="mh">0x400</span>
</pre></div>
</div><p>The <tt class="docutils literal">loadaddr</tt> describes the address where the bootloader will be loaded to on the
SoC, on the i.MX6ul 0x80000000 corresponds to the beginning of RAM.
Next, the SoC is described and the DCD table offset within the image is defined.</p>
</div>
<div class="section" id="image-creation">
<h4>Image creation</h4>
<p>The required entries for the images Makefile are listed here:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="nv">pblb-$(CONFIG_MACH_DIGI_CCIMX6ULSBCPRO)</span><span class="w"> </span><span class="o">+=</span><span class="w"> </span>start_imx6ul_ccimx6ulsbcpro
<span class="nv">CFG_start_imx6ul_ccimx6ulsbcpro.pblb.imximg</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="k">$(</span>board<span class="k">)</span>/digi-ccimx6ulsbcpro/flash-header-imx6ul-ccimx6ulsbcpro.imxcfg
<span class="nv">FILE_barebox-imx6ul-ccimx6ulsbcpro.img</span><span class="w"> </span><span class="o">=</span><span class="w"> </span>start_imx6ul_ccimx6ulsbcpro.pblb.imximg
<span class="nv">image-$(CONFIG_MACH_DIGI_CCIMX6ULSBCPRO)</span><span class="w"> </span><span class="o">+=</span><span class="w"> </span>barebox-imx6ul-ccimx6ulsbcpro.img
</pre></div>
</div><p>The first line describes the entry function of the pre-bootloader.
This function was created in the <tt class="docutils literal">lowlevel.c</tt> file.
The second line describes the flash header to be used for the image, which is
compiled into an <em>imximg</em> file.
The third line adds the prebootloader image to the barebox image.
Finally, the image creation is enabled if the corresponding Kconfig variable is
enabled in the configuration.</p>
</div>
<div class="section" id="further-work">
<h4>Further Work</h4>
<p>This concludes the port of barebox to the Digi board. Barebox can now be
loaded onto the board with <em>imx-usb-loader</em> and returns a usable prompt.
What remains to be tested and added are the following points:</p>
<ul class="simple">
<li>Support for the OCOTP node to read the persistent MAC address from the device</li>
<li>Addition of NAND partition nodes to use <tt class="docutils literal">barebox_update</tt></li>
<li>Test of the persistent barebox flashed to NAND</li>
<li>Test of the Ethernet PHYs to verify that network works</li>
</ul>
<p>After these points have been addressed, the resulting patch can be sent to the
mailing list and this blog post will be updated with a link to the patch.</p>
<p><strong>Update</strong>: Version 2 of the upstream barebox patch can be found here:
<a class="reference external" href="http://lists.infradead.org/pipermail/barebox/2019-May/038026.html">http://lists.infradead.org/pipermail/barebox/2019-May/038026.html</a></p>
</div>
</div>
<div class="section" id="video">
<h3>Video</h3>
<p>The video recorded during the Stratum 0 talks (in german) is embedded here:</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/FIwF6GfmsWM"></iframe>
</div>
</div>
</div><p>One of our projects required the addition of board support for the <a class="reference external" href="https://www.digi.com/products/models/cc-sbp-wmx-jn58">Digi
ConnectCore 6UL SBC Pro</a>
to the <a class="reference external" href="https://www.barebox.org">Barebox bootloader</a>.
This article outlines the used development setup and required additions to the
bootloader to support a board with a well supported processor.
Development of the board support was done live during the monthly talks at
<a class="reference external" href="https://stratum0.org">Stratum 0</a>, the hackerspace in Braunschweig. The video
(in German) is embedded at the end of the article.</p>2019-05-14T00:00:00+01:00tag:www.pengutronix.de,2019-04-05:/2019-04-05-usb-sd-mux_emc.htmlUSB-SD-Mux: EMC Testing2019-04-05T00:00:00+01:00Chris Fiege<div class="section" id="usb-sd-mux-emc-testing">
<p>Today Jonas and I went to our EMC testing lab to continue the measurements
needed to certify electromagnetic compatibility for the
<a class="reference external" href="https://www.pengutronix.de/en/tags/usb-sd-mux.html">USB-SD-Mux</a>.</p>
<p>To make it short: It has passed the radiation tests.
In the end we found out that it wasn't the USB-SD-Mux itself that caused us a
lot of headache.
We are now quite confident that most radiation was caused by the system we
used to stimulate the USB-SD-Mux.
In the end we had the stimulation-box (containing a Beagle Bone Black) hidden behind
multiple absorber-panels beneath the measurement table.
This way we were able to dampen enough noise to pass tests.
It seems for our next measurements we need to find something other than
a Beagle Bone Black for that.</p>
<p>This brings us a lot closer to finally bring the USB-SD-Mux to you.
But testing is not completely done:
Next step is to pass the RF-immunity tests.
We keep our fingers crossed!</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-ant.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-ant.thumb.7f87990b487f512273c51d187931d804.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Wideband antennae in the measurement chamber.
It's surprisingly dark in there.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-box.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-box.thumb.bb627477ddc01305d907918f45417b41.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>This box contains the Beagle Bone Black we used to stimulate our
devices under test.
Hidden behind a lot of absorbers we were finally able to suppress most
of it's noise.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x820" href="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-dut.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-dut.thumb.95a9b057626f3c1a598525a0be38974c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The USB-SD-Mux has evolved since our last blog post.
During the test we used one USB-SD-Mux as a card reader and the other as
a multiplexer.
This way we have control about the card reader and can test both modes
in one measurement.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x1365" href="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-selfie.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-04-05_usb-sd-mux-emc/2019-04-05_usb-sd-mux_emc-selfie.thumb.86706b16fa9ac93b710b8a1cfe9a4e30.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
<p>Today Jonas and I went to our EMC testing lab to continue the measurements
needed to certify electromagnetic compatibility for the
<a class="reference external" href="https://www.pengutronix.de/en/tags/usb-sd-mux.html">USB-SD-Mux</a>.</p>2019-04-05T00:00:00+01:00tag:www.pengutronix.de,2019-03-25:/2019-03-25-netdev-0x13.htmlNetdev 0x132019-03-25T00:00:00+01:00Marc Kleine-Budde<div class="section" id="netdev-0x13">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5184x3880" href="https://www.pengutronix.de/media/blog/2019/2019-03-25_netdev-0x13/2019-03-25_netdev-0x13_bridge.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-25_netdev-0x13/2019-03-25_netdev-0x13_bridge.thumb.919638a9350453632bfce998cc855fff.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>This year's iteration of the <a class="reference external" href="https://netdevconf.org/0x13/">Netdev</a>, the technical conference on Linux
networking, was held at the Hotel Grandium, Prague in mid
March.
Pengutronix was asked to attend the <a class="reference external" href="https://netdevconf.org/0x13/session.html?workshop-on-iot-related-mac-layers-header-compressions-and-routing-protocols">IoT Workshop</a>,
which we did with two developers.</p>
<div class="section" id="introduction">
<h3>Introduction</h3>
<p>For the usual hacker it was a bit too early in the morning at 8:30 when
Stefan Schmidt opened this year's IoT workshop.</p>
<p>After Stefan's welcoming words he gave an overview of the session
followed by all attendees introducing themselves.</p>
</div>
<div class="section" id="can-and-iot">
<h3>CAN and IoT</h3>
<p>Although the CAN protocol has been around for a while, with a bit of
abstraction, CAN is used in a similar fashion as modern IoT
communication hardware.
Linux based devices that include one or more CAN buses are usually some kind of
embedded hardware.
CAN is used in many cases to communicate with actuators and sensors that are
less powerful and don't run Linux.
In others, a CAN bus may include several Linux based electronic control units (ECUs).</p>
</div>
<div class="section" id="can-basics-and-discussion">
<h3>CAN Basics and Discussion</h3>
<p>My co-worker Oleksij Rempel held a presentation about the CAN networking
stack on Linux in general, as well as the ongoing activities of
mainlining an SAE J1939 compatible stack. This talk laid the foundations for
the following discussion, that was focused on the challenges of the CAN
networking stack:</p>
<ul class="simple">
<li>lots of small packets (only 8 bytes of payload)</li>
<li>J1939 messages up to 112 MiB</li>
<li>packet scheduling, <tt class="docutils literal">fq_codel</tt></li>
</ul>
</div>
<div class="section" id="packet-scheduling-and-fq-codel">
<h3>Packet Scheduling and fq_codel</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2019/2019-03-25_netdev-0x13/2019-03-25_netdev-0x13_guitar.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-25_netdev-0x13/2019-03-25_netdev-0x13_guitar.thumb.43e50f6fb0ad502b41d7d209785636ee.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Almost a year ago an <a class="reference external" href="https://github.com/systemd/systemd/issues/9194">issue</a> popped up on the
systemd issue tracker. The problem is that some distributions set the
default packet scheduler to <tt class="docutils literal">fq_codel</tt>, either via the kernel
configuration or systemd's <tt class="docutils literal"><span class="pre">systemd-sysctl</span></tt> service.</p>
<p>The <tt class="docutils literal">fq_codel</tt> packet scheduler works great for TCP/IP but causes
lots of silently dropped CAN frames, which renders CAN unusable on
these setups.</p>
<p>After the IoT workshop I talked to several people about the problem
which helped me to understand the problem better. But at the end of
day one Dave Taht, co-founder of the Bufferbloat project, got in touch
with me.</p>
<p>After an insightful meeting with Dave on the next day, several hours
of browsing kernel code, hacking and testing later, I posted the
following <a class="reference external" href="https://lore.kernel.org/netdev/20190327165632.10711-1-mkl@pengutronix.de/t/#u">RFC patch series</a>
to solve the problem:</p>
<blockquote>
<p>There is networking hardware that isn't based on Ethernet for layers 1 and 2.</p>
<p>For example CAN.</p>
<p>CAN is a multi-master serial bus standard for connecting Electronic Control
Units [ECUs] also known as nodes. A frame on the CAN bus carries up to 8 bytes
of payload. Frame corruption is detected by a CRC. However frame loss due to
corruption is possible, but a quite unusual phenomenon.</p>
<p>While fq_codel works great for TCP/IP, it doesn't for CAN. There are a lot of
legacy protocols on top of CAN, which are not build with flow control or high
CAN frame drop rates in mind.</p>
<p>When using fq_codel, as soon as the queue reaches a certain delay based length,
skbs from the head of the queue are silently dropped. Silently meaning that the
user space using a send() or similar syscall doesn't get an error. However
TCP's flow control algorithm will detect dropped packets and adjust the
bandwidth accordingly.</p>
<p>When using fq_codel and sending raw frames over CAN, which is the common use
case, the user space thinks the packets have been sent without problems, because
send() returned without an error. pfifo_fast will drop skbs, if the queue
length exceeds the maximum. But with this scheduler the skbs at the tail are
dropped, an error (-ENOBUFS) is propagated to user space. So that the user
space can slow down the packet generation.</p>
<p>On distributions, where fq_codel is made default via CONFIG_DEFAULT_NET_SCH
during compile time, or set default during runtime with sysctl
net.core.default_qdisc (see [1]), we get a bad user experience. In my test case
with pfifo_fast, I can transfer thousands of million CAN frames without a frame
drop. On the other hand with fq_codel there is more then one lost CAN frame per
thousand frames.</p>
<p>As pointed out fq_codel is not suited for CAN hardware, so this patch
introduces a new netdev_priv_flag called "IFF_FIFO_QUEUE" (in contrast to the
existing "IFF_NO_QUEUE").</p>
<p>During transition of a netdev from down to up state the default queuing
discipline is attached by attach_default_qdiscs() with the help of
attach_one_default_qdisc(). This patch modifies attach_one_default_qdisc() to
attach the pfifo_fast (pfifo_fast_ops) if the "IFF_FIFO_QUEUE" flag is set.</p>
</blockquote>
<p>And for those who wonder, the gentleman playing guitar at netdev's social
event, that's Dave.</p>
</div>
</div>
<p>This year's iteration of the <a class="reference external" href="https://netdevconf.org/0x13/">Netdev</a>, the technical conference on Linux
networking, was held at the Hotel Grandium, Prague in mid
March.
Pengutronix was asked to attend the <a class="reference external" href="https://netdevconf.org/0x13/session.html?workshop-on-iot-related-mac-layers-header-compressions-and-routing-protocols">IoT Workshop</a>,
which we did with two developers.</p>2019-03-25T00:00:00+01:00tag:www.pengutronix.de,2019-03-20:/2019-03-20-labgrid-logo.htmlA Logo for labgrid2019-03-20T00:00:00+01:00Enrico Jörns<div class="section" id="a-logo-for-labgrid">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="741x350" href="https://www.pengutronix.de/media/blog/2019/2019-03-20_labgrid-logo/labgrid_logo.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-20_labgrid-logo/labgrid_logo.thumb.e517c9005472a2987793bd5663bcacb2.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>It took us a while to find a good logo for one of our latest (but already
quite-a-few-years-out) software projects, called labgrid.
In case you have not heard of it yet, feel free to read our short <a class="reference external" href="https://www.pengutronix.de/de/blog/2017-05-11-labgrid_released.html">blog post</a> from 2017 or
visit labgrid's <a class="reference external" href="https://github.com/labgrid-project/labgrid">GitHub page</a>.</p>
<p>Finding an expressive logo was not that easy because it is quite abstract and
hard to depict what labgrid actually does or provides.</p>
<p>Basically, labgrid is an abstraction framework bridging the gap between
pure hardware control and high-level software description.</p>
<p>The new logo now symbolizes this link between the hardware layer on one side
(depicted by the plug symbol) and the software interface on the other side,
depicted by the UML-like interface symbol.
It also comes in the same style as our other projects, such as
<a class="reference external" href="https://rauc.io">RAUC</a>,
<a class="reference external" href="https://www.ptxdist.org/">PTXdist</a> or
<a class="reference external" href="https://www.barebox.org/">barebox</a>.</p>
<p>We would like to thank <a class="reference external" href="https://morr.cc/">@blinry</a> for developing our
initial hand-drawn drafts (selected from a long list of other ideas) into a
clear and beautiful logo.</p>
<p>The new logo is already rolled out to <a class="reference external" href="https://github.com/labgrid-project/labgrid">GitHub</a> as well as
our internal <a class="reference external" href="https://www.pengutronix.de/de/software/labgrid.html">project website</a>.
We hope that you will like it as much as we do.</p>
</div>
<p>It took us a while to find a good logo for one of our latest (but already
quite-a-few-years-out) software projects, called labgrid.
In case you have not heard of it yet, feel free to read our short <a class="reference external" href="https://www.pengutronix.de/de/blog/2017-05-11-labgrid_released.html">blog post</a> from 2017 or
visit labgrid's <a class="reference external" href="https://github.com/labgrid-project/labgrid">GitHub page</a>.</p>2019-03-20T00:00:00+01:00tag:www.pengutronix.de,2019-03-16:/2019-03-16-clt-2019.htmlDiary: Chemnitzer Linux Tage 20192019-03-16T00:00:00+01:00Chris FiegeRobert Schwebel<div class="section" id="diary-chemnitzer-linux-tage-2019">
<p>In this article we are writing our diary about the two fascinating days
at the Chemnitzer Linux Tage 2019.
We invite you to visit us at our booth.
This year the <a class="reference external" href="https://wwww.osadl.org/">OSADL</a> is our guest.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ptxdist.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ptxdist.thumb.c3dc073de2c0751cca3f79a073c3ba69.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4096x3072" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ptxstand2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ptxstand2.thumb.fe89dcd029a89a2ecd0c795d7423524e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4081x2374" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ausstellung.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ausstellung.thumb.3a43e9d8dc56017a2a71d36d7de20733.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div><div class="section" id="managementtool-from-the-open-source-development">
<h3>Managementtool from the Open-Source Development</h3>
<p>Saturday begins early at 10:00 with a
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/180">talk from Marie</a>.
Marie reports about how we at Pengutronix replaced our Wiki-based
processmanual with a hacker-friendly solution.</p>
<p>Marie points out that our requirements have been:</p>
<ul class="simple">
<li>usability for all users</li>
<li>participation</li>
<li>approval from our management</li>
<li>optional later ISO 9001 certification</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2789x2789" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_mcm.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_mcm.thumb.fab7f7f3958aea48876701483433162e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>As a company providing services around Linux-development <cite>hacker tools</cite> are
established with our employees.
Thus we want to use these very same tools for our process manual.
That means:</p>
<ul class="simple">
<li>Processes are documented as <cite>Restructured Text</cite>.</li>
<li>Metadata are part of the plain text document.</li>
<li>We use <cite>git</cite> to manage all the files.</li>
<li>We use Sphinx to translate the processes into a website.
This makes it possible for our <cite>non-hacker</cite> employees to read the processes.</li>
</ul>
<p>Marie's talk continued with the git workflow we use to edit the
processmanual:</p>
<ul class="simple">
<li>We have a protected <cite>master branch</cite> that can only be written by the
management.</li>
<li>Employees can create their own <cite>topic branches</cite> in the same repository in
which they improve old or design new processes.</li>
<li>The management reviews the new processes before merging them into the
master branch.</li>
</ul>
<p>The next part of Marie's talk is about how we use <cite>continuous integration</cite> to
translate the plaintext into a website using git, Sphinx and Jenkins.</p>
<p>Marie wants to motivate all decision-makers to take a closer look
at their employee's workflows. And to have the courage to select the
tools making to those workflows for process manuals.</p>
</div>
<div class="section" id="container-stuff">
<h3>Container Stuff</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2659x2659" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_container.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_container.thumb.534b6b830ca49ab7c58cdfbea0a6e29d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>My next talk was at 12:00 with
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/314">Martin Neitzel</a>.
The schedule announced his talk as <cite>Linux container basics</cite>;
but his first (and only) slide was titled <cite>Container Stuff</cite>. After he threw the
first packs of gummy bears into the audience it was clear:
this is going to be a fun talk.</p>
<p>Martin's solution is not to use an off-the-shelf solution like <cite>Docker</cite> or
<cite>LXC</cite>.
Instead he took a look at the low-level APIs for container.
And thus the first half of Martin's talk is about <cite>unshare</cite>, <cite>setns</cite> and
alike.</p>
<p>In the second part of his presentation he showed us how to use the
<cite>systemd-nspawn</cite> as a thin wrapper around these low-level functions.</p>
</div>
<div class="section" id="recordings-at-the-clt-with-ai">
<h3>Recordings at the CLT with AI</h3>
<p>My last talk for today is done by
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/343">Daniel Schreiber</a>.
He talks about how videos are recorded at the CLT and how AI is used in that
process.</p>
<p>Before this year the slides were grabbed using a HDMI-grabber and the
sound was recorded from the amplifier in the room.
But there was no recording of the speaker.
This is mainly caused by the fact that the CLT do not have enough helping
hands to have a camera-helper in every room.</p>
<p>Last year Daniel recorded the speaker in one lecture room using a 4K-camera
to create a data basis for further software development.</p>
<p>He uses <a class="reference external" href="https://opencv.org/">OpenCV</a> to process the video files.
First he tries to track the faces of the speakers.
The results were moderate at best.
In the next step he tries to track the movements of the speaker during his talk.
Again with moderate results.
The tracker got distracted too easily.</p>
<p>Daniel therefore gave in to the hype of neuronal networks.
Naturally he got a bunch of new problems:
different sorting of the color channels, differing range of values, lack of
computing power, reasonable prepossessing and more...</p>
<p>But in the end he is able to track the speaker using a lot of computing power
and interpolation. That makes it possible to crop out the part of the
video that contains the speaker - just as a helping hand at the camera would.</p>
<p>Daniel has already deployed the new technique for this year's CLT:
There are new racks with video-equipment and he is using multiple HDMI-grabbers
with audio input.
It looks like we can look forward to recordings containing videos of the slides
and the speaker from this years CLT.</p>
</div>
<div class="section" id="writing-ansible-modules">
<h3>Writing Ansible Modules</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2039x2039" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ansible.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_ansible.thumb.0f92925f541b55059b201af8fc026213.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Sunday begins late at 11:00.
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/290">Martin Schütte</a>
gives an
<a class="reference external" href="https://noti.st/mschuett/WEGXSS/writing-ansible-modules">introduction</a>
in writing
<a class="reference external" href="https://docs.ansible.com/ansible/latest/modules/modules_by_category.html">Ansible Modules</a>.
His poll at the beginning shows: half of the audience identify themselves as
sysadmins, the other half identifies as software developers.</p>
<p>Martin begins his talk with the hint, that one should take a good look
at the Ansible Module index before writing any code.
A lot can be achieved using stuff what is already there.
He uses code examples to give an overview how Ansible Modules work.
Martin continues with design patterns as well as <cite>dos</cite> and <cite>don'ts</cite> for the
development of Ansible Modules.</p>
</div>
<div class="section" id="bringing-light-into-the-dark">
<h3>Bringing Light into the Dark</h3>
<p>At 12:00
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/242">Alexander Schreiber</a>
started with his talk about
<a class="reference external" href="https://prometheus.io/">Prometheus</a>
and
<a class="reference external" href="https://grafana.com/">Grafana</a>.
He begins this talk with a lot of things that monitoring should be able to do.
That includes the metrics that should be monitored and useful alerting.</p>
<p>He continues to present the history and architecture of Prometheus.</p>
</div>
<div class="section" id="scripting-gdb-with-python">
<h3>Scripting GDB with Python</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3072x4096" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_mol.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_mol.thumb.7754d22d527952135dc3c16578991d85.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Michael Olbrich, developer in the Pengutronix graphics team, shows in
his talk at 12:00 how to manage the challenges that arise when debugging
complex GStreamer video pipelines. Unfortunately, those pipelines are
both highly dynamic and complex and involve many threads. In case of a
bug, looking into the code with GDB often shows highly complex and
convoluted data structures. In the past, this often led to a lot of
debug effort.</p>
<p>Meanwhile GDB got a debug interface which can be scripted with Python.
Michael shows in his talk how to write <cite>pretty printers</cite> - little python
scripts that make it possible to output well structured information that
can be gained from the internal structures using the full power of
Python. With the toolbox, complex interdependencies between structured data
can be visualized in a well arranged way. Further on, it is
possible to write selfmade GDB commands and functions.</p>
</div>
<div class="section" id="kernel-panel">
<h3>Kernel-Panel</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4096x3072" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_kernelpanel.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_kernelpanel.thumb.1885bdaeeb8e53d8221c4a8a3d91e5ff.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Like in the last years, Wolfram Sang moderates the kernel panel, and our
colleague Lucas Stach, graphics developer and Etnaviv maintainer, was
one of the participants on stage. The panel asked for questions from the
audience. A topic that comes up almost every year is quality, and
surprisingly it turned out that today it is often easier for embedded
companies to use modern mainline kernels in production systems than for
enterprise distributors. While embedded devices have a restricted set of
functionality and can be well tested for their use cases, enterprise
distros must take any use into account, and thus sometimes collect up to
40.000 patches, bringing up new quality challenges. Other discussed
topics involved the trend towards more proprietary firmware in modern
CPUs and the recent discussions about Spectre and Meltdown.</p>
</div>
<div class="section" id="the-rest-of-sunday">
<h3>The Rest of Sunday</h3>
<p>We spent the rest of the day with exiting discussions at our and other booths and
enjoyed the <cite>Chemnitz Catering Days</cite> (as the catering-team calls themselves).</p>
<p>We want to thank all organizers, supporters, speakers, exhibitors and visitors.
From our own experience we know how much hard work it takes to make such a
event possible.
All the more we are amazed how smooth and trouble-free everything went.
It was fun to be at the CLT, meet friends and make new ones.</p>
</div>
<div class="section" id="some-more-impressions-from-today">
<h3>Some More Impressions from Today</h3>
<p>These are some more impressions from today that did not fit under any other
headline, but are still worth sharing:</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_schild.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_schild.thumb.864f76b36726e645bd9d098dc27f8831.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3004x3004" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_catering.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_catering.thumb.173dba192b904c288bd82b6103a9cde8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3138x3138" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_bunt.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_bunt.thumb.2761932deaaeb5609dedd49b9f9ec927.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_schatten.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-16_clt-2/2019-03-16_clt-2019_schatten.thumb.984d88a2fa54d813eb039232b239411d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>In this article we are writing our diary about the two fascinating days
at the Chemnitzer Linux Tage 2019.
We invite you to visit us at our booth.
This year the <a class="reference external" href="https://wwww.osadl.org/">OSADL</a> is our guest.</p>2019-03-16T00:00:00+01:00tag:www.pengutronix.de,2019-03-04:/2019-03-04-whats-new-in-linux-5.0.htmlPengutronix Contributions to Linux 5.02019-03-04T00:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-contributions-to-linux-5-0">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="871x581" href="https://www.pengutronix.de/media/blog/2019/2019-03-04_whats-new-in-linux-5-0/2019-03-04_linux5.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-04_whats-new-in-linux-5-0/2019-03-04_linux5.thumb.95c9bd4d6ff3129d8f38c05d57e3a760.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Linux 5.0 is out, and while Linus keeps on telling everyone that the
number has no special meaning at all, we again contributed about 90
patches as part of our work on industrial projects.</p>
<p>Marco Felsch and Michael Grzeschik added a set of patches to improve
support for the MT9M111 camera chip. Userspace code is now able to
select several formats, framerates and the streaming status, while board
support code is now able to configure the PCLK polarity. Another device
Marco worked with was the TVP5150, a chip that converts analog video to
digital video. He improved the probe code. In addition, he added support
for the DLC1010GIG TFT panel.</p>
<p>Philipp Zabel worked on graphics and video topics. In one of the
patches, he made the error handling more robust by avoiding
false-positive bugs that happen if a userspace dies unexpectedly while
the framebuffer is updated on a DRM plane. For the CODA video unit on
i.MX6, the deblocking filters for H.264 have been fixed for negative
offsets. The offset handling has been adapted in a way that can 1:1
reuse the information from the H.264 headers. Two other patches improve
the debug output and the error output of the CODA driver. Several v4l2
test suite compliance fixes improves the error handling for the case
that the application tries to modify a read-only target, limit the time
per frame to useful values and allow enumeration of the frame interval.
Another patch reduces the minimal video size from 176x144 to 48x16
pixel. A more complex patch models the prefetch mechanics of the CODA
bitstream reader in a way that makes sure that there is always enough
data in the bitstream ring buffer before the hardware runs, in order to
avoid buffer-underruns and makes it possible that the driver is always
able to switch between different contexts. Another patch series cares
about position comparisms and does some cleanup. With a new patch,
having more than 32 encoder or decoder instances will be possible. Last
but not least, Philipp mainlined a series of 15 patches for the IPU (the
graphics unit on i.MX6): with the series, it is now again possible to
use the IPU scaler for frame sizes of more than 1024x1024 pixels; this
case is error prone, as it is necessary to split the video into several
tiles, with a bunch of hardware limitations for position and size. The
series finds out optimal tile boundaries and scale factors for a minimal
derivation from the theoretically-optimal bi-linear one-pass scaling.</p>
<p>Marc Kleine-Budde maintains the Linux CAN subsystem. He fixed several
bugs and improved the overall code quality.</p>
<p>Lucas Stach continues to work on i.MX8M support for the mainline kernel.
He cleaned up the IRQSTEER interrupt controller driver: the unit is used
on all three different i.MX8 families (MX8M, MX8QM and MX8X), so this is
an important contribution for MX8 base support. With another patch, the
GPCv2 IRQ hierarchy can now be completely described. Several cleanup
patches and performance micro optimizations have been added. With Linux
5.0, i.MX8MQ is finally supported in mainline, including the MX8M EVK
eval board. Like with earlier i.MX SoCs, it is being maintained by NXP
and by Pengutronix developers. As the MX8M has many peripherals that
have been also available in older SoCs, special care was taken that
older units can continue to be supported with minimal impact. A set of
three patches adds GPCv2 power domain support to i.MX8M. Also a set of
clock drivers has been submitted. On i.MX6, Lucas fixed an atomic
update bug that led to only half the possible frame rate. A more complex
series of patches allows to use an external clock as PCIe reference
clock on i.MX6. With this change, it is possible to use an external
clock generator that runs within the specs of PCIe Gen2 and makes it
possible to run the PCIe link with double the bandwidth, taken that the
hardware was designed the right way. A patch adds byte queue limits for
the CODA driver. The bit streaming buffer for the decoder has a certain
size, as it is large enough to hold bigger I-Frames. For well compressed
streams, this leads to several minutes of videostream time in the ring
buffer, which extremely delays resolution changes (i.e. with HLS). By
limiting the queue to the minimal size of bytes that still allow
successful decoding, the flush latency will be heavily improved. Some
smaller patches for example fix misleading warnings on boot time,
improve the interrupt latency for the CODA video encoder/decoder and
make it possible to provide a board specific thermal policy from device
tree. The eGalay touch driver was improved and does now also support
devices with swapped axis. Lucas maintains the Etnaviv driver; he
improved the raw hardware fences and cleaned up old functionality which
is now realized by the modern GPU scheduler.</p>
<p>Michael Tretter worked on mainline support for the Zynq Ultrascale, a
family of FPGAs with integrated ARM cores. Some initial patches made
their way into the kernel, but the larger part of the current work will
follow later.</p>
</div>
<p>Linux 5.0 is out, and while Linus keeps on telling everyone that the
number has no special meaning at all, we again contributed about 90
patches as part of our work on industrial projects.</p>2019-03-04T00:00:00+01:00tag:www.pengutronix.de,2019-03-04:/2019-03-04-clt-2019.htmlChemnitz Linux Days 20192019-03-04T00:00:00+01:00Chris Fiege<div class="section" id="chemnitz-linux-days-2019">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="197x70" href="https://www.pengutronix.de/media/blog/2019/2019-03-04_clt-1/2019-03-04_clt.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-04_clt-1/2019-03-04_clt.thumb.84543f5be257fd65f20816b8ea93de13.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>As last years, Pengutronix will again support the
<a class="reference external" href="https://chemnitzer.linux-tage.de/">Chemnitz Linux Days</a>,
both by sponsoring the event, and by being there with a large crowd.</p>
<p>A team of 15 pengutronix people will be there, listening to interesting
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/en/programm">lectures</a>.
We are looking forward to lots of fruitful talks with community people!</p>
<p>Like in the last years, we'll have a
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/135">booth</a>.
So come around and let's talk about recent <em>Embedded Linux</em> topics and our work
on a variety of Open Source programs!</p>
<p>We'll present some of our current work with a few demos; this year, we'll
show:</p>
<ul class="simple">
<li>Redundant Over-The-Air Updates of devices with our <a class="reference external" href="https://rauc.io">RAUC</a> demonstrator</li>
<li>Automated unit testing of hardware, written in Python, with the new <a class="reference external" href="https://labgrid.org">labgrid</a> demonstrator.</li>
</ul>
<p>Of course we'll also bring lots of Pengutronix pencils (our best selling
product!) and penguin stickers with us! It's another opportunity to get
stickers for <cite>barebox</cite>, <cite>labgrid</cite>, <cite>PTXdist</cite> and <cite>RAUC</cite>.</p>
<p>Two of our colleagues will have a talk at CLT:</p>
<table border="1" class="docutils">
<colgroup>
<col width="4%"/>
<col width="48%"/>
<col width="47%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="3">Our talks at CLT 2019</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Time</td>
<td>Room V4</td>
<td>Room V5</td>
</tr>
<tr><td>Sa,
10:00</td>
<td> </td>
<td>Managementwerkzeuge aus der Open-Source-Entwicklung (Marie Mann)
(<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/180">Link</a>)</td>
</tr>
<tr><td>Su,
13:00</td>
<td>GDB - Erweiterungen mit Python (Michael Olbrich)
(<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/278">Link</a>)</td>
<td> </td>
</tr>
</tbody>
</table>
<p>We are looking forward to meeting you at Chemnitz Linux Days!</p>
<p>PS:
A personal remark:
If you like to watch the schedule on your mobile phone, try the android
app <a class="reference external" href="https://f-droid.org/de/packages/net.gaast.giggity/">Giggity</a>.
The app is able to import and show the whole schedule in
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/api/ical/programm">iCal</a>
format.
To get the schedule into the app, scan the following QR code directly
from within Giggity:</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="820x820" href="https://www.pengutronix.de/media/blog/2019/2019-03-04_clt-1/2019-03-04_clt_ical.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-03-04_clt-1/2019-03-04_clt_ical.thumb.3a924660bd1f92dabd182a56b491b343.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div></div>
<p>As last years, Pengutronix will again support the
<a class="reference external" href="https://chemnitzer.linux-tage.de/">Chemnitz Linux Days</a>,
both by sponsoring the event, and by being there with a large crowd.</p>2019-03-04T00:00:00+01:00tag:www.pengutronix.de,2019-02-26:/2019-02-26-embedded-world.htmlPengutronix at Embedded World 20192019-02-26T00:00:00+01:00Chris Fiege<div class="section" id="pengutronix-at-embedded-world-2019">
<p>Like every year, Pengutronix is an exhibitor at the
<a class="reference external" href="https://embedded-world.de">Embedded World 2019</a> trade fair in Nuremberg, Germany.
You find us in Hall 4 Booth 4/261
(<a class="reference external" href="https://www.embedded-world.de/de/ausstellerprodukte/embwld19/aussteller-38826723/pengutronix-e-k">map</a>).</p>
<p>At our booth we are presenting demonstrators from our different topics:</p>
<ul class="simple">
<li>Progress of the Open Source graphics stack on the i.MX8M</li>
<li>Our Workhorse: Pure Open Source video playback on the i.MX6</li>
<li>Safe updating with <a class="reference external" href="https://www.rauc.io/">RAUC</a></li>
<li>Control of lab hardware for Embedded Devices with <a class="reference external" href="https://github.com/labgrid-project/labgrid">labgrid</a></li>
</ul>
<p>Additionally, Enrico gives a talk about
'Safe and Secure Field Updates of Embedded Linux Systems'
at the
<a class="reference external" href="https://www.embedded-world.eu/program.html">Embedded World Conference</a>.</p>
<p>We are happy to welcome you at our booth.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x2048" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-welcome.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-welcome.thumb.3cfa3bb03a78a5d2c92cc79e842e0836.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-barebox.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-barebox.thumb.ca3993ff781d9af51a87c100f9320977.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-labgrid.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-labgrid.thumb.c077eedba2db87e4a91f6ddc9107ff47.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-labgrid-2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-labgrid-2.thumb.d0ba2419bd2bbe51b4e295cc9f914e32.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-mx8m.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-mx8m.thumb.edeef352ecac60c4cb64714f8362c3c6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-mx6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-mx6.thumb.8aa0250b63107d01874e68467bccca98.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-rauc.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-26_embedded-world/2019-02-26_embedded-world-rauc.thumb.47bfe65023697fe348c0ba216fd171c6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
<p>Like every year, Pengutronix is an exhibitor at the
<a class="reference external" href="https://embedded-world.de">Embedded World 2019</a> trade fair in Nuremberg, Germany.
You find us in Hall 4 Booth 4/261
(<a class="reference external" href="https://www.embedded-world.de/de/ausstellerprodukte/embwld19/aussteller-38826723/pengutronix-e-k">map</a>).</p>2019-02-26T00:00:00+01:00tag:www.pengutronix.de,2019-02-03:/2019-02-03-fosdem-2019.htmlFOSDEM 2019: cfi's Diary2019-02-03T00:00:00+01:00Chris Fiege<div class="section" id="fosdem-2019-cfi-s-diary">
<p>This year 14 Pengutronix developers attended the
<a class="reference external" href="https://fosdem.org/2019/">FOSDEM</a> at the Université Libre de Bruxelles.
Since there was no embedded track this year we had
lot's of time to follow talks, workshops and meetups on embedded Linux,
graphics, multimedia, electronics and many more.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-1.thumb.60bd7f89a47f5f63e0777909d4b938c1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div class="section" id="wifi">
<h3>WiFi</h3>
<p>FOSDEM made a huge leap into the future this year: The <cite>FOSDEM</cite>-WiFi was
IPv6-only and had no IPv4 connectivity.
For legacy systems on the internet there was NAT64 and DNS64 available.
I was happy that all Pengutronix services worked like a charm.
(Thanks to our admins for that!)
I am quite lucky: There was no point where I had to change into the
dual stack <cite>FOSDEM-legacy</cite> network.</p>
</div>
<div class="section" id="saturday">
<h3>Saturday</h3>
<p>For me as a hardware engineer Saturday was mostly about FLOSS philosophy and
entertaining talks.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="480x640" href="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-2.thumb.f2dfbf4129d198d8f2534d8deae40a71.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 112px;
"></figcaption>
</figure>
</div><p>I started with the
<a class="reference external" href="https://fosdem.org/2019/schedule/event/keynotes_welcome/">Opening</a> event.
Did you know that FOSDEM 2019 had 740 lectures from 715 speakers in just 33
rooms?
It's always fascinating for me what the FOSDEM staff makes possible!</p>
<p>Afterwards I stayed there to listen to Bradley M. Kuhn and Karen Sandler talking
about how and if
<a class="reference external" href="https://fosdem.org/2019/schedule/event/full_software_freedom/">Anyone can Live in Full Software Freedom Today?</a>.
Their talk gave me interesting impulses on the thought if a life just based
on FLOSS software is possible and how far the impacts of proprietary software go.</p>
<p>Later on I watched John Garbutt's talk about the
<a class="reference external" href="https://fosdem.org/2019/schedule/event/square_kilometre_array/">Sqare Kilometer Array and its Software Defined Supercomuter</a>.
The <a class="reference external" href="https://en.wikipedia.org/wiki/Square_Kilometre_Array">SKA</a> is a large
multi-antennae radio telescope.
John talked about how they are planning to store, transport, process and reduce the
1 TByte/s data output of the radio telescope.
For me as a hardware guy the <cite>astronomical</cite> data rates sounded incredible.
But John also talked about how they are planning to orchestrate their
software-defined super computer using openstack.</p>
<p>Daniel Stenberg's talk on
<a class="reference external" href="https://fosdem.org/2019/schedule/event/dns_over_http/">DNS over HTTPS</a> was
full - even though it was in Janson (the largest room at the venue).
We took the chance to get a sandwich and a coffee in the
<a class="reference external" href="https://nav.fosdem.org/l/janson_bar/@0,238.08,87.33,5">Janson Bar</a>.</p>
</div>
<div class="section" id="sunday">
<h3>Sunday</h3>
<p>The <a class="reference external" href="https://fosdem.org/2019/schedule/track/cad_and_open_hardware/">hardware devroom</a>
was scheduled for Sunday this year.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2019/2019-02-03_fosdem/2019-02-03_fosdem-2019-3.thumb.bf7f17b030c27d2a63641bf0db05e975.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The day began with talks about three interesting open source electronics
design tools:</p>
<ul class="simple">
<li>Felix Salfelder talked about the state of <a class="reference external" href="https://fosdem.org/2019/schedule/event/gnucap/">Gnucap</a>.</li>
<li>Holger Vogt talked about the current possibilities and the future of <a class="reference external" href="https://fosdem.org/2019/schedule/event/ngspice/">ngspice</a>.</li>
<li>Thorsten Liebig introduced the audience into <a class="reference external" href="https://fosdem.org/2019/schedule/event/openems/">openEMS</a>.
I wasn't aware that openEMS had a Python-based scripting interface.
I really hope to find the time to try this interesting piece of software one time!</li>
</ul>
<p>After a coffee break I came back to Staf Verhaegen talking about the
<a class="reference external" href="https://fosdem.org/2019/schedule/event/chips4makers/">Lessons learned from Retro-uC</a>.
Staf started a crowdfunding for his <a class="reference external" href="https://www.crowdsupply.com/chips4makers/retro-uc">Retro-uC</a>
last year.
He showed us why he thought that the project wasn't able to attract enough
backers and afterwards gave an overview on the state of current
<a class="reference external" href="https://en.wikipedia.org/wiki/Hardware_description_language">HDLs</a>.</p>
<p>When Wayne Stambaugh started his talk on the
<a class="reference external" href="https://fosdem.org/2019/schedule/event/kicad/">KiCad Project Status</a> the
room was packed with people.
Wayne talked about the current roadmap.
There will be a stable 5.1 release in the next months.
Afterwards the developers will start with the release 6 development.
I am really looking forward to try all the interesting features on the roadmap.</p>
<p>Wayne also talked about the current donation campaigns: an open donation at CERN
raised over 70k CFH.
Also AISLER announced that they will donate for every board manufactured using
KiCad design files.
Wayne stated that he was happy to promote three more developers with
push rights to the central repository. He also stated that the project has
gained velocity and attracted more developers over the last years.</p>
<p>I want to thank all volunteers who make this great event happen every year.</p>
</div>
</div>
<p>This year 14 Pengutronix developers attended the
<a class="reference external" href="https://fosdem.org/2019/">FOSDEM</a> at the Université Libre de Bruxelles.
Since there was no embedded track this year we had
lot's of time to follow talks, workshops and meetups on embedded Linux,
graphics, multimedia, electronics and many more.</p>2019-02-03T00:00:00+01:00tag:www.pengutronix.de,2018-12-21:/2018-12-21-seasons-greetings.htmlMerry Christmas and Happy New Year!2018-12-21T00:00:00+01:00Marie Mann<div class="section" id="merry-christmas-and-happy-new-year">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1740x2608" href="https://www.pengutronix.de/media/blog/2018/2018-12-21_seasons-greetings/2018-12-21_penguin-cookies.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-12-21_seasons-greetings/2018-12-21_penguin-cookies.thumb.808aa106381dd5e041560f8e8bc53534.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>So, this is the time, where the days are quite short, where we are going
to spend time with our families or looking forward to meet at
<a href="https://events.ccc.de/2018/09/11/35c3-call-for-participation-and-submission-guidelines/">35C3</a>.
Traditionally this is the time to have a look back and making plans for 2019.</p>
<div class="section" id="a-glance-back-at-2018">
<h3>A Glance Back at 2018</h3>
<ul class="simple">
<li>We welcomed three new colleagues on board, who are helping us to develop
BSPs, kernel drivers and some more hardware.</li>
<li>We connected with the open-source community at events like
<a href="https://www.pengutronix.de/en/blog/2018-10-22-elce-2018-day-one.html">ELCE</a>,
<a href="https://www.pengutronix.de/en/blog/2018-08-28-froscon.html">FroSCon</a>,
<a href="https://www.pengutronix.de/en/blog/2018-11-19-xdc-2018.html">XDC</a>,
<a href="https://www.pengutronix.de/en/blog/2018-03-06-clt-2018.html">CLT</a>,
<a href="https://www.pengutronix.de/en/blog/2018-02-12-fosdem-2018.html">FOSDEM</a> or
<a href="https://www.pengutronix.de/en/blog/2018-05-18-ripe76.html">RIPE</a>
and developed new ideas and strategies at
<a href="https://www.pengutronix.de/en/blog/2018-06-05-techweek.html">Techweek</a></li>
<li>We contributed 368 patches to the Linux kernel, had 12 PTXdist releases,
16 for barebox, 3 for RAUC, 2 for dt-utils, and 2 new OSELAS Toolchains.</li>
<li>We ate about 882 pizzas, 627 loafs of bread, 4270 bread rolls, and drank 4518 espressi for lunch.
Additionally, we celebrated 2.0000000934 weddings (approximately).</li>
</ul>
</div>
<div class="section" id="up-and-coming">
<h3>Up and Coming</h3>
<p>We look forward to sending next patch-series, improving our tools and projects
and making the world a happier place.</p>
<p>For now, we wish you Merry Christmas and Happy New Year 2019.
Oh, and enjoy your cookies!</p>
</div>
</div><p>So, this is the time, where the days are quite short, where we are going
to spend time with our families or looking forward to meet at
<a href="https://events.ccc.de/2018/09/11/35c3-call-for-participation-and-submission-guidelines/">35C3</a>.
Traditionally this is the time to have a look back and making plans for 2019.</p>2018-12-21T00:00:00+01:00tag:www.pengutronix.de,2018-12-20:/2018-12-20-RAUC-1.0.htmlRAUC v1.0 Released2018-12-20T21:27:00+01:00Enrico Jörns<div class="section" id="rauc-v1-0-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="http://rauc.io/pages/download.html">v1.0</a> release of RAUC</p>
</div>
</div>
<p>Four days before Christmas Pengutronix prepared a very special present that
probably many of you have been waiting for: The 1.0 version of RAUC!</p>
<p>This finally visibly underlines the maturity RAUC already had in the
prior releases.</p>
<p>This v1.0 release adds several enhancements and new features concerning signing
and signature handling.
One of the most important improvements is the support for passing
keys/certificates stored on <em>PKCS#11</em> tokens (e.g. for using a smart card
or HSM).
Also the boot selection interface gained several fixes and enhancements,
especially concerning the <em>U-Boot</em> integration that now implements the full
feature set of obtaining and setting the boot status.</p>
<p>Several extensions of the <em>D-Bus API</em> and some code refactoring now allow 'rauc
status' to fully work over D-Bus (if enabled) and finalize the clear
separation between client and service.</p>
<p>Another topic that got a lot attention is easing RAUC debugging by providing
more targeted debugging and error messages, adding documentation, etc.</p>
<div class="ptx-sidebar">
<div class="title">
Changes
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li><a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-0-released-dec-20-2018">v1.0-rc1</a> changes list</li>
<li><a class="reference external" href="https://rauc.readthedocs.io/en/latest/changes.html#release-1-0-rc1-released-oct-12-2018">v1.0</a> changes list</li>
</ul>
</div>
</div>
<p>It is important to note that also several potential issues for the actual
installation process were fixed, e.g. by adding proper fsync() handling, using
O_EXCL for opening devices, or by fixing uid/gid handling during tar
extraction.</p>
<p>RAUC now also fully supports using <tt class="docutils literal"><span class="pre">file://</span></tt> URIs and allows to open bundles
that have a custom file name extensions for cases where this is really mandatory
of any reason.</p>
<p>With the 1.0 release we now also support OpenSSL 1.1.</p>
<p>The rest are 'only' minor new options, bug fixes, documentation updates,
typo fixes, etc.</p>
<p>Thanks to all contributors since v0.4: Ahmad Fatoum, Alexander Dahl, Arnaud
Rebillout, Bastian Stender, Emmanuel Roullit, Enrico Jörns, Jan Lübbe, Jan
Remmet, Jim Brennan, Marcel Hamer, Matthias Bolte, Michael Heimpold, Philip
Downer, Philipp Zabel, Rasmus Villemoes, Thomas Petazzoni, Timothy Lee, Ulrich
Ölmann, Vyacheslav Yurkov, Yann E. MORIN</p>
</div>
<p>Four days before Christmas Pengutronix prepared a very special present that
probably many of you have been waiting for: The 1.0 version of RAUC!</p>2018-12-20T21:27:00+01:00tag:www.pengutronix.de,2018-11-21:/2018-11-21-ripe77.htmlbbu's Diary: RIPE77 - Amsterdam2018-11-21T18:00:00+01:00Bjørn Bürger<div class="section" id="bbu-s-diary-ripe77-amsterdam">
<p>The second RIPE Meeting in 2018 took place at the Hotel Okura in Amsterdam from 15-19 October 2018.
Here's my report :-)</p>
<div class="section" id="sweet-1">
<h3>127.0.0.1 - sweet ::1</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="867x651" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_vacation.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_vacation.thumb.3bca2c400ab8270c20e8cdd41c6a962e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>You might ask: "Wait. Oct 15, you say? Lazy bastard! It's november already!", and you are right.
Sometimes, as we learned in the hitchhiker's guide to the galaxy, TIME is an ILLUSION (and lunchtime doubly so).
To be honest, I spent some time on a ~1000km hike through europe and enjoyed the awesome IPv4-sunset at the end of the world.</p>
<p>But after that, I wasn't the only one to come home: The second RIPE Meeting of 2018 took place in Amsterdam, the hometown of <a class="reference external" href="https://www.ripe.net/">RIPE NCC</a>, a vibrant, friendly and modern city
full of bicycles, canals, <a class="reference external" href="https://www.opsolder.nl/de">hidden museums</a> and one of the biggest internet exchanges worldwide.</p>
</div>
<div class="section" id="monday">
<h3>Monday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1242x932" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_monday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_monday.thumb.d37a0335b318dca12fc9b17c22f2076a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Although this has been the biggest RIPE meeting so far, it felt nice and familiar.
Due to the warm and friendly weather, some of the more than 800 attendees started the day with
a little chat at the canal and I couldn't resist either, taking a cup of well prepared coffee outside
(and probably missing some very good tutorials about IPv6, P4 and the RIPE DB).</p>
<p>The first day was filled with some <a class="reference external" href="https://ripe77.ripe.net/programme/meeting-plan/">interesting talks</a>,
ranging from new optical transceivers for 400G (heck, I'd love to see 25G and 40G in our very small
datacenter first), to latest developments in DNS ("It’s DNS Jim, But Not as We Know It" by Sara Dickinson
is worth a view) and lightning talks on various topics like zombie routes et al.</p>
<p>But, as this is the RIPE-Meeting (and not RIPE-Conference), the most interesting part happened
between coffee bar and welcome reception: Talking to old friends and meeting new ones. I should
mention a big 'thank you' to the coffee bar sponsors and the baristi, who constantly delivered
a stream of black gold to the crowd ;-)</p>
</div>
<div class="section" id="tuesday">
<h3>Tuesday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1242x932" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_tuesday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_tuesday.thumb.c9e0249445648c649f16187f70867871.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Tuesday was packed with plenary sessions and there was almost no chance to escape for
more than a few minutes to enjoy the warm and sunny weather: Henrik Kramshoej started
with interesting insights to VXLAN security or injection, from there the sessions rushed
through several topics like EVPN, BGP communities and "even more worms in the routing can"
by Florian Streibelt (including a very handsome cat) to routing attacks on the bitcoin
system and some Internet history, remembering <a class="reference external" href="https://de.wikipedia.org/wiki/Jon_Postel">Jon Postel</a>.
Constanze Dietrich presented her findings on <a class="reference external" href="https://ripe77.ripe.net/archives/video/2112">the human factors of security misconfigurations</a>
and several talks about politics, internet self-regulation, human rights as well as the the
RIPE accountability task force report filled the program, followed by more technical
topics like machine learning for networking traffic classification and security enhancements
or rolling out a global anycast infrastructure with open source system orchestration tools.
Time for an <a class="reference external" href="https://ripe77.ripe.net/programme/social-events/tuesday/">ESCAPE</a>. Funny enough, this was the name of this years social event location :-)</p>
</div>
<div class="section" id="wednesday">
<h3>Wednesday</h3>
<p>Wednesdays are difficult. Especially on RIPE Meetings. We followed sessions on DNS OARC, the KSK rollover, DNS compliance, Address Policy,
IPv4 address-dust and RIPE Database cleanups for RIPE-NONAUTH data using RPKI. A considerable lack of cats made this part of the day really
hard. As usual, the day closed with the RIPE NCC General Meeting and while some attended <a class="reference external" href="http://techinc.nl/">a Tour to the local Hackerspace</a>, others
took a tour to the Amsterdam city center or just enjoyed good pasta with friends at the italian restaurant around the corner.</p>
</div>
<div class="section" id="thursday">
<h3>Thursday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1242x932" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_dinosaur.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_dinosaur.thumb.f6b222babf6479a8070312b4efb3d1c5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>From Salt to Dinosaurs. On thursday, we rushed from Salt for network automation (cloudflare) to ASPA (improving routing security),
segment routing, neverending discussions about NON-AUTH objects (politics), the ITU Plenipotentiary (more politics) and
the ICANN EPDP on WHOIS/GDPR (wheeeeeeee!) to some more politics. Meanwhile Jen Linkova gave an update on
the IPv6 work taking place in the IETF and Oliver Gasser talked about the IPv6 hitlists project. Jens Link
talked about IPv6 connected rabbits and Benedikt Stockebrand closed the session with a talk about
<a class="reference external" href="https://www.heise.de/newsticker/meldung/RIPE77-Von-der-Kunst-IPv6-Adressraum-zu-verbrennen-4196981.html">The Art of Running Out of IPv6 Addresses</a>.</p>
</div>
<div class="section" id="iot">
<h3>IoT</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1242x932" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_iot.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_iot.thumb.4275eab0b2acda70dc7bd3c03107889c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The IoT Session was both, enlightning and frustrating. As it seems, security is still the biggest issue regarding
the IoT sphere in general and a lot of presentations covered this topic, mostly with a focus on DDOS attack mitigation (just
like you would expect it from a network community meeting). So, most of the talks covered topics like "secure homenet gateways",
automatic quarantining of affected networks and biometric access control for users. But it tells a lot, if a member
of the dutch police needs to remind the community, that using biometric features is not a good idea in terms of privacy and
protection of human rights. The key to IoT security are open firmware, open documentation and instant availability of security
related updates to all devices.</p>
</div>
<div class="section" id="friday">
<h3>Friday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1242x932" href="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_venue2019.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-21_ripe77/2018-11-21_ripe77_venue2019.thumb.a3b1e81bc9ad9496c9ce244b4b5b00ed.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Friday was filled with stats and updates on various topics around other RIRs, NRO EC, or was it ASO AC ...
I'm confused with the ICANN structure already and just call it politics :-) Louis Poinsignon, however,
got my attention with a report on Cloudflare RPKI deployment and Amanda Gowland encouraged everyone
to have more diversity at technical meetings like RIPE. Actually, there is. You just have to open your eyes
and see all the awesome people around. Never stop learning, never stop aiming for a better world.</p>
<p>See you again at <a class="reference external" href="https://ripe78.ripe.net/">RIPE 78</a> (Reykjavík, 20-24 May 2019)</p>
</div>
</div>
<p>The second RIPE Meeting in 2018 took place at the Hotel Okura in Amsterdam from 15-19 October 2018.
Here's my report :-)</p>2018-11-21T18:00:00+01:00tag:www.pengutronix.de,2018-11-19:/2018-11-19-xdc-2018.htmlPengutronix at XDC 20182018-11-19T12:00:00+01:00Michael Tretter<div class="section" id="pengutronix-at-xdc-2018">
<p>This year the <a class="reference external" href="https://xdc2018.x.org">X Developer's Conference</a> was held in
A Coruña, Spain at the end of September. Pengutronix attended with three
developers of the Pengutronix graphics team. This report collects the most
interesting topics for graphics on Linux that were discussed at the XDC.</p>
<div class="section" id="wayland-layer-shell-protocol">
<h3>Wayland layer-shell protocol</h3>
<p>As Wayland is increasingly getting hold in desktop and embedded systems and
many discussions have settled, there wasn't much talk about Wayland on this
year's conference.</p>
<p>Still Drew DeVault, maintainer of sway and the wlroots library, presented the
<a class="reference external" href="https://www.youtube.com/watch?v=VuRXHJu5Kmg">layer shell protocol</a>.
This new Wayland protocol allows clients to specify their position and z-order
in in relation to the remaining desktop and applications. Usually the
compositor, e.g., Weston, Mutter or KDE, takes full care of implementing the
desktop user interface by providing a specific shell. The layer shell allows
users to extend and customize their desktops with additional applications
without relying on the configuration means of the existing shell. Currently
this protocol is used in sway to implement the wallpaper, lock screen, panel,
and notification bar.</p>
<p>While the security of this protocol remains an open question, because it
breaks the assumption that Wayland clients don't know anything about the
desktop layout, wlroots is working towards adding the layer-shell protocol to
the standard Wayland protocols.</p>
<p>The layer-shell could simplify the creation of GUIs for embedded systems in
the same way it helps to write desktop application components. However, to be
really interesting for embedded use cases, wlroot still needs more
improvements in the drm-backend, especially proper use of hardware display
overlays.</p>
</div>
<div class="section" id="heterogeneous-memory-management">
<h3>Heterogeneous memory management</h3>
<p>On Thursday, a highlight was the talk by Jerome Glisse about the current state
of <a class="reference external" href="https://xdc2018.x.org/slides/hmm-gup-no-more.pdf">heterogeneous memory management</a> (HMM). HMM allows to
synchronize the CPU page table and the device page table, and, thus, enables a
shared address space between the CPU and devices and avoids relocations.</p>
<p>Additionally, HMM provides a unified interface to migrate memory between main
memory and device memory, which allows device drivers to take advantage of
separate device memory which has a higher bandwidth and lower latency than
main memory. The interface still requires drivers to define the policy for the
migration, because the conditions for optimal usage are highly device and use
case specific.</p>
<p>My colleague Lucas Stach considered using HMM for implementing the reloc
support for texture descriptors in etnaviv. This is still missing for support
of the GC7000, which is, e.g., found on the i.MX8M. Unfortunately HMM requires
that the device address space to be at least as large as the CPU address
space, which is not the case for the 64 bit ARM cores on the i.MX8M, as the
Vivante GPU only supports 32 bit addresses. The discussions lead to the
decision to use per process address spaces to solve the reloc support on the
GC7000. Stay tuned for news about GC7000 support in etnaviv.</p>
</div>
<div class="section" id="opencl-with-clover-using-spir-v-and-nir">
<h3>OpenCL with Clover using SPIR-V and NIR</h3>
<p>Friday started with a talk by Karol Herbst about <a class="reference external" href="https://xdc2018.x.org/slides/clover.pdf">OpenCL support inside Mesa
through SPIR-V and NIR</a>.</p>
<p>While the AMDGPU driver already supports OpenCL via its LLVM intermediate
representation (IR), other drivers that don't use the LLVM IR for generating
the machine code have a hard time supporting OpenCL. Adding means to use NIR
as the general purpose IR within Mesa would enable all NIR-based drivers
(currently Nouveau and freedreno) to benefit from Mesa OpenCL support.</p>
<p>Rob Clark, Pierre Moreau and Karol Herbst have been working on converting
OpenCL C code into SPIR-V, which in turn can be translated into NIR. The talk
covered which features are still missing in NIR and Clover for supporting
OpenCL in NIR. Especially NIR is missing support for real pointers and various
OpenCL specific opcodes and intrinsics and Clover lacks support for SPIR-V
files and the conversion using the SPIRV-LLVM-Translator.</p>
<p>While there were patches for experimental NIR support in etnaviv, these
haven't been merged into Mesa mainline yet. However, adding NIR support to
etnaviv is essential for using this work to implement OpenCL in etnaviv.</p>
</div>
<div class="section" id="panfrost">
<h3>Panfrost</h3>
<p>Also on Friday, Lyude Paul and Alyssa Rosenzweig introduced their work on
<a class="reference external" href="https://xdc2018.x.org/slides/Panfrost-XDC_2018.pdf">Panfrost</a>, a
reverse-engineered open source 3D driver for Mali GPUs. Mali is a GPU
architecture by ARM, which is commonly found on embedded systems. The work is
focused on the more recent Midgard (Txxx) and Bifrost (Gxx) series, which
still leaves the older Utgard architecture something to avoid in maintainable
systems.</p>
<p>Midgard is already supported by a prototype Mesa driver, which shows
impressive results compared to the binary blob driver. Bifrost shares a kernel
driver with Midgard, but the shader core has been completely changed. Although
much of the ISA has been reverse-engineered, there is no Mesa support, yet.</p>
<p>Maybe with their work on the Mali GPUs, we might be able to start using SoCs
that contain Mali GPUs for maintainable and updatable embedded systems.</p>
</div>
<div class="section" id="conclusion">
<h3>Conclusion</h3>
<p>Thanks to the X.Org Foundation and the GPUL (Galician Linux User Group) for
organizing a great conference.</p>
</div>
</div>
<p>This year the <a class="reference external" href="https://xdc2018.x.org">X Developer's Conference</a> was held in
A Coruña, Spain at the end of September. Pengutronix attended with three
developers of the Pengutronix graphics team. This report collects the most
interesting topics for graphics on Linux that were discussed at the XDC.</p>2018-11-19T12:00:00+01:00tag:www.pengutronix.de,2018-11-13:/2018-11-13-electronica.htmlPengutronix at Electronica in Munich2018-11-13T00:00:00+01:00Chris Fiege<div class="section" id="pengutronix-at-electronica-in-munich">
<p>This year Pengutronix again has a Booth at the
<a class="reference external" href="https://electronica.de/">Electronica</a> trade fair in Munich, Germany.
You find us in Hall B5 Booth 102
(<a class="reference external" href="https://exhibitors.electronica.de/onlinecatalog/2018/details_halloverview/hall_b5/?this_hallen_id=12&sb1=&sb_n=&elb=800.1100.1818.1.1111&elm_boo_viewsize=1">map</a>).</p>
<p>We are presenting demonstrators from our different topics:</p>
<ul class="simple">
<li>Open source graphics stack on the i.MX8M</li>
<li>Video capturing and playback on the i.MX6</li>
<li>Safe updating with <a class="reference external" href="https://www.rauc.io/">RAUC</a></li>
<li>Control of lab-hardware for Embedded Devices with <a class="reference external" href="https://github.com/labgrid-project/labgrid">labgrid</a></li>
</ul>
<p>We are happy to welcome you at our booth.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2305x2305" href="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_matches.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_matches.thumb.de8b64661ed276bbfb2ecef83e567a6b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3878x2568" href="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_labgrid.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_labgrid.thumb.9fc6bc6a33f50a32020fdb6011e8dbce.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3138x3138" href="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_coalcam.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-13_electronica/2018113_electronica_coalcam.thumb.140aae913d927e158c2a558d3f19668a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
<p>This year Pengutronix again has a Booth at the
<a class="reference external" href="https://electronica.de/">Electronica</a> trade fair in Munich, Germany.
You find us in Hall B5 Booth 102
(<a class="reference external" href="https://exhibitors.electronica.de/onlinecatalog/2018/details_halloverview/hall_b5/?this_hallen_id=12&sb1=&sb_n=&elb=800.1100.1818.1.1111&elm_boo_viewsize=1">map</a>).</p>2018-11-13T00:00:00+01:00tag:www.pengutronix.de,2018-11-09:/2018-11-09-ats-summit.htmlSummary: Automated Testing Summit 20182018-11-09T00:00:00+01:00Chris Fiege<div class="section" id="summary-automated-testing-summit-2018">
<p>The Automated Testing Summit (ATS) was a co-located event at the ELC-E 2018
in Edinburgh. The summit was organized by Tim Bird and Kevin Hilman and brought
together over 35 (embedded) testing experts from different projects and
companies.</p>
<div class="section" id="the-idea">
<h3>The Idea</h3>
<p>At ELC-E 2017 Andrew Murray did his BoF
<a class="reference external" href="https://www.youtube.com/watch?v=-oO9y2HnoYs">Farming Together</a>. This BoF
showed that lots of companies and individuals in the embedded world are running some
kind of board farm: They all have the need to remote-control real hardware and
test software on that hardware.</p>
<p>During the discussion the idea of more collaboration in this area arose. Tim
Bird suggested to collect e-mail addresses in the
<a class="reference external" href="https://elinux.org/Board_Farm">eLinux.org Wiki</a>. Afterwards, the existing
<a class="reference external" href="https://lists.yoctoproject.org/listinfo/automated-testing">automated-testing mailing list</a>
run by the Yocto Project was used for further coordination.</p>
</div>
<div class="section" id="the-summit">
<h3>The Summit</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1880x3686" href="https://www.pengutronix.de/media/blog/2018/2018-11-09_automated-testing-summit/2018-11-09_ats-summit.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-11-09_automated-testing-summit/2018-11-09_ats-summit.thumb.51719dfb470c2f9722653c6e7bd0f4e6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>During the next year, Tim Bird and Kevin Hilman organized the Automated Testing
Summit as a co-located event during the ELC-E 2018. Linaro and DENSO TEN sponsored
the summit.</p>
<p>The summit brought together 35 testing experts from over 22 projects. Most of
the people represented testing of embedded devices. But some also represented
high-level projects that test software without hardware. eLinux.org has a list
of represented <a class="reference external" href="https://elinux.org/Automated_Testing_Summit#Attendees">projects</a>.</p>
<p>During eight hours of productive discussion, we worked on:</p>
<ul class="simple">
<li>defining a common terminology and reference testing workflow</li>
<li>identifying interfaces where we could share test suites, build and test artifacts (by creating an interchange format)</li>
<li>learning how other board farms are built and used</li>
<li>and many smaller topics</li>
</ul>
<p>(For some attendees the discussion even continued in a pub near the venue.)
The minutes are available on the <a class="reference external" href="https://elinux.org/ATS_2018_Minutes">wiki</a> as well.</p>
</div>
<div class="section" id="action-items">
<h3>Action Items</h3>
<p>Taking into account the number of companies, projects and individuals involved
in the summit the list of
<a class="reference external" href="https://elinux.org/Automated_Testing_Summit#Action_items_from_meeting">resulting action items</a>
is quite long.
The summit also showed that there are even more possibilities to collaborate in
testing -- even if some parts of the process are proprietary.</p>
<p>In the short term, the following action items will probably have the most
relevance for us at Pengutronix.</p>
<div class="section" id="pdudaemon">
<h4>pdudaemon</h4>
<p>All projects that need to control embedded hardware switch the board's power
supply in one or another way. The attendees agreed that a common interface
would help all projects: a driver only has to be developed once.
The idea is to support <a class="reference external" href="https://github.com/pdudaemon/pdudaemon">pdudaemon</a>
as the common interface to control power switches and to upstream drivers for
new switches to pdudaemon.</p>
</div>
<div class="section" id="design-for-testing-document">
<h4>Design for Testing Document</h4>
<p>The attendees agreed that a <em>design for embedded testing</em> document could
help test engineers to communicate with the hardware developers. The document
should describe measures that ensure software development and automated
testing are possible.</p>
<p>Since the Automated Testing has no formal body yet, the document could be signed
by multiple projects, companies and individuals that support its contents.</p>
<p>I volunteered to coordinate the creation of the document. I will post an update
as soon as there are any resources available online.</p>
</div>
</div>
<div class="section" id="next-meeting">
<h3>Next meeting</h3>
<p>The attendees agreed that we would like to meet again next year. The meeting
will probably be during the ELC-E 2019 in Lyon, France.</p>
</div>
</div>
<p>The Automated Testing Summit (ATS) was a co-located event at the ELC-E 2018
in Edinburgh. The summit was organized by Tim Bird and Kevin Hilman and brought
together over 35 (embedded) testing experts from different projects and
companies.</p>2018-11-09T00:00:00+01:00tag:www.pengutronix.de,2018-10-29:/2018-10-29-gstconf.htmlGStreamer Conference 2018, Edinburgh, Scotland, UK2018-10-29T17:00:00+01:00Philipp Zabel<div class="section" id="gstreamer-conference-2018-edinburgh-scotland-uk">
<p>We are back from two days of interesting talks at the <a class="reference external" href="https://gstreamer.freedesktop.org/conference/2018/">GStreamer Conference
2018</a>, which was held in
Edinburgh last week, right after the <a class="reference external" href="https://events.linuxfoundation.org/events/elc-openiot-europe-2018/">Embedded Linux Conference Europe (ELC-E)</a>.</p>
<div class="section" id="state-of-the-union">
<h3>State of the union</h3>
<p>Tim-Philipp Müller started off the conference with the <a class="reference external" href="https://gstconf.ubicast.tv/videos/gstreamer-state-of-the-union_42782/">"State of the Union"</a>
talk about the release schedule, notable features of the current 1.14 release,
upcoming features for the 1.16 release in December 2018, and planned future
development. The new features are too numerous to list them all, but a few
highlights for us are V4L2 codec improvements, OpenGL dmabuf uploader updates
for zero-copy, the Meson build system, which should be almost complete for
1.16, and the upcoming move to gitlab.freedesktop.org.</p>
</div>
<div class="section" id="debugging-tracing-and-testing">
<h3>Debugging, tracing, and testing</h3>
<p>Our colleague Michael Olbrich gave an overview of his GDB plugins created to
ease <a class="reference external" href="https://gstconf.ubicast.tv/videos/post-mortem-gstreamer-debugging-with-gdb-and-python/">post-mortem debugging of crashed GStreamer processes</a>.
The talk was well received, according to feedback received during the remainder
of the conference. Marcin Kolny of Amazon gave a talk about <a class="reference external" href="https://gstconf.ubicast.tv/videos/profiling-gstreamer-applications-with-hawktracer-and-tracing-subsystem/">profiling with
HawkTracer</a>,
and Michał Budzyński presented about the <a class="reference external" href="https://gstconf.ubicast.tv/videos/trust-but-verify-our-road-to-robust-multimedia-and-graphics-stack-verification-aka-multimedia-testing-on-the-budget-for-everyone/">scenario driven multimedia testing
setup</a>
used for full-system testing at Samsung R&D Poland.</p>
</div>
<div class="section" id="video4linux">
<h3>Video4Linux</h3>
<p>Ezequiel Garcia and Nicolas Dufresne of Collabora spoke about how the GStreamer
<a class="reference external" href="https://gstconf.ubicast.tv/videos/discovering-video4linux-codecs/">V4L2 video codec</a>
plugins use the stateful and stateless V4L2 codec APIs, which are currently
under review. Nicolas Dufresne also updated everyone on V4L2 in his usual
GStreamer V4L2 lightning talk. The annual reading of the V4L2 developer patch
count high score wasn't enough to boost any egos this time, but is a sign that
GStreamer V4L2 is stable and useful enough, unchanged, for many of our embedded
use cases.</p>
</div>
<div class="section" id="feature-and-performance-improvements">
<h3>Feature and performance improvements</h3>
<p>Furthermore, some of the upcoming and future improvements were presented in
detail. Sebastian Dröge introduced his work on <a class="reference external" href="https://gstconf.ubicast.tv/videos/when-adding-more-threads-adds-more-problems-thread-sharing-between-elements-in-gstreamer/">thread-sharing between elements</a>
to allow massively parallel pipelines with less overhead. He also reported
about the current state of <a class="reference external" href="https://gstconf.ubicast.tv/videos/whats-new-with-gstreamer-rust/">GStreamer & Rust</a>
integration. George Kiagiadakis from Collabora reported about the
non-interleaved audio format support in 1.16, and Edward Hervey mastered
technical difficulties, improvising his talk about <a class="reference external" href="https://gstconf.ubicast.tv/videos/closed-captions-in-gstreamer/">Closed Captions</a>
support without any slides. He also gave a talk about future <a class="reference external" href="https://gstconf.ubicast.tv/videos/streams-and-collections-were-not-done-yet/">stream selection
and collection</a>
support in playbin3. Mathieu Duponchelle of Centricular reported about the
ongoing GStreamer Documentation efforts, which should lead to a unified
developer portal soon.</p>
</div>
<div class="section" id="web-technologies">
<h3>Web technologies</h3>
<p>One of the more prominent topics this year was web technologies, starting off
with a talk by Philippe Normand from Igalia about GStreamer based <a class="reference external" href="https://gstconf.ubicast.tv/videos/multimedia-support-in-webkitgtk-and-wpe-current-status-and-plans/">Multimedia
handling in WebKitGTK and WPE</a>
(WebKit port for embedded), a talk by Manish Goregaokar about <a class="reference external" href="https://gstconf.ubicast.tv/videos/using-gstreamer-for-servos-webaudio-implementation-in-rust/">Servo Media</a>,
the WebAudio API implementation for Mozilla's Servo Browser Engine, as well as
a lightning talk by Victor Jáquez from Igalia about Servo and GStreamer
integration and two lightning talks about WebRTC progress updates and data
channel support by Mathieu Duponchelle and Matthew Waters of Centricular.</p>
</div>
<div class="section" id="various-streaming-video-neural-networks-signal-analysis">
<h3>Various: streaming video, neural networks, signal analysis</h3>
<p>Wim Taymans presented the current work in progress on <a class="reference external" href="https://gstconf.ubicast.tv/videos/pipewire-wants-to-be-your-audio-server-too/">PipeWire used as
audio server</a>.</p>
<p>Streaming and cloud topics were covered by talks about <a class="reference external" href="https://gstconf.ubicast.tv/videos/gstreamer-for-cloud-based-live-video-handling/">cloud-based
live video handling</a>
by Matthew Clark and Luke Moscrop from BBC, a talk about <a class="reference external" href="https://gstconf.ubicast.tv/videos/d3dx-video-game-streaming-on-windows/">streaming Direct3D
video games on Windows</a>
by Florian Nierhaus from Bebo, and a talk by Håvard Graff from Pexip about
their <a class="reference external" href="https://gstconf.ubicast.tv/videos/microsoft-teams-connector/">Microsoft Teams Connector</a>.</p>
<p>There were a few talks about integrating deep neural networks with GStreamer,
mostly just for inferencing purposes, implementing <a class="reference external" href="https://gstconf.ubicast.tv/videos/bringing-deep-neural-networks-to-gstreamer/">different</a>
<a class="reference external" href="https://gstconf.ubicast.tv/videos/nnstreamer-neural-networks-as-gstreamer-filters/">abstraction</a>
<a class="reference external" href="https://gstconf.ubicast.tv/videos/gstinference-a-gstreamer-deep-learning-framework/">layers</a>
for different deep learning backends. Time will tell whether the different
approaches will move towards unification or whether one of them will become
accepted.</p>
<p>Further lightning talks were concerned with using GStreamer on various
platforms, such as webOS OSE, iOS, or Windows (DirectShow), as well as on
vendor frameworks, e.g. Intel MSDK or Nvidia CUDA, or even using GStreamer as a
backend for FFmpeg by implementing libav API on top, and an entertaining
lightning talk about the history of MeTV, a live TV viewing application, up to
the latest rewrite in Rust using GStreamer.</p>
<p>One surprise lightning talk was given in the form of a question by Martin Ling
from the Edinburgh Hacklab, who wondered whether GStreamer could be a good fit
for use in sigrok.</p>
<p>The talks were recorded by Ubicast and can be found in the <a class="reference external" href="https://gstconf.ubicast.tv/channels/#gstreamer-conference-2018">GStreamer
Conference 2018 channel</a>.</p>
</div>
</div>
<p>We are back from two days of interesting talks at the <a class="reference external" href="https://gstreamer.freedesktop.org/conference/2018/">GStreamer Conference
2018</a>, which was held in
Edinburgh last week, right after the <a class="reference external" href="https://events.linuxfoundation.org/events/elc-openiot-europe-2018/">Embedded Linux Conference Europe (ELC-E)</a>.</p>2018-10-29T17:00:00+01:00tag:www.pengutronix.de,2018-10-24:/2018-10-24-elce-2018-day-three.htmlrsc's Diary: ELC-E 2018 - Day 32018-10-24T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2018-day-3">
<p>This is my report from the 3rd day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>
<div class="section" id="keynote-astronomy-with-gravitational-waves">
<h3>Keynote: Astronomy with Gravitational Waves</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gravitation1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gravitation1.thumb.18ac9dada0354bc50582215157a7aea0.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the first talk of the morning, Dr. Alexander Nitz from MPI for
Gravitational Physics talked about gravitational waves and the LIGO
experiment. Let me note that the GEO600 detector (which was involved in
the experiments and is part of a global network of gravitational wave
detectors) is just 10 km away from the Pengutronix office in Hildesheim
(and we have visited it with the crew some years ago).</p>
<p>Gravitational waves exist when masses rotate around each other, but
unfortunately, the effect is pretty small, even if you try to observe
collapsing black holes. The first actual detection with the LIGO
detector in the USA happened back in 2015.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gravitation2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gravitation2.thumb.28ac4fed822c3ad87072a13a75a8afdb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another possibility to observe gravitational waves is the merger of
neutron stars; in contrast to merging black holes, it has the advantage
that, while merging, the system emits radiation, and in fact in 2017 it
was possible to correlate a gamma ray burst with signals from the wave
detectors.</p>
<p>During the time, seven events have been observed, so scientists begin to
understand the characteristics of the signals and find out which kind of
events they can be correlated with. All this is a good start, but for
the future, scientists plan to extend the activities towards other parts
of the spectrum.</p>
<p>Finally, data is processed with open source software in python, and in
fact even the data itself is open data.</p>
</div>
<div class="section" id="openocd-beyond-simple-software-debugging">
<h3>OpenOCD - Beyond Simple Software Debugging</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-jtag1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-jtag1.thumb.46829e194aded48e356e891a0007f94b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>My colleague Oleksij Rempel works on OpenOCD and JTAG, mainly on his
hobby project reverse engineering unknown hardware, with a focus on
MIPS based WiFi hardware for the freifunk project. JTAG is a pretty old
technology, coming from the early 90es. Most users just use it for
pushing software into a system; however, boundary scan is the more
interesting part for him. Most chip vendors publish the BSDL files
(which describe the boundary scan register), but some don't, or at least
not to normal people, and in this case you need to guess what the bits
might mean.</p>
<p>The first step of working with JTAG is to locate the JTAG port; however,
for instance most Allwinner SoCs multiplex the JTAG contacts with the SD
card signals and expose them only in a short time window at the
beginning of the power-on sequence.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-jtag2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-jtag2.thumb.eb8f08c94331b257fbfceed1ef7d24cc.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>To hook in, a programmable power supply was used and an SD card
multiplexer. If you attach some pull-up resistors to the right lines, it
is possible to use a logic analyzer to find out the right pins. Once you
have done that, playing with the bits starts in order to find out about
the meaning: the chain can be scanned, and by adding pull-ups and
pull-downs, the purpose of certain bits can be explored. However, it
turned out that some chips are easier to be analyzed than others.</p>
<p>Another use case was to play with JTAG on i.MX6: when using boundary
scan, the device goes into reset state. The chain does not only go to
the actual processor, but also to components as the SDMA controller and
the PCIe and SATA PHYs. At this point in time, only support for the main
CPU is supported in OpenOCD, so there are many more challenges waiting
for interested developers.</p>
</div>
<div class="section" id="on-this-rock-i-will-build-my-system-why-open-source-firmware-matters">
<h3>On this Rock I will Build my System - Why Open-Source Firmware Matters</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock1.thumb.532114ee2becf41fe8672cd8d1c0c632.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the last Pengutronix talk of this conference, my colleague Lucas
Stach talked about why open source firmware in today's SoCs matters a
lot. Working on lowlevel graphics tasks for industry projects, most of
the devices he deals with have to be maintained for a very long time.</p>
<p>Traditionally, the firmware on those systems is really minimalistic:
setting up the hardware, then fully passing control to the kernel. On a
traditional system, there is basically no interaction between the kernel
and the firmware at runtime. In this setup, the Linux kernel is in full
control of what happens on the system, so the update story is quite
easy: updating the kernel is what most people have at least thought
about - in contrast to updating the firmware. With this model, the
kernel is in control of everything, which contains a certain amount of
complexity, but this complexity is there because the systems <em>are</em>
complex, not because of the Linux kernel.</p>
<p>The moment things become complicated is when virtualization kicks in:
in a virtualized system, none of the virtual machines shall directly
talk to the hardware; this task is pushed to a hypervisor. As
functionality shouldn't be split, PSCI was invented (the Power State
Coordination Interface). On ARM, PSCI is a secure monitor call, and it
makes bare metal kernel and virtualization look the same. However,
central functionality has to be pushed into the secure monitor
firmware. As it turned out that chip vendors started to implement things
wrong, ARM started implementing PSCI in Trusted Firmware to make it
right. However, as Trusted Firmware is BSD licensed, it makes it
possible for the chip vendors to close the code down and have really
central components of the system in closed code, with no options for
kernel devs for improving things.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock2.thumb.e7636300593825c7a44f11a557eb8dad.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Experience shows that when the design of this hits real world, things
happen that the developers didn't think of. For instance, Lucas has seen
implementations where power domain bits for different processors have
been in the same registers, without having an interlocking mechanism.
Another example is the communication with an external power controller:
in system bring-up, the firmware needs to talk to the PMIC via I2C, which
should be under control of the kernel. So in fact, a lot of current
hardware isn't designed to provide the separation required by PSCI.</p>
<p>In result, even more stuff is pushed down into firmware, by using the
SCMI interface. It makes it possible to handle power, clocks, sensors
and system control down in the firmware. Now the implementation in the
kernel becomes easy, but firmware gets <em>much</em> more complex, and lots of
runtime interactions between firmware and operating system become
necessary. If you are now hunting down a system malfunction, you cannot
look at a single code base any more. Even worse, the firmware part might
be closed source, so things become really hard to fix.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3244x2462" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-rock3.thumb.fb493d35e0f570f8bfb2d93caf061532.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Unfortunately, as soon as anyone cares about virtualization, the
complexity cannot be ignored any more. Even worse, looking at more
modern systems, SoCs are becoming more asymmetric and add management
processors to the application processors. While it becomes more easy to
offload functionality to the coprocessors, the need for more shared
resources explodes: i.e. Linux is suddenly just one of the users of
clock control. Vendors now start adding system control coprocessors for
these central tasks, with all kinds of weird interfaces.</p>
<p>In conclusion, firmware is taking over more control over our systems; we
should have a close look that the chip companies continue open
sourcing their firmware code. There are some good examples out there,
like Xilinx which opens up all their code, but we need to stay fully
awake and try to push vendors into an open direction.</p>
</div>
<div class="section" id="the-gnss-subsystem">
<h3>The GNSS Subsystem</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gnss1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gnss1.thumb.a8c0238cefc3a0355bc5c76e8a4ca245.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After lunch, Johan Hovold talked about the newly merged GNSS kernel
subsystem, dealing with Global Navigation Satellite Systems. So far,
talking to GNSS receivers has been handled entirely in userspace, but
this has changed recently. While the initialization and triangulation
algorithms mainly happen inside the GNSS chipset, the devices usually
incorporate an interface such as an UART or USB to connect to the SoC.
On the receiver protocol side, NMEA0183 is the de-facto standard;
however, proprietary vendor specific protocols are also around, and in
some cases it is even possible to switch between both variants.</p>
<p>On Linux, gpsd is usually used in Linux userspace and deals with the
serial or USB port and with power management. However, it turned out
that this was not enough, especially when it comes to power state
information: in some cases, this has to be handled inband, and in more
sophisticated embedded scenarios it even had to handle serdev devices.
This in combination with regulator, gpio and clock handling meant that
something had to change. Nevertheless, pushing everything into the
kernel was no solution as well, as for example some proprietary
protocols cannot be implemented in the kernel. So a decision was made to
keep the protocol handling in userspace and move the other mechanisms
into the kernel.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gnss2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-gnss2.thumb.e5a340affe45e70e826d1a4ddc799881.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The framework was merged into the 4.19 kernel released last Monday. It
currently provides support for NMEA, SiRFstar and UBX style devices and
provides a /dev/gnss0 interface. Power regulator issues are handled by
devicetree specifications. One of the remaining issues that is not
resolved yet is line speed handling and hotplugging, but things are
being discussed.</p>
<p>In addition to standalone receivers, there are devices available that
are integrated into modems, which offer more sophisticated features such
as A-GPS or reduced-time-to-fix, or integration with the ofono stack; as
it turned out that not everything could be done in the kernel, ugnss was
invented which pushes part of the handling back into userspace.</p>
<p>For the future, features like integration with pulse per second devices,
low-noise amplifiers, more ugnss support and a new highlevel interface
stay to be solved.</p>
</div>
<div class="section" id="iot-tls-why-it-is-hard">
<h3>IoT TLS: Why it is Hard</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-tls1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-tls1.thumb.73c59c01f3f75f946a65ee4972668fbe.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>David Brown then talked about TLS in the Zephyr context: he found that
none of the IoT examples around were secure. From a scientific
perspective, IoT security is not different from normal IT security, but
reality is different: as long as you talk about Raspberry Pis, it is a
normal Linux, with OpenSSL etc. But what about really small and cheap
systems? They might not even have enough memory for OpenSSL; and, of
course, there are lots of "middle size" devices which might have enough
memory, but it's hard.</p>
<p>On midsize devices, there might not even be a "real" kernel that
implements the lower layers of the network stack. The TLS handshake
consists of the device and the server agreeing on a cipher suite and
exchange certificates; however, in contrast to "big" servers, once a
certain cipher suite becomes insecure, the device might not even be able
to talk to anyone any more, so one should make sure software can be
updated. Another aspect is that the whole security comes from good
randomness on the device. So when selecting CPUs for IoT devices, one
should watch out for a model with a good hardware random number generator.
If randomness is bad, solving the problem might go down from "more than
the remaining lifetime of the universe" to "just a few minutes". And of
course the certificate of the server you are talking to needs to be
properly checked. Resources are pretty much constrained on embedded
devices: they might just have something as 100 kB of memory; there might
not be a good time source.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-tls2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-tls2.thumb.26be6cdec6f97f6136cdcb85fb539729.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>On the software side, existing TLS libraries such as OpenSSL are
not designed for devices that use a single-threaded software pattern.
Normally, TLS is integrated into the transportation layer, so it is
mainly transparent to the application; however, on small devices, this
abstraction doesn't fit: there is often a mainloop, so sending and
receiving packets is done in the same loop.</p>
<p>David looked at where Zephyr is now: while there still is Sockets+TLS
support, the Zephyr network API changes towards ideas that fit the
mainloop better; however, the work is not done yet, and the available
patches are not merged yet. So sorry - at the moment, it <em>stays</em> hard.</p>
</div>
<div class="section" id="a-sockets-api-for-lora">
<h3>A Sockets API for LoRa</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3292x2426" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-lora1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-lora1.thumb.d8fe714df32c2a778dd51e005c2156bf.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the last talk of the day, Andreas Färber talked about LoRa, a low
speed IoT protocol that works on license free ISM bands. When he started
with his first hardware, there was a lot of lowlevel technology. The
chipset he started with was equipped with a chipset without permanently
stored register setting, and the MAC had to be done on the Linux side as
well. A 2nd generation of modules had a microcontroller running an
optionally certified MAC, so there was a chance of certifying the
resulting device. Still, the question remained how to integrate all that
into Linux.</p>
<p>The first attempt of attaching LoRa devices goes via userspace
interfaces (SPI, serial, USB); however, this has several issues. The
solutions are mostly vendor specific, there is no upstream community,
the stacks have license issues, and many other tasks that should be
done by a kernel are externalized to userspace. So the idea came up to
move chipset drivers into the mainline kernel and encourage generic,
community-maintained packet forwarders.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3290x2428" href="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-lora2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-24_elce-day-three/2018-10-24_elce-2018-day-three-lora2.thumb.b70efc9f2dfc9465ce4cbed822650d0b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Following this idea, he started collecting requirements and implemented
some code, following the ideas of the kernel's WiFi and 802.15.4 stacks.
Unfortunately, in contrast to Ethernet based protocols, there is no good
possibility to actually find out about the used upper layer protocol (as
LoRAWAN); with that many differences between the hardware and software
components of the stack, it stays challenging to find out the right
abstractions for the kernel.</p>
</div>
</div>
<p>This is my report from the 3rd day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>2018-10-24T10:00:00+01:00tag:www.pengutronix.de,2018-10-23:/2018-10-23-elce-2018-day-two.htmlrsc's Diary: ELC-E 2018 - Day 22018-10-23T22:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2018-day-2">
<p>This is my report from the 2nd day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>
<div class="section" id="grabbing-audio-and-video-on-a-board-farm">
<h3>Grabbing Audio and Video on a Board Farm</h3>
<p>Krzysztof Opasiak runs board farms at Samsung. Board farms are both used
for automated testing and for making boards available to the developers,
because hardware is always rare in early project phases. Another use case
in Samsung is to give developers access to devices without actually
giving the (potentially secret prototypes!) new devices to them
physically and maybe shipping boards around the world. He found that
running board farms is almost like running a server room, so putting
that into centralized places with staff available that can fix cables is a
good idea. On the software side, he uses LAVA to manage his test queue.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-muxpi3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-muxpi3.thumb.3f57b9f0a86cf857ddb660ab54ed6ec3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>On the hardware side, they decided that each DuT should be connected to
one computer, called MuxPi; the architecture can be <a class="reference external" href="https://github.com/SamsungSLAV">found on GitHub</a>. Each device provides an API to
access the hardware. The layer above, BORRUTA, takes care of organizing
access to devices (similar to what labgrid does).</p>
<p>A MuxPi consists of a NanoPi (well, it's cheap) and does power supply,
SD muxing and "dipers" (dynamic jumpers - relais for power-on switches
etc.), plus an USB serial switch and the usual serial console. In
addition, they found that it is a good idea to have a display, in order
to show the board status.</p>
<p>Audio and video are not directly included, but there is an HDMI
connector on the board with an EDID injector to fake monitors in case
the DuT expects one. If you really want to grab audio and video, an
add-on board is available with an LKV373a HDMI extender: it is normally
used for distributing HDMI over Ethernet to synchronized monitors.</p>
<p>The chip streams video (in an mpeg-ish way with proprietary extensions)
into the network, and it costs $30. The MuxPi then emulates keyboard and
mouse, using the USB device controller on the NanoPi NEO. While sending
keyboard events was easy, sending mouse events was CPU load intensive,
so he better sends touchscreen events.</p>
<p>As there are issues with the LKV device, there might be a better option
with the HDMI2USB, an Australian grabber project. However, that device
is currently too expensive for their needs.</p>
</div>
<div class="section" id="drone-sitl-bringup-with-the-iio-framework">
<h3>Drone SITL Bringup With the IIO Framework</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3292x2426" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-sitl1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-sitl1.thumb.14157094c97cd92ba81c179c875985c1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Next, Bandan Das talked about software in the loop and the industrial
I/O framework, which is one of his hobby projects back from university
days. Today most drone controller hardware is based on microcontrollers,
i.e. STM32, but that's not the right choice if you want to have more
powerful hardware and algorithms involved, such as sophisticated video
processing. He is using the Intel Aero Compute Board that consists of an
x86 processor with a companion STM32 CPU for the actual flight control,
which looks a bit like redundancy to him, so he searched for options to
run the actual control code on x86 as well.</p>
<p>In a first step, he played with the SPI and I2C userspace drivers to
access the sensors, but it would be better for system stability to have
proper drivers, so he started working with the industrial I/O framework.
The board has an inertia measurement unit, a 3-axis geomagnetic sensor
and a pressure sensor; fortunately, there were already drivers available
in the IIO framework.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3278x2438" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-sitl2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-sitl2.thumb.e3a247b93b38c04ae4052eda5367285e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>IIO has an abstraction of "channels" which bundle the data from one
sensor, "buffers" to transport the raw data and transport it into a
ringbuffer with mmap support for userspace and "triggers". Triggers can
be triggered by the same/another device or even by userspace, and they
provide the events to attach your application to. In userspace, there is
a shim layer library called libiio, making access to IIO devices easy to
handle.</p>
<p>Next, he was dealing with SITL/HITL: the idea is that, other than
directly working with the real hardware, it is possible to have
software-in-the-loop and simulate the actual hardware, while the drone
software thinks it is software from the sensors. The SITL code basically
has to fill in data into the corresponding data structures; instead of
getting that from real sensors, it can be pushed in and out via UDP
network packets.</p>
<p>Currently, he doesn't have the whole flight stack running, but played
with the loop speed. Unsurprisingly, an unpatched mainline stack showed
spikes in the cycle time; however, isolating CPUs did already make the
spikes go away. He has a todo list, which also includes testing the
RT_PREEMPT kernel and doing more latency tests.</p>
</div>
<div class="section" id="deploy-software-updates-for-linux-devices">
<h3>Deploy Software Updates for Linux Devices</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-mender.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-mender.thumb.3fdd94fc19bf9a18d5b74e4a22adecba.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Mirza Krak then talked about how to build, test and deploy embedded
Linux firmware for devices. He first explained the overall Linux
development environment and possibilities to transfer self written
software to the devices; for the automated integration of his systems,
he uses Yocto and the Ångström distribution.</p>
<p>For deploying firmware into production, he recommends using an image
based update, because it is stateless: once you have flashed a
device, you know what you are running. He is using mender for updating
the systems; for local development, images can simply be loaded from a
local server, but it does also scale towards bigger setups.</p>
<p>Unfortunately, he stopped explaining where the actually interesting
things started, so playing with mender and finding out about its
possibilities and limitations stays as an exercise for the listener.</p>
</div>
<div class="section" id="linux-and-zephyr-talking-to-each-other-in-the-same-soc">
<h3>Linux and Zephyr "talking" to each other in the same SoC</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-rpmsg1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-rpmsg1.thumb.e0c68411110e18067cf83d4ef3bb89cf.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After lunch, Diego Sueiro talked about how "heterogeneous" processors on
the same SoC can communicate. In recent times, more and more SoCs turn
up which, besides the main CPU, contain a set of usually small
coprocessors for dedicated realtime ore otherwise privileged tasks.
For example, the processor Diego is working on is an i.MX7 from NXP.</p>
<p>While realtime Linux with RT Preempt might be a solution for some
realtime tasks, having special controllers which only run the realtime
load might be helpful for some use cases. The i.MX7 has a Cortex-A7 for
Linux and a Cortex-M4 which can be used for companion work. For
communication between the processors, there are hardware mailboxes and
semaphores available.</p>
<p>The OpenAMP standard provides a set of software infrastructure with
hardware support:</p>
<ul class="simple">
<li><em>remoteproc</em> to control/manage remote processors (power off, reset,
load firmware)</li>
<li><em>RPMsg</em> for inter processor communication (virtio)</li>
<li>Proxy operations: remote access to system services</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-rpmsg2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-rpmsg2.thumb.b085edf3cd7647660595fb8f83dfbcc7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Diego explained the different hardware components which make those
interfaces possible.</p>
<p>On the Zephyr side, there is a RPMsg-lite implementation available with
a small footprint: currently it supports a queue and a name service
which allows the communicating node to send announcements about "named"
endpoints. He explained how to build the necessary components on Zephyr.</p>
<p>In his demo, he showed how to operate one serial interface from the
Cortex-A and a second one from the Cortex-M, communicating via rpmsg.</p>
<p>Unfortunately, Diego didn't find our recent kernel patches that brought
RPMsg support into mainline but used the outdated NXP 4.9 kernel
instead, so the details outlined in the talk have to be taken with a
piece of salt.</p>
</div>
<div class="section" id="years-of-industrial-io">
<h3>10 Years of Industrial IO</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3256x2454" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-iio1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-iio1.thumb.0bc3fa4636f21bfc60fe438b504f65c0.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Jonathan Cameron then talked about his experiences of maintaining the
IIO subsystem of the kernel for the last 10 years. It all started when
he was trying to upstream some sensor drivers at that time, but there
was no right abstraction for it in the kernel, so he asked on the kernel
mailing list and got the answer: "you'll need to do something new". And
so he started.</p>
<p>Over the time, all sorts of devices like ADCs, DACs, but also
accelerometers, gyroscopes, magnetometers, IMUs, light chemical sensors
etc. have been added. Basically, IIO's most important characteristic is
it's userspace interface, which makes it possible to have hardware
independent application code. Single-channel data is read from sysfs,
but mass data can also be transferred via FIFOs implemented with
character devices.</p>
<p>Some years ago, a mechanism has been added that makes it possible to use
IIO devices not only from userspace but also from other kernel drivers,
even from different drivers at the same time. Higher level drivers like
touch screen can thus make use of low-level ADC interfaces. A lot of
complexity has been added, but of course not all devices need that.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3290x2428" href="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-iio2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-23_elce-day-two/2018-10-23_elce-2018-day-two-iio2.thumb.27ec6b063fa640778ee34bf34aba29ba.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The biggest issue still is that it is difficult to predict the future.
In the past, the maintainers have tried to stay compatible with current
ABIs (like for hwmon), but that didn't always turn out to be a good
choice. So deciding about the right level of simplicity vs. abstraction
stays difficult, as one can't predict which future requirements may come
up. Another common question is about how high performance devices fit
in: instead of reading values one by one, there are use cases that
require high performance DMA transfers with inline meta data, self
describing flows etc.; these are currently not handled in mainline.
Complex sensors with proprietary userspace interfaces, like pulse
oximeters, are also not solved so far.</p>
<p>Besides the technical part of the story, there's also the community one.
IIO started in staging, so it needed quite some discussions until the
code was in "unstaged" mainline. In recent times, new drivers come in
the normal way, but some drivers are still left in the staging area.
Once the subsystem was there, quite a few companies, but also hobbyists
and students were interested; over the time, more than 1000 authors
contributed to the subsystem.</p>
</div>
</div>
<p>This is my report from the 2nd day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>2018-10-23T22:00:00+01:00tag:www.pengutronix.de,2018-10-22:/2018-10-22-elce-2018-day-one.htmlrsc's Diary: ELC-E 2018 - Day 12018-10-22T22:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2018-day-1">
<p>This is my report from the first day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>
<div class="section" id="keynotes">
<h3>Keynotes</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-intro.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-intro.thumb.ff3a71b7e7e6cd25c5575549a2ffd94a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The morning of the first ELC-E day started with keynotes; I used the
time to visit the booths. Unfortunately, there are not that many
embedded topics around, so it was a quick walk. I tried to visit
Jonathan Corbet's kernel keynote, but it was already full, so I watched
the livestream. Jonathan talked about long term kernel stability, and it
was good to see that he is proposing to use modern mainline kernels (or
at least the latest "stable" kernels) instead of trying to use those
pretty old longterm kernels - that's basically what we at Pengutronix
tell our customers for a long time now.</p>
<p>Later, in the evening, I watched the video of the LF Energy project. I
have no idea what they want to do: a talk without any content, and
anyone who is interested shall come to an extra $200 session on
Thursday. Really, LF...?</p>
</div>
<div class="section" id="prplmesh">
<h3>prplMesh</h3>
<p>The first technical talk I heard on day 1 was Arnout Vandecappelle's
talk about "prplMesh: An Open-Source Implementation of the Wi-Fi
Alliance Multi-AP Specification". Basically, the standard provides a
possibility to connect different access points by WiFi instead of a
cable. There is a concept of a single "controller agent" per network -
the device that has an upstream link. Controller agents propagate their
availability through the network.</p>
<p>The first-time authentication works similar as WPS, routed over the
network. The Multi AP standard has been finished, so the first vendors
start implementing it. The idea of the carriers is that they have full
control over people's networks, so that normal folks can call their
helpdesk and they have full management possibilities.</p>
<p>The prpl stack sits in Linux userspace, provides features for
configuration, multicast, routing, QoS and meshing and provides a high
level API for upper layers. The reference implementation for Linux is
open source and ready to be WiFi certified, but they see the controller
agent as a differentiator, so that part isn't open source.</p>
<p>The prpl mesh system works with cfg80211 and a patched hostapd. Some
features are still missing, such as end-to-end authentication/encryption
or QoS, but those parts are being worked on and should be fixed in their
2nd release.</p>
</div>
<div class="section" id="the-modern-linux-graphics-stack-on-embedded-systems">
<h3>The Modern Linux Graphics Stack on Embedded Systems</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-graphic1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-graphic1.thumb.4ffcf622b9eb4c26ead086920ea3664c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>My colleague Michael Tretter then talked about the recent Linux graphics
stack. In contrast to desktop environments (which have been dominated by
X.org for the last 30 years), embedded setups have a set of new
challenges; this is where wayland comes into the play. While wayland is
mainly about the protocols, the compositor does the actual work, being
complemented by the wayland "shell", which is the visible part. All
major toolkits (Qt, GTK+, Chromium) have been ported to wayland. In
contrast to X11, the toolkit directly talks to Mesa/OpenGL and the
compositor does only care about compositing.</p>
<p>On embedded systems, we have limited hardware resources, memory
bandwidth and maybe even (battery) power. This results in different
hardware accelerators on embedded systems. In many cases, the different
parts of the graphics hardware are from several IP core vendors, which
often results in incompatibilities of the used memory formats.</p>
<p>One important mechanism for saving memory bandwidth is the dma-buf
framework: it makes it possible to hand over hardware memory buffers
from one component to the other without actually copying memory. A
second important mechanism is atomic modeset, which makes it possible to
change all components of a graphics format at once. Although the drivers
support many of the accelerated features, it is a challenge to make
those mechanisms available for the upper layers of the stack. Weston,
with its DRM backend, turned out to be a good candidate for that task:
it takes care of dma-buf, atomic modesets, overlays and format
modifiers. Currently directly putting tiled buffers on an output plane
is not supported yet.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-graphic2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-graphic2.thumb.fec24bb56df94253fcfb0eca4db25dc1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>While Weston provides a default shell, on an actual embedded system you
might want to write your own shell - in the end, it's the thing visible
to the user. There are several example shells in the code base like the
Desktop Shell, the IVI Shell or the Fullscreen Shell. It turned out that
the IVI Shell, initially written for in-vehicle-infotainment, might be a
good candidate for other kinds of embedded systems as well, so Michael
took a closer look. Unfortunately, the xdg_shell protocol was not
implemented, so normal applications couldn't be used; however, there is
a patch set available. Michael took that and replaced the HMI
controller with a custom plugin and made it possible to hook in a
selfmade user interface.</p>
<p>Looking for alternatives, there is another framework available for
writing own compositors, called wlroots, which is a modular wayland
compositor library (used by Sway, Phosh and Rootston). In his opinion,
the problem with wlroots is that it doesn't make use of overlay planes
and format modifiers. For people writing their visible components in
QML, Qt Compositor is also available, but does also not use atomic
modeset and format modifiers.</p>
<p>In conclusion, Michael is currently not unhappy with the possibilities
Weston provides.</p>
</div>
<div class="section" id="developing-open-source-software-rtos-with-functional-safety-in-mind">
<h3>Developing Open-Source Software RTOS with Functional Safety in Mind?</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-safety1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-safety1.thumb.338f6c2fefb0113b4d6107732150a09b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In my first afternoon session, I listened to Anas Nashif talking about
Zephyr and safety. He outlined that open source software can in general
be used for safety critical systems, but one must take care that the
safety aspect is taken into account early in the project's life cycle -
otherwise things might become really expensive.</p>
<p>While Zephyr has a small trusted code base and offers all the core
features of an realtime operating system, safety standards require a
V-model and traceability from requirements to the code; it turned out
that this is difficult to achieve for open source projects which are
developed to a more bazaar like development model: for every line of
code, you need a requirement, documentation and testing. The group has
used doxygen to scan and document all these things, and it turned out to
be a lot of work.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3282x2434" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-safety2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-safety2.thumb.9dcd72c5a70d3b573b3f2c6eed0839e4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>For coding standard, Zephyr uses the MISRA-C guidelines; MISRA-C
requires functions to have a single point of exit at the end, which
turns out problematic from time to time.</p>
<p>One of the issues people have with open source is that there is always
the question "who is liable if something goes wrong?". Even if you have
a codebase that fulfills the requirements, nobody wants to be the first
one using it.</p>
<p>Currently the best way of doing safety with Zephyr turned out to start
with snapshotting the source tree, then validating it, specify which
features to use and automatically track and document it - basically
building a cathedral on top of the bazaar. It is also a good idea to get
a proof of concept approval from a certification authority as early as
possible. In his point of view, the ideal project has a split
development model: a flexible open source instance, plus an auditable
and controlled instance. In this setup, the open source community helps
to enrich the open instance, while the owning entity maintains the
auditable instance and takes on the certification qualification
overheads. He explained that SafeRTOS did something similar on top of
the FreeRTOS codebase, but not in public, and they want to stay in
public with their own Zephyr based codebase. Their roadmap to FuSA &
Security pre-certification contains things like limiting the scope - i.e.
by concentrating on a PSE52 environment.</p>
<p>My conclusion was that I'm still not convinced by Zephyr from a
political point of view: one of the strengths of Linux is that the GPL
enforces everyone in the industry who makes actual <em>use</em> of Linux to
have equal rights and possibilities. With the Apache 2 license of Zephyr
and with people doing safety processes behind closed doors, my
expectation is that they happily take contributions from the community
while doing lucrative things like safety projects which nobody else can
do, because the safety process is not open.</p>
</div>
<div class="section" id="gbps-open-source-software-router-it-s-here">
<h3>100 Gbps Open source Software Router? It's Here</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3236x2468" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-router.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-router.thumb.abe6ba62b930bc18139efdaa307de5c4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Then Jim Thompson talked about high bandwidth routing in the 2nd
afternoon session. It turned out that there is an increasing demand for
open source router platforms - mainly because people want to include
routers in their standard IT automation and monitoring systems instead
of relying on proprietary offers.</p>
<p>It turned out that filling network pipelines at 100 Gbps speed contains
a whole set of engineering challenges. The solution he proposed is based
on commodity hardware (water cooled and overclocked), offload network
cards (Mellanox) plus a userspace control and dataplane stack, including
userspace network card drivers, using the DPDK, VPP, Clixon, Strongswan,
FRR and Netgate software stacks. With that setup, they bring the cost of
such a router down to $7,500.</p>
</div>
<div class="section" id="linux-on-risc-v">
<h3>Linux on RISC-V</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3256x2452" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-riscv.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-riscv.thumb.98521108fb7354721ca1eade2232420a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Next, Khem Raj explained the current status of the RISC-V Linux port.
After showing the feature set of the instruction set architecture he
talked about the state of the toolchain, being developed with an
"upstream first" strategy. Binutils is supported since 2.28, the RISC-V
port landed in GCC 7.0 and in glibc 2.27. As there is still not much
hardware available, it is important that QEMU 2.12.0 supports RISC-V as
well. The RV64GC-LP64 little endian ABI is the current standard for the
Linux port; currently the number of Debian packets ported to the
architecture is increasing and reached a fairly nice level. Open
Embedded is also providing good coverage of the architecture and
supports QEMU and the SiFive Freedom U540. However, some key packages
are not compiling yet, like GStreamer.</p>
<p>Other tools make progress with RISC-V support as well, such as LLVM,
OpenOCD and GDB; there is also an ongoing effort for support in UEFI,
Grub, V8, Node.js and Rust. As there is still a lot of work to be done,
the project is searching for more contributors.</p>
</div>
<div class="section" id="primer-testing-your-embedded-system">
<h3>Primer - Testing Your Embedded System</h3>
<p>As we have initiated the labgrid project for automated testing, looking
at what's happening in the Linux test community is always interesting.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3252x2456" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-test1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-test1.thumb.dfe18bdac729dbbfceb6dd5fe45a01d3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Jan-Simon Möller then talked about "Primer - Testing Your Embedded
System". He looked into a set of testing frameworks, starting with
Yocto's ptest, a mechanism to package the results of 'make test' of a
package "foo" into a package "foo-ptest", transfer and then execute them
to the target. Unsurprisingly, ptest is well integrated into Yocto/OE
(although some sysroot path fixup needs to be done manually in order to
make the tests run on the target). Currently, about 64 ptest packages
are in the OE codebase. However, the output is quite large, a full
run takes a lot of time (such as 5 hours) and the resulting visualization
needs postprocessing.</p>
<p>The next test framework he tested is Fuego, an automated testing system
for embedded targets from a host with 100 pre-packaged tests. Fuego is a
Jenkins instance already pre-loaded with the tests; it can also build and
upload the tests to the target, then parse and visualize the results. A
big plus is that there are many tests out of the box; the system needs
no prerequisites on the target besides ssh and the test results can be
nicely graphed in Jenkins. On the negative side, it assumes the board is
local, deployed with filesystems and each board needs a separate
configuration.</p>
<p>The next system to look at was LAVA, started by Linaro. LAVA manages
the deployment of filesystems to a board farm, then power on, boot and
execute the tests on the DuT. Currently, about 150 types of boards are
supported and LAVA scales nicely towards large numbers of
devices-under-test. Multiple labs are supported as well. However, the
initial setup is hard and the test result parsing is not easy.</p>
<p>He then looked into KernelCI, which is about test aggregation and
visualization. The test results are collected in a JSON format and
uploaded to the kernelci.org visualization web interface. Most of the
labs run LAVA, but the upload is independent of the tools. Meanwhile, in
addition to boot testing, KernelCI does also care about actual runtime
tests. The setup stays difficult.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3246x2460" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-test2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-test2.thumb.75b766cb119f10e0347875399c27acb7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The next system Jan-Simon looked at was labgrid. It was started by
Pengutronix and it is an abstraction of hardware control layer for
testing embedded Linux systems. In addition to automated testing, it
makes boards accessible for a developer for interactive use. His
positive findings are that it's easy to get automated and developer
access and abstracts the hardware nicely. On the negative side,
integration with test tools (LAVA/Fuego) and the setup with pip were
difficult. The docs are quite good. Those findings are of course
extremely helpful for us, because seeing what kind of issues people have
with labgrid helps us improving the codebase; some of the setup issues
he has seen might already be solved in more recent versions.</p>
<p>Next, r4d was analyzed, which is used by the PREEMPT_RT folks. It
integrates into libvirt, so switching boards on and off feels like
switching virtual machines on and off, which is nice. However, the
libvirt patches are not in upstream yet.</p>
<p>All in all, his conclusion was that the frameworks all have their own
strengths; collaboration and test result aggregation stay the most
important thing to do.</p>
</div>
<div class="section" id="bof-embedded-update-tools">
<h3>BoF: Embedded Update Tools</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3264x2448" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-updating1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-updating1.thumb.28426f29b468cf85a3c708c67fc323a5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The last session of the day I participated in was my colleague Jan
Lübbe's "BoF: Embedded Update Tools". Instead of a talk, Jan decided to
offer a BoF, in order to hear more about what the attendees need in the
embedded updating area. Good tools should make sure the intended
software ends up on the devices in a fail-safe and secure way. The
existing image based tools like SWUpdate, Mender, RAUC etc. or the file
based tools like OSTree and SWUpdate (used by Clear Linux) provide all
that. For the BoF, Jan wanted to focus on image based mechanisms (in
contrast to systems like deb/rpm/opk based systems or systems that focus
on container updates).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-updating2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-10-22_elce-day-one/2018-10-22_elce-2018-day-one-updating2.thumb.f0dc6a76b7f8c67e430b9f43963116f2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The discussion was very active and people talked about their user
stories. From the content point of view, too many aspects have been
discussed for this short overview article, so this might be a topic
to another blog post.</p>
</div>
</div>
<p>This is my report from the first day of Embedded Linux Conference Europe
(ELC-E) 2018 in Edinburgh.</p>2018-10-22T22:00:00+01:00tag:www.pengutronix.de,2018-09-28:/2018-09-28-osfc2018.htmlOpen Source Firmware Conference 20182018-09-28T07:52:00+01:00Oleksij Rempel<div class="section" id="open-source-firmware-conference-2018">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2018/2018-09-28_osfc2018/2018-09-28_osfc2018_en.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-09-28_osfc2018/2018-09-28_osfc2018_en.thumb.7cf7a918c25c2a1920ea431c4d602e1c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>At September 12-15 the first conference focusing exclusively on open
source firmware took place in Erlangen, Germany - the OSFC 2018. The
mission of this conference is to provide an appropriate platform to
bring together as many Open Source projects, hardware manufacturers and
developers as possible, in order to collaborate, share knowledge and
push the firmware development in an Open Source manner.</p>
<p>Different topics related to the open firmware developments mostly targeting
different bootloader or payload variants were presented at the conference.
LinuxBoot, coreboot, U-Boot and TianoCore and ARM Trusted Firmware related topics
were intensively covered in different talks.</p>
<p>Pengutronix and the <a class="reference external" href="https://barebox.org">barebox</a> bootloader project
were represented by Sascha Hauer and Oleksij Rempel. While we didn't do
any presentation ourselves we had a chance to communicate with many
developers representing different projects with open or even closed
nature.</p>
<p>From different talks I would note the following:</p>
<ul class="simple">
<li>many vendors do things and not always contribute back to initial open source
projects - (this is not new)</li>
<li>some vendors are looking for open source alternatives, for example for BIOS,
because government related customers forbid usage of closed software for security
reasons.</li>
<li>almost all companies make their own variants of bootloaders, with special use
case covering specific hardware.</li>
</ul>
<p>All in all, it was an interesting conference, with many good talks and
insights into other firmware projects' motivation.</p>
</div>
<p>At September 12-15 the first conference focusing exclusively on open
source firmware took place in Erlangen, Germany - the OSFC 2018. The
mission of this conference is to provide an appropriate platform to
bring together as many Open Source projects, hardware manufacturers and
developers as possible, in order to collaborate, share knowledge and
push the firmware development in an Open Source manner.</p>2018-09-28T07:52:00+01:00tag:www.pengutronix.de,2018-09-13:/2018-09-13-fixing_icecc.htmlFixing ICECC, our Workhorse for Building BSPs2018-09-13T16:19:00+01:00Lucas Stach<div class="section" id="fixing-icecc-our-workhorse-for-building-bsps">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1031x715" href="https://www.pengutronix.de/media/blog/2018/2018-09-13_fixing-icecc/2018-09-13_fixing_icecc_github.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-09-13_fixing-icecc/2018-09-13_fixing_icecc_github.thumb.b18046255c9cca0b5a99d07d2d996f91.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>While developing operating system infrastructure for industrial devices
for our customers, we build lots of embedded Linux board support
packages, kernels, bootloaders etc. at Pengutronix. Although ICECC should be
a good tool to distribute the computing power to a cluster of
machines, it recently turned out that things are not that simple.</p>
<p>Building embedded Linux systems is a time consuming task: in order to
make them reproducible, the whole software stack is usually compiled
with a build system, for instance <a class="reference external" href="https://ptxdist.org">PTXdist</a> or
<a class="reference external" href="https://yoctoproject.org">Yocto/OE</a>. Even for a medium-sized project,
about 100 million lines of code have to be compiled. The advantage is that
building the code is an everyday job, well tested and exercised, so
everything is under control and in case of issues we <em>know</em> that we are
able to instrument the code and find out what goes wrong. However, the
downside is that compilation on a single PC needs a lot of time.</p>
<p>At Pengutronix we have already used <a class="reference external" href="https://github.com/icecc">ICECC</a>
for several years now, spreading compile jobs over the available CPUs in
the office. Over the years, the teams are growing, CPU and storage
bandwidth need to be scaled up, and so we recently got a new dedicated
compile cluster. However, when setting up the new hardware, it turned
out that ICECC itself had software issues that made the tool less
helpful than expected.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x758" href="https://www.pengutronix.de/media/blog/2018/2018-09-13_fixing-icecc/2018-09-13_fixing_icecc_dude2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-09-13_fixing-icecc/2018-09-13_fixing_icecc_dude2.thumb.9865a5d73f0053530fb5799b2cdfaa44.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The ICECC project was developed at SUSE several years ago, based on
distcc. A central server machine – we have one of those in each cluster –
runs a scheduler that dynamically distributes compile jobs to the
fastest free CPU nodes in the cluster.</p>
<p>Unfortunately, it turned out that the heuristics that decide about which
machine to send jobs to showed the age of the code:</p>
<ul class="simple">
<li>Machines which contained more than 128 MB of free RAM (which is quite
common with modern machines) were always considered to have no
memory load, which is obviously not true.</li>
<li>Another problem was that in a cluster with machines of roughly the
same speed, the algorithm was fully loading the fastest machine
instead of distributing the load equally over the available
resources. This led to some machines being overloaded (stepping down
from their highest clock speeds and using sibling threads), while
others were sitting idle.</li>
<li>From time to time it happened that ICECC downrated a node due to
external influences outside of the control of ICECC; when this
happened, a downrated node would never get any new jobs assigned and
was thus unable to get a new (possibly better) speed rating
calculated until the cluster was loaded heavily enough for jobs to
spill over to those "slow" nodes.</li>
</ul>
<p>At this year's Pengutronix Technology Week, I took some time and
reworked the algorithms to fix those issues. <a class="reference external" href="https://github.com/icecc/icecream/pull/412">The resulting pull request
was merged into ICECC</a>
in August 2018.</p>
<p>Exact performance numbers are hard to come up with due to a lot of noise
on the cluster, but our results seem to indicate a reduction in overall
build times of about 30% for a typical PTXdist based rootfs.</p>
</div>
<p>While developing operating system infrastructure for industrial devices
for our customers, we build lots of embedded Linux board support
packages, kernels, bootloaders etc. at Pengutronix. Although ICECC should be
a good tool to distribute the computing power to a cluster of
machines, it recently turned out that things are not that simple.</p>2018-09-13T16:19:00+01:00tag:www.pengutronix.de,2018-08-28:/2018-08-28-what_kernel_to_use.htmlWhat Kernel Should I Use (Embedded Edition)2018-08-28T08:00:00+01:00Robert Schwebel<div class="section" id="what-kernel-should-i-use-embedded-edition">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="877x547" href="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_gregkh-kernelversion.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_gregkh-kernelversion.thumb.00af19f025709133f0c5e2536c34f217.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Some days ago, Greg Kroah-Hartmann wrote a great blogpost about <a class="reference external" href="http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/">Which Stable
Kernel One Should Use?</a>.
I fully agree with his position; however, I'd like to make
some additions for the industry device manufacturer use case and some
common pitfalls and misunderstandings we see in that area.</p>
<p>If you didn't read Greg's article yet, please do so first; Greg does a
great job maintaining the stable kernels, and in his article, he
explains the motivation and mechanisms of the kernel's "stable" process
and its different variants.</p>
<p>Especially in the "Older LTS release" section, he describes the dilemma
industrial device manufacturers (like Pengutronix' customers) are in:
SoC manufacturers often start Linux development years before a new chip
comes out, and once the chip is released, the kernel support they give
to their customers is already quite old and contains tons of out-of-tree
patches.</p>
<div class="section" id="lts-isn-t-automatically-long-term-stable">
<h3>LTS Isn't Automatically Long Term Stable</h3>
<p>While the chip manufacturers originally have started with a LTS series,
the name is misleading: a "long term stable" kernel does not magically
start being long term stable just because of the name: you only get the
promises of the maintainer teams for your industrial product if…</p>
<blockquote>
<ul class="simple">
<li>… you use an LTS kernel unmodified, and</li>
<li>… if you always update to the latest versions of an LTS series,
because that's the version that contains all the bugfixes and
security fixes known and backported from mainline at a certain point
in time.</li>
</ul>
</blockquote>
<p>What we see in many industry projects is that chip vendors push BSPs to
their customers that start with an LTS version, then they add up to 3000
patches for their chips which never went through the community review
process. However, the review process is what makes Linux the rock solid
and high quality operating system we all love!</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="972x1436" href="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_what_kernel_to_use_nand.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_what_kernel_to_use_nand.thumb.17b602cf956b0445a6d75c63d12953f3.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p><a class="reference external" href="http://lists.infradead.org/pipermail/linux-mtd/2018-May/080743.html">Broken Backport to LTS Kernel</a></p>
</figcaption>
</figure>
</div><p>Another thing to notice is that many of the bug fixes that end up in the
LTS kernel have no good test coverage: they have been developed on
top-of-tree kernels, then it was decided that they look like stable
material and backported. However, the number of developers that actually
<em>test</em> the patches on the LTS kernels are quite small: we recently had a
case where important NAND bugs we found and fixed for mainline were
backported, but nobody noticed that some other infrastructure in the MTD
subsystem was missing in those old kernels; in result, it <em>looked</em> as if
the patches were better, but in fact they simply were broken and
untested.</p>
<p>Industrial device manufacturers often still stick to the old waterfall
development model: design, implement, test, ship, then never touch a
device again; this is especially true in regulated markets like medical,
automotive or machine control. If this mind set is combined with an LTS
based vendor frankenkernel, you get worst of all worlds and the
resulting kernel is old, badly tested and far away from anything that
gets community support.</p>
<p>If this strategy is used, it doesn't mean ANYTHING that it is called
"Long Term Stable".</p>
</div>
<div class="section" id="define-long-term">
<h3>Define "Long Term"</h3>
<p>Another pitfall is that industrial device manufacturers then conclude
they need something which is <em>even longer</em> stable: if you look at Greg's
table, you'll notice that what the IT industry calls longterm is
supported for 2-5 year. That's by far not longterm enough for embedded
industrial devices! If you build a tractor, it might be used for 25
years. If you build a medical device, it might be used for 10…15
years. Chip vendors of industrial devices often promise 10…15 years
availability of their chips, but in reality, you can still buy embedded
chips from the early 90ies.</p>
<p>So even if the argument is "we got this from our chip vendor and it is
based on an LTS kernel", you should be prepared to have 3…5 kernel
updates over the lifetime of the device. With a vendor kernel, you are
then absolutely dependent on the chip manufacturer's kernel teams and
his willingness to forward-port 3000 patches for a 10 year old chip! We
have seen more than once that chip vendor kernel teams simply don't do
that, because their software resources are limited and focussed on new
devices. It might even happen that they don't remember the exact reasons
for the patches any more…</p>
</div>
<div class="section" id="for-conservative-goals-be-progressive">
<h3>For Conservative Goals, Be Progressive!</h3>
<p>Our strategy here at Pengutronix is different when it comes to kernel
decisions: when we talk to a customer who wants to build a new
industrial device, we strongly suggest to start with a top-of-tree
mainline kernel; in many cases, it is even a totally "unstable" -rc
kernel. The newer, the better. You can imagine that this is often
surprising for our customers and leads to many discussions…</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1200x901" href="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_maintenance_workflow.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-08-28_what-kernel-to-use/2018-08-28_maintenance_workflow.thumb.f37a3dd45dad03eff489222573cee9c2.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>We observe that industrial customers who do full custom or module based
product development have a development cycle of about 1-2 years from the
first product idea to Start-of-Production (SoP). It doesn't matter at
all, that we are not on a LTS kernel during that time, as that kernel is
not what's used in the final product.</p>
<p>When starting with a top-of-tree mainline kernel, we have the advantage
that we get <em>all</em> the bugfixes, performance- and infrastructure patches
people have developed until now, on exactly the kernel they were
developed (which is also top-of-tree). We test those kernels on customer
hardware quickly, which makes sure that bugs and regressions turn up
during the time when developers actually <em>work</em> with the hardware. If
something is missing in the kernel, we can do the development on
top-of-tree as well, which makes it easy to get the patches into
mainline. Product specific patches are going through the normal kernel
quality cycle, and even our experienced kernel developers always get
<em>really</em> great feedback from the other community developers! While we
try hard to keep our patch stack small, BSP integration technologies
like <a class="reference external" href="https://www.ptxdist.org">PTXdist</a> or Yocto make it possible to
do the integration of all the feature patches on top of a mainline
kernel and iterate quickly. Testing is automated as far as possible
with the help of <a class="reference external" href="https://labgrid.readthedocs.io">labgrid</a>.</p>
<p>While the customer heads towards SoP, we mainline patches and support
all of the necessary hardware. The kernel our customers work with during
that time is often synchronized every few weeks and often contains -rc
kernels.</p>
<p>Once the product enters its more intensive production testing phase, we
of course look at what kernel we suggest for the final product. The
result might be a LTS kernel (for headless i.MX6 devices, we have several
products in the field which are patch free on vanilla LTS kernels from
upstream), a normal "stable" kernel or even a normal kernel release.</p>
<p>An important feature for this strategy is the ability to upgrade systems
in the field: that's why we developed <a class="reference external" href="https://rauc.io">RAUC</a>, the Robust Auto
Update Controller. Even after Start-of-Production and roll-out of the
first devices, it is possible to bring new kernels to the devices. Once
the "hot" product development phase is over, we often continue to bring
patches mainline during a maintenance project. In result, the customer
hardware might not be fully supported by a LTS kernel right from the
start, but once it is, we have a <em>really</em> low patch count!</p>
<p>In conclusion, our experience is that with this development strategy,
"having a device on a LTS kernel" is really possible for industrial
devices. However, it is necessary to understand that "longterm" doesn't
come automatically, but needs a certain amount of effort. Fortunately,
the community is there to help: once you are on a mainline strategy,
there are so many friendly community folks out there who really <em>care</em>
about mainline, and even do some of the work!</p>
<p>If you want to learn more about our mainline strategy, you should watch
my colleague Jan Lübbe's ELCE talk from 2016:</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/xviInQoN-74"></iframe>
</div>
</div>
</div>
<p>Some days ago, Greg Kroah-Hartmann wrote a great blogpost about <a class="reference external" href="http://kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/">Which Stable
Kernel One Should Use?</a>.
I fully agree with his position; however, I'd like to make
some additions for the industry device manufacturer use case and some
common pitfalls and misunderstandings we see in that area.</p>2018-08-28T08:00:00+01:00tag:www.pengutronix.de,2018-08-28:/2018-08-28-froscon.htmlPengutronix at FrOSCon 20182018-08-28T00:00:00+01:00Marie Mann<div class="section" id="pengutronix-at-froscon-2018">
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2019x1514" href="https://www.pengutronix.de/media/blog/2018/2018-08-28_froscon/2018-08-28-froscon-from-above.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-08-28_froscon/2018-08-28-froscon-from-above.thumb.6b5e7276e52b2dbf9ef734d233e8a836.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>This year, a team from Pengutronix attended <a class="reference external" href="https://www.froscon.de/">FrOSCon</a> in St. Augustin for the first time.
We took the opportunity to shake hands, talk about our latest developments
and meet hackers interested in working with embedded Linux.</p>
<p>To show some of our work, we brought a demo for updating embedded devices with <a class="reference external" href="https://rauc.io">RAUC</a> and hawkBIT
and a Video Demo based on a fully open-source graphics stack with Etnaviv, Weston and GStreamer,
cycling through four of <a class="reference external" href="https://www.blender.org/about/projects/">the Blender Project's Open Movies</a> in HD resolution.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1536" href="https://www.pengutronix.de/media/blog/2018/2018-08-28_froscon/2018-08-28-froscon-rauc-demo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-08-28_froscon/2018-08-28-froscon-rauc-demo.thumb.040d0ccb202a0ab0a81abd8c7a0c9c4f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>A Raspberry Pi in our RAUC demo downloading an update bundle.</p>
</figcaption>
</figure>
</div><p>Our hardware hacker had some fruitful discussions about electronic designs
and possible use-cases for tools like our <a class="reference external" href="https://www.pengutronix.de/de/2017-10-23-usb-sd-mux-automated-sd-card-juggler.html">USB-SD-Mux</a>,
that makes the annoying juggling of SD cards between development host and target hardware a remnant of the past.
When we started with that project, we would never have guessed that there was such a high demand for such a device,
but from the large number of interested questions we gather that this is a niche that needs to be filled.</p>
<p>We also recognize that testing embedded devices is becoming an increasingly important and visible subject in the community.
This motivates us to continue our efforts around this topic.</p>
<p>Besides that, our Penguin stickers and black pencils were popular as usual ;)</p>
<p>We'd like to thank FrOSCon Team for this great conference.</p>
</div>
<p>This year, a team from Pengutronix attended <a class="reference external" href="https://www.froscon.de/">FrOSCon</a> in St. Augustin for the first time.
We took the opportunity to shake hands, talk about our latest developments
and meet hackers interested in working with embedded Linux.</p>2018-08-28T00:00:00+01:00tag:www.pengutronix.de,2018-06-20:/2018-06-20-osadl_networkingday_afternoon.htmlOSADL Networking Day 2018, Afternoon Session2018-06-20T14:14:00+01:00Robert Schwebel<div class="section" id="osadl-networking-day-2018-afternoon-session">
<div class="section" id="afternoon-session">
<h3>Afternoon Session</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-13.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-13.thumb.9b6081a791096be6ce44be88d23f4b2a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The report for the afternoon session will be a bit shorter than my last
report, mainly because it is mainly about products and services of the
OSADL member companies.</p>
<p>Rüdiger Kügler (WIBU-SYSTEMS) talked about "Secure distribution and
storage of private keys for OPC UA". The question they care about is how
to ensure privacy and authentication in industrial scenarios. He
basically explained how public key infrastructures work.</p>
<p>Philipp Michel (Wind River) then talked about "Titanium Control - Secure
on-premise virtualization platform for critical infrastructure"; the
talk mainly explained "Industrie 4.0", cloud, fog and their related
products.</p>
<p>Steffen Schlette (PHOENIX CONTACT Software) talked about "PLCnext
strategy based on Linux RT". Until 2015, Win CE was their main operating
system for the PLCs; since then, they have moved to Linux RT and Debian.
The focus of the devices has changed from fixed-function to a versatile
platform, where apps can be installed and change functionality over the
time. While in the past 61131 languages were in focus, this has now
changed towards more languages, including standard IT ones like C/C++;
people can use standard IDEs and any kind of other open or closed source
software, including OPC UA mechanisms.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-16.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-16.thumb.25a41cb53824b703fcc52f2bdd46651b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>My colleague Enrico Jörns then talked about "The fearless way of
effective platform updates": he explained that customers often build
embedded products for pretty long lifetimes of 10...15 years. However,
as embedded systems today are computers, it might happen that at some
point in the future, security incidents happen and i.e devices might
turn into a part of a botnet. It turned out that the upstream versions
of software components are usually only maintained over max. 5 years, so
staying with one version of a software over 10...15 years is not a good
idea. Even within the supported time, backporting security fixes is not
easy (think of Spectre/Meltdown). In result, a good way of caring with
updating is a continuous maintenance strategy: after the initial feature
development phase (already based on mainline Linux) of a project is
over, a maintenance phase follows. During this time, support for the
device in the mainline kernel is improved, patches are ported, more
tests are written and automated.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-15.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-15.thumb.3de0b450bd7a8e1fb7350cf97da1f15d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>With this in place, it gets easier and easier over the time to
continuously test the device against upstream components. The more tests
and documentation are there, the easier it is to quickly test upcoming
versions without much manual interference. One should establish a
maintenance cycle (i.e. a year, or half a year) and during that time
revisit the components used, check for new versions and new security
incidents (the CVE database is your friend). As the software is
continuously updated and tested, it is basically always deployable, i.e.
by using the <a class="reference external" href="https://rauc.io">RAUC</a> field upgrade framework. Of course, it is
not necessary to deploy <em>any</em> new eversion - it is just <em>possible</em> to do
so and the processes are well defined and all involved people are used
to them. Automation techniques such as Jenkins and <a class="reference external" href="https://www.pengutronix.de/en/software/labgrid.html">labgrid</a> are helpful to
keep the effort low.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-14.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday-afternoon/osadlnwd2018-14.thumb.df9e40f3fa5cbe7099d6be691a214f44.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Joachim Dietrich (OSADL) talked about "The OSADL Linux add-on patch: Why
is it separate and what does it contain?". Maintaining the OSADL test
farm, it turned out that the "magic sysrequest key" is a helpful tool to
diagnose hanging realtime systems. The patch stack contains a patch that
makes it possible to send sysreq keys over the network, which is helpful
in cases where the local console is not reactive any more. Another patch
adds support for the OSADL diagnostics parport card. The most important
patch of the patch set adds special latency histograms to the kernel; it
adds more statistic data to the kernel's histogram functionality. While
there is a generic histogram feature in the kernel, they decided that it
is too difficult to port their needs to the upstream variant.</p>
</div>
<div class="section" id="afternoon-session-part-ii">
<h3>Afternoon Session, Part II</h3>
<p>After the coffee break, Armijn Hemel (Tjaldur Software Governance
Solutions) talked about the OSADL License Compliance Audit (LCA). The
reason why OSADL and Armijn do this is that license compliance cases
have hit the courts recently, so companies see an increased need to be
sure they play after the copyright rules correctly. The LCA starts with
a questionnaire for preparation, then a one day workshop on-site, with a
technician and a lawyer, who can be asked anything. Then the team tries
to rebuild the core components, following the rules provided by the
manufacturer.</p>
<p>Carsten Emde then added more insights into the license scanning topic by
talking about "The OSADL Scanbook". It turned out that some of the scan
tools do not easily install on modern distributions, so OSADL decided to
provide a pre-installed notebook with all the relevant software
installed.</p>
</div>
</div>
2018-06-20T14:14:00+01:00tag:www.pengutronix.de,2018-06-20:/2018-06-20-osadl_networkingday.htmlOSADL Networking Day 20182018-06-20T11:04:00+01:00Robert Schwebel<div class="section" id="osadl-networking-day-2018">
<div class="section" id="morning-session">
<h3>Morning Session</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-4.thumb.0ef8b1fd844753ff7b971f01ed8122e1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Today, Pengutronix engineers Jan Lübbe, Enrico Jörns and Robert Schwebel
joined the OSADL Networking Day in Heidelberg. Here is my report about
the morning session with the technical talks.</p>
<p>The morning session was introduced by OSADL chairman Dr. Carsten Emde:
This year's main topic is the industrial communication standard <cite>OPC UA</cite> and
<cite>TSN</cite> (Time-Sensitive Networking).
Compared to last year,
many more participants from OSADL member companies joined the session,
so the audience was expecting many interesting talks and discussions.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-5.thumb.fe3b09f51a528e8df42c09ced2432b9f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 220px;
"></figcaption>
</figure>
</div><p>The first talk by Stefan Bina (B&R Industrial Automation), "OPC - from
proprietary DCOM technology to a universal and versatile network
protocol of the future and example application" outlined some history of
the OPC protocol: starting in 1996, OPC was used for data access,
history, alarms and events. OPC UA is the new generation, released in
2009 and standardized by IEC in 2011. While the first variants were not
scalable, Windows-only and had no security and data modeling, the new
variant is an object oriented architecture, is independent of the
transport method, was designed with security in mind and can be
horizontally and vertically scaled.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-3.thumb.f757404cfa91adf6887d8abae7d2473d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The lower layers are based on TCP and HTTP, used by "services" such as
<cite>Read</cite>, <cite>Write</cite>, <cite>Browse</cite> etc. and an RPC mechanism. The data model contains
objects, methods (commands) and events. In terms of footprint, B&R
recently developed an IO bus coupler, "Edge Connect", based on a 50 MHz
FPGA processor with 800 kB ROM and 700 kB RAM, utilizing 50 variables in
10 ms, 5 parallel sessions and monitoring 300 events. One of the high
level ideas is to have a common abstraction for automation things, i.e.
robots, across the industry: the information model is supposed to
contain all the information automatically. While the new possibilities
can be easily used for new machines, there still is a huge base of old
machines already installed in the field. For these machines, the Axoom
Gate (<a class="reference external" href="https://axoom.com/de/">https://axoom.com/de/</a>) makes it possible to connect them to the
cloud. One of the recent developments is to extend OPC UA to the lower
layers of the automation stack: in IO communication, devices need a
deterministic communication mechanism, mostly in a cyclic way. This is
where TSN (Time-Sensitive Networking) comes into play. However, this is
an area of active development and will be discussed in more detail in
the later sessions. Bina concluded that OPC UA has the potential to
unify all the different standards of the automation pyramid into one
technology stack.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-1.thumb.1a266948d025a4e5f98b7b8758a7aa9a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Julius Pfrommer (Fraunhofer IOSB) then talked about "Current status of
the open62541 based Open Source implementation of OPC UA Pub/Sub",
shading a light on the topic from a bottom-up view. The "normal" OPC UA
protocol is request/respond-based and defines 37 standard services used
to interact with the information model, i.e. explore the network, call
methods etc. He showed a demo of a simulated robot and how the
corresponding information model can be explored with the "Unified
Automation UaExpert" GUI tool (written in Qt). Changing the values in
the tool makes the robot move. Pfrommer then explained the <cite>Subscriptions</cite>
and <cite>MonitoredItems</cite> mechanisms: MonitoredItems sample attribute values or
listen to events emitted by objects, while Subscriptions collect changes
in those MonitoredItems and send them out. While one should never write
his own crypto, database and network parsing code oneself, the
<a class="reference external" href="https://github.com/open62541/open62541">open62541</a>
project has broken all those rules, because someone has to
provide the basic infrastructure. The project provides a platform-independent
Open Source OPC UA stack, licensed under the MPLv2, written
in C99. The project started in 2013 and has about 5.000 commits now. The
footprint of a minimal server is about 100 kB; a single core machine is
able to handle about 16.000 requests per second.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="775x776" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-6.thumb.c78c4027ae593801c2fdbaee003eab8b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The official conformance testing tools are used by members of the OPC
Foundation, and the codebase passes all conformance tests for the
supported features. In addition, the team uses many state of the art
quality tools like Travis, whitebox fuzzing etc. There is extensive
documentation available. Some time ago it was identified that in
addition to the built-in push notifications, a publish/subscribe pattern
is required; this makes it possible to have instances that are loosely
coupled, just sending publications to a common bus and make it possible
for receivers to subscribe to the information they are interested in.
Without pub/sub, servers need to send out notifications for any client
that is connected; this is resource-hungry, especially if encryption
comes into play. The pub/sub mechanism was developed during the last
year and has recently be merged to the codebase. A demonstrator has been
built in an OSADL organized consortium, using hardware from four
different vendors. A second phase of the project is currently being
planned.</p>
<p>Yours truly used the time of the talk to quickly try if open62541 cross
compiles for embedded systems; this has been a bigger issues for other
automation frameworks like ROS in the past (who invented their own make
system, not taking care of cross compiling at all); the exercise turned
out to be pretty easy, as the project is using CMake. An experimental
DistroKit branch can be found at
<a class="reference external" href="https://git.pengutronix.de/cgit/DistroKit/log/?h=rsc/topic/open62541">https://git.pengutronix.de/cgit/DistroKit/log/?h=rsc/topic/open62541</a> .</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-7.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-7.thumb.d1529a47cc695d7055f177603ddf93e3.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>After the coffee break, Pekka Varis (Tesas Instruments) reported about
"Realtime performance of Ethernet driver and Linux networking stack on
Sitara AM572x processors". IEEE802.1Q and TSN enables single digit
microsecond level jitter for realtime traffic, but we have the situation
that most upper layers of today's network concepts are not prepared for
this usecase; in result, RTOSes are still used. The device he analyzed
is an AM5728, containing a switch; his team measured the times packets
need for passing the hardware and software layers, from wire to the
application, using the IEEE1588 mechanics built into the device. In most
cases, packages need 20...35 µs from the userspace socket based
application to MII; while this is fast, it isn't enough for industrial
control protocols like ProfiNet. He discussed techniques currently
discussed in the Linux community, i.e. the <cite>Credit Based Shaper</cite> (CBS), or newer
capabilities like 802.1Qbv; the latter one seems to show good results
for jitter to the wire. His conclusion is that, with a time aware shaper
(Qbv), there is a need for making sure the packet is available on the
wire when the timeslot opens; typical applications need a minimized
latency to the wire. While 200 µs are possible today, it will be
necessary to be 1-2 orders or magnitude faster in the future.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-8.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-8.thumb.bb03ba731a90e58474b81e3bc47d9ff5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Siddharth Ravikumar (Kalycito Infotech) talked about "What is TSN and
overview of industrial automation control system traffic types in a TSN
network". While time-sensitive mechanisms in standard Ethernet have a
longer history, originating from audio video and automotive scenarios,
they can provide fieldbus level determinism in packet delivery and
timing. TSN adds time awareness to the Ethernet stack: recently
discussed topics care about basic switching, support for streams,
support for synchronisation, time triggering and reliable communication,
while allowing normal communication on the same network. He gave an
overview about all of the currently available and discussed standards,
which are in fact quite many. The most important one is probably
802.1as, the current variant for precise time synchronisation. The
"time aware shaper" technique makes it possible to define several queues
for network packets, attaching priorities and an algorithm that controls
the "gate" when a queue opens to the wire. Taking care of one device
alone isn't enough: all those schedules need to be distributed in the
network with <a class="reference external" href="https://tools.ietf.org/html/rfc5539">NETCONF over TLS (RFC5539)</a>. Ravikumar then gave an overview
about the different traffic types that happen in industrial setups. He
then looked at the platforms they are currently caring: i210, Cyclone V
SoC, Zynq, AD fido5000 REM switch (can be attached to the memory bus of
an application processor) and TI Sitara PRU. Finally, the hope is that
once the device vendors have all those standard techniques ported to
their devices, it will be possible to have a much better
interoperability than what we ever had in industrial communication. The
next step is to perform intensive performance measurements.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-9.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-9.thumb.f6251c3a9af031bf66159c5c1bb81452.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Jan Lübbe (Pengutronix) talked about "State of TSN in mainline Linux".
His team provides mainline kernel based Linux systems to customers, so
he evaluated which TSN techniques are already in the mainline kernel,
which are work in progress and which are still needed in the future.
There have been several previous projects caring about TSN topics, such
as OpenAVB, Henrik Austad's AVB experiments and userspace based (mostly
closed) stacks: the problem with these issues is that they are often
very device- and vendor-specific, single application and generally
difficult to use for best-effort traffic; not what we expect from a high
quality Linux stack. For in-kernel mechanisms, <cite>tc</cite> provides a
configuration interface for traffic shaping and scheduling, based on
queueing disciplines (qdisc) which can be offloaded to hardware. On the
sending side, precise transmit times are important in many usecases; one
example is sending packets in predefined time windows. 802.1AS (PTP)
support has a longer history in the kernel, many drivers have support to
make use of hardware timestamping and offset measuring. On the userspace
side, this is supported by linuxptp. The next topic is 802.1Qav (Credit
Based Shaper), which was developed by Intel and went into the mainline
kernel in 4.15, and is implemented as a tc qdisc. It makes it possible
to make sure that bandwidth is not overloaded. Support for i210 is
already mainline as well, while for other hardware such as TI CPSW there
are already patches on the mailing list. Time Based Packet Transmission
is currently under review on the mailing lists: the mechanism queues and
sorts the packages and makes sure they are sent out with µs accuracy
once their TXTIME is reached. The patch series is at v3, but it seems as
if the current userspace interface is to specific, so the design will
probably be changed based on the review. For the receive side, the
situation is completely different: we want to have low latency for
critical traffic, while keeping the possibility to have any other
traffic in parallel.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-10.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-10.thumb.5bd3795be1f09d738a9384bca05f8c36.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The XDP (eXpress Data Path) mechanism makes it
possible to run BPF programs quickly and sorting incoming packages even
before SKBs are allocated; it might be an alternative to previously used
userspace network stacks. With XDP, a packet can bypass most of the
Linux network stack on its way from hardware to the application. Patches
are in v4.18-rc1, but the userspace interface is still discussed and
might disappear again before the final 4.18 release. Zero-copy mode is
also under discussion. There are also ideas around to separate one CPU
core for busypoll, so in case you can effort to lose a CPU, all the
interrupt latency should be gone. Lübbe then gave an overview about
further topics not yet addressed in the kernel. 802.1Qcc (Improved
Stream Reservation) will be interesting to configure the network, but
there is no open source implementation available right now. Another
interesting area is switchdev: Linux gains more and more support to
control switches, but nobody has worked on TSN issues there. The talk
concluded with a hint to the audience to contribute, try things out and
give feedback.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-11.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-11.thumb.61d6545e56e426fd246ac9cfd37e270b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>The final slot before lunch by Siddharth Ravikumar (Kalycito) was about
"TSN and OPC UA under Linux - how are they connected?". The current goal
of the group is to connect two Linux systems using OPC UA and TSN,
without any switches (those will be taken care of later) and put certain
test loads onto the communication. The test setup shall run in 24×7×365
operation. The first testcase with two systems connects an external
oscilloscope to outputs of both systems, to have the time stamping
independent of the devices-under-test and with about 20 ns accuracy.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-12.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-20_osadl-networkingday/osadlnwd2018-12.thumb.6c004a51eedfd39a45b276f2b55ee88f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Measurements have shown that ptp reaches +-100 ns accuracy in most
cases, but there are some longer latencies: an 8 h test shows a worst
case of about 1 µs. The end-to-end test with an DIO line shows a jitter
of ±20 µs between the flanks of the two systems; however, tests show
that latencies on the same system are in the same range. The aim is to
first stabilize on the ±20 µs, then try to improve to about ±1 µs.</p>
</div>
</div>
2018-06-20T11:04:00+01:00tag:www.pengutronix.de,2018-06-08:/2018-06-08-techweek_imx_mips.htmlPengutronix TechWeek 2018: Cortex-M Coprocessor and MIPS2018-06-08T11:17:00+01:00Oleksij Rempel<div class="section" id="pengutronix-techweek-2018-cortex-m-coprocessor-and-mips">
<div class="section" id="running-linux-on-m4-coprocessor-on-i-mx7">
<h3>Running Linux on M4 Coprocessor on i.MX7</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1762x2048" href="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_imx7.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_imx7.thumb.c3aa030e469cf80b8c797a0e8bf07344.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>Several i.MX SoC versions, for example i.MX7D, i.MX6SX and the i.MX8
derivates are asymmetric multiprocessing (AMP) systems: They have at
least one ARM Cortex A core and at least one ARM Cortex M core.</p>
<p>Most people run a small microcontroller operating system on it; however,
there are usecases that make it interesting to run uCLinux instead:
Linux has sophisticated drivers even for the more complex hardware units
(think of ethernet and TSN, or digital audio cores), and technology is
complex enough that we don't want to duplicate all bugs and challenges
in different operating systems. Some years ago, Pengutronix brought
Cortex-M support into the mainline kernel, but so far there are not many
single-chip Cortex-M devices with enough RAM to make it useful. Modern
AMP systems might change this.</p>
<p>Last year, at TechWeek 2017, I wrote an <cite>imx-remoteproc</cite> driver to allow
starting some code on the Cortex M system as a proof of concept. To make
it more interesting, thanks to effort of Uwe Kleine-König, we were able
to run a second Linux image on the Cortex-M4 as well. However, the code
was quite hacky; basically as there was no sane concept about sharing
and distributing ressources like clocks and pinmux settings. So we went
back to the blackboard and brainstormed about possible mechanisms. It
turned out that a good design could work in a way that a 'primary' CPU
takes care about all the clock and pinmux handling, while a 'secondary'
CPU talks to it via some messaging API in order to claim clocks and
pins.</p>
<p>My challenge for the current TechWeek was to prepare basic communication
between two Linux instances. i.MX7D is providing a Messaging Unit (MU)
that can be used as a doorbell with shared memory for huge messages, or
as a pipe for 4 bytes which can be transferred over the MU HW directly.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1848x1001" href="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_techweek_imx_mips_en.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_techweek_imx_mips_en.thumb.72cee4155ece24dff1815de25d9684a9.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>I implemented a mailbox driver based on the kernel's mailbox framework
for i.MX MU (<a class="reference external" href="https://www.spinics.net/lists/arm-kernel/msg656955.html">https://www.spinics.net/lists/arm-kernel/msg656955.html</a>)
and used the same driver on both sides of the SoC. The mailbox-test
driver was used on top of imx-mailbox driver to send a message over
shared memory and MU doorbell.</p>
<p>In the screenshot on the left, Linux is running on the Cortex-A7 of an
i.MX7D on the left side and a second linux instance is started with the
help of the imx-remoteproc driver on the Cortex-M4 of the same i.MX7D
SoC on the right sight. In this example, the message was transfered from
the A7 to the M4.</p>
<p>The actual interface for pinmuxing and clock needs to be written, but as
always, the idea of TechWeek projects is to have an incubator to
demonstrate new technologies. Hopefully, we'll find a usecase in one of
our next customer projects.</p>
</div>
<div class="section" id="mips">
<h3>MIPS</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1365" href="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_mips.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_mips.thumb.72726853e981340f58669a1da02d0b9c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another target of last TechWeek was my personal hobby project – Freifunk.
Most of Freifunk hardware is usually based on some variant of Qualcomm Atheros
Wireless SoCs running LEDE/<a class="reference external" href="https://openwrt.org/">OpenWRT</a> modification.
Most hardware support for this SoCs is not upstream which makes long term
maintenance and kernel updates difficult.
One of the reasons why many drivers and patches are still not in kernel
mainline is the lack of a developer friendly environment.
For example there is no unified boot loader combining the following futures:</p>
<ul class="simple">
<li>maintained upstream, with working support of Qualcomm Atheros WiSoCs</li>
<li>support of latest MIPS UHI boot protocol</li>
<li>working with kernel images just produced by kernel vanilla source three without additional
image preparation (for example converting to uImage).</li>
</ul>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="927x1053" href="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_mips_barebox_boot.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-08_techweek-imx-mips/2018-06-08_mips_barebox_boot.thumb.1ee489541abe56f0255ca847e753b14e.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>While barebox was already ported to different Qualcomm Atheros WiSoCs and works
as first stage boot loader, we still missed proper MIPS Kernel boot support.
In the last days of the TechWeek, I prepared a minimalistic ELF parser with MIPS
ELF boot handler which was accepted mainline just today (2018-06-08)</p>
<p>As a result of this work, we prepared a DPTechnics DPT-Board based on Atheros
AR9331 WiSoC which should from now on be used as first ever MIPS based SoC
tested within <a class="reference external" href="https://kernelci.org/">kernelci.org</a>.</p>
</div>
</div>
2018-06-08T11:17:00+01:00tag:www.pengutronix.de,2018-06-05:/2018-06-05-techweek.htmlPengutronix TechWeek 2018: NIR for Etnaviv2018-06-05T00:00:00+01:00Marie MannPhilipp Zabel<div class="section" id="pengutronix-techweek-2018-nir-for-etnaviv">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2048x1365" href="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_team.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_team.thumb.ba9d0ee79fea9f4893fdff6bd79b9a10.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Once in a year, mostly during springtime, no phone call is answered at
Pengutronix, no customer Mail receives a reply, no BSP is built and no coffee
machine gargles. But, no fear, this is not the end! It is just the time for
something new! New ideas, focused development on new world domination plans and
time to think outside the box. Yes, it's again the time for the Pengutronix
TechWeek!</p>
<p>As every year, we hid in a green and isolated place with acceptable
bandwidth and good catering. The perfect mixture for focused hacking,
starting new projects and discussing the big picture.</p>
<div><div class="clearfix"></div></div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3456x4608" href="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_richtfunk.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_richtfunk.thumb.2d0f261c8aad8fdca17a530f3f281048.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Thanks to <a class="reference external" href="https://stratum0.org/blog/posts/2018/06/01/freifunk-event-wlan/">Freifunk Braunschweig</a>,
we could set up our own WiFi infrastructure. Besides that we enjoyed
ourselves at a trip to Wisentgehege Springe, a local nature park, and on
a pgp-keysigning party as well as on a BBQ.</p>
<p>But back to topic:
On Friday morning, we had some short talks to share each team's results among
our colleagues.
In this and some following blog posts, we like to summarize these here as well.</p>
<p>Let's start with some news from our graphics team: During TechWeek 2017,
Philipp Zabel and Michael Tretter had taken the first steps towards
extending the etnaviv driver in Mesa with NIR compiler support. NIR is
a compiler intermediate representation that is well suited for
optimizing code transformations and is already used by many other Mesa
drivers. Supporting NIR allows to share common optimizations with other
drivers and facilitates better register allocation strategies.</p>
<p>Overall this will lead to faster shader code that runs in less
instructions and uses fewer registers. Furthermore, using the shared
NIR compiler layer will allow to work on common support for OpenCL and
SPIR-V in the future.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_gstreamer.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-06-05_techweek/2018-06-05_gstreamer.thumb.10198d56a9d675fc445cdf2c8cf54ae0.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Philipp and Michael were able to continue their work compiling NIR
shaders from the GLSL compiler to Vivante machine code. The screenshot
on the right shows one of the glmark2 programs, exposing some visual
artefacts resulting from a still-incomplete NIR support; the work
consisted of analyzing those artefacts, finding and finally fixing the
reasons in the code.</p>
<p>While the code is far from feature complete, the current state
looked promising enough that a first patch series was cleaned up and
sent to the <a class="reference external" href="https://lists.freedesktop.org/archives/mesa-dev/2018-June/196793.html">Mesa-developer ML</a>. Hopefully people out in the community will start
experimenting with the new possibilities, finding further bugs, adding
features and extending the NIR support in Etnaviv.</p>
<p>For a TechWeek project, the challenge and fun of it was enough
motivation. Thinking of future use, Etnaviv has meanwhile reached a
maturity status that already enabled its use in many of our industrial
customer projects, even in critical markets such as medical, automotive
and aerospace. OpenCL on a full blown open source graphics stack will
hopefully add interesting additional possibilities in the near future.</p>
</div>
<p>Once in a year, mostly during springtime, no phone call is answered at
Pengutronix, no customer Mail receives a reply, no BSP is built and no coffee
machine gargles. But, no fear, this is not the end! It is just the time for
something new! New ideas, focused development on new world domination plans and
time to think outside the box. Yes, it's again the time for the Pengutronix
TechWeek!</p>2018-06-05T00:00:00+01:00tag:www.pengutronix.de,2018-05-18:/2018-05-18-ripe76.htmlbbu's Diary: RIPE76 -Marseille2018-05-18T18:00:00+01:00Bjørn Bürger<div class="section" id="bbu-s-diary-ripe76-marseille">
<p>The first RIPE Meeting in 2018 took place at Palais du Pharo in Marseille, France from 14 to 18 May 2018.
Here's my report :-)</p>
<div class="section" id="france-home-of-air-traffic-controller-strikes-and-unstable-weather">
<h3>France - Home of air traffic controller strikes and unstable weather</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1000x695" href="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_pharo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_pharo.thumb.dcaa1d7246ce54ed167a652d8a2d8477.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Unfortunately, unlike for ripe72, I couldn't afford the time to <a class="reference external" href="https://www.penguin.de/blog/bbu/2016/0612_ripe72">ride my bike to the meeting</a> (See footnote, if this link seems to be broken for you).
But, foreseeing the strike of the french air traffic controllers, I arrived early enough to have two wonderful and sunny days
in Marseille, just before the bad weather and airport-chaos kicked in. Other attendees weren't so lucky, so there
was a steady stream of latecomers in the following days. In the end, this RIPE Meeting had more than 700 attendees at Palais Du Pharo
and almost 200 where newcomers. Amazing.</p>
<p>As is turns out, there's more to the 'Palais du Pharo', than immediately meets the eye: There's a full blown conference center
hidden underground and on one side, large windows provide an awesome view to Vieux Port, the historic port of Marseille. A notable
addition was a new childcare area at the venue, similar to those at other hacker- and networking community meetings.</p>
</div>
<div class="section" id="monday">
<h3>Monday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_monday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_monday.thumb.26247b80d0bc98c0b4b744c91424226c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The first day started with wind and rain. What's the best thing to do in such a situation? Yes, you are absolutely right: A nice welcome
reception at one of the sponsored coffee-bars and a long chat with other community members :-) Then there where several tutorials on
IPv6 security & segment-routing, network programming and event-driven network orchestration. It seems, that segment routing has the
potential to pull a bigger community towards IPv6 adoption, especially in datacenters and IoT, but there's also a lot of complexity involved.
If you are working in this field and haven't done v6 yet: Now is the time to start with it. There's a new and exciting world ahead.</p>
<p>Later on, Artyon Gavrichenkov of Qrator Labs provided some insights into new types of amplification attacks, like the 1.7 Tb/s attack recently seen
with insecure memcached installations. But especially the growing fleet of embedded devices are of concern. Large parts of the embedded devices
industry seems to be stuck in the 90s, where IPv4, lazy security and closed source software where dominating. But times have changed. Any modern
embedded device might end up in the next big DDoS farm and we'll need means to control and mitigate the resulting risks. But it's not only the
devices, as Erik Bais from A2B pointed out; people need to think about network hygiene and thread mitigation on the network level.</p>
</div>
<div class="section" id="tuesday-wednesday">
<h3>Tuesday & Wednesday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_tuesday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_tuesday.thumb.e1f86f20a0b4fab8e3daa7dd2f98eead.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Tuesday started with several network-protocol centric talks, so I put my "networking cap" on and learned more about monitoring and security of
the BGP ecosystem, enjoyed Geoff Huston’s talks about some of his latest experiments with TCP & the scalability of BBR, then Louis Plissonneau
from Facebook talked about passive monitoring, Total TCP Loss detection, etc. Richard Sheehan, Facebook, talked about commodity-based networks
and the challenges to run 1280 40G-Ports on Linux based hardware in a single 42" rack, just for fun and curiosity. Life seems to be easy, if
you consider a 500k$ rack of networking hardware as a cheap playground and if network security is not of concern, because you pushed to the edges
of your network. But, actually, we are working at the other end of the line and although we might learn a lot from Facebook's insights, other
topics are more relevant for us. So I followed Aaron Glenns talk about the packet processing language P4 and Jacky Hammers overview about
RFC 6980 implementations on different operating systems.</p>
<p>The meeting programme on Wednesday was more policy-oriented. Following the discussions around organising a post-IPv4-depletion world, it became
clear that we are facing a hard time if people don't start acting quickly. It is horrifying to see, what type of "solutions" are introduced,
just to keep IPv4 a little longer alive. But the pool of IP-Addresses has been empty for several years now and we start to see the
negative effects all around. While several VPN- and communication protocols stopped working behind the growing number of CGN- and protocol translators,
more and more clients are pooled behind scarce IP-resources (sometimes 100+ clients per global v4 address). IPv4-Brokerage starts to look
like a new field for the mafia of the 21st century, even large companies start to hijack "uninteresting" IPv4-Address space,
mapping all their overlapping RFC1918 networks to something different and the price for IPv4 address space is rising. "Oh, that space is
reserved and unroutable on most devices? We don't care, our devices appear to work with it", "Oh, that IPv4 space belongs to someone else? We don't know them, so we don't care".
Well, you might care, when your networks CGN cascade <a class="reference external" href="https://www.youtube.com/watch?v=_y36fG2Oba0">starts to collapse</a>.</p>
<p>What we are watching here, is nothing else than the death of the internet. A whole industry is acting crazy. Like a drowning person, committed to rather die than leave some valued baggage behind,
the IP-networks of today will rather accept closed, mostly disconnected, AOL-like network islands than moving forward and implementing IPv6. Oh, we just move to the
cloud … yeah. This will definitely solve all our problems. Want some blockchain on top of it, dude?</p>
<p>But what does that mean for embedded computing? Won't we need even more address space for all of those shiny IoT devices?
YES. Move now or you are doomed. If anything is crystal clear, then it is the insight, that there is no viable alternative to IPv6 adoption. We are running out of time.</p>
</div>
<div class="section" id="thursday">
<h3>Thursday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_thursday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_thursday.thumb.4914fc3fab172c2fce3cc5753d73e5d6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The talks on Thursday shed some more light on the IPv4 pool size distribution in Europe, the need for some countries to use CGN to keep their users online and
a call for action regarding more research on internet infrastructure related topics. I skipped some talks about regulatory topics in favor of some more technical
conversations at the coffee bar, but topics like the new European NIS Directive, e-evidence and a "cybersecurity act" proposal are definitely worth reviewing.</p>
<p>In the Open Source WG, cz.nic presented their newest hardware project, the modular <a class="reference external" href="https://mox.turris.cz/en/overview/">Turris Mox</a> SOHO router. From an
operational point of view, the talk on recent Kea developments was quite interesting. With added high-availability support, Kea might soon be ready to
replace the good old isc-dhcpd. The last talk was about the applicability of blockchain to secure IP addresses allocations and delegations. Well, I'll pass.</p>
<p>Unfortunately, the first regular meeting of the new founded IoT WG was in parallel to the IPv6 WG Track, but luckily there's
<a class="reference external" href="https://ripe76.ripe.net/programme/meeting-plan/iot-wg/">all slides and recordings</a> available on the ripe76 website. In the IPv6 WG, Geoff Huston started with another interesting view
on IPv6 deployment measurements, asking: "What Drives Deployment of IPv6?", followed by several interesting topics, like Helge Holz with "Painting by Numbers" (I'd like the blue block
of addresses, please) and Jordi Palet about distributing unique /64 prefixes instead of single addresses from a shared prefix. Interesting stuff, done with standard ra-infrastructure.</p>
<p>From my point of view, Jen Linkovas ideas about <a class="reference external" href="https://ripe76.ripe.net/presentations/19-ConditionalRAs.pdf">Enterprise IPv6 Multihoming using PA</a> were … debatable.
The presented concept is interesting and surely works for small eyeball networks with only short living udp/tcp connections (e.g. a small Wifi HotSpot Infrastructure).
However, for classic small- and medium-sized business, this isn't a presentable multihoming solution. Nowadays, even the smallest barbershop has permanent infrastructure
like video cameras, cashdesk systems, music-servers, NAS Boxes, VoIP Telephony, some even have external facing webservers on their NAS. Dynamic DNS usually saves the
day, but with current implementations, renumbering everything from your printer to your coffee machine is a real pain. Currently, there is a wide gap between theory and practice.
For medium sized businesses, it is worse. You can expect to have critical infrastructure with lots of ACLs and long running connections, like terminal server-sessions, rsync,
SSH, distributed network filesystems, Backup, Databases, Web-, Printing- and Application-Servers, NFS, Virtualisation Servers, […]. Yes, you could use ULA, NAT 66,
Local Link Addressing, but why would anyone in their right mind want to do that in a IPv6 world, where end-to-end communication and stable global addressing is possible again?
As long as shim6 or IPv6 mobility are not widely deployed, even small enterprise networks with need for multihoming will (actually should) continue to use IPv6 PI for
enterprise multihoming. I might add: There is another area, where Jens idea actually fits nicely: Mobile WiFi routers and tethering setups with multiple uplinks.</p>
</div>
<div class="section" id="friday">
<h3>Friday</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="640x640" href="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_friday.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-05-18_ripe76/2018-05-18_ripe76_friday.thumb.cda220ec2bc353f525aec66915be4593.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Due to flight plan changes, I missed the plenaries on Friday, but videos of all talks are <a class="reference external" href="https://ripe76.ripe.net/programme/meeting-plan/plenary/#fri1">available on the ripe76 website</a>.
As for the last years, the RIPE76 meeting was a nice opportunity to meet with colleagues and friends from a variety of very different networks, discussing best current operational
practice, as well as the findings of the academic community. See you <a class="reference external" href="https://ripe77.ripe.net/">in Amsterdam</a>!</p>
</div>
<div class="section" id="footnote">
<h3>Footnote</h3>
<p>If you clicked on the <a class="reference external" href="https://www.penguin.de/blog/bbu/2016/0612_ripe72">first link in this article</a> and it seemed to be broken, then your internet connection is missing IPv6 support. Please go to your ISP and ask for IPv6.</p>
</div>
</div>
<p>The first RIPE Meeting in 2018 took place at Palais du Pharo in Marseille, France from 14 to 18 May 2018.
Here's my report :-)</p>2018-05-18T18:00:00+01:00tag:www.pengutronix.de,2018-04-09:/2018-04-09-RAUC-0.4.htmlRAUC v0.4 Released2018-04-09T15:07:00+01:00Enrico Jörns<div class="section" id="rauc-v0-4-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="http://rauc.io/pages/download.html">v0.4</a> release of RAUC</p>
</div>
</div>
<p>The RAUC team is proud to announce that we've just released RAUC v0.4!</p>
<p>Beside a few fixes, this version provides some useful new features such as
atomic bootloader updates for eMMC, a central storage location for the RAUC
system status information and experimental support for using RAUC with the
casync chunking tool for delta updates over the network.</p>
<div class="section" id="enhancements">
<h3>Enhancements</h3>
<ul class="simple">
<li>Add <tt class="docutils literal"><span class="pre">barebox-statename</span></tt> key to <tt class="docutils literal">[system]</tt> section of system.conf in order
to allow using non-default names for barebox state</li>
<li>Support atomic bootloader updates for eMMCs.
The newly introduced slot type <tt class="docutils literal"><span class="pre">boot-emmc</span></tt> will tell RAUC to handle
bootloader updates on eMMC by using the <tt class="docutils literal"><span class="pre">mmcblkXboot0/-boot1</span></tt> partitions
and the EXT_CSD registers for alternating updates.</li>
<li>Support writing <tt class="docutils literal">*.vfat</tt> images to vfat slots</li>
<li>Add basic support for streaming bundles using casync tool.
Using the casync tool allows streaming bundle updates chunk-wise over
http/https/sftp etc.
By using the source slot as a seed for the reproducible casync chunking
algorithm, the actual chunks to download get reduced to only those that
differ from the original system.<ul>
<li>Add <tt class="docutils literal">rauc convert</tt> command to convert conventional bundles to casync
bundle and chunk store</li>
<li>Extend update handler to handle <tt class="docutils literal">.caibx</tt> and <tt class="docutils literal">.caidx</tt> suffix image types in
bundle</li>
</ul>
</li>
<li>Added <tt class="docutils literal"><span class="pre">--detailed</span></tt> argument to <tt class="docutils literal">rauc status</tt> to obtain newly added slot
status information</li>
<li>Added D-Bus Methods <tt class="docutils literal">GetSlotStatus</tt> to obtain collected status of all slots</li>
<li>Extended information stored in slot status files (installed bundle info,
installation and activation timestamps and counters)</li>
<li>Optionally use a central status file located in a storage location not
touched during RAUC updates instead of per-slot files (enabled by setting
<tt class="docutils literal">statusfile</tt> key in <tt class="docutils literal">[system]</tt> section of <tt class="docutils literal">system.conf</tt>).</li>
<li>Add <tt class="docutils literal"><span class="pre">write-slot</span></tt> command to write images directly to defined slots (for use
during development)</li>
</ul>
</div>
<div class="section" id="bug-fixes">
<h3>Bug fixes</h3>
<ul class="simple">
<li>Fix documentation out-of-tree builds</li>
<li>Fixed packaging for dbus wrapper script rauc-service.sh</li>
<li>Some double-free and error handling fixes</li>
</ul>
</div>
<div class="section" id="testing">
<h3>Testing</h3>
<ul class="simple">
<li>Create uncrustify report during Travis run</li>
</ul>
</div>
<div class="section" id="code">
<h3>Code</h3>
<ul class="simple">
<li>Unified hash table iteration and variable usage</li>
<li>Add uncrustify code style configuration checker script to gain consistent
coding style. Committed changes revealed by initial run.</li>
</ul>
</div>
<div class="section" id="documentation">
<h3>Documentation</h3>
<ul class="simple">
<li>Updated and extended D-Bus interface documentation</li>
<li>Added documentation for newly added features (casync, central slot status,
etc.)</li>
<li>Fixed and extended Yocto (meta-rauc) integration documentation</li>
<li>Add link to IRC/Matrix channel</li>
<li>Some minor spelling errors fixed</li>
</ul>
</div>
</div>
<p>The RAUC team is proud to announce that we've just released RAUC v0.4!</p>2018-04-09T15:07:00+01:00tag:www.pengutronix.de,2018-03-06:/2018-03-06-clt-2018.htmlChemnitzer Linux Tage 20182018-03-06T00:00:00+01:00Marie Mann<div class="section" id="chemnitzer-linux-tage-2018">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="197x70" href="https://www.pengutronix.de/media/blog/2018/2018-03-06_clt-2018/logo_clt2018.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-03-06_clt-2018/logo_clt2018.thumb.621214aabb475fe01de180db38290102.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Auch dieses Jahr werden wir mit dem Team wieder zu den Chemnitzer Linux-Tagen reisen.
In dem Business Forum werden wir, wie auch in den letzten Jahren, auf einem Stand die neusten Demos präsentieren.
Darunter wird auch die Demonstration der Open Source Grafik-Treiber (Etnaviv) auf dem neuen i.MX8M, eine 4-Video-Demonstration auf i.MX6
und unser bereits bekannter RAUC-Updating-Demonstrator sein.</p>
<p>Selbstverständlich werden wir auch einige der beliebten Bleistifte und Pinguinaufkleber im Gepäck haben. ;-)</p>
<p>Besonders freuen wir uns, dass fünf unserer Pinguine an der <a class="reference external" href="https://chemnitzer.linux-tage.de/2018/de/programm/vortraege">Vortragsgestaltung</a> mit spannenden Themen beteiligt sind.</p>
<table border="1" class="docutils">
<colgroup>
<col width="9%"/>
<col width="25%"/>
<col width="22%"/>
<col width="17%"/>
<col width="27%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="5">Samstag, 10. März 2018:</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Zeit</td>
<td>Raum V1</td>
<td>Raum V2</td>
<td>Raum V5</td>
<td>Raum V6</td>
</tr>
<tr><td>09:00</td>
<td> </td>
<td> </td>
<td> </td>
<td>P. Zabel:
Virtual Reality
mit Freier Software</td>
</tr>
<tr><td>10:00</td>
<td> </td>
<td> </td>
<td>C. Fiege:
Aufbau eines
Sensornetzes
mit LoRa-WAN</td>
<td> </td>
</tr>
<tr><td>11:00</td>
<td> </td>
<td> </td>
<td> </td>
<td>M. Tretter:
Synchrone Audio- und
Videowiedergabe auf
mehreren Geräten</td>
</tr>
<tr><td colspan="5">...</td>
</tr>
<tr><td>17:00</td>
<td> </td>
<td>B. Lässig:
OpenSSH -
für Anfänger und
Fortgeschrittene</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<table border="1" class="docutils">
<colgroup>
<col width="9%"/>
<col width="25%"/>
<col width="22%"/>
<col width="17%"/>
<col width="27%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head" colspan="5">Sonntag, 11. März 2018:</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Zeit</td>
<td>Raum V1</td>
<td>Raum V2</td>
<td>Raum V5</td>
<td>Raum V6</td>
</tr>
<tr><td>13:00</td>
<td>E. Jörns:
Beyond the Basics:
Update
eingebetteter
Systeme</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p>Wir freuen uns, Euch auf den Chemnitzer Linux-Tagen zu treffen.</p>
</div>
<p>Auch dieses Jahr werden wir mit dem Team wieder zu den Chemnitzer Linux-Tagen reisen.
In dem Business Forum werden wir, wie auch in den letzten Jahren, auf einem Stand die neusten Demos präsentieren.
Darunter wird auch die Demonstration der Open Source Grafik-Treiber (Etnaviv) auf dem neuen i.MX8M, eine 4-Video-Demonstration auf i.MX6
und unser bereits bekannter RAUC-Updating-Demonstrator sein.</p>2018-03-06T00:00:00+01:00tag:www.pengutronix.de,2018-02-23:/2018-02-23-embedded-world-2018.htmlEmbedded World 2018: Etnaviv on MX8M!2018-02-23T07:40:00+01:00Robert Schwebel<div class="section" id="embedded-world-2018-etnaviv-on-mx8m">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="277x182" href="https://www.pengutronix.de/media/blog/2018/2018-02-23_embedded-world/2018-02-23_embedded-world-2018.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-23_embedded-world/2018-02-23_embedded-world-2018.thumb.267c3902ed2e77ced5474711d2da2799.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Every year's end-of-winter highlight starts next Tuesday: Embedded
World 2018, and like every year, it is our main trade show and a good
opportunity to meet many long-term customers in person. This year's
highlight of the highlight: We have Etnaviv and Wayland running on MX8M!</p>
<p>For us, the whole i.MX 8M story started shortly before Christmas holidays
in late 2017, when we got the first piece of evaluation hardware from NXP.
Fortunately, the friendly folks in the Etnaviv community had already
started working on public documentation of GC7000 (the new 3D IP block
in i.MX 8M), so we could directly focus on the kernel side.</p>
<p>In mid January 2018, the Pengutronix graphics team member Lucas Stach
started working on Etnaviv kernel support for GC7000, and it turned out
that it was a quick job to get initial support for the 3D unit up and
running. The demo you can see at Embedded World is running Wayland on a
Full-HD HDMI monitor, with weston-terminal, glmark and GStreamer
decoding a 720p video (entirely in software so far). It was developed in
roughly four weeks…</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1920x1080" href="https://www.pengutronix.de/media/blog/2018/2018-02-23_embedded-world/2018-02-23_mx8m-wayland.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-23_embedded-world/2018-02-23_mx8m-wayland.thumb.6650481e5f8475a3c5f587b84d3d9e6f.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>While we are quite enthusiastic about the quick results right now, you
should also be aware of the fact that there is still a long way to go
until i.MX 8M is equally well supported in mainline as i.MX6 is. For example,
although you can of course see the demo output on the monitor, the whole
display scanout driver will be <em>a lot</em> of work until being ready for
mainline. Fortunately for us, the developers at NXP already wrote a DRM
driver in their enablement BSP (in previous years the display drivers were
based on the legacy framebuffer driver infrastructure). This was one of
the reasons why we could get output in that short amount of time; however,
the output unit supports many interesting features like eDP,
parallel displays, MIPI-DSI and HDMI, so drivers which fulfill our high
quality standards for the mainline kernel need to be done <em>right</em>.</p>
<p>Bringing the scanout driver to mainline quality will be one of our tasks
for the upcoming months. Fortunately, the first customers will be ready
with their hardware soon: as all of our work is driven by customers who
care about operating system quality while getting their devices ready
for production, it will give a great boost for MX8M support in the
mainline kernel.</p>
<p>Being able to do these kind of kernel support is of course always a
community thing, as we are standing on the shoulders of giants! Thanks
to Wladimir van der Laan for his great documentation and userspace OpenGL
implementation work, thanks to the NXP folks for providing hardware and
enablement code, thanks to VeriSilicon for a great family of GPUs, and
thanks to C.H. for you-know-what-I-mean 😀</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/iQRqRKyHzJ8"></iframe>
</div>
<p>We have several other demos, like:</p>
<ul class="simple">
<li>Fully Open Source Automotive Grade Linux demo with Yocto + Etnaviv</li>
<li>i.MX6 based dual-head ATEX camera with OpenGL video transformation</li>
<li>Robust Software Updating with RAUC and barebox</li>
<li>Embedded Linux Test Automation with labgrid</li>
<li>Real-Time Testing with labgrid</li>
</ul>
<p>Visit us in H4-261!</p>
</div>
<p>Every year's end-of-winter highlight starts next Tuesday: Embedded
World 2018, and like every year, it is our main trade show and a good
opportunity to meet many long-term customers in person. This year's
highlight of the highlight: We have Etnaviv and Wayland running on MX8M!</p>2018-02-23T07:40:00+01:00tag:www.pengutronix.de,2018-02-12:/2018-02-12-fosdem-2018.htmlPengutronix at FOSDEM 20182018-02-12T00:00:00+01:00Enrico Jörns<div class="section" id="pengutronix-at-fosdem-2018">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3077x2051" href="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_rauc-talk-ejo.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_rauc-talk-ejo.thumb.74bce43f952050ef665f98178efe5d8a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>As in the previous years a bunch of Pengutronix developers
attended the FOSDEM Open Source conference in Brussels to stay up-to-date with
the latest developments in the context of embedded Linux, graphics and media,
electronics and lots of other interesting topics.</p>
<p>With his talk <a class="reference external" href="https://fosdem.org/2018/schedule/event/updating_complex_systems/">Facing the Challenges of Updating Complex Systems</a>
Pengutronix developer Enrico Jörns looked at the updating topic beyond the
basic considerations about redundancy, atomicity, simple verification and A/B
setups that are luckily solved by most nowadays Open Source updating frameworks
such as <a class="reference external" href="https://rauc.io">RAUC</a>.</p>
<p>Instead, he pointed out, designing a robust update system does not mean
assembling unrelated building blocks but instead requires fine-tuned
configuration of all system components from the bootloader to the deployment
software to smoothly interact.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1920x1080" href="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_rauc-talk-bootchooser.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_rauc-talk-bootchooser.thumb.06114719a15671a17d08c76457966d3b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>While installing updates itself is solved by standard frameworks by now,
handling target selection in the bootloader still requires error-prone custom
scripting in many cases.
With <a class="reference external" href="https://barebox.org/doc/latest/user/bootchooser.html">bootchooser</a>
Pengutronix brought a framework for this to the Barebox bootloader, making
it an ideal candidate for redundant system designs.
Enrico also noted that UEFI provides a similar mechanism with its boot
target handling as well.</p>
<p>One of the other noteworthy topics covered in his talk was the possible
benefit of using the <a class="reference external" href="https://github.com/systemd/casync">casync</a> content
chunking tool for embedded system updates over limited data connections.
With this, it is possible to reuse local data chunks that are identical between the
update and the current system and download only those which differ over the network
connection.
Thus, future versions of <a class="reference external" href="https://github.com/rauc/rauc/pull/217">RAUC will support</a>
casync-based bundles.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3483x2322" href="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_fosdem-2018-demonstrator.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_fosdem-2018-demonstrator.thumb.9964f3c34ea95ff186ff8df41e960614.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Thanks to the folks from
<a class="reference external" href="https://www.openembedded.org/wiki/Main_Page">OpenEmbedded</a> we were able
to bring our over-the-air updating demo to their stand at FOSDEM.
This was a great opportunity for us to discuss with hackers from all different
fields of interest about reproducible embedded system builds and the
closely related importance of safe and secure update strategies in a growing
world of embedded and IoT devices.</p>
<div><div class="clearfix"></div></div>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3483x2322" href="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_ptx-sticker.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-02-12_fosdem/2018-02-12_ptx-sticker.thumb.c7b9a63ff74ae1379f3f313345ef44b9.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Beside our popular black pencils also our new Pengutronix penguin stickers and
project/job cards that we got ready right in time before FOSDEM enjoyed
great popularity.</p>
<p>Thanks to the entire FOSDEM team for organization, support and video
recordings!</p>
</div>
<p>As in the previous years a bunch of Pengutronix developers
attended the FOSDEM Open Source conference in Brussels to stay up-to-date with
the latest developments in the context of embedded Linux, graphics and media,
electronics and lots of other interesting topics.</p>2018-02-12T00:00:00+01:00tag:www.pengutronix.de,2018-02-01:/2018-02-01-RAUC-0.3.htmlRAUC v0.3 Released2018-02-01T21:27:00+01:00Enrico Jörns<div class="section" id="rauc-v0-3-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="http://rauc.io/pages/download.html">v0.3</a> release of RAUC</p>
</div>
</div>
<p>The RAUC team is proud to announce that we've just released RAUC v0.3!
Again, we have worked a lot on stability and support for more and more
use cases. RAUC now supports pure UEFI-based booting on x86, multiple
board variants in the same bundle, intermediate certificates and
enhanced feedback from the boot selection layer.</p>
<div class="section" id="enhancements">
<h3>Enhancements</h3>
<ul class="simple">
<li>Added support for intermediate certificates, improved bundle resigning and
certificate information for hooks.
This makes it easier to use a multi-level PKI with separate intermediate
certificates for development and releases.</li>
<li>Added support for image variants, which allow creating a single bundle which
supports multiple hardware variants by selecting the matching image from a
set contained in the bundle.</li>
<li>Added support for redundant booting by using EFI boot entries directly.</li>
<li>Added boot information to <tt class="docutils literal">rauc status</tt></li>
<li>Added <tt class="docutils literal">rauc extract</tt> command to extract bundles</li>
<li>Support detection of the booted slot by using the <tt class="docutils literal">UUID=</tt> and
<tt class="docutils literal">PARTUUID=</tt> kernel options.</li>
<li>Improved the status and error output</li>
<li>Improved internal error cause propagation</li>
</ul>
</div>
<div class="section" id="bug-fixes">
<h3>Bug Fixes</h3>
<ul class="simple">
<li>Fixed boot slot detection for <tt class="docutils literal"><span class="pre">root=<symlink></span></tt> boot parameters (such as
<tt class="docutils literal"><span class="pre">root=/dev/disk/by-path/pci-0000:00:17.0-ata-1-part1</span></tt>)</li>
<li>Removed redundant image checksum verification during installation.</li>
</ul>
</div>
<div class="section" id="testing">
<h3>Testing</h3>
<ul class="simple">
<li>Improve robustness and test coverage</li>
<li>Use gcc-7 for testing</li>
</ul>
</div>
<div class="section" id="documentation">
<h3>Documentation</h3>
<ul class="simple">
<li>Added documentation for intermediate certificates, re-signing bundles, image variants and UEFI support</li>
</ul>
</div>
</div>
<p>The RAUC team is proud to announce that we've just released RAUC v0.3!
Again, we have worked a lot on stability and support for more and more
use cases. RAUC now supports pure UEFI-based booting on x86, multiple
board variants in the same bundle, intermediate certificates and
enhanced feedback from the boot selection layer.</p>2018-02-01T21:27:00+01:00tag:www.pengutronix.de,2018-01-17:/2018-01-17-first-mx8m-mainline-patches.htmlFirst i.MX 8M Patches posted for Mainline2018-01-17T17:56:00+01:00Robert Schwebel<div class="section" id="first-i-mx-8m-patches-posted-for-mainline">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="872x518" href="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-board.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-board.thumb.d894732baf57e7485184760739f64d07.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Eight days after <a class="reference external" href="http://investors.nxp.com/mobile.view?c=209114&v=203&d=1&id=2325748">NXP announced the immediate availability of the i.MX 8M
processor family</a>,
Pengutronix developer Lucas Stach today posted a first set of 11 patches to support i.MX 8M
in the mainline kernel (<a class="reference external" href="https://marc.info/?l=linux-gpio&m=151621369110503&w=1">linux-gpio</a>, <a class="reference external" href="https://marc.info/?l=linux-clk&m=151621379810561&w=2">linux-clk</a>, <a class="reference external" href="https://marc.info/?l=linux-arm-kernel&m=151621403210662&w=2">linux-arm-kernel</a> and <a class="reference external" href="https://marc.info/?l=linux-netdev&m=151621386110609&w=2">linux-netdev</a>).</p>
<p>This first patch series (together with five additional patches which are
not ready for mainline yet) makes it possible to boot an i.MX 8M into
userspace, with support for pinmux, clocks, network and eMMC. With
these features in place, it will be possible to continue development on
a top-of-tree kernel towards support for more interesting peripherals.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1167x778" href="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-kernel.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-kernel.thumb.aa7e7cab5db18c80d0266699dd40a54b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>i.MX 8M is the newest (available) member of NXP's (former Freescale's,
former Motorola's) i.MX family of application processors, initially
introduced back in 2001 and used by many, many Pengutronix customers
over all those years. In contrast to many other application processors,
the i.MX family always made a good compromise between performance,
features and availability, especially when it comes to industrial,
medical and automotive applications and their longterm requirements.
With first class mainline kernel support, i.MX is also a good choice for
device manufacturers who care about IoT security, updates and
top-of-tree kernels.</p>
<p>In contrast to the industry-work horse i.MX 6, the kernel support for i.MX 8M
in mainline is still in it's early stage of development. The hardware is
a moderate evolution of the i.MX 6 peripherals, replacing the Cortex-A9
cores by up to four Cortex-A53 cores (ARM64) and improving the overall
memory bandwidth, which has always been a bottleneck for graphic
intensive applications.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="450x300" href="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-userspace.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2018/2018-01-17_first-mx8m-mainline-patches/2018-01-17_first-mx8m-mainline-patches-userspace.thumb.f9b6a9b7005c3a0a56af43203934e67a.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The most intrusive change between i.MX 6 and i.MX 8M is the replacement of the
IPU display unit and the VPU video accelerator by VeriSilicon IP cores,
so supporting the graphics subsystem will be high on the list of
upcoming challenges.</p>
<p>Later this year, NXP will make more i.MX 8 families available: i.MX 8QM and
i.MX 8X will be completely different hardware, with much more power but
also much less software synergies with the existing i.MX 6 code in
mainline.</p>
</div>
<p>Eight days after <a class="reference external" href="http://investors.nxp.com/mobile.view?c=209114&v=203&d=1&id=2325748">NXP announced the immediate availability of the i.MX 8M
processor family</a>,
Pengutronix developer Lucas Stach today posted a first set of 11 patches to support i.MX 8M
in the mainline kernel (<a class="reference external" href="https://marc.info/?l=linux-gpio&m=151621369110503&w=1">linux-gpio</a>, <a class="reference external" href="https://marc.info/?l=linux-clk&m=151621379810561&w=2">linux-clk</a>, <a class="reference external" href="https://marc.info/?l=linux-arm-kernel&m=151621403210662&w=2">linux-arm-kernel</a> and <a class="reference external" href="https://marc.info/?l=linux-netdev&m=151621386110609&w=2">linux-netdev</a>).</p>2018-01-17T17:56:00+01:00tag:www.pengutronix.de,2017-12-07:/2017-12-07-PTXdist_org_launch.htmlPTXdist.org: Departure into a new Age2017-12-07T08:00:00+01:00Enrico Jörns<div class="section" id="ptxdist-org-departure-into-a-new-age">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1532x1013" href="https://www.pengutronix.de/media/blog/2017/2017-12-07_ptxdist-org-launch/2017-12-07-ptxdist-org.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-12-07_ptxdist-org-launch/2017-12-07-ptxdist-org.thumb.af809a37a0491a288bcbe97213f70a55.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>The new ptxdist.org website</p>
</figcaption>
</figure>
</div><p>Over the past months, we did a lot of work in giving some open source
projects maintained by Pengutronix folks the attention they deserve while
also being more open to the community and ease contributing to and using
them.</p>
<p>Another notable milestone has now been finished; we have launched the
new website for the PTXdist embedded Linux build system: <a class="reference external" href="http://ptxdist.org">ptxdist.org</a>.
While the domain was just a redirect to an inconspicuous sub-page of
pengutronix.de it now became a mature and stand-alone project website.</p>
<p>The new website comes with a responsive design allowing access from all kinds
of devices.
The already existing but not yet much utilized PTXdist Logo now sits
at the top of the website inviting you to cook your own embedded Linux Project,
from simple hobby projects to full-featured and highly customized professional
Linux platforms.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1340x1013" href="https://www.pengutronix.de/media/blog/2017/2017-12-07_ptxdist-org-launch/2017-12-07-ptxdist-org-doc.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-12-07_ptxdist-org-launch/2017-12-07-ptxdist-org-doc.thumb.ae256af01253a305b3648bdfbb2fa48f.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>ptxdist.org online HTML documentation</p>
</figcaption>
</figure>
</div><p>It is not only giving a project a more informative landing page:
With the website launch we have also put the HTML documentation of PTXdist
online.
Based on the old documentation that was still tex-based we started a conversion
marathon about two years ago and moved everything to the more lightweight
reStructuredText format.
Using rst increases readability of the source while reducing the hurdle for
contributors to modify and extend documentation on their own.
With <a class="reference external" href="http://www.sphinx-doc.org">Sphinx</a> PTXdist generates the full
documentation in either HTML or PDF formats.</p>
<p>Putting the (latest) HTML version of the documentation online finally
enables really useful features such as easy full text search (both
JavaScript-based and in your browser), easier linking and googling, and, last
but not least a quickly available solution to most of the issues you may
stumble across while working with building embedded systems.</p>
<p>We have also put the DistroKit quick-start BSP and some core components as the
Barebox bootloader and the update tool RAUC at a more prominent position to
help new users taking their first steps.</p>
<p>Finally, on the <a class="reference external" href="http://ptxdist.org/pages/download.html">Download</a> page
you will always find out which is the latest version of PTXdist and be able to
download it.</p>
</div>
<p>Over the past months, we did a lot of work in giving some open source
projects maintained by Pengutronix folks the attention they deserve while
also being more open to the community and ease contributing to and using
them.</p>2017-12-07T08:00:00+01:00tag:www.pengutronix.de,2017-11-21:/2017-11-21-rauc-hawkbit.htmlBridging the Gap: The RAUC hawkBit Client2017-11-21T08:00:00+01:00Enrico Jörns<div class="section" id="bridging-the-gap-the-rauc-hawkbit-client">
<p>OTA field updates are a common requirement in modern embedded device
deployments.
The larger the amount of devices to control, the more important is having a
good infrastructure that is reliable in updating and smart in rolling out the
software.</p>
<p>With the RAUC update framework, we already have one of the components required
for solving this challenge: an update client operating on your target and
making sure that your updates are installed safely and securely.</p>
<p>The second component is a deployment server that manages your update artifacts,
controls roll-out strategies, gives feedback about device update states, etc.</p>
<p>This is where the Eclipse hawkBit project comes into play.
While RAUC focuses on being not much more than the update core,
hawkBit focuses on being a deployment server only.
This qualifies it as an ideal counterpart for RAUC.</p>
<p>Thus, the only question remaining is: How should we bring them together?</p>
<div class="section" id="evolution-of-rauc-hawkbit">
<h3>Evolution of rauc-hawkbit</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1024x768" href="https://www.pengutronix.de/media/blog/2017/2017-11-21_rauc-hawkbit/2017-11-21_rauc-hawkbit-demonstrator.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-11-21_rauc-hawkbit/2017-11-21_rauc-hawkbit-demonstrator.thumb.56ee1bcb5e16723c5eacb40063ea335c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 325px;
"><p>RAUC hawkbit Demonstrator on CLT 2016</p>
</figcaption>
</figure>
</div><p>In the middle of 2016, in the context of a customer project where unattended
OTA field updates with hawkBit as the deployment infrastructure were required,
Pengutronix started implementing a python-based service that runs on the target
and talks to RAUC on the one side via its D-Bus interface and to hawkBit on
the other side over its RESTful
<a class="reference external" href="http://www.eclipse.org/hawkbit/documentation/interfaces/ddi-api.html">DDI API</a>.</p>
<p>Later that year, parts of the code were reused in an internal project, a RAUC
hawkBit deployment server demonstrator.
We presented this at the FOSDEM in Brussels, at the Chemnitz Linux days and on
the Embedded World exhibition.</p>
<p>Finally, in early 2017, the customer and we decided to make a reusable project
out of the hawkBit client core components and provide it as open source
software.
The advantages that were the motivation behind doing this step are quite the
same as for almost every open source project:
Only this way it will have the chance to be actively maintained, used, tested
and possibly improved by the community.</p>
<p>A few month later, after a bunch of refactoring, cleanup and testing, we
now finally release the initial version (0.1.0) of this project.</p>
</div>
<div class="section" id="see-how-it-works">
<h3>See How It Works</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="356x521" href="https://www.pengutronix.de/media/blog/2017/2017-11-21_rauc-hawkbit/2017-11-21-rauc-hawkbit.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-11-21_rauc-hawkbit/2017-11-21-rauc-hawkbit.thumb.90a7d65ed201beb0252d92f9f78a70fa.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Now, let's conclude the history lesson and start with some technical facts.</p>
<p>The <em>rauc-hawkbit</em> client uses asynchronous routines and HTTP communication abstraction
provided by <a class="reference external" href="https://docs.python.org/3/library/asyncio.html">asyncio</a>
and <a class="reference external" href="https://aiohttp.readthedocs.io/en/stable/">aiohttp</a> for its
communication with the REST API of the hawkBit deployment server.</p>
<p>The communication with the D-Bus interface of RAUC is done using the
corresponding glib methods from Python via the GObject introspection interface.</p>
<p>During its initial interaction with the server,
the client identifies itself to the server and sends some meta-data that
allows identification, filtering, etc.
Then the client service regularly polls the deployment server for new
artifacts or actions.
The polling interval itself is a property set by the hawkBit server and can be
adjusted to specific needs.
Once hawkBit has an update available for the device, the client first downloads
it and then triggers RAUC via D-Bus to install the downloaded bundle.</p>
<p>During installation, the client receives progress feedback from RAUC and
forwards it to hawkBit, allowing the user to see the exact individual progress
of each pending update.
After a successful or failed update, hawkBit gets notified about the result,
allowing to base roll-out strategies on this information.</p>
</div>
<div class="section" id="using-it">
<h3>Using it</h3>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="https://github.com/rauc/rauc-hawkbit/releases/tag/v0.1.0">v0.1.0</a> release of rauc-hawkbit
or vist on <a class="reference external" href="https://github.com/rauc/rauc-hawkbit">GitHub</a> or
<a class="reference external" href="https://pypi.python.org/pypi/rauc-hawkbit/">pypi</a></p>
</div>
</div>
<p>rauc-hawkbit is available in the python package index
(<a class="reference external" href="https://pypi.python.org/pypi/rauc-hawkbit/">pypi</a>) making it easy to
install for testing purposes.</p>
<p>For those who use Yocto/OpenEmbedded as build system, the
<a class="reference external" href="https://github.com/rauc/meta-rauc">meta-rauc</a> layer provides a <cite>rauc-hawkbit</cite>
recipe and all required dependencies. You can simply add it to your image:</p>
<pre class="literal-block">
IMAGE_INSTALL_append = " rauc-hawkbit"
</pre>
<p>or build it directly with bitbake:</p>
<pre class="literal-block">
bitbake rauc-hawkbit
</pre>
<p>The rauc-hawkbit client is designed to be both an example application as well
as a base library providing the required functionality for bringing RAUC and
hawkBit together.
For testing, you can simply use the provided executable python script
<tt class="docutils literal"><span class="pre">rauc-hawkbit-client</span></tt>.
If you consider actually using it in the field, you may want to integrate it
into your application, web interface or something else.
In that case, you can use it as a python module via <tt class="docutils literal">import rauc_hawkbit</tt>.</p>
<p>To use the example command-line application, all you need is a configuration
file containing some mandatory information, such as the server address,
an authentication token or the name of your target:</p>
<div class="code-block">
<div class="highlight"><pre><span></span><span class="k">[client]</span>
<span class="na">hawkbit_server</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">127.0.0.1</span>
<span class="na">ssl</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">false</span>
<span class="na">tenant_id</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">DEFAULT</span>
<span class="na">target_name</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">test-target</span>
<span class="na">auth_token</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">ahVahL1Il1shie2aj2poojeChee6ahShu</span>
<span class="na">mac_address</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">ff:ff:ff:ff:ff:ff</span>
<span class="na">bundle_download_location</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">/tmp/bundle.raucb</span>
<span class="na">log_level</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="s">debug</span>
</pre></div>
</div><p>To start the rauc-hawkbit client run:</p>
<pre class="literal-block">
rauc-hawkbit-client -c config.cfg
</pre>
<p>Note that for this example to be fully functional,
you also need to have a RAUC instance running on your device and a
hawkBit instance set up on your server.
Refer to <a class="reference external" href="https://github.com/eclipse/hawkbit#build-and-start-hawkbit-update-server">this</a>
page on how to quickly set up a development instance of hawkBit.</p>
</div>
</div>
<p>OTA field updates are a common requirement in modern embedded device
deployments.
The larger the amount of devices to control, the more important is having a
good infrastructure that is reliable in updating and smart in rolling out the
software.</p>2017-11-21T08:00:00+01:00tag:www.pengutronix.de,2017-11-09:/2017-11-09-RAUC-0.2.htmlRAUC v0.2 Released2017-11-09T15:00:00+01:00Enrico Jörns<div class="section" id="rauc-v0-2-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download <a class="reference external" href="http://rauc.io/pages/download.html">v0.2</a> release of RAUC</p>
</div>
</div>
<p>We proudly just sent out a new release of the RAUC update framework.</p>
<p>With 171 individual changes since v0.1.1 we have put much effort in enhancing
both the usability and the stability of RAUC while adding a set of useful
features making RAUC applicable for even more use cases.</p>
<p>Scroll through the following list to get an overview of the most significant
changes for this release:</p>
<ul>
<li><p class="first">For those who use RAUC from the command line, the tool now provides an output
of the installation progress as well as improved error reporting to ease
quickly finding configuration or runtime issues.</p>
</li>
<li><p class="first">RAUC now supports splitting up the installation and the actual activation of
an update. This can be quite useful for scenarios where you first want to
roll out updates to all devices in the field and then enable it for all
devices together at a defined point in time.</p>
<p>Therefor both the system configuration option <tt class="docutils literal"><span class="pre">activate-installed</span></tt> as well
as new D-Bus method <tt class="docutils literal">mark</tt> along with the new <tt class="docutils literal">rauc status <span class="pre">mark-active</span></tt>
sub command were introduced.</p>
<p>The changes not only allow to handle delayed activation but also enable you
to use the RAUC bootloader abstraction to modify the target to boot, e.g. for
testing.</p>
</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1335x1043" href="https://www.pengutronix.de/media/blog/2017/2017-11-09_rauc-0-2/2017-11-09_RAUC-0.2-certificate-handling.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-11-09_rauc-0-2/2017-11-09_RAUC-0.2-certificate-handling.thumb.540620f8f3ec458a36691af2524458f9.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Certificate information dump with <tt class="docutils literal">rauc info</tt></p>
</figcaption>
</figure>
</div><ul>
<li><p class="first">When dealing with certificates, you might have asked yourself often in the
past if you signed your update correctly, if the verification works as
expected, etc.</p>
<p>Now, the RAUC commandline tool provides features and options to ease dealing
with certificate debugging:</p>
<ul>
<li><p class="first">A newly introduced <tt class="docutils literal"><span class="pre">--keyring</span></tt> argument allows you to directly define the
keyring to use for verification without the need to have a system.conf
file.
This is especially useful for inspecting bundles on your build host.</p>
</li>
<li><p class="first">The output of <tt class="docutils literal">rauc info</tt> now dumps the trust chain (with subject,
issuer, and calculated
<a class="reference external" href="https://tools.ietf.org/html/rfc7469#section-2.4">SPKI (SubjectPublicKeyInfo)</a> hash)
successfully verify the inspected bundle.</p>
<p>If passing the newly introduced <tt class="docutils literal"><span class="pre">--dump-cert</span></tt> argument, you will also get
the full signer cert of the bundle printed.</p>
</li>
</ul>
</li>
<li><p class="first">But, debug printout is not the only improvement targeting certificate
support:</p>
<p>When scrolling through the help text of the RAUC tool, you may encounter a
fully new command <tt class="docutils literal">rauc resign</tt>. We finally added (after we've already
mentioned it in the documentation) support for resigning bundles.
This can be quite useful when changing a bundle (after having tested it
successfully) from development/testing state to production state without
actually having to touch its well-proven content anymore.</p>
<p>RAUC resign allows you to verify the bundle on your build host, remove the
signature and add a new one created from a different key.</p>
</li>
<li><p class="first">Last but not least, a significant effort we've put in enhancing the
documentation, as you could already read in
<a class="reference external" href="https://www.pengutronix.de/en/blog/2017-10-10-rauc_documentation_update.html">this</a> blog post.</p>
</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3100x2322" href="https://www.pengutronix.de/media/blog/2017/2017-11-09_rauc-0-2/2017-11-09_RAUC-0.2-card-sticker.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-11-09_rauc-0-2/2017-11-09_RAUC-0.2-card-sticker.thumb.8ffff6ceec0c4a32f205f98dcc5add18.png"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"><p>Our brand new cool business cards and stickers</p>
</figcaption>
</figure>
</div><p>For an extended list of all changes (especially the bugfixes) contained in the
v0.2 release, see the
<a class="reference external" href="https://github.com/rauc/rauc/blob/master/CHANGES">CHANGES</a> file.</p>
<p>For the next release we already have a bunch of new features planned or already
prepared, including a central comprehensive status file for storing slot
checksum and metadata, support for placing and honoring intermediate
certificates in bundles, streaming support based on
<a class="reference external" href="https://github.com/systemd/casync">casync</a> and much more.</p>
</div>
<p>We proudly just sent out a new release of the RAUC update framework.</p>2017-11-09T15:00:00+01:00tag:www.pengutronix.de,2017-10-25:/2017-10-25-elce-2017-day-three.htmlrsc's Diary: ELC-E 2017 - Day 32017-10-25T12:01:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-day-3">
<p>Day 3 of the Embedded Linux Conference Europe 2017 in Prague is over,
all of our talks have been absolved successfully and we made many new
community contacts and refreshed old ones. Here is my report.</p>
<div class="section" id="op-tee-using-trustzone-to-protect-our-own-secrets">
<h3>OP-TEE Using TrustZone to Protect Our Own Secrets</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee1.thumb.8d6322d495094a3c4e098762da1833d2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>As his talk was in a much too small room on day one, my colleague Marc
Kleine-Budde got a 2nd chance to talk about OP-TEE and storing data in
the trustzone in a secure way. The room was well filled with visitors,
so giving the talk a 2nd time seems to have been the right choice.</p>
<p>The "Trusted Execution Environment" (TEE) is a small isolated
environment for sensitive code and data. The idea is that only a small
ammount of code runs in the TEE, leaving the major part of the
functionality for the normal Linux environment. On ARM, TEE can be
implemented with the help of the "trustzone" technology: while the code
runs on the same CPU, the processor hardware isolates the code in a
separate mode which has more permissions than normal operating system
code ("secure world"). The only way to switch between normal world and
secure world is a call into the secure monitor.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee2.thumb.08efdc4ecebb9a22ea01032601ef040d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In secure world, the hardware makes sure that access to certain parts of
the address space is limited. It is also possible to restrict access to
certain hardware units (but this mode of operation has its own issues).
On ARMv7, the secure monitor is implemented in OP-TEE, while on ARMv8 it
is part of the "trusted firmware". After bootup, the system initially
starts in secure state.</p>
<p>OP-TEE was initially implemented as proprietary code; in 2015, it was
relicensed and published under the BSD license. Since 4.12, the kernel
part (implementing the Global Platform API) is in Linux mainline.
Currently, there are about 20 ports in the kernel. The OP-TEE mini
operating system consists of the TEE core, an internal API and the
trusted apps.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-optee3.thumb.7a9f4e1ed8a03d3a7d8c9df4f966b002.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>On i.MX6, the boot process is secured via HABv4; OP-TEE is integrated
into the bootloader (barebox in our case) and is executed during
startup. Barebox checks the signature of the kernel (FIT image) and
starts the rest of the system. The OP-TEE code continues to exist during
the lifetime of the system and is called in case of a secure monitor
call. As our experiments were gained as part of this year's Pengutronix
TechWeek, we just got the base mechanisms working. For the future, some
features for real applications would be helpful, such as
adapting OP-Tee to the kernel's keystore API. With such a mechanism in
place, the trustzone could be used to securely store keys.</p>
<p>During the discussion, several security issues have been addressed;
surprisingly, it turned out that security is complex and there are no
guarantees that mechanisms cannot be circumvented. However, the audience
and the involved people would like to see more people being involved, in
order to get more testing, fuzzing etc.</p>
</div>
<div class="section" id="stable-device-tree-abi-it-s-possible">
<h3>Stable Device Tree ABI - It's Possible</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-oftree1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-oftree1.thumb.40d6abbb4d60f1477d57a759a160b44f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After the lunch break, my colleague Lucas Stach reported about
strategies to ensure ABI stability of open firmware devicetree bindings.
One motivation for ABI stability is that the embedded systems we do at
Pengutronix are usually based on the mainline kernel; production systems
will be provided with new kernels for quite some time.</p>
<p>While the kernel initializes from oftree for quite a while now, other
components start making use of it as well (barebox, U-Boot, secure world
firmware). Some devicetree properties are well established (i.e. memory
nodes), but for many peripherals it's not immediately obvious how to
model them in oftree, so bindings will change over time. So assuming
absolute devicetree longterm stability is no valid strategy.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-oftree2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-oftree2.thumb.29b4ddec8ec8e2297adfa111e8a1a719.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The expertise outlined in the talk was gained while maintaining the i.MX
platform and represents what maintainers learned during the last years.
The first step when defining a stable binding is to look into the
datasheet of a component: all hardware properties need to be described
in the binding - not only that ones which are being used in the
currently relevant design. It is important that mandatory compatibles
are stable from day one: later on, it's not possible to change them any
more without additional maintenance burden. For new variants of existing
IP blocks new compatibles should be defined: for instance, the SPI core
on MX6 ULL got the compatible "fsl,imx6ul-ecspi, fsl,imx51-ecspi". The
driver only makes use of the last part for now, but in case hardware
differences are found, the first information is already available.
In case modifications need to be made, they should be done in the
kernel, not in oftree.</p>
<p>In result, Lucas explained that the set of rules to be followed for a
stable devicetree ABI is small. The talk was followed by an engaged
discussion which showed that the topic is more complex than many people
expect.</p>
</div>
<div class="section" id="swupdate">
<h3>swupdate</h3>
<p>Stefano Babic reported in my next talk about the swupdate project; for
me, it was interesting to see how other developers address issues in the
same area where we use RAUC at Pengutronix.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-swupdate.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-swupdate.thumb.41b8c66ec2eba2afb43262cf335746da.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The talk started with an introduction about update usecase, based on USB
sticks up to network based setups. swupdate can (similar to RAUC) make
use of the hawkBit update server. It is also possible to implement a
secure fallback to an existing update slot. Other requirements such as
atomicity or making sure that only properly validated firmwares are
rolled out to the field are more or less similar to what we are used to.</p>
<p>swupdate exists since 2014 and is licensed under GPLv2/LGPLv2. During
the last time, it found quite some contributors. The system has a local
interface, it is possible to integrate it into applications and it
provides a set of OTA update variants. Yocto and buildroot integration
is availabe; the supported bootloaders are U-Boot and grub. swupdate's
update format is based on CPIO. There are handlers for different backend
store device and a LUA scripting facility. Boot counters are possible
when being used with U-Boot. The developers have topics like bootloader
fallback, file updaters, a progress indication interface and a streaming
update mechanism on their agenda.</p>
</div>
<div class="section" id="zero-copy-video-streaming-on-embedded-systems-the-easy-way">
<h3>Zero-Copy Video Streaming on Embedded Systems the Easy Way</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero1.thumb.549698b4f3a737e2700491fb486e92c1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the last Pengutronix talk of the conference, Michael Tretter and
Philipp Zabel talked about their experiences how to reduce memory
bandwith in video streaming scenarios. The usecase are systems that
capture video with a sensor, process it, transfer it via some network
channel, receive it on a 2nd system and display it. The tasks need a
certain amount of processing power, while the systems often have low
power requirements.</p>
<p>One of the typical issues is that the various components in the SoCs
need their data in special colour formats: cameras provide bayer
pattern, encoders/decoders need YUV, while 3D units understand tiled
formats. The task is to move those video buffers around without wasting
memory bandwidth.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero2.thumb.b8926b6d915d2a8335139be8a6d375f4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The 3D units, used i.e. for geometrical transformations such as lense
correction, are covered by the Etnaviv project; the relevant patches are
now in MESA and Linux mainline. The output side is covered by the
imx-drm driver, while the video encoder/decoder handling is done by the
coda driver, which is also part of the mainline kernel.</p>
<p>The main feature to hand over buffers between several control blocks is
the dmabuf mechanis: it makes it possible to transfer control over a
kernel allocated buffer between several userspace components by handing
over a filedescriptor handle; userspace doesn't have direct access to
the memory addresses any more, and the kernel is responsible for buffer
allocation and life time management.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-zero4.thumb.de99d6dace09e1fdce5112ccc3d840f4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After showing some v4l2 and EGL examples (which indeed did <em>not</em> look
easy), Michael and Philipp showed how to make use of all those features
from within GStreamer. The internals of the examples are still not easy,
but at least from the user perspective it looks easy... More complex
scenarios with compositing of video and GUIs are usually realized with
Wayland these days.</p>
<p>The camera input side of the game stays complex for now: the pipelines
need to be configured with media-ctl. The developers are currently
working on providing better default settings to configure cameras in a
way that they at least output some video without further config steps.
In addition, atomic mode setting is being implemented for wayland by
others in the community, but those patches havn't landed in mainline
yet.</p>
</div>
<div class="section" id="closing-game-attendee-party">
<h3>Closing Game & Attendee Party</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party1.thumb.025cf7b5755b4108d29efcb639b65ec2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party2.thumb.cf72bebd1c433849e99541b8652b6db1.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party3.thumb.0a0b915655a10e4fe47e7dc371f518a4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party4.thumb.3b2461653a2543e8d5821477f58512be.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party10.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party10.thumb.01531bcc84801b64627ec76ac4ca581e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party5.thumb.ee913a15384dcc986f6e80fb27006ef8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party6.thumb.e9a942d830576a04615eeb813863a337.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party7.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party7.thumb.97c931b86162916855b8ba07a20d1246.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2432x3286" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party8.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party8.thumb.c6a09431fcef0f2df8def69a3ed3785b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3286x2432" href="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party9.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-25_elce-day-three/2017-10-25_elce-2017-day-three-party9.thumb.9099ab6e82b0c070820e6f3f93c19ec4.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>Day 3 of the Embedded Linux Conference Europe 2017 in Prague is over,
all of our talks have been absolved successfully and we made many new
community contacts and refreshed old ones. Here is my report.</p>2017-10-25T12:01:00+01:00tag:www.pengutronix.de,2017-10-24:/2017-10-24-elce-2017-day-two.htmlrsc's Diary: ELC-E 2017 - Day 22017-10-24T11:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-day-2">
<p>The second day of ELC-E is over. This is my report.</p>
<div class="section" id="safety-critical-linux">
<h3>Safety Critical Linux</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-safety1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-safety1.thumb.0ed04de2b207cb830f78bb20ceb144ca.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Lukas Bulwahn reported in the first talk I heard on tuesday morning
about the current state of the OSADL SIL2LinuxMP project. It deals with
the question if a Linux based system can be used for safety critical
systems, as needed for autonomous drive. IEC61501 asks the question how
to make sure there are no "inacceptable risks", and this project is
about finding the answer.</p>
<p>To fulfill the requirements of SIL2, there are several architectural
options:</p>
<ul class="simple">
<li>Check the output of a system with a small safety hardware</li>
<li>Safety Hpyervisor</li>
<li>Use the Linux kernel to isolate critical and non-critical parts of the
system</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-safety2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-safety2.thumb.dac4ec8edf76861c3095ef9652f57d51.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the third variant, parts of the Linux kernel need to be certified;
this is the variant that is investigated in the project. The challenges
are not small: the participants of the project try to find a process to
qualify a kernel with 23 million lines of code and a community driven
development process. The speaker reported that, when he presents this
project in the safety community, half of the audience leaves the room...</p>
<p>One of the biggest conceptional challenges is that safety software is
usually developed from day one with a safety process in mind. As this is
not the case with Linux, the kernel development processes are compared
with the required safety processes and identified gaps are closed with
own mechanisms. One example is that they investigated the open() syscall
for safety impact ("Hazard Driven Decomposition, Design & Development").
As part of this overall topic, the project also develops a small init
replacement.</p>
<p>Another activity of the project is to analyze git commits in the kernel
repository for certain factors. The "patch impact tester" analyzes,
which config options of the kernel a certain patch has influence on. The
project also analyzes a minimal kernel patch set. One (IMHO not
necessarily right) assumption is that, in a longterm kernel, the number
of bugs found over time decreases (I'm wondering if this could have the
reason that nobody in the community is interested in old kernels), so
they prefer old kernels over newer ones. On the bright side, a set of
analysis tools is developed that will also have a positive impact on the
non-safety aspects of kernel quality.</p>
</div>
<div class="section" id="industrial-grade-open-source-base-layer-development">
<h3>Industrial Grade Open Source Base Layer Development</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-cip.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-cip.thumb.82f85425ac8029e95a392ae4c51211d2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>The 2nd talk was about the "Civil Infrastructure Platform" (CIP). CIP
wants to be a base operating system infrastructure for components like
trains, ticketing systems, energy distribution, industrial control
systems, building automation and medical technology. All those systems
have in common that they need to be maintained for a very long time,
which also includes providing security fixes. For example, there are
train control systems on the market which are in operation for more than
50 years. These kind of systems have typically a development cycle of
several years, until all development- and certification steps have been
finished. The idea of the project is to have a super longterm kernel
(4.4) and other components such as Debian being supported for more than
10 years.</p>
<p>The talk didn't disturb my concern that CIP follows a fundamentally
wrong strategy. One of the advantages of Linux is that reasonably modern
kernels get a lot of test coverage and community feedback and thus
bugfixes, while such old kernels as proposed by CIP are not really
interesting for anyone anymore. So while there are industry people who
want to <em>have</em> them, there is almost nobody anymore who is interested
in <em>developing</em> and <em>maintaining</em> them. Additionally, we have often seen
that customers want stability and new features at the same time, so
people start backporting patches and patches over the time, which
doesn't make things better in any way and ends up in maintenance hell.
The only practicable way (in my oppinion) is to have proper update
systems and follow kernels which are still in upstream maintenance (see
Jan Lübbe's talk <a class="reference external" href="https://www.youtube.com/watch?v=xviInQoN-74">Long Term Maintenance, or: How to (Mis-)Manage
Embedded Systems for 10+ Years</a> from ELC-E 2016).</p>
</div>
<div class="section" id="opensource-in-neuroimaging">
<h3>Opensource in Neuroimaging</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-neuro1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-neuro1.thumb.4c713bf830d70bdd6ed2bf2024817547.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>After lunch break, Ben Dooks reported about using Open Source to find
out what the 1.2 kg mass in his head does. While many methods to
visualize the brain are still not within the reach of amateurs, some new
options arised recently: there are for instance creative commons
licensed databases with anonymized measurement data.</p>
<p>Another possibility to measure the brain is to sense the electrical
communication between neurons (EEG). The relevant voltages are in the uV
range, with frequencies of 1-100 Hz, so this kind of information can
safely be measured. There is a kickstarter funded open source sensor
(<a class="reference external" href="http://openbci.com">OpenBCI</a>) with 16 channels available, which can either
be built with a 3D printer or bought from a manufacturer. The setup can
measure brain waves and visualize, which area of the brain the
information comes from. Additionally, there are other open source
relevant devices (i.e. Brainstorm, OpenEEG, HackEEG).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-neuro2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-neuro2.thumb.32ad29a61f77858d004d216e36133636.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another variant is to measure magnetic fields (MEG); the signals are in
the 10 fT range. The method is able to produce better images, but due to
the low signal strength it is sensitive to noise. Ben has worked on a
measurement product making use of this mechanism. The control system
consists of several nodes, measuring up to 600 channels with 24 bit
resolution, and the data can be stored and visualized in realtme. The
system is based on debian, stores the data in HDF5 format and makes
intensive use of OpenGL and Python (NumPY, Arrow, HSPy), while doing
time sensitive tasks within an FPGA. He tried to use open source
mechanisms on the FPGA side as well, but this area stays complicated
with regard to open tools.</p>
</div>
<div class="section" id="ubifs-security-features">
<h3>UBIFS Security Features</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-ubisec.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-ubisec.thumb.cd53d970c76f03a8893e948ecc2a43f2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Richard Weinberger reported about security features on NAND chips, a
topic which is also interesting for our current work. After a short
introduction of the available encryption mechanisms in Linux he talked
about which ones could be used on NAND flash.</p>
<p>One interesting variant is fscrypt, a successor of eCryptFS, which has
filesystem integrated encryption (see fs/crypto in the kernel tree). It
is possible to specify a policy for each node in the directory tree. The
keys are handled with the in-kernel keystore. Files the user doesn't
have a key for are represented with a base 64 variant of the filename.
Tools for fscrypt are still being worked on but will be available soon.
Richard explained that the implementation to port fscrypt to UBIFS was a
bigger challenge than initially expected, but in the meantime it is
available if you switch on the kernel symbol CONFIG_UBIFS_FS_ENCRYPTION.</p>
<p>Another interesting feature would be to ensure file integrity on UBIFS.
Although there is IMA (the Integrity Measurement Architecture) for this
functionality, it is not implemented for ubifs in mainline, and options
to provide it are currently under discussion. One idea could be to
re-use the keys from fscrypt and only have a separate HMAC for the index
tree, in order to avoid unnecessary writes and performance penalties.
However, this topic will continue to be discussed.</p>
</div>
<div class="section" id="preempt-rt">
<h3>Preempt RT</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-rt1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-rt1.thumb.77e2037d44e69a86e095f9c6b67ff12b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In my last slot on tuesday, Sebastian Siewior reported about the state
of the RT Preempt patch set. The Linux Foundation collaborative project
has started in october 2015, and his patch plot shows that during the
3.10-rt cycle, the queue contained more or less a constant amount of
patches. When 3.14-rt and 3.18-rt were released, statistics show the
beginning of more activities, and with 4.4-rt it was obvious that
mainlining activities have accelerated. So it seems that the funding of
the project (first by OSADL, now by LF) improved the situation a lot.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="5472x3648" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-rt2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-rt2.thumb.6ea7b4890adbd178deb19aa16dbc05ef.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Since 4.9, developers have worked intensively on CPU hotplug, around
4.11 the timer wheel was reworked. He showd the current areas of work,
but didn't go into the details. Currently, the developers provide a
patch set for every second kernel and especially for the LTS kernels.</p>
<p>From an outside point of view, I still find it difficult to judge the
progress of the RT project. A short look into the patch queue still
showed many backports from upstream and many old patches, and it's
unclear why they havn't gone mainline already. Other patches are more
"tooling" than RT core features. In former times, the series file
contained the status of the patches, but that doesn't seem to be the
case any more; it might have moved elsewhere (I didn't follow the
activities closely in recent times).</p>
</div>
<div class="section" id="showcase">
<h3>Showcase</h3>
<p>Our team showed three open source projects relevant for our recent work
during the showcase:</p>
<ul class="simple">
<li>Etnaviv (Open Source GPU Drivers for i.MX6)</li>
<li>Labgrid (test automation)</li>
<li>RAUC (field upgrading)</li>
</ul>
<p>There were many interesting talks with the audience.</p>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase1.thumb.52916113e073dc26cc0e88a16cc8100f.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Rouven Czerwinski and Enrico Jörns showing labgrid and RAUC</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase2.thumb.0aa93bb8ef515dd85fa9e9e648a10a10.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Michael Grzeschik + Michael Tretter looking at things</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase3.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase3.thumb.7f87a144269be0e5282eab5a9e79625e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Many, many visitors</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase4.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase4.thumb.563fa15cf790738b2d117a648af6f0f2.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Rollout of Embedded Linux updates with RAUC and hawkBit</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase5.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase5.thumb.c0eb27f8323671b64ad33e7ca2b5e3d6.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Etnaviv is now in Linux, MESA and Wayland/Weston mainline.</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase6.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase6.thumb.a56679d32fc50b2b2eb960786ab9ba8e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Updating with RAUC</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase7.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase7.thumb.794970ea80cc639f1f023f9bbf1d1e59.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Etnaviv diskussions</p>
</figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase8.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-24_elce-day-two/2017-10-24_elce-2017-day-two-showcase8.thumb.f7bdf8671c236b7105b9d48f38d5a302.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Etnaviv diskussions</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>The second day of ELC-E is over. This is my report.</p>2017-10-24T11:00:00+01:00tag:www.pengutronix.de,2017-10-23:/2017-10-23-elce-2017-day-one.htmlrsc's Diary: ELC-E 2017 - Day 12017-10-23T15:08:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-day-1">
<p>This is my report from the first day of Embedded Linux Conference Europe
(ELC-E) 2017 in Prague.</p>
<div class="section" id="op-tee">
<h3>OP-TEE</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x399" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-optee.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-optee.thumb.65733f11f22bf264676d2e3889c5bc0c.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>My plan for the first timeslot at 09:00 was to see my colleague Marc
Kleine-Budde's talk about "OP-TEE - Using Trust Zone to Protect Our Own
Secrets", but the room was so fully crowded that I didn't get a seat any
more (embedded folks seem not to be too happy to join keynotes early in
the morning and prefer tech talks...). So I started the day with a
little bit longer coffee break... Obviously, more conference attendees
were also not amused, so the talk will be repeated on wednesday.</p>
</div>
<div class="section" id="linux-powered-arctic-buoys">
<h3>Linux Powered Arctic Buoys</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x400" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-boye1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-boye1.thumb.caaf159169d1a3e3048765fc55f4504e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>In the second talk, Satish Chetty reported about "Linux Powered
Autonomous Arctic Buoys".</p>
<p>The speaker is operating some of those self built and low cost sensor
carriers in Alaska as a part of research activities and talked about the
experiences he made with operating an embedded linux / ARM based
platform at temperatures as low as -40 °C. The devices are being used
for research of arctic ice meltdown in summer (while "summer" is not
what you think of, when it comes to arctic locations).</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x400" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-boye2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-boye2.thumb.093f94940faa1d2ffb6c873335d3e411.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>One of his most important topic was to save as much power as possible
with the measurement device: it schedules one measurement cycle, then
shuts down with the help of a microcontroller and then wakes up hours
later to start the next cycle.</p>
<p>Surprisingly, it was found out that standard mobile phone battery packs
are optimal for power supplies, as these can be easily replaced by
untrained staff (such as bear hunters) under harsh environmental
conditions, and even can be charged in the research station with
standard equipment. However, some other problems such as cable bites by
polar foxes or ice bears sitting on the sensor carriers could not be
solved so far.</p>
</div>
<div class="section" id="agl">
<h3>AGL</h3>
<p>In the next talk, Walt Miner gave an insight into the Automotive Grade
Linux project of the Linux Foundation. Unfortunately, the talk was very
high level and didn't go into much technical details. The main message
was to encourage the automotive community for more collaboration.</p>
</div>
<div class="section" id="r4d">
<h3>r4d</h3>
<p>During the last slot before lunch, Anna-Maria Gleixner and Manuel Traut
reported about their experiences with Jenkins and libvirt to automate
their testlab for the Preempt RT testing. It turned out that many of
their requirements are quite similar to our own (which motivated us to
develop labgrid).</p>
<p>Unfortunately, it seems like test automation is currently a hot topic,
and everyone looks around, doesn't find a project that fits his need and
starts a new one.</p>
</div>
<div class="section" id="farming-bof">
<h3>Farming BoF</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x400" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-farming.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-farming.thumb.85e5a4b09246187ba25ef2a4afd033b8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>This impression continued during Andrew Murray's BoF session "Farming
Together": many of the attendees operate a test farm, but almost nobody
uses the same technology. Agreement can be achieved in the upper parts
of the stack: people use Jenkins and LAVA there (we do that as well, for
automatic builds and for our kernelci.org testlab).</p>
<p>Tim Bird encouraged the crowd to create a mailing list and a wiki page,
which was created during the BoF session on <a class="reference external" href="https://elinux.org/Board_Farm">elinux.org</a>. On that page, contact data of
interested people will be collected.</p>
</div>
<div class="section" id="kernel-process">
<h3>Kernel Process</h3>
<p>The "Bash the Kernel Maintainers" BoF by Laurent Pinchart dealt with the
well known problem to get kernel maintainers into accepting certain
patches. One problem is that, even small contributions, sometimes fall
into some kind of "black hole" and nobody answers any more. People only
recognise after months that the path got lost. In many cases, it is
especially a problem for small consulting companies, who might have
moved on to other topics or even don't have the respective hardware any
more when feedback finally arrives. Hans Verkuil proposed to talk about
this kind of issues openly on the mailinglists; maintainers might be
more responsive if they know those issues.</p>
<p>The conclusion of the session was: ping politely, and continue talking
to the maintainers.</p>
</div>
<div class="section" id="labgrid">
<h3>labgrid</h3>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2952x4428" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-labgrid1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-labgrid1.thumb.8d911424d6b5fd44f24fe64e9976d2e0.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Another highlight for the Pengutronix team was Jan Lübbe's talk about
"Automation beyond Testing and Embedded System Validation". The
background of those activities is that Pengutronix quite often
integrates many (constantly changing) Open Source components for
customer projects. As updating and rollout of updates doesn't work
without intensive testing, it seems to be time for more automation in
that area. However, it was an important criterium to use the same remote
control technology for automatic tests as well as for interactive work
at the developer's desks, as many of the embedded targets are only
available in small prototype quantities.</p>
<p>Other features which could not be fulfilled with the existing frameworks
are testing of updates (including booting of devices during the test) or
concurrently remote-controlling more than one device (i.e. video
streaming box + receiver). Jan gave a shot overview about the currently
existing test frameworks and explained why they didn't turn out to be a
solution for our requirements.</p>
<p>labgrid provides a python based infrastructure. Remote control devices
such as power switches or USB serial converters are abstracted as
drivers. An important feature are the "strategies": they can be used to
instruct the system to bring the device-under-test into a certain state
(i.e. the Linux userspace commandline). If necessary, the system is
automatically booted or provisioned with new firmware behind the scenes.
The tests themselfs are written in pytest, the output is generated as
JUnit XML files and can for example be visualized in Jenkins.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="600x400" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-labgrid2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_elce-day-one/2017-10-23_elce-2017-day-one-labgrid2.thumb.2845edc933a1538918aef96631c6335d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>For labs which consist of more than one PC, the labgrid concentrator
does the coordination of the available resources.</p>
<p>Besides the test functionality, labgrid can also be used in production
lines, to put the firmware into the devices and do the production tests.</p>
<p>At the end of the talk, he showed a demo and automated the upgrading of
a qemu based simulated hardware with the help of RAUC.</p>
</div>
</div>
<p>This is my report from the first day of Embedded Linux Conference Europe
(ELC-E) 2017 in Prague.</p>2017-10-23T15:08:00+01:00tag:www.pengutronix.de,2017-10-23:/2017-10-23-usb-sd-mux_Intro.htmlUSB-SD-Mux: Automated SD-Card Juggler2017-10-23T09:00:00+01:00Chris Fiege<div class="section" id="usb-sd-mux-automated-sd-card-juggler">
<div class="alert alert-danger" role="alert">
USB-SD-Mux devices are now available in the
<a href="https://shop.linux-automation.com">Linux Automation GmbH Shop </a>.
</div><p>Once the bootloader on your embedded device is up and running the development
of kernel and userland in PTXdist-based BSPs is usually based on booting
from network. Thus there is no need for the developer to write the boot
media with a new image.</p>
<p>But if you want to introduce automated testing of whole BSPs on a
target you need a way to re-write the boot media with the latest
image from continuous integration.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1425x1203" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_usb-sd-mux/2017-10-23_usbsdmux_1.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_usb-sd-mux/2017-10-23_usbsdmux_1.thumb.df295d29121714b7e75822d011c755eb.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 299px;
"><p>USB-SD-Mux: Front</p>
</figcaption>
</figure>
</div><div class="section" id="introducing-the-usb-sd-mux">
<h3>Introducing the USB-SD-Mux</h3>
<p>For systems with SD- or Micro-SD-Card slot an USB-SD-Mux can help you with this job.
The USB-SD-Mux has the following interfaces:</p>
<ul class="simple">
<li><strong>Micro-SD-Card slot</strong>: This slot contains the media you want to use
with your target. You can use your off the shelf Micro-SD-Card here
or use your top-notch low-voltage high-speed card - what ever fits
your target.</li>
<li><strong>Micro-SD-Card shape</strong>: This part of the PCB mimics the shape of a
Micro-SD-Card and can be inserted into Micro-SD-slots on most targets.</li>
<li><strong>USB-Interface</strong>: The USB-Connection is used to power the device and
to expose the USB-SD-Mux to your automation server. This
interface is used to control the USB-SD-Mux and to access the
Micro-SD-Card via the integrated card reader.</li>
</ul>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1359x1143" href="https://www.pengutronix.de/media/blog/2017/2017-10-23_usb-sd-mux/2017-10-23_usbsdmux_2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-23_usb-sd-mux/2017-10-23_usbsdmux_2.thumb.4035624379e551619b277e5e3eb84476.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 299px;
"><p>USB-SD-Mux: Back</p>
</figcaption>
</figure>
</div><p>The key feature of the USB-SD-Mux is the ability to switch the Micro-SD-Card
between the target and the test server. This makes it possible to use
sequences like the following:</p>
<ul class="simple">
<li>Switch the Micro-SD-Card to the integrated card reader and thus
make it accessible to your test server.</li>
<li>Write your image to the Micro-SD-Card.</li>
<li>Switch the Micro-SD-Card over to the target.</li>
<li>Power up your target and boot from Micro-SD-Card.</li>
</ul>
</div>
<div class="section" id="using-the-usb-sd-mux">
<h3>Using the USB-SD-Mux</h3>
<p>Once connected to your test server the USB-SD-Mux will be
detected as an off the shelf card reader:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>cfi@klee:~$ dmesg -w
[ 4097.117229] usb 1-4: new high-speed USB device number 9 using xhci_hcd
[ 4097.257372] usb 1-4: New USB device found, idVendor=0424, idProduct=2640
[ 4097.257381] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4097.258324] hub 1-4:1.0: USB hub found
[ 4097.258354] hub 1-4:1.0: 1 port detected
[ 4097.545236] usb 1-4.1: new high-speed USB device number 10 using xhci_hcd
[ 4097.701956] usb 1-4.1: New USB device found, idVendor=0424, idProduct=4041
[ 4097.701970] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4097.701974] usb 1-4.1: Product: usb-sd-mux_rev2.0
[ 4097.701978] usb 1-4.1: Manufacturer: Pengutronix
[ 4097.701981] usb 1-4.1: SerialNumber: 000000000101
[ 4097.720825] usb-storage 1-4.1:1.0: USB Mass Storage device detected
[ 4097.720864] scsi host6: usb-storage 1-4.1:1.0
[ 4097.720970] usbcore: registered new interface driver usb-storage
[ 4097.721880] usbcore: registered new interface driver uas
[ 4098.742245] scsi 6:0:0:0: Direct-Access PTX sdmux HS-SD/MMC 2.09 PQ: 0 ANSI: 0
[ 4098.742963] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 4098.744841] sd 6:0:0:0: [sdb] Attached SCSI removable disk
</pre></div>
</div><p>Every USB-SD-Mux is identified by a unique SerialNumber at USB-level.
This makes it possible to use several USB-SD-Mux on a test server and keep them apart:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>cfi@klee:~$ ls /dev/usb-sd-mux/
id-000000000101
</pre></div>
</div><p>On a high-level perspective the USB-SD-Mux is controlled via a piece of Python
software. This software is available at
<a class="reference external" href="https://github.com/pengutronix/usbsdmux">GitHub</a>.
Using this software you can simply switch the destination of your
Micro-SD-Card:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>cfi@klee:~$ usbsdmux --help
usage: usbsdmux [-h] sg {dut,host,off,client}
positional arguments:
sg /dev/sg* to use
{dut,host,off,client}
mode to switch to. Can be {off, DUT, host}
optional arguments:
-h, --help show this help message and exit
</pre></div>
</div><p>For example using DistroKit to build a BSP for a BeagleBoneBlack and deploying it using
the USB-SD-Mux can look like:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>cfi@klee:~/DistroKit$ ptxdist images
cfi@klee:~/DistroKit$ sudo usbsdmux /dev/usb-sd-mux/id-000000000101 host
cfi@klee:~/DistroKit$ dd if=platform-v7a/images/beaglebone.hdimg of=/dev/sdb bs=4M
cfi@klee:~/DistroKit$ sudo usbsdmux /dev/usb-sd-mux/id-000000000101 dut
cfi@klee:~/DistroKit$ # Powercycle your target
</pre></div>
</div></div>
<div class="section" id="low-level-features">
<h3>Low-Level Features</h3>
<div class="section" id="target-voltage">
<h4>Target Voltage</h4>
<p>The USB-SD-Mux uses a high speed analog switch to connect the
Micro-SD-Card to either of the targets.
Such devices are designed to operate just inside their supply voltage range.</p>
<p>The USB-SD-Mux is internally powered with 3.3V.
This limits the usable voltage range of the target SD-Card-supply
to 0 .. 3.5V.
On the bright side: The SD-Card interface is only specified up to
3.3V so this should fit most needs.
And you are able to use low-voltage Micro-SD-Cards with - for
example - 1.8V.</p>
</div>
<div class="section" id="break-before-make-switching">
<h4>Break-Before-Make Switching</h4>
<p>The control software uses, what the hardware guys would call,
break-before-make switching.
This means that the Micro-SD-Card is disconnected from the
previous endpoint before connecting it to the next endpoint.
The sequence is timed in a way that powers off the Micro-SD-Card
before re-connecting it.
A complete power-off makes sure the Micro-SD-Card is reset properly.</p>
</div>
<div class="section" id="customize-usb-representation">
<h4>Customize USB-Representation</h4>
<p>The Product-, Manufacturer- and Serialnumber-Strings reported via USB
can be customized to your needs:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>cfi@klee:~$ usbsdmux-configure --help
usage: usbsdmux-configure [-h] [--productString PRODUCTSTRING]
[--manufacturerString MANUFACTURERSTRING]
[--VID VID] [--ScsiManufacturer SCSIMANUFACTURER]
[--ScsiProduct SCSIPRODUCT] [--PID PID]
sg serial
This tool writes and verifies the configuration EEPROM of the usb-sd-mux with
the information given on the command line.
positional arguments:
sg The /dev/sg* to use
serial Serial-Number to write. Should be unique.
optional arguments:
-h, --help show this help message and exit
--productString PRODUCTSTRING
Product-Name to write.
--manufacturerString MANUFACTURERSTRING
Manufacturer-Name to write.
--VID VID USB Vendor ID
--ScsiManufacturer SCSIMANUFACTURER
Value for the SCSI Manufacturer to write
--ScsiProduct SCSIPRODUCT
Value für the SCSI Product Name to write
--PID PID USB Product ID
</pre></div>
</div></div>
</div>
</div><p>Once the bootloader on your embedded device is up and running the development
of kernel and userland in PTXdist-based BSPs is usually based on booting
from network. Thus there is no need for the developer to write the boot
media with a new image.</p>2017-10-23T09:00:00+01:00tag:www.pengutronix.de,2017-10-22:/2017-10-22-all_systems_go.htmlAll Systems Go 2017: Updating Embedded Systems2017-10-22T00:00:00+01:00Robert Schwebel<div class="section" id="all-systems-go-2017-updating-embedded-systems">
<p>At the <a class="reference external" href="https://all-systems-go.io">All Systems Go</a> conference in
Berlin, Michael Obrich reported at 2017-10-22 about "Updating Embedded
Systems - Putting it all together", based on the experiences of the
Pengutronix integration team.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1281x719" href="https://www.pengutronix.de/media/blog/2017/2017-10-22_all-systems-go/2017-10-22_all_systems_go.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-22_all-systems-go/2017-10-22_all_systems_go.thumb.9a2cb6c91002e3ded8810222f3f2e976.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p><a class="reference external" href="https://media.ccc.de/v/ASG2017-133-updating_embedded_systems_--_putting_it_all_together#video&t=12">Video of the talk at media.ccc.de</a></p>
</figcaption>
</figure>
</div><p>While some years ago embedded systems have almost never been updated,
the recent IoT security incidents started to make the device
manufacturers think about how to bring new software to their embedded
devices. Many Linux systems implement an "A/B" scheme, consisting of two
system software slots. One is currently running and an update is written
to the currently-unused slot. This mechanism can be implemented in an
"atomar" way, so even a failure in the update process cannot brick the
system.</p>
<p>Besides writing the actual update (being more or less generic), there is
another important task: the functionality of the updated system needs to
be checked against possible errors. In case something went wrong,
interactive devices have the possibility to show a related message on
the screen, giving the user the option to switch back to the old
software. The same concept works for non-interactive systems which are
controlled by a rollout server. Completely unattended systems are a more
difficult case: there is the possibility to use the watchdog to
supervise the startup procedure; after the kernel has booted, <a class="reference external" href="https://www.freedesktop.org/wiki/Software/systemd/">systemd</a> can be used as
the watchdog handler. While in normal desktop usecases systemd falls
back to a shell in case of an error, non-interactive embedded usecases
need to take additional effort to supervise its applications correctly:</p>
<ul class="simple">
<li>The system can try to boot a 2nd time in case of an error, counting
the boot attempts in the bootloader (i.e. <a class="reference external" href="http://www.barebox.org">barebox</a>). When the reboot counter reaches a limit,
the system can do an automatic fallback to the old version.</li>
<li>In case of transient errors, this mechanism can run in a loop.</li>
<li>For more safety critical systems, the device can be brought into a
safe state and shutdown in case of an error.</li>
</ul>
<p>Usually the exact setup is highly project specific.</p>
<p>The infrastructure for writing updates and taking care of the software
slots is often implemented with <a class="reference external" href="http://www.rauc.io">RAUC</a> in our
projects; RAUC is a sophisticated tool that can check cryptographical
signatures or update the boot slots while transferring minimal data by
using the new <a class="reference external" href="https://github.com/systemd/casync">casync</a> mechanism.</p>
</div>
<p>At the <a class="reference external" href="https://all-systems-go.io">All Systems Go</a> conference in
Berlin, Michael Obrich reported at 2017-10-22 about "Updating Embedded
Systems - Putting it all together", based on the experiences of the
Pengutronix integration team.</p>2017-10-22T00:00:00+01:00tag:www.pengutronix.de,2017-10-21:/2017-10-21-all_systems_go.htmlTalk at All Systems Go 2017 Conference2017-10-21T00:00:00+01:00Robert Schwebel<div class="section" id="talk-at-all-systems-go-2017-conference">
<p>Before the ELC-E conference starts in Prague, Berlin hosts the <a class="reference external" href="https://all-systems-go.io">All
Systems Go</a> conference, the successor of
the systemd conference. In times of increasing IT security incidents
with IoT devices, updating such systems in a secure and reliable way
becomes more and more important. Michael Olbrich's talk outlines the
challenges and possible solutions for a robust update process.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="300x200" href="https://www.pengutronix.de/media/blog/2017/2017-10-21_all-systems-go/2017-10-21_all_systems_go.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-21_all-systems-go/2017-10-21_all_systems_go.thumb.0bbd2c4d8bc5157e9fe4144f347fa170.png"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><p>Common system update patterns from the IT world can not be simply
transferred to IoT devices, which usually don't have an administrator
and thus need to have absolutely relyable mechanisms for unattended
updates.</p>
<p>Our modern update concepts use many open source components, such as
<a class="reference external" href="http://www.barebox.org">barebox</a>, <a class="reference external" href="https://www.freedesktop.org/wiki/Software/systemd/">systemd</a>, <a class="reference external" href="http://www.rauc.io">RAUC</a> and <a class="reference external" href="https://github.com/systemd/casync">casync</a>.</p>
<p>More about the talk can be found in the <a class="reference external" href="https://cfp.all-systems-go.io/en/ASG2017/public/events/133">conference schedule</a>. Usually,
there is a live stream at <a class="reference external" href="https://media.ccc.de/b/conferences">media.ccc.de</a>.</p>
</div>
<p>Before the ELC-E conference starts in Prague, Berlin hosts the <a class="reference external" href="https://all-systems-go.io">All
Systems Go</a> conference, the successor of
the systemd conference. In times of increasing IT security incidents
with IoT devices, updating such systems in a secure and reliable way
becomes more and more important. Michael Olbrich's talk outlines the
challenges and possible solutions for a robust update process.</p>2017-10-21T00:00:00+01:00tag:www.pengutronix.de,2017-10-20:/2017-10-20-elce_talks.htmlPengutronix Talks at ELC-E in Prague2017-10-20T00:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-talks-at-elc-e-in-prague">
<p>The autumn conference highlight is the Embedded Linux Conference Europe
(ELC-E), which takes place in Prague this year. The Pengutronix team
will be present with four talks and two demo points / showcases,
presenting current open source projects (RAUC, labgrid, etnaviv).</p>
<div class="ps-gallery single-image center" itemscope="" itemtype="http://schema.org/ImageGallery" style="
width: 100%;
text-align: center;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="2578x1910" href="https://www.pengutronix.de/media/blog/2017/2017-10-20_elce-talks/2017-10-20_elce_talks.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-20_elce-talks/2017-10-20_elce_talks.thumb.db0cdff9dc3b14f6741423ec75be8a9d.png"/>
</a><figcaption itemprop="caption description" style="
"></figcaption>
</figure>
</div><p>Two talks will take place on monday, 2017-10-23:</p>
<ul class="simple">
<li><strong>OP-TEE: Using Trust Zone to Protect Your Own Secrets:</strong> At 09:00,
Marc Kleine-Budde talks about OP-TEE: since Linux 4.12, the
infrastructure to use the Trusted Execution Environment on modern ARM
cpus was merged into the mainline kernel. Marc shows how it can be
used to store secret information in a (probably) secure way.</li>
<li><strong>Automation Beyond Testing and Embedded Systems Validation:</strong> At
17:10, Jan Lübbe talks about the recent progress with automation
in continuous testing setups and about the labgrid framework.</li>
</ul>
<p>Another two takls will take place on wednesday, 2017-10-25:</p>
<ul class="simple">
<li><strong>Stable Device Tree ABI: It's Possible:</strong> At 14:15, Lucas Stach talks
about strategies for ABI stability of the open firmware device tree.</li>
<li><strong>Zerocopy Video Streaming the Easy Way:</strong> Finally, at 16:15,
Philipp Zabel and Michael Tretter talk about how to use zerocopy
mechanisms to avoid bandwith waste when streaming media on modern ARM
cpus.</li>
</ul>
<p>In addition, several open source projects relevant for us will be shown
as part of the Technical Showcase on tuesday, 2017-10-24:</p>
<ul class="simple">
<li>Etnaviv, the open source drivers for the i.MX6 3D graphics hardware</li>
<li>RAUC: Robust Auto Upgrade Controller</li>
<li>labgrid: test automation for continuous testing of embedded linux
systems</li>
</ul>
</div>
<p>The autumn conference highlight is the Embedded Linux Conference Europe
(ELC-E), which takes place in Prague this year. The Pengutronix team
will be present with four talks and two demo points / showcases,
presenting current open source projects (RAUC, labgrid, etnaviv).</p>2017-10-20T00:00:00+01:00tag:www.pengutronix.de,2017-10-10:/2017-10-10-rauc_documentation_update.htmlComprehensive RAUC Documentation Update2017-10-10T00:00:00+01:00Enrico Jörns<div class="section" id="comprehensive-rauc-documentation-update">
<p>As in many projects, also in RAUC phases of extensive development did
often not leave sufficient time to explain the latest changes, new features or
at least some basic concepts in an appropriate manner.</p>
<div class="ptx-sidebar">
<div class="title">
Statistics
<div class="corner"></div>
</div>
<div class="body">
<table border="1" class="docutils">
<colgroup>
<col width="45%"/>
<col width="26%"/>
<col width="29%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head"> </th>
<th class="head">before</th>
<th class="head">after</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>lines</td>
<td>2135</td>
<td>3522</td>
</tr>
<tr><td>words</td>
<td>9275</td>
<td>16805</td>
</tr>
<tr><td>characters</td>
<td>66991</td>
<td>119992</td>
</tr>
</tbody>
</table>
<p><a class="reference external" href="https://rauc.readthedocs.io">https://rauc.readthedocs.io</a></p>
</div>
</div>
<p>As a result, not only useful and helpful features simply go by the board.
Also the amount of questions and misunderstanding that might have been
prevented by a good documentation increases over the time.</p>
<p>Therefore, Pengutronix decided to take
the virtual pen and paper in the hand and extend and improve the RAUC
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/">Documentation</a>
in many places.</p>
<p>The result of that work is quite impressive if you look at the quantitative
impact, for example.
Taking the number of characters, the volume of the documentation has increased
by almost 80%.</p>
<p>The structure and content of the introductory chapter, that presents an
overview of fundamental concepts and ideas behind RAUC to the user
has been completely redesigned and complemented by many aspects.
In addition, some complex topics were accompanied with vivid graphics.</p>
<p>With the newly created chapter
<a class="reference external" href="http://rauc.readthedocs.io/en/latest/scenarios.html">Scenarios</a>
some of the most common redundancy setups are discussed while
configuration examples point out how to implement them with RAUC.</p>
<p>The important chapters on integration of Barebox and U-Boot were extended by
technically more detailed instructions.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="1715x1091" href="https://www.pengutronix.de/media/blog/2017/2017-10-10_rauc-documentation-update/2017-10-10_rauc_documentation_update.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-10-10_rauc-documentation-update/2017-10-10_rauc_documentation_update.thumb.ba1a96d20496b63c0d269ed5becdb1d0.png"/>
</a><figcaption itemprop="caption description" style="
width: 350px;
"></figcaption>
</figure>
</div><p>Also, a whole series of additional topics have been added,
such as dealing with security, generation and handling of certificates,
application data handling and migration, bootloader updates, or software
deployment.</p>
<p>But, even if there are robust updating frameworks like RAUC,
building an individually fitting and robust update concept requires much
know-how and accuracy in assembling and configuring the different system
components.
From the selection of the boot loader over the watchdog set up and handling
to the detection of a successfully booted user space various components must
closely engage with each other.</p>
<p>With the newly introduced
<a class="reference external" href="http://rauc.readthedocs.io/en/latest/checklist.html">Design Checklist</a>
we have therefore developed a basic pamphlet, which (without claim
on completeness) covers many general cases and possible pitfalls in the design
and the implementation of update concepts.</p>
</div>
<p>As in many projects, also in RAUC phases of extensive development did
often not leave sufficient time to explain the latest changes, new features or
at least some basic concepts in an appropriate manner.</p>2017-10-10T00:00:00+01:00tag:www.pengutronix.de,2017-09-29:/2017-09-29-ptx_ypp.htmlPengutronix Becomes Yocto Project Participant2017-09-29T00:00:00+01:00Enrico Jörns<div class="section" id="pengutronix-becomes-yocto-project-participant">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="700x600" href="https://www.pengutronix.de/media/blog/2017/2017-09-29_pengutronix-becomes-yocto-project-participant/Yocto_Project_Badge_Participant_Web_RGB.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-29_pengutronix-becomes-yocto-project-participant/Yocto_Project_Badge_Participant_Web_RGB.thumb.34da0440392bbccdc25250299164ba9e.png"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div><p>Not at least since the Yocto project cannot be thought away from the embedded
world, Pengutronix successfully also uses OpenEmbedded next to PTXdist as a
distribution build tool in various projects for several years.</p>
<p>Since then, we have always been as close as possible to the widely spreaded
community,
either through participation in conferences such as the OEDEM,
various BoFs at the Embedded Linux Conference Europe or through discussion
and contributions on the various mailing lists.</p>
<div class="ps-gallery single-image left" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: left;
margin-right: 1em;
clear: left;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="434x391" href="https://www.pengutronix.de/media/blog/2017/2017-09-29_pengutronix-becomes-yocto-project-participant/2017-09-29_ptx_ypp.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-29_pengutronix-becomes-yocto-project-participant/2017-09-29_ptx_ypp.thumb.201c9f03624d5cafee513a69942a25c5.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 250px;
"></figcaption>
</figure>
</div><p>With <a class="reference external" href="https://github.com/rauc/meta-rauc">meta-rauc</a>,
the Yocto Layer for the Open Source Update Framework <a class="reference external" href="http://rauc.io/">RAUC</a>,
Pengutronix works closely with the community on one of the key components for
modern and secure embedded systems.</p>
<p>We are pleased that now with the official listing as
<a class="reference external" href="https://www.yoctoproject.org/organization/pengutronix">Yocto-Project Participant</a>
our contributions to the Yocto and Embedded community are visibly appreciated.
We take this as a further incentive, to continue improving the reproducibility,
stability and security in the development of embedded Linux system through
robust build tools such as PTXdist or OpenEmbedded.</p>
</div>
<p>Not at least since the Yocto project cannot be thought away from the embedded
world, Pengutronix successfully also uses OpenEmbedded next to PTXdist as a
distribution build tool in various projects for several years.</p>2017-09-29T00:00:00+01:00tag:www.pengutronix.de,2017-09-28:/2017-09-28-etnaviv.htmlEtnaviv now supported in Weston mainline2017-09-28T00:00:00+01:00Lucas Stach<div class="section" id="etnaviv-now-supported-in-weston-mainline">
<p>If you are following the Linux graphics development it should be no news
to you that MESA 17.2 and Weston 3.0 have been released in the last
weeks. While those carry the usual improvements and bugfixes for a lot
of graphics hardware, they are a pretty important milestone for the
Etnaviv project: we finally have fully working Wayland support!</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/dq6AXAMreos"></iframe>
</div>
<p>While Etnaviv, being just another hardware driver within MESA, inherited
all common support code like GBM and the Wayland EGL platform, which got
the compositor side working right with the initial merge, Wayland
applications haven't worked correctly up until now. While they
technically did work already, they were unusable as the window content
was only a scrambled mess. The reason for this is the tiled memory
layout the GPU is using for texturing and rendering. <a class="reference external" href="https://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-swizzling/">This article Gives
a nice in-depth explanation for those interested in the details</a>.</p>
<p>That's actually a very common thing in 3D rendering with all modern GPUs
using this technique. So why didn't things work with Etnaviv? The "old"
protocols for sharing graphics buffers between application and
compositor/server, like DRI2 and wl_drm, did not include any way to
include buffer metadata like the used tiling layout, so all the mature
DRM drivers like Radeon, Nouveau and Intel have a side-channel to share
this information between different processes. Those drivers are
attaching the buffer metadata to the kernel side graphics buffers, which
works well as long as the userspace side and kernel buffers have a
direct 1:1 relationship. Modern graphics uses like Vulkan increasingly
move in a direction where a kernel side buffers are sub-divided into
several userspace buffers. As this means a single kernel buffer can
carry buffers with differing buffer metadata the side-channel starts to
breaks down.</p>
<p>As attaching the buffer metadata to the kernel side buffers seems to
have limited value in a modern graphics stack and would increase the API
between the Etnaviv kernel and userspace driver (which we would have to
support until the end of time due to the Linux kernel no regressions
rule), we decided against adding such a kernel-based solution for
Etnaviv. Instead we decided to piggy-back on the efforts undertaken by
Intel and Collabora to allow sharing the tiling information entirely in
userspace. This is done through so called "modifiers", which are
basically just 64bit enum values. The registry for the available
modifiers is located in the kernel, which makes it possible to use them
not only in the 3D stack, but also on the display side. Ben Widawsky
<a class="reference external" href="https://www.x.org/wiki/Events/XDC2017/Program/#ben_widawsky">talked about how this used for end-to-end compression in the Intel graphics stack at XDC</a>
a few days ago.</p>
<p>So what changed with Weston 3.0 and MESA 17.2?</p>
<p>Weston now implements the zwp_linux_dmabuf protocol in addition to the
wl_drm protocol. This allows to share buffers between the Wayland
application and the compositor using standard dma-buf file descriptors
and push all sorts of metadata describing the buffer content over the
Wayland protocol.</p>
<p>MESA uses this protocol when available to implement the buffer sharing
in the Wayland EGL platform.</p>
<p>Most of the work to enable this in Weston and MESA common code was done
by Collabora's Daniel Stone. Varad Gautam (also at Collabora) added
support for the modifiers at the Gallium interface level. As part of my
job at Pengutronix I helped to review the Gallium changes and added all
the necessary bits to the Etnaviv driver, which makes Etnaviv the first
Gallium driver to support the new way of sharing buffer metadata over
the Wayland protocol.</p>
<p>So those changes combined provide a fully working Wayland stack on the
platforms supported by the Etnaviv driver. And the best thing about
that? All the driver level support is being used unchanged to enable the
<a class="reference external" href="https://www.collabora.com/news-and-blog/blog/2017/06/05/android-nxp-imx6-buffer-modifier-support/">Android graphics stack on top of Etnaviv</a>.</p>
</div>
<p>If you are following the Linux graphics development it should be no news
to you that MESA 17.2 and Weston 3.0 have been released in the last
weeks. While those carry the usual improvements and bugfixes for a lot
of graphics hardware, they are a pretty important milestone for the
Etnaviv project: we finally have fully working Wayland support!</p>2017-09-28T00:00:00+01:00tag:www.pengutronix.de,2017-09-25:/2017-09-25-embedded_recipes.htmlTalk: Long Term Maintenance at Embedded Recpies (Paris)2017-09-25T00:00:00+01:00Robert Schwebel<div class="section" id="talk-long-term-maintenance-at-embedded-recpies-paris">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="150x135" href="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes.thumb.15a098f42b97cf7670c55ef460cac3c4.png"/>
</a><figcaption itemprop="caption description" style="
width: 150px;
"></figcaption>
</figure>
</div><p>While the technical side of building embedded Linux systems is mostly
solved, running such systems connected to the internet over a long time
has its own challenges. At the
<a class="reference external" href="https://embedded-recipes.org/2017/">Embedded Recipes Conference</a>
in Paris, Marc Kleine-Budde will talk about establishing a sustinable
workflow for this usecase tomorrow (2017-09-26).</p>
<div class="section" id="gallery">
<h3>Gallery</h3>
<div class="ps-gallery multi-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_selfie.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_selfie.thumb.f0a1b0dd5745ca198f09019bccff737e.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_wunner_P1010721.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_wunner_P1010721.thumb.a8925e7e85cbb7f841257960acaadf23.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="4608x3456" href="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_wunner_P1010723.JPG" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-25_embedded-recipes/2017-09-25_embedded_recipes_wunner_P1010723.thumb.98796d4ff35894d02e33ba9ffdba74fb.JPG"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"></figcaption>
</figure>
</div><div style="clear: both"></div></div>
<div class="section" id="update-2017-10-13-video">
<h3>Update 2017-10-13: Video</h3>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/whhMnIrALbI"></iframe>
</div>
</div>
</div>
<p>While the technical side of building embedded Linux systems is mostly
solved, running such systems connected to the internet over a long time
has its own challenges. At the
<a class="reference external" href="https://embedded-recipes.org/2017/">Embedded Recipes Conference</a>
in Paris, Marc Kleine-Budde will talk about establishing a sustinable
workflow for this usecase tomorrow (2017-09-26).</p>2017-09-25T00:00:00+01:00tag:www.pengutronix.de,2017-09-04:/2017-09-04-ptxdist_did_you_know.htmlPTXdist: Did you know? Today: Just a reboot2017-09-04T00:00:00+01:00Jürgen Borleis<div class="section" id="ptxdist-did-you-know-today-just-a-reboot">
<p>While the development on an embedded system I need to reboot it quite often.
Doing so I appreciate to keep the required steps as less as possible and be sure
the embedded system uses the recently changed data in a consistent manner.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="299x320" href="https://www.pengutronix.de/media/blog/2017/2017-09-04_ptxdist-did-you-know-just-a-reboot/2017-09-04_more_fun_with_coffee.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-09-04_ptxdist-did-you-know-just-a-reboot/2017-09-04_more_fun_with_coffee.thumb.04912356e430d78f0a2b1aad84e6f9b7.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 299px;
"><p>Kaffee relaxes</p>
</figcaption>
</figure>
</div><p>I never want to be a disk jockey, moving around an SD card, writing it here,
using it there, just to test a litte change in my root filesystem. It needs too
much time and its boring.</p>
<p>That's why I want to run my embedded system via network only. And here "only"
means, it includes the kernel and its devicetree as well.
I presume the bootloader of the embedded system supports the NFS protocol and
also the
<a class="reference external" href="https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/">BootLoaderSpec</a>
(if you are using the bootloader <a class="reference external" href="http://www.barebox.org">barebox</a> you are
already in a nice position). Both features in addition to an NFS service support
the possibility to run the embedded system solely and in a consisten manner via
network. The NFS service possibilities I already discussed
<a class="reference external" href="https://www.pengutronix.de/en/blog/2017-08-21-ptxdist_did_you_know.html">here</a>.</p>
<p>I'm using the bootloader <em>barebox</em> on all of mine embedded systems, so it will
be a prerequisite for this example.</p>
<p>The NFS service must export the BSP subdirectory <tt class="docutils literal"><span class="pre">platform-<name>/root</span></tt>. It is
the root filesystem dedicated for the embedded system and the embedded system
must use a path to this directory from its point of view. The BSP subdirectory
is created when the command <tt class="docutils literal">ptxdist go</tt> has run.</p>
<p>Initially the bootloader <em>barebox</em> must configure its network interface. Its
possible to configure it statically or via DHCP.</p>
<p>To load the Linux kernel and its devicetree via network, I need to define an
additional <em>automount</em> entry in the <em>barebox</em> environment. On my embedded system
I'm using the <tt class="docutils literal">eth0</tt> interface for the network, so my <em>automount</em> entry looks
like that:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox:/ edit /env/init/automount
[...]
mkdir -p /mnt/nfs
automount /mnt/nfs 'ifup eth0 && mount -t nfs ${eth0.serverip}:/<path> /mnt/nfs'
[...]
</pre></div>
</div><p>The <tt class="docutils literal"><path></tt> component is just a placeholder here and it must be replaced by
the path to the NFS export of the BSP's root filesystem directory.</p>
<p>Now the bootloader <em>barebox</em> is already using the network, but the Linux kernel
needs an additional parameter as well to make use of the network and NFS for
its root filesystem. <em>barebox</em> will add this required parameter automatically
if the <em>BootLoaderSpec</em> config file contains the line <tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt>.
More about this detail will follow. That's all to be done at the embedded system.</p>
<p>At the PTXdist side (my development host) its sufficient to enable the entry
<tt class="docutils literal">default bootloader spec entry</tt> in the submenu <tt class="docutils literal">bootloader spec entries</tt> in
the platform configuration. Due to PTXdist does not automatically add the
<tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt> line mentioned above, I have to add it by my own. In
order to, I copy the file <tt class="docutils literal">default.conf</tt> from the path
<tt class="docutils literal">projectroot/loader/entries</tt> in the PTXdist installation directory to my
local BSP into the <tt class="docutils literal">projectroot/loader/entries</tt> directory and add the required
<tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt> line to it. It now should look like this:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>title @TITLE@
version @VERSION@
options @CMDLINE@
linux-appendroot true
linux @KERNEL@
@DEVICETREE@
</pre></div>
</div><p>Now I run the <tt class="docutils literal">ptxdist go</tt> command to create the root filesystem directory on
my local harddisk, start the NFS service (if not already done) and switch on my
embedded system. I can now boot my embedded system simply by typing the command:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox:/ boot /mnt/nfs
</pre></div>
</div><p>Doing so looks like this at my side:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox 2017.09.0 #2 Mon Sep 04 11:55:04 CEST 2017
Board: jb's board
detected i.MX53 revision 2.1
running /env/bin/init...
Hit any key to stop autoboot: 3
barebox:/ boot /mnt/nfs
booting 'PTXdist - jb's board'
blspec: booting PTXdist - jb's board from none
Adding "root=/dev/nfs nfsroot=192.168.23.4:/<path>,v3,tcp ip=dhcp" to Kernel commandline
Loading ARM Linux zImage '/mnt/nfs//boot/zImage'
Loading devicetree from '/mnt/nfs//boot/imx53-board.dtb'
commandline: root=/dev/nfs nfsroot=nfsroot=192.168.23.4:/<path>,v3,tcp ip=dhcp
</pre></div>
</div><p>My embedded system is DHCP configured and thus <em>barebox</em> automatically adds this
method to the kernel command line (<tt class="docutils literal">ip=dhcp</tt>). Here the <path> component
mentioned above appears as well. <em>barebox</em> has extracted this parameter automatically
from the <em>automount</em> entry and appended it in a suitable way to the kernel
command line.</p>
<p>To avoid to re-type the mentioned boot command after each start or reset, I
can configure it as the default:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox:/ nv boot.default=/mnt/nfs
barebox:/ saveenv
</pre></div>
</div><p>As for me, I am already relaxed at work and let the high pressure
do its work in my coffee maker instead...</p>
</div><p>While the development on an embedded system I need to reboot it quite often.
Doing so I appreciate to keep the required steps as less as possible and be sure
the embedded system uses the recently changed data in a consistent manner.</p>2017-09-04T00:00:00+01:00tag:www.pengutronix.de,2017-08-28:/2017-08-28-DistroKit_Intro.htmlDistroKit - A Playground BSP for PTXdist2017-08-28T00:00:00+01:00Robert Schwebel<div class="section" id="distrokit-a-playground-bsp-for-ptxdist">
<p>At Pengutronix we are using PTXdist to automatically integrate many
industrial embedded Linux projects. Some time ago I started <a class="reference external" href="https://git.pengutronix.de/cgit/DistroKit/">DistroKit</a>: This example BSP shall
be able to demonstrate PTXdist features.</p>
<p>For DistroKit, I had these design criteria in mind:</p>
<ul class="simple">
<li><strong>Small BSP, but not opimized for minimum size</strong>: Modern Embedded
Linux systems have enough ressources for a certain set of comfort
features; however, DistroKit leaves out anything that does not qualify
as base features.</li>
<li><strong>Modern Linux Userspace</strong>: DistroKit makes use of glib, D-Bus,
systemd and NetworkManager.</li>
<li><strong>Multi Platform Support</strong>: We support several target devices, such as
<em>Raspberry Pi 1+2</em>, <em>BeagleBone white and black</em>, the <em>RIoT Board</em>,
<em>Udoo Neo</em> and a QEmu supported <em>Versatile Express</em> platform.</li>
</ul>
<p>During this tutorial I'd like to show you, how to set up DistroKit.</p>
<div class="section" id="setting-up-a-development-environment">
<h3>Setting Up a Development Environment</h3>
<p>If you like to start playing with DistroKit, the Versatile Express
supported in QEmu is probably a good target device, as you don't need
any hardware. To build the BSP, a cross compiler toolchain is needed;
although you can build it yourself from the sources, we also provide
OSELAS.Toolchain as debian packages, which can easily be installed with:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~$ sudo echo 'deb http://debian.pengutronix.de/debian/ sid main contrib non-free' > /etc/apt/sources.list.d/pengutronix.sid.list
rsc@leda:~$ sudo apt install oselas.toolchain-2016.06.1-arm-v7a-linux-gnueabihf-gcc-5.4.0-glibc-2.23-binutils-2.26-kernel-4.6-sanitized
</pre></div>
</div><p>Now checkout DistroKit from our git server:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~$ cd git
rsc@leda:~/git$ git clone https://git.pengutronix.de/git/DistroKit
rsc@leda:~/git$ cd DistroKit
rsc@leda:~/git/DistroKit$
</pre></div>
</div><p>To build DistroKit, you need the <a class="reference external" href="http://www.ptxdist.org">PTXdist</a> version
specified in the ptxconfig file:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~/git/DistroKit$ grep PTXCONF_CONFIGFILE_VERSION configs/ptxconfig
PTXCONF_CONFIGFILE_VERSION="2017.07.0"
</pre></div>
</div><p>Ok, in this example, we need ptxdist-2017.07.0, which can be downloaded from
the <a class="reference external" href="http://public.pengutronix.de/software/ptxdist/">PTXdist archive server</a>.
Installing PTXdist is a separate step, which can be done with the usual
configure/make/make install. Make sure that you have the ptxdist command in
your path.</p>
<p>Now everything is prepared to build DistroKit from sources.</p>
</div>
<div class="section" id="building-distrokit">
<h3>Building DistroKit</h3>
<p>To build DistroKit with ptxdist, you need to select a "platform" first. In
ptxdist terminology, a platform is something you need a dedicated compiler for:
in our case, we can start with the ARM v7a platform:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~/git/DistroKit$ ptxdist platform configs/platform-v7a/platformconfig
info: selected platformconfig:
'configs/platform-v7a/platformconfig'
found and using toolchain:
'/opt/OSELAS.Toolchain-2016.06.1/arm-v7a-linux-gnueabihf/gcc-5.4.0-glibc-2.23-binutils-2.26-kernel-4.6-sanitized/bin'
rsc@leda:~/git/DistroKit$
</pre></div>
</div><p>Building a BSP from sources needs some time and CPU ressources,
therefore ptxdist tries do do as many things as possible in parallel if
you run it like this:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~/git/DistroKit$ ptxdist -j --quiet images
started : host-dummy-install-info.get
started : base.get
started : host-system-perl.get
started : cross-dummy-strip.get
finished: host-dummy-install-info.get
finished: base.get
finished: host-system-perl.get
finished: cross-dummy-strip.get
started : usr-rootfs.get
started : cross-pkg-config-wrapper.get
started : blspec-boneblack.get
finished: usr-rootfs.get
finished: cross-pkg-config-wrapper.get
started : gcclibs.get
</pre></div>
</div><p>The "ptxdist images" command instructs ptxdist to build the firmware images for
the selected v7a platform. In order to do so, ptxdist executes many rules that
specify how to fetch, configure and build the involved source packages and does
all necessary steps to build a firmware image.</p>
<p>Once the image has been built, you can start it in QEmu:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>rsc@leda:~/git/DistroKit$ configs/platform-v7a/run barebox
barebox 2017.07.0-20170703-1 #1 Fri Aug 18 13:00:12 CEST 2017
Board: ARM Vexpress
smc911x 4e000000.ethernet: LAN911x identified, idrev: 0x01180001, generation: 1
mdio_bus: miibus0: probed
eth0: got preset MAC address: 52:54:00:12:34:56
cfi_flash 40000000.flash: found cfi flash at 0x40000000, size 64 MiB
cfi_flash 40000000.flash: found cfi flash at 0x44000000, size 64 MiB
Concatenating MTD devices:
(0): "40000000.flash"
(1): "40000000.flash"
into device "nor"
state: New state registered 'state'
netconsole: registered as netconsole-1
mmci-pl18x mmci-pl18x: registered as mmci-pl18x
mci0: detected SD card version 1.0
mci0: registered disk0
malloc space: 0x7bfd7580 -> 0x7ffd757f (size 64 MiB)
found force-builtin environment, using defaultenv
running /env/bin/init...
Hit any key to stop autoboot: 1
</pre></div>
</div><p>And, after Linux has created the SSH keys for the simulated devices:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>ext4 ext40: EXT2 rev 1, inode_size 128, descriptor size 32
blspec: ignoring entry with incompatible devicetree "ti,am335x-bone"
blspec: ignoring entry with incompatible devicetree "raspberrypi,2-model-b"
blspec: ignoring entry with incompatible devicetree "riot,imx6s-riotboard"
blspec: ignoring entry with incompatible devicetree "fsl,imx6q-sabrelite"
blspec: ignoring entry with incompatible devicetree "ti,am335x-bone-black"
blspec: ignoring entry with incompatible devicetree "udoo,neofull"
booting 'PTXdist - Pengutronix-DistroKit'
blspec: booting PTXdist - Pengutronix-DistroKit from mci0
Adding "root=PARTUUID=74823abf-01" to Kernel commandline
Loading ARM Linux zImage '/mnt/disk0.0//boot/zImage'
Loading devicetree from '/mnt/disk0.0//boot/vexpress-v2p-ca9.dtb'
commandline: root=PARTUUID=74823abf-01 loglevel=5 systemd.log_level=warning systemd.show_status=auto rootwait rootfstype=ext4 console=ttyAMA0,115200
[ 0.000000] GIC CPU mask not found - kernel will fail to boot.
[ 0.000000] GIC CPU mask not found - kernel will fail to boot.
[ 0.000000] L2C: platform modifies aux control register: 0x02020000 -> 0x02420000
[ 0.000000] L2C: DT/platform modifies aux control register: 0x02020000 -> 0x02420000
[ 0.000000] smp_twd: clock not found -2
[ 0.004158] Failed to initialize '/smb@4000000/motherboard/iofpga@7,00000000/timer@12000': -22
[ 0.479904] OF: amba_device_add() failed (-19) for /memory-controller@100e0000
[ 0.481207] OF: amba_device_add() failed (-19) for /memory-controller@100e1000
[ 0.481664] OF: amba_device_add() failed (-19) for /watchdog@100e5000
[ 0.506035] OF: amba_device_add() failed (-19) for /smb@4000000/motherboard/iofpga@7,00000000/wdt@f000
[ 0.511195] irq: type mismatch, failed to map hwirq-75 for /interrupt-controller@1e001000!
[ 0.940917] of-flash 48000000.psram: do_map_probe() failed for type map_ram
[ 0.941772] of-flash 48000000.psram: do_map_probe() failed
[ 17.466631] systemd-rc-once[138]: remounting root rw...done
[ 17.577853] systemd-rc-once[138]: running rc.once.d services...
[ 18.917195] systemd-rc-once[138]: Creating dynamic linker cache...
[ 25.394839] systemd-rc-once[138]: Creating ED25519 key; this may take some time ...
[ 26.306195] systemd-rc-once[138]: Creating ED25519 key; done.
[ 26.388585] systemd-rc-once[138]: Creating RSA key; this may take some time ...
[ 107.122933] systemd-rc-once[138]: Creating RSA key; done.
[ 110.396604] systemd-rc-once[138]: remounting root ro...done
____ _ _
| _ ` ___ _ __ __ _ _ _| |_ _ __ ___ _ __ (_)_ __
| |_) / _ ` '_ ` / _` | | | | __| '__/ _ `| '_ `| ` `/ /
| __/ __/ | | | (_| | |_| | |_| | | (_) | | | | |> <
|_| `___|_| |_|`__, |`__,_|`__|_| `___/|_| |_|_/_/`_`
|___/
____ _ _ _ ___ _
| _ `(_)___| |_ _ __ ___ | |/ (_) |_
| | | | / __| __| '__/ _ `| ' /| | __|
| |_| | `__ ` |_| | | (_) | . `| | |_
|____/|_|___/`__|_| `___/|_|`_`_|`__|
OSELAS(R)-DistroKit-0000.00.0-00260-g838ea9d300c8 / v7a-0000.00.0-00260-g838ea9d300c8
ptxdist-2017.07.0/2017-08-18T13:09:40+0200
DistroKit login:
</pre></div>
</div></div>
</div>
<p>At Pengutronix we are using PTXdist to automatically integrate many
industrial embedded Linux projects. Some time ago I started <a class="reference external" href="https://git.pengutronix.de/cgit/DistroKit/">DistroKit</a>: This example BSP shall
be able to demonstrate PTXdist features.</p>2017-08-28T00:00:00+01:00tag:www.pengutronix.de,2017-08-21:/2017-08-21-ptxdist_did_you_know.htmlPTXdist: Did you know? Today: Beautify your developer's life2017-08-21T00:00:00+01:00Jürgen Borleis<div class="section" id="ptxdist-did-you-know-today-beautify-your-developer-s-life">
<p>Simplify and beautify your developer's life. An example.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="300x362" href="https://www.pengutronix.de/media/blog/2017/2017-08-21_ptxdist-did-you-know/2017-08-21_fun_with_coffee.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-08-21_ptxdist-did-you-know/2017-08-21_fun_with_coffee.thumb.fe2ca291ba514868ff674961871bdf4b.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Coffee changes your life</p>
</figcaption>
</figure>
</div><p>When <a class="reference external" href="http://www.ptxdist.org">PTXdist</a> builds your project, it creates
a subdirectory with the full root-filesystem content which can be
exported via NFS.</p>
<p>This subdirectory can be exported by the regular kernel based NFS daemon or
via the userland based NFS daemon coming with PTXdist.</p>
<p>We recommend the PTXdist based userland NFS daemon, because it uses the PTXdist
generated list of user and permission information for each file in the
root-filesystem. This feature isn't available for the kernel based NFS daemon.</p>
<p>If it is a development requirement to work with valid user and permission
information for each file, there is no alternative to the PTXdist based
userland NFS daemon. Else we will stumble across failures based on wrong
user and permission information finally when we are using the root-filesystem
images PTXdist creates on the target's local storage.</p>
<p>Whatever variant of NFS daemon we use, using a NFS based root-filesystem on
our target system simplifies developer's life by ways.</p>
<p>Whenever we miss a software component, we now can activate it in the PTXdist menu,
just let PTXdist build it and we can use it immediately on the target. There is
no need anymore to copy files to the target, nor to replace full root-filesystem
images. Most of the time even a reboot of the target system can be avoided.</p>
<p>Exceptions like the Linux kernel proves the rule. But even in the case of
Linux kernel driver development, it might be possible to work on a driver module.
It can be unloaded at run-time and the reworked version can be re-loaded. The
reworked version just need to be re-created by PTXdist and will be exported to
the target system like any other file via the NFS daemon.</p>
<p>You might know how painful it is to edit some configuration files with "vi"
locally on the target system. Here is the good news: Thanks to the NFS daemon
you can change these files with your preferred editor locally on your host
instead. The change is immediately "visible" on the target system as well.</p>
<p>An NFS daemon makes your developer's life more beautiful and you won't drink
your coffee in despair anymore, you can enjoy it instead.</p>
</div>
<p>Simplify and beautify your developer's life. An example.</p>2017-08-21T00:00:00+01:00tag:www.pengutronix.de,2017-05-31:/2017-05-31-OSADL-NetworkingDay.htmlOSADL Networking Day 20172017-05-31T00:00:00+01:00Robert Schwebel<div class="section" id="osadl-networking-day-2017">
<p>In the last talk before lunch, my colleague Enrico Jörns talked about the RAUC
(Robust Auto Update Controller) framework.</p>
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="810x608" href="https://www.pengutronix.de/media/blog/2017/2017-05-31_osadl-networkingday/2017-05-31_OSADL-NetworkingDay.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-05-31_osadl-networkingday/2017-05-31_OSADL-NetworkingDay.thumb.38d8ac6939ecf8ac843e6bf958e547b8.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Enrico Jörns talking about RAUC</p>
</figcaption>
</figure>
</div><p>While customers might disagree, the
most important reason for updating is deploying security updates and bugfixes,
not features. Updating should be as robust as possible; unattended updates
should not brick your device. In addition, unauthorized modification should be
avoided. Often people start with a shell script (well, there is never enough
time to develop an update system, right?), but over the time it turned out that
this also often misses a lot of important corner cases regarding NAND handling,
sudden power loss, out-of-memory situations etc. An updating concept always
starts with a controlled environment (i.e. Yocto, PTXdist, Buildroot) and a lot
of (mostly automated) testing of the generated root filesystem. Then you need
to verify identity, both of the device (is it the right image for it?) and of
the update service (is this authorized to update this device?). In order to
achieve atomicity, RAUC makes use of redundancy. A+B scenarios have the
advantage that it is really robust (you can fallback if something goes wrong),
but needs enough space for two systems. One of the design criteria for RAUC was
that it is designed as a framework, so you can use it with many different
bootloaders (Barebox, U-Boot, Grub), media (USB stick, NAND, eMMC, ...). RAUC
contains an update daemon that runs on the device under Linux, plus a D-Bus
connected command line tool to talk to RAUC. Updates are put into bundles
(compressed and mountable squashfs) which are signed with X.509 signatures and
can basically contain anything. Bundles contain things to put into slots (i.e.
rootfs, app-fs, bootloader). Enrico outlined that RAUC also supports different
integrity mechanisms (IMA/EVM, DM-Verity), even those where files are re-hashed
with a key which is only available on the target. Finally, RAUC can be
integrated with the Hawkbit deployment server. For integration, there is
meta-rauc for Yocto, and it is also integrated in PTXdist mainline.</p>
</div>
<p>In the last talk before lunch, my colleague Enrico Jörns talked about the RAUC
(Robust Auto Update Controller) framework.</p>2017-05-31T00:00:00+01:00tag:www.pengutronix.de,2017-05-11:/2017-05-11-RAUC-0.1.1.htmlRAUC v0.1.1 released2017-05-11T00:00:00+01:00Robert Schwebel<div class="section" id="rauc-v0-1-1-released">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Visit <a class="reference external" href="http://rauc.io/pages/download.html">rauc.io</a> to get the latest
version of RAUC</p>
</div>
</div>
<p>RAUC is making progress, and my colleagues Enrico Jörns and Jan Lübbe finally
pushed out a new release today that reflects what happened during the last
months. Updating embedded linux systems in the field in a secure and robust way
becomes more and more important; we had many interesting talks with our
customers during the last time, and some of the new ideas are already finding
their way into the codebase. However, there is still a lot of work ahead, and
if you have more ideas, either drop us a note on the community channels, send
patches or github pull requests, or ask for commercial help!</p>
</div>
<p>RAUC is making progress, and my colleagues Enrico Jörns and Jan Lübbe finally
pushed out a new release today that reflects what happened during the last
months. Updating embedded linux systems in the field in a secure and robust way
becomes more and more important; we had many interesting talks with our
customers during the last time, and some of the new ideas are already finding
their way into the codebase. However, there is still a lot of work ahead, and
if you have more ideas, either drop us a note on the community channels, send
patches or github pull requests, or ask for commercial help!</p>2017-05-11T00:00:00+01:00tag:www.pengutronix.de,2017-05-11:/2017-05-11-labgrid_released.htmllabgrid: Test Automation Framework Released2017-05-11T00:00:00+01:00Robert Schwebel<div class="section" id="labgrid-test-automation-framework-released">
<div class="ptx-sidebar">
<div class="title">
Website
<div class="corner"></div>
</div>
<div class="body">
<p>GitHub:
<a class="reference external" href="https://github.com/labgrid-project/labgrid">github.com/labgrid-project/labgrid</a></p>
<p>Documentation:
<a class="reference external" href="https://labgrid.readthedocs.io/en/latest/">labgrid.readthedocs.io</a></p>
</div>
</div>
<p>At Pengutronix, one of the most important tasks in our industrial linux
projects is testing of embedded systems. While testing is easy on the component
level (there are many unit test frameworks around), it is increasingly
difficult on system level. Tests do not only run code and compare results, they
need to bring the device-under-test into different states (i.e. "bootloader",
"linux console", "power off"). If you have many embedded Linux devices,
remote-controlling power, serial consoles, network, switches, reset lines, SD
cards in scalable, automatic labs is also on the wishlist.</p>
<p>After 6 months of hard work behind the scenes, a team around Jan Lübbe and
Rouven Czerwinski at Pengutronix released labgrid today - our framework to
abstract and automate embedded Linux devices-under-test: labgrid makes it
possible to use pytest for the actual tests, while the whole complexity of
distributed lab automation is hidden from the test developer. While labgrid is
lightweight and runs on the developer PC without much infrastructure, it can
also be integrated with Jenkins, LAVA and similar build&test services.</p>
<p>Please check our github page and the documentation!</p>
</div>
<p>At Pengutronix, one of the most important tasks in our industrial linux
projects is testing of embedded systems. While testing is easy on the component
level (there are many unit test frameworks around), it is increasingly
difficult on system level. Tests do not only run code and compare results, they
need to bring the device-under-test into different states (i.e. "bootloader",
"linux console", "power off"). If you have many embedded Linux devices,
remote-controlling power, serial consoles, network, switches, reset lines, SD
cards in scalable, automatic labs is also on the wishlist.</p>2017-05-11T00:00:00+01:00tag:www.pengutronix.de,2017-03-12:/2017-03-12-CLT-2017.htmlChemnitz Linux Days 20172017-03-12T00:00:00+01:00Robert Schwebel<div class="section" id="chemnitz-linux-days-2017">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="810x540" href="https://www.pengutronix.de/media/blog/2017/2017-03-12_clt-2017/2017-03-12_CLT-2017.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2017/2017-03-12_clt-2017/2017-03-12_CLT-2017.thumb.123428620c24f879b6bec9695ad1cced.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Rouven Czerwinski talking about labgrid</p>
</figcaption>
</figure>
</div><p>In the first talk today, Michael Tretter reports about the current state of
Open Source Graphics for Embedded Systems. For regular observers, it's probably
not surprising that the focus will be on i.MX6, Etnaviv and the IPU.</p>
<p>Next talk at the Chemnitzer Linux-Tage embedded track: Enrico
Jörns reporting about RAUC, the Robust Auto Update Controller.</p>
<p>The last of our sunday morning talks at Chemnitzer Linux-Tage is
now Rouven Czerwinski's talk about continuous integration and testing,
featuring our brand new labgrid project.</p>
</div>
<p>In the first talk today, Michael Tretter reports about the current state of
Open Source Graphics for Embedded Systems. For regular observers, it's probably
not surprising that the focus will be on i.MX6, Etnaviv and the IPU.</p>2017-03-12T00:00:00+01:00tag:www.pengutronix.de,2017-02-19:/2017-02-19-Linux-4.10-PTX-report.htmlPengutronix Contributions to v4.102017-02-19T00:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-contributions-to-v4-10">
<p>Here is a short report about Pengutronix' contributions to the 4.10 kernel. It
mainly contains more improvements for the i.MX6 graphics and video subsystem,
Etnaviv, Marvell Orion and Altera SoCFPGA.</p>
<div class="section" id="memory-subsystem">
<h3>Memory Subsystem</h3>
<ul class="simple">
<li>A bug was fixed that led to performance impact on CMA
memory (lst)</li>
</ul>
</div>
<div class="section" id="etnaviv">
<h3>Etnaviv</h3>
<ul class="simple">
<li>Memory handling was improved for the low IOVA case (lst)</li>
<li>Move GPU linear window for i.MX6SoloX; make FAST_CLEAR
work where possible (lst)</li>
<li>Don't invoke OOM killer for dump code, as it's only a debug
feature (lst)</li>
<li>Return new SG table for prime (lst)</li>
<li>Implement dma-buf mmap (lst)</li>
</ul>
</div>
<div class="section" id="graphics-subsystem">
<h3>Graphics Subsystem</h3>
<ul class="simple">
<li>Add support for AUO G185HAN01 panel (lst)</li>
<li>Add support for AUO G133HAN01 panel (lst)</li>
<li>Add more properties for Innolux G121I1-L1 panel (lst)</li>
<li>Remove a warning for TC358767 analog video digitizer (lst)</li>
<li>IPU DI: silence videomode logspam (lst)</li>
<li>Remove unnecessary double disable check for i.MX LDB (pza)</li>
<li>Make the LDB_DI0 and LDB_DI1 clocks read-only (pza)</li>
<li>Mask mmdc_ch1 handshake for periph2_sel and
mmdc_ch1_axi_podf (pza)</li>
<li>Initially clear all GPU interrupts, preparation for better IPU reset
behaviour in the future (pza)</li>
<li>Merge ipu_plane_atomic_set_base into atomic_update for
IPUv3 (pza)</li>
<li>Request modeset if plane offsets changed on IPUv3 (pza)</li>
<li>Fix LDB clock tree on i.MX6 QuadPlus (lst)</li>
</ul>
</div>
<div class="section" id="video-subsystem">
<h3>Video Subsystem</h3>
<ul class="simple">
<li>Support downsizing to 1/2 width and/or height in the CSI (pza)</li>
<li>Add support for YUV 4:2:2 and 4:4:4, NV12, and NV16 formats
to the IPUv3 (pza)</li>
<li>Add YUV 4:4:4 support to the IPUv3 (pza)</li>
<li>Remove unused ipu_cpmem_set_yuv_planar function for
IPUv3 (pza)</li>
<li>Let drm_plane_state_to_ubo/vbo handle chroma subsampling
other than 4:2:0 on IPUv3 (pza)</li>
</ul>
</div>
<div class="section" id="misc">
<h3>Misc</h3>
<ul class="simple">
<li>Make use of CURDIR, to make the build system more
robust (ukl)</li>
<li>Fix coding style in clock gate code (ukl)</li>
<li>Fix duplicate level interrupts on MXS (sha)</li>
<li>Use enable/disable regs to (un)mask irqs on MXS (sha)</li>
<li>FEC: drop check for clk==NULL before calling clk_* (ukl)</li>
</ul>
</div>
<div class="section" id="marvell-orion">
<h3>Marvell Orion</h3>
<ul class="simple">
<li>Fix documentation for SPI (ukl)</li>
<li>Fix some error paths alloc_nand_ressource() (ukl)</li>
<li>armada-370-rn102: add pinmuxing for i2c0 (ukl)</li>
<li>armada-370-rn102: drop specification of compatible for
i2c0 (ukl)</li>
<li>armada-xp-rn2120: add pinmuxing for ethernet (ukl)</li>
<li>armada-xp-rn2120: drop wrong compatible for i2c0 (ukl)</li>
</ul>
</div>
<div class="section" id="lowpan">
<h3>802.15.4 / 6LoWPAN</h3>
<ul class="simple">
<li>Fix CCA ED values for RF233 (aar)</li>
</ul>
</div>
<div class="section" id="socfpga">
<h3>SoCFPGA</h3>
<ul class="simple">
<li>Add NAND controller nodes (str)</li>
<li>Enable QSPI, add to several oftrees (str)</li>
</ul>
</div>
</div>
<p>Here is a short report about Pengutronix' contributions to the 4.10 kernel. It
mainly contains more improvements for the i.MX6 graphics and video subsystem,
Etnaviv, Marvell Orion and Altera SoCFPGA.</p>2017-02-19T00:00:00+01:00tag:www.pengutronix.de,2016-10-13:/2016-10-13-ELCE-2016.htmlELC Europe 2016, Berlin2016-10-13T00:00:00+01:00Robert Schwebel<div class="section" id="elc-europe-2016-berlin">
<p>At the ELC Europe 2016 in Berlin our colleagues Jan Lübbe and Marc Kleine-Budde
are talking about two interesting and important presentations about Kernel
longterm maintenance strategies and verified boot.</p>
<div class="row"><div class="col-md-12">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="810x599" href="https://www.pengutronix.de/media/blog/2016/2016-10-13_ELCE-2016/2016-10-13_ELCE-2016.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2016/2016-10-13_ELCE-2016/2016-10-13_ELCE-2016.thumb.502f03453c528d0908bb0e8f9033f76d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Jan Lübbe talking about longtermn maintenance</p>
</figcaption>
</figure>
</div><p>Jan Lübbe talking about long term maintenance
strategies of the Linux kernel. For embedded systems, an operation time of more
than 10 years is not too untypical, but what do you do if the system has
connectivity and you need to care about keeping the system stable and secure at
the same time? The mainline kernel has interesting offerings for that, but how
do you establish a working maintenance process around it? Jan's talk should
give you some interesting insights.</p>
<div class="clearfix"></div></div></div><div class="row"><div class="col-md-12">
<div class="ps-gallery single-image right" itemscope="" itemtype="http://schema.org/ImageGallery" style="
float: right;
margin-left: 1em;
clear: right;
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="810x1080" href="https://www.pengutronix.de/media/blog/2016/2016-10-13_ELCE-2016/2016-10-13_ELCE-2016-2.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2016/2016-10-13_ELCE-2016/2016-10-13_ELCE-2016-2.thumb.1ff6e2944628f3406b17677923010058.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>Marc Kleine-Budde talking about verified boot</p>
</figcaption>
</figure>
</div><p>Marc Kleine-Budde talking about verified boot on i.MX6.
The crypto boot topic is keeping us busy for quite some time now, so this is a
good opportunity for a roll up and the state of the union.</p>
<p>For more discussions about the topic, Marc will also be available at the
barebox booth during the booth crawl.</p>
<div class="clearfix"></div></div></div></div>
<p>At the ELC Europe 2016 in Berlin our colleagues Jan Lübbe and Marc Kleine-Budde
are talking about two interesting and important presentations about Kernel
longterm maintenance strategies and verified boot.</p>2016-10-13T00:00:00+01:00tag:www.pengutronix.de,2014-07-11:/2014-07-11-bsp_for_emulated_platforms.htmlFree Linux BSP for ARM/x86 Emulated Platforms2014-07-11T10:00:00+01:00Robert Schwebel<div class="section" id="free-linux-bsp-for-arm-x86-emulated-platforms">
<p>Hildesheim, Germany - Pengutronix offers a new release of its free Board
Support Package for generic and emulated platforms. It provides all
required components to get everything run in a QEMU environment, and is
dedicated for beginners in the embedded world. And for the experienced
user it can act as a quick start for her/his own development as well.</p>
<p>Feature List:</p>
<ul class="simple">
<li>PTXdist based buildsystem for easy setup and build</li>
<li>Recent GCC Toolchain (GCC 4.8.2, libc 2.18)</li>
<li>Kernel: 3.0/3.7.1 Linux</li>
<li>QEMU: Recent 2.0</li>
<li>Comprehensive documentation how to prepare and build all software components
and run the QEMU emulation. It also includes the PTXdist reference manual.</li>
</ul>
</div>
<p>Hildesheim, Germany - Pengutronix offers a new release of its free Board
Support Package for generic and emulated platforms. It provides all
required components to get everything run in a QEMU environment, and is
dedicated for beginners in the embedded world. And for the experienced
user it can act as a quick start for her/his own development as well.</p>2014-07-11T10:00:00+01:00tag:www.pengutronix.de,2014-06-16:/2014-06-16-techweek.htmlPengutronix Techweek 20142014-06-16T10:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-techweek-2014">
<p>During week 25/2016 (2016-06-16 to 2016-06-20) the Pengutronix team
is out-of-office, due to the yearly internal TechWeek event. During that
time, our availability in the Hildesheim office is reduced and we can
only be contacted by e-Mail.</p>
<p>If you are a Pengutronix customer, please send any requests to your
personal project mailing list.</p>
<p>In any other case, please write a mail to <a class="reference external" href="mailto:info@pengutronix.de">info@pengutronix.de</a>.</p>
<p>The TechWeek event is our yearly internal hack event where the whole
Pengutronix team is out at some secret location, working on all those
cool ideas for Embedded-Linux-of-Tomorrow we never have time for during
daytime working hours. If you are interested, you might want to check
our postings on Google+.</p>
</div>
<p>During week 25/2016 (2016-06-16 to 2016-06-20) the Pengutronix team
is out-of-office, due to the yearly internal TechWeek event. During that
time, our availability in the Hildesheim office is reduced and we can
only be contacted by e-Mail.</p>2014-06-16T10:00:00+01:00tag:www.pengutronix.de,2014-03-07:/2014-03-07-barebox.htmlBarebox-2014.03.02014-03-07T10:00:00+01:00Robert Schwebel<div class="section" id="barebox-2014-03-0">
<p>The Barebox project has released version 2014.03.0 of its bootloader:</p>
<p>New or updated Barebox features are:</p>
<ul class="simple">
<li>The i.MX25 and i.MX27 processors got support for initializing from
devicetree now. For the other i.MX boards supported in Barebox, the
devicetrees have been updated.</li>
<li>Initial support for the MIPS Loongson architecture has been added.</li>
<li>The UBIFS implementation is now able to read links.</li>
<li>We can now automatically construct a console= parameter for the
kernel, by reading the necessary information from the oftree.</li>
<li>Several bugs have been fixed, i.e. for eMMC, SoC type detection for
i.MX6, PFD clock gating, the ASIX AX88772B USB network card, NAND chip
handing and SD cards on MX25.</li>
<li>A new driver for the National Semiconductor DP83865 PHY has been
added, and the Freescale MCIMX53-START-R is now supported and the
support for Tegra20 was improved.</li>
<li>The environment for the sandbox has been updated.</li>
</ul>
<p>All in all, Barebox makes good progress. We see more and more community
people working with it in the meantime.</p>
</div>
<p>The Barebox project has released version 2014.03.0 of its bootloader:</p>2014-03-07T10:00:00+01:00tag:www.pengutronix.de,2014-02-04:/2014-02-04-barebox.htmlBarebox-2014.02.02014-02-04T10:00:00+01:00Jürgen Borleis<div class="section" id="barebox-2014-02-0">
<p>The Barebox project has released version 2014.02.0 of its bootloader:</p>
<p>New or updated Barebox features are:</p>
<ul class="simple">
<li>many bug fixes and improvements all over the code</li>
<li>support for the OpenCores 10/100 Mbps ethernet MAC was added</li>
<li>the IPU framebuffer driver (i.MX35) was improved and now supports clock
calculation with low jitter. This enables the usage of external LVDS
connected LC displays</li>
<li>the memory management was changed and Barebox now finds a location where to
store the ATAGS for the kernel parameters by its own in a generic way.
All platforms now make use of it, so the platform specific code shrinks
once more a little bit, due to the armlinux_set_bootparams() function is
gone now.</li>
</ul>
</div>
<p>The Barebox project has released version 2014.02.0 of its bootloader:</p>2014-02-04T10:00:00+01:00tag:www.pengutronix.de,2014-01-26:/2014-01-26-linux_3.13.htmlPengutronix' Activities in Linux 3.132014-01-26T10:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-activities-in-linux-3-13">
<p>During our embedded linux projects, the kernel engineers at Pengutronix
do a lot of improvements which end up in the mainline kernel. Here's a
short story about what went into the recently released 3.13:</p>
<p>SocketCAN maintainer Marc Kleine-Budde fixed a memory leak in the
peak_usb driver. He found out that the flexcan driver used the wrong
clock on MX5, which resulted in wrongly calculated bit rates. In the
c_can driver, he fixed a "scheduling while atomic" bug. Other janitorial
work has been done to the ti_hecc CAN driver and the CAN core.</p>
<p>Philipp Zabel works on graphics tasks on MX5 and MX6, both related ot
the DRM driver and to the Video parts. He submitted a patch to the v4l2
subsystem which makes it possible to map DMABUF buffers with write
permission. A spec violation regarding the setting of the pixel format
and with invalid pixel formats for v4l2 has been fixed. He also
implemented try_decoder_cmd to let userspace determine available
commands and flags. For the CODA video encoder/decoder found on
i.MX27/53/6, debugging was improved. The picture type reported by the
CODA unit is now properly propagated into the software framework, and
the driver does now correctly detect different CODA hardware types. The
compressed flag is now fixed in output buffers and the buffer handling
in case of a stream-off is improved. On CODA7541, the video
encoder/decoder component in MX5 and MX6, the driver is now able to
handle more than 4 concurrent accesses. In the v4l2 driver core, Philipp
added patches which improve DMABUF and user pointer handling. For the
i.MX DRM driver which is currently in staging, Philipp added support to
make use of the PRIME functionality introduced by the "drm: GEM CMA: Add
DRM PRIME support" patch and added DRM plane support. He removed the old
ipu_framebuffer data structure from the kernel and added suport for the
BGR888 graphics format to the IPU driver and its display controller and
for the BGR565 format. In order to support small displays on MX6, he
improved the end of line handling. As the IPU is used both on the
display output and video input side, he improved the handling of
drm_fourcc format description.</p>
<p>Michael Grzeschik fixed a bug in the USB gadget subsystem for composite
drivers, which happened when an USB device got unplugged while still
being used. Michael is working on improving the ci13xxx USB controller
driver, which had a lot of issues recently. A lot more patches are
currently pending for this controller.</p>
<p>During the 3.13 cycle, Uwe Kleine-König mainlined the EFM32 Cortex-M3
processor platform. During this work, EFM32 got DEBUG_LL functionality
and proper timekeeping, and a bug with GPIO bitbanging was fixed. Uwe
started to package the CAN utilities for debian. As a preparation, he
went through the CAN files in mainline and improved the copyrights in
the headers. Uwe also fixed some issues in the fsl-dspi driver. Uwe
helped the transition to clockevents_config_and_register function, which
had to be reverted for AT91RM9200 some time ago. At that time, a
rounding problem let this driver fail, due to the bug in the driver
core; the mechanism was also added for the DaVinci processor family.
Other janitorial work has been done in the CSR SiRF watchdog driver.</p>
<p>Markus Pargmann hunted several audio issues this time. One of them was
caused by locking issues in the mxs-dma driver for MX28. A patch hit
mainline which fixes the locking in this driver. A second bug in this
driver happened after a channel reset. Now that the issue is fixed, the
state is set correctly after a reset occured. The channel reset does
also seem to have a hardware issue: when being in READ_FLUSH state, the
dma controller could stop working. A fix was added to the kernel to
avoid this situation. Another patch fixes the correct residuum reporting
for cyclic DMA; the DMA interrupt handler so far formerly handled all
available channel interrupts it could finde; now the interrupt handling
was fixed to handle only the relevant channels. On AM335x, Markus fixed
an error with rx handling in the c_can driver and improved the IRQ
register checking. The w1-gpio driver was changed to use devm_*
functions. While doing so, the error handling for this driver was
improved. All in all, the mainline situation improves slow but
constantly for AM335x. For i.MX27, Markus added the pincontrol driver,
with a core driver to access registers on MX1/21/27. On MX28, Markus
fixed the error handling of the serial audio interface (SAIF) and
improved the consumption of trigger commands and its state handling.</p>
<p>Steffen Trumtrar mainly worked on mainline support for the SoCFPGA FPGA
plus ARM-SOC made by Altera. He improved the clock management and
improved the devicetrees: an important part of this work was to
distribute the right devicetree nodes to the different dtsi files. He
added support for the Terasic SoCkit board, a whitespread development
kit for the SoCFPGA. Additionally, he fixed a bug to handle PWM
correctly when being initialized from oftree. He also worked on the
MC13783 power controller and added more infrastructure (i.e. routes,
muxes, switches) and more mixer controls to the audio part to the
mc13783.</p>
<p>Jan Lübbe added support for oftree initialisation to the AT25 SPI EEPROM
driver.</p>
<p>Sascha Hauer fixed the event clearing in the i.MX6 DRM driver for the
rare case when a userspace program exits exactly during a page flip.</p>
<p>Jürgen Beisert improved the i.MX23/i.MX28 I2C controller driver and
split up the functionality for the two different chips. The PIO mode
does not work. He also worked on the Low Rate ADC driver currently in
staging and added devicetree initialisation and interrupt support. He
made it also possible now to distinguish MX23 and MX28 on runtime, so
the same driver can now be used for both chips. As it was not possible
to fix all remaining issues, he improved the TODO list in staging.</p>
<p>All in all, 3.13 was a busy cycle for the Pengutronix kernel team. The
patch rate hitting mainline is nevertheless decreasing, as we are
working on more complex components (i.e. the IPU graphics unit on MX6).</p>
</div>
<p>During our embedded linux projects, the kernel engineers at Pengutronix
do a lot of improvements which end up in the mainline kernel. Here's a
short story about what went into the recently released 3.13:</p>2014-01-26T10:00:00+01:00tag:www.pengutronix.de,2014-01-25:/2014-01-25-ptxdist-2014.01.0.htmlPTXdist 2014.01.02014-01-25T10:00:00+01:00Jürgen Borleis<div class="section" id="ptxdist-2014-01-0">
<p>The PTXdist project has released version 2014.01.0 of the embedded linux
build system:</p>
<ul>
<li><p class="first">The pakage templates for integrating self-written programs into a
PTXdist BSP have been fixed. This mechanism lets you create a new set of
build rules for packages with "simple" makefiles:</p>
<p>$ ptxdist newpacket src-make-prog</p>
<p>After answering a few questions, a template for the build rules and
for the menu entries is created in rules/<packagename>.{in,make}</p>
<p>If the program does not already exist (i.e. when starting a new
program), ptxdist creates a Makefile and hello-world file in
local_src/<packagename>-<version>.</p>
<p>With this release, the mechanism above was fixed to do the right
thing.</p>
</li>
<li><p class="first">Recently, the lowpan-tools package has been added, which contains
several utilities for using the 6LoWPAN IPv6-over-802.15.4 wireless
communication stack on Linux.</p>
<p>The lowpan-tools package had dependency issues regarding python. With
the current updates, python is now only a dependency if really
necessary. This improves the build time.</p>
</li>
<li><p class="first">Introduction of a "staging" area:</p>
<p>Some packages have been moved into the newly introduced "staging" area:
acpid, upstart and mplayer. These packages do not compile any more, but
they are currently not so important for the maintainer team that they
have already spent the effort to reactivate them and fix the bugs.</p>
<p>This is something where we hope for the wider community: if you are
interested in getting these packages back into ptxdist mainline, please
help us and send patches.</p>
</li>
<li><p class="first">Some help texts in the ptxdist menus and the toplevel helpfile have been
improved and reflect the behaviour of the code in a better way now.</p>
<p>The automatically generated ptxdistrc has been synchronized with the
current configuration.</p>
</li>
<li><p class="first">The build rules for Valgrind, the memory leak debug tool, got improved
error messages, so it should now be easier to get a working
configuration.</p>
</li>
<li><p class="first">rc-once is ptxdist's method of doing certain things on the first boot
of a freshly installed embedded system, i.e. when a new SSH host key
needs to be created.</p>
<p>With this release, the error handling for rc-once has been improved, so
that the user gets booted into rescue mode when rc-once fails.</p>
</li>
<li><p class="first">A lot of small patches have been added, which affects packages like
glib, the icu-tools (for C++/Java unicode encoding), libsndfile and
JVisu. The SQL database SQ-Lite got cross compiling improvements,
and GStreamer does now build properly with Bison 3. Additionally,
the host-xz tool has been improved regarding its shared library
handling, and some unused files have been removed.</p>
</li>
</ul>
<p>All in all, it was a quiet cycle, as most developers have been out for
christmas holidays for the last weeks.</p>
</div><p>The PTXdist project has released version 2014.01.0 of the embedded linux
build system:</p>2014-01-25T10:00:00+01:00tag:www.pengutronix.de,2014-01-20:/2014-01-20-ptxdist_in_2013.htmlNew PTXdist Features in 20132014-01-20T10:00:00+01:00Jürgen Borleis<div class="section" id="new-ptxdist-features-in-2013">
<p>The main new feature was the introduction and tuning of the toolchain
'wrapper': This wrapper ensures a new level of control about how a
PTXdist project is build. In earlier days, the binary results relied
more or less on the buildsystem each package comes with. With the new
wrapper, a package's buildsystem calls the wrapper instead of gcc and
other toolchain components, and all command line parameters given to it
can be checked or extended. The wrapper provides enforcement of:</p>
<ul class="simple">
<li>user or project specific compile and link time parameters</li>
<li>project and cross compile specific include and library search paths</li>
<li>architecture specific settings and optimization</li>
<li>link time optimization (omit unused libraries)</li>
<li>runtime linker optimization</li>
<li>hardening settings like built-in buffer overflow detection and read-only relocation tables</li>
<li>checking all kind of include paths against illegal host paths</li>
</ul>
<p>Using the wrapper improves the reliability of the PTXdist generated
root filesystem and catches build failures and inconsistencies at a very
early project state.</p>
<p>Basic support for the new graphical environment 'Wayland' was added.
This addition is intended for development yet, because various different
components Wayland depends on to provide a full featured environment for
production are still missed.</p>
<p>For special hardened target systems, PTXdist supports the SELINUX
infrastructure. As there is no generic way to configure and parametrize
SELINUX, PTXdist cannot support this out-of-the-box. Adding the policies
to make use of the SELINUX features is still something an experienced
developer must manage manually.</p>
<p>Since mid of 2013 PTXdist can handle plain git and subversion repositories in
addition to its handling of archives and directories to get the sources of a
package. This new feature simplifies project development in conjunction with
application development.</p>
</div>
<p>The main new feature was the introduction and tuning of the toolchain
'wrapper': This wrapper ensures a new level of control about how a
PTXdist project is build. In earlier days, the binary results relied
more or less on the buildsystem each package comes with. With the new
wrapper, a package's buildsystem calls the wrapper instead of gcc and
other toolchain components, and all command line parameters given to it
can be checked or extended. The wrapper provides enforcement of:</p>2014-01-20T10:00:00+01:00tag:www.pengutronix.de,2010-07-29:/2010-07-29-arm-benchmarks.htmlPerformance Measurement on ARM2010-07-29T00:00:00+01:00Robert Schwebel<div class="section" id="performance-measurement-on-arm">
<p>After working mostly with different ARM processors in the 200...400 MHz
range in lots of Embedded Linux projects over the last years, we have
seen an interesting development in the market recently:</p>
<ul class="simple">
<li>ARM cpus, having been known for their low power consumption, are
becoming faster and faster (example: OMAP3, Beagleboard,
MX51/MX53).</li>
<li>x86, having been known for its high computing
performance, is becoming more and more SoC-like, power
friendly and slower.</li>
</ul>
<p>If you read the marketing stuff from the chip manufacturers, it sounds
like if ARM is the next x86 (in terms of performance) and x86 is the
next ARM (in terms of power consumption). But where do we stand today?
How fast are modern ARM derivates?</p>
<div class="ptx-sidebar">
<div class="title">
More Infos
<div class="corner"></div>
</div>
<div class="body">
<p>Want to learn more about our benchmarking setup?</p>
</div>
</div>
<p>The Pengutronix Kernel team wanted to know, and so we measured, in order
to get some real numbers. Here are the results, and they turn up some
interesting questions. Don't take the "observations" below too
scientifically - I try to sum up the results in short claims.</p>
<p>As ARM is explicitly a low power architecture, it would have been
interesting to measure some "performance vs. power consumption" data.
However, as we have done our experiments on board level products, this
couldn't be done. Some manufacturers tend to put more peripheral chips
on their modules than others, so we would have only measured the effects
of the board BoMs.</p>
<div class="section" id="test-hardware">
<h3>Test Hardware</h3>
<p>In order to find out more about the real speed of today's hardware, we
collected some typical industrial hardware in our lab, so this is the
list of devices we have benchmarked:</p>
<table border="1" class="docutils">
<colgroup>
<col width="30%"/>
<col width="20%"/>
<col width="11%"/>
<col width="21%"/>
<col width="8%"/>
<col width="9%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head">Test Hardware</th>
<th class="head">CPU</th>
<th class="head">Freq.</th>
<th class="head">Core</th>
<th class="head">RAM</th>
<th class="head">Kernel</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>phyCORE-PXA270</td>
<td>PXA270 (Marvell)</td>
<td>520 MHz</td>
<td>XScale (ARMv5)</td>
<td>SDRAM</td>
<td>2.6.34</td>
</tr>
<tr><td>phyCORE-i.MX27</td>
<td>MX27 (Freescale)</td>
<td>400 MHz</td>
<td>ARM926 (ARMv5)</td>
<td>DDR</td>
<td>2.6.34</td>
</tr>
<tr><td>phyCORE-i.MX35</td>
<td>MX35 (Freescale)</td>
<td>532 MHz</td>
<td>ARM1136 (ARMv6)</td>
<td>DDR2</td>
<td>2.6.34</td>
</tr>
<tr><td>O3530-PB-1452
(Texas Instruments)</td>
<td>OMAP3530</td>
<td>500 MHz</td>
<td>Cortex-A8 (ARMv7)</td>
<td>DDR</td>
<td>2.6.34</td>
</tr>
<tr><td>Beagleboard C3</td>
<td>OMAP3530</td>
<td>500 MHz</td>
<td>Cortex-A8 (ARMv7)</td>
<td>DDR</td>
<td>2.6.34</td>
</tr>
<tr><td>phyCORE-Atom</td>
<td>Z510 (Intel)</td>
<td>1100 MHz</td>
<td>Atom</td>
<td>DDR2</td>
<td>2.6.34</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="lmbench-command-lines">
<h3>LMbench command lines</h3>
<div class="section" id="lat-ops">
<h4>lat_ops</h4>
<div class="code-block">
<div class="highlight"><pre><span></span>root@target:~<span class="w"> </span>lat_ops<span class="w"> </span><span class="m">2</span>><span class="p">&</span><span class="m">1</span>
</pre></div>
</div><p>filtered by</p>
<div class="code-block">
<div class="highlight"><pre><span></span>grep<span class="w"> </span><span class="s2">"^float mul:"</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>cut<span class="w"> </span>-f3<span class="w"> </span>-d<span class="s2">" "</span>
</pre></div>
</div></div>
<div class="section" id="bw-mem">
<h4>bw_mem</h4>
<div class="code-block">
<div class="highlight"><pre><span></span>root@target:~<span class="w"> </span><span class="nv">list</span><span class="o">=</span><span class="s2">"rd wr rdwr cp fwr frd bzero bcopy"</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="k">for</span><span class="w"> </span>i<span class="w"> </span><span class="k">in</span><span class="w"> </span><span class="nv">$list</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="k">do</span><span class="w"> </span><span class="nb">echo</span><span class="w"> </span>-en<span class="w"> </span><span class="s2">"</span><span class="nv">$i</span><span class="s2">\t"</span><span class="p">;</span><span class="w"> </span><span class="k">done</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
echo<span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="k">for</span><span class="w"> </span>i<span class="w"> </span><span class="k">in</span><span class="w"> </span><span class="nv">$list</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="k">do</span><span class="w"> </span><span class="nv">res</span><span class="o">=</span><span class="k">$(</span>bw_mem<span class="w"> </span><span class="m">33554432</span><span class="w"> </span><span class="nv">$i</span><span class="w"> </span><span class="m">2</span>><span class="p">&</span><span class="m">1</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>awk<span class="w"> </span><span class="s2">"{print \$2}"</span><span class="k">)</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="nb">echo</span><span class="w"> </span>-en<span class="w"> </span><span class="s2">"</span><span class="nv">$res</span><span class="s2">\t"</span><span class="p">;</span><span class="w"> </span><span class="k">done</span><span class="p">;</span><span class="w"> </span><span class="se">\</span>
<span class="nb">echo</span><span class="w"> </span>MB/Sec
</pre></div>
</div><p>filtered by</p>
<div class="code-block">
<div class="highlight"><pre><span></span>awk<span class="w"> </span><span class="s2">"/rd\twr\trdwr\tcp\tfwr\tfrd\tbzero\tbcopy/ { getline; print \$3 }"</span>
</pre></div>
</div></div>
</div>
</div>2010-07-29T00:00:00+01:00tag:www.pengutronix.de,2010-03-02:/2010-03-02-embedded-world.htmlEmbedded World 20102010-03-02T00:00:00+01:00Jan Lübbe<div class="section" id="embedded-world-2010">
<p>Das Pengutronix Team hat auf der embedded world Exhibition & Conference in
Nürnberg die aktuellsten Entwicklungen rund um Embedded Linux vorgestellt.</p>
<p>Sehen Sie unsere Messe-Galerie und lesen Sie unseren Pengutronix Newsletter Nr.
17!</p>
<div class="ps-gallery single-image" itemscope="" itemtype="http://schema.org/ImageGallery" style="
">
<figure itemprop="associatedMedia" itemscope="" itemtype="http://schema.org/ImageObject"><a data-size="3648x2736" href="https://www.pengutronix.de/media/blog/2010/2010-03-02_embedded-world/img_0044.jpg" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2010/2010-03-02_embedded-world/img_0044.thumb.30f4e64c4716b412f35dd39cd00c1189.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"></figcaption>
</figure>
</div></div>
2010-03-02T00:00:00+01:00