www.pengutronix.de/de/Pengutronix e.K.2024-03-18T14:34:18.288214+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: Rückblick auf 2023 - Teil III2024-01-09T10:00:00+01:00Enrico JörnsLeonard Göhrs<div class="section" id="pengutronix-ruckblick-auf-2023-teil-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="buntes Feuerwerk vor schwarzem Hintergrund" 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>Im dritten und letzten Teil unserer Rückblicks-Reihe blicken wir auf unserer
Schwester-Firma <em>Linux Automation GmbH</em>, die neben einem Umzug in neue
Räumlichkeiten, das Jahr genutzt hat um vor allem den lang erwarteten <em>LXA
TAC</em> (Test Automation Controller) allen Widrigkeiten zum Trotz der Marktreife
näher zu bringen.
Die Kollegen geben hierzu, wie auch zu aktuellen Weiterentwicklungen
bestehender Produkte einen kurzen Rück- und Einblick.</p>
<p>Zu guter Letzt hat sich unsere im letzten Jahr begonnene Podcast-Reihe
"Kernel-Panic: Board on Fire" als voller Erfolg heraus gestellt, den wir zum
Abschluss des Rückblicks noch einmal kurz im Überblick haben.</p>
<div class="section" id="hardware-entwicklungen">
<h3>Hardware-Entwicklungen</h3>
<p>Auch die Linux Automation GmbH, die Pengutronix Hardware-Tochterfirma,
war das Jahr 2023 über nicht tatenlos.
Es gibt neue Hardware in unserem <a href="https://shop.linux-automation.com/">Shop</a>
und Produkte auf die wir uns in 2024 freuen können.</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-Platine mit USB-C und D-Sub-9-Stecker" 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>Seit einigen Jahren schon fertigen und verkaufen wir in unserem Shop
<a href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00-en">CandleLight</a>
open hardware USB-CAN-Adapter.
Dabei handelt es sich, von
<a href="https://github.com/linux-automation/candleLight/">wenigen Tweaks</a>
abgesehen, um das Design von
<a href="https://github.com/HubertD/candleLight">HubertD auf GitHub</a>.
Danke dafür übrigens nochmal!</p>
<p>Seit diesem Jahr leisten wir auch unseren ersten wirklich eigenen Beitrag zur
USB-CAN-Adapter-Welt: das
<a href="https://shop.linux-automation.com/candlelight-fd-en">candleLight FD</a>!</p>
<p>Das candleLight FD ist eine modernisierte Variante des candleLight,
mit CAN FD und USB-C Anschluss.
Wie das candleLight ist auch das candleLight FD
<a href="https://github.com/linux-automation/candleLightFD">open hardware</a>.</p>
</div>
<div class="section" id="lxa-tac">
<h4>LXA TAC</h4>
<p>Ein Projekt, das wir immer wieder auf Messen und im Internet anteasern ist das
LXA TAC, ein Linux Rechner als Entwicklungswerkzeug für andere Linux Rechner.
Der viel gefürchtete EMV-Test und die noch viel gefürchtetere Part-Shortage
haben unseren geplanten Launch mächtig verschoben, aber beide Hürden sind
jetzt überwunden und erste TACs sind schon an externe Tester gegangen.</p>
<p>In Kürze sollten auch erste TACs in den offenen Verkauf in unserem Shop gehen.</p>
<p>Dieses Jahr haben wir auch das Yocto-Projekt veröffentlicht mit dem LXA TAC
Images und Bundles erzeugt werden können.
Wer also schon vor Verkaufsstart contributen möchte, kann das im
<a href="https://github.com/linux-automation/meta-lxatac">meta-lxatac</a>
Projekt tun.</p>
</div>
<div class="section" id="usb-sd-mux-fast">
<h4>USB-SD-Mux Fast</h4>
<p>Wer die Release-Notes der USB-SD-Mux Kontrollsoftware scharf verfolgt wird es
schon gesehen haben: Wir arbeiten an einer neuen Generation des USB-SD-Mux,
dem USB-SD-Mux Fast.</p>
<p>Der USB-SD-Mux Fast enthält einen neuen Umschalter für die Datenleitungen
der SD-Karte und erlaubt somit in manchen Geräten schnellere Karten zu
verwenden.</p>
<p>Außerdem hat auch hier USB-C Einzug erhalten und es gibt zwei neue digitale
Ausgänge mit denen sich z.B. Bootmode und Reset eines Device under Test steuern
lassen.</p>
<p>Noch machen wir eine ausgiebige interne Erprobung des USB-SD-Mux Fast,
aber in nicht allzu ferner Zukunft sollte er auch im Shop verfügbar sein.</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>Im zweiten (und ersten 'richtigem') Jahr unseres Podcasts <em>Kernel Panic - Board
on Fire</em> hat sich Leonard nacheinander mit insgesamt sechs Kollegen um das
imaginäre Lagerfeuer versammelt und sich weitere Geschichten rund um Linux und
knifflige Bug-Such-Geschichten erzählen lassen.</p>
<ul>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-01-24-kernel-panic-board-on-fire-003-ein-rennen-um-nanosekunden.html">Folge #003</a>: <em>Ein Rennen um Nanosekunden</em> mit Michael Grzeschik</p>
<p>Über die knifflige Fehlersuche mit Tracing, Disassembler und Co um einem sporadisch aussetzenden USB-Controller auf die Schliche zu kommen.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-05-24-kernel-panic-board-on-fire-004-optee-und-trustzone.html">Folge #004</a>: <em>OP-TEE und TrustZone - Geheimnisträger in der CPU</em> mit Rouven Czerwinski</p>
<p>Über OP-TEE und die ARM TrustZone, wie beides zusammen hängt und zum Beispiel für die Ablage von kryptographischen Schlüsseln genutzt werden kann.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-06-24-kernel-panic-board-on-fire-005-time-sensitive-networking.html">Folge #005</a>: <em>Time Sensitive Networking - Was wann wo wieso?</em> mit Johannes Zink</p>
<p>Über die Grundlagen von Time Sensitive Networking (TSN) und dem Precision Time Protocol (PTP) und die vielfältigen Anwendungsmöglichkeiten.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-07-24-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten.html">Folge #006</a>: <em>Der Browser im Fahrkartenautomaten</em> mit Bastian Krause</p>
<p>Über den Einsatz von Web-Technologien für GUIs auf Embedded-Geräten, verschiedene Browser-Engines und Möglichkeiten Web-Applikationen zu testen.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-08-24-kernel-panic-board-on-fire-007-der-weg-zum-offenen-grafiktreiber.html">Folge #007</a>: <em>GPU und nu? Der Weg zum offenen Grafiktreiber</em> mit Lucas Stach</p>
<p>Über Hintergründe und Ursprünge von Open-Source GPU-Treibern wie <em>Etnaviv</em> und <em>Nouveau</em> im Linux-Kernel und deren prinzipielle Funktionsweise.</p>
</li>
<li><p class="first"><a href="https://www.pengutronix.de/de/blog/2023-09-24-kernel-panic-board-on-fire-008-aus-dem-takt.html">Folge #008</a>: <em>Aus dem Takt - Das Doppelpack Clock-Glitches</em> mit Ahmad Fatoum</p>
<p>Über die Erzeugung und Verteilung von Takten/Clocks in SoCs und was dabei so alles schief gehen kann.</p>
</li>
</ul>
</div>
<div class="section" id="vielen-dank">
<h3>Vielen Dank!</h3>
<p>Zum Abschluss dieser Reihe möchten wir nochmal allen Kunden, Entwicklern,
Maintainern, Bug-Reportern, Interessierten, Hackern, und Pinguinen danken für
den wertvollen technischen und menschlichen Austausch in 2023 und freuen uns
mit euch auf ein spannendes Jahr 2024!</p>
</div>
</div><p>Im dritten und letzten Teil unserer Rückblicks-Reihe blicken wir auf unserer
Schwester-Firma <em>Linux Automation GmbH</em>, die neben einem Umzug in neue
Räumlichkeiten, das Jahr genutzt hat um vor allem den lang erwarteten <em>LXA
TAC</em> (Test Automation Controller) allen Widrigkeiten zum Trotz der Marktreife
näher zu bringen.
Die Kollegen geben hierzu, wie auch zu aktuellen Weiterentwicklungen
bestehender Produkte einen kurzen Rück- und Einblick.</p>2024-01-09T10:00:00+01:00tag:www.pengutronix.de,2024-01-08:/2024-01-04-rueckblick-auf-2023-2.htmlPengutronix: Rückblick auf 2023 - Teil II2024-01-08T12:00:00+01:00Enrico JörnsMarie MannMichael TretterLeonard Göhrs<div class="section" id="pengutronix-ruckblick-auf-2023-teil-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="buntes Feuerwerk vor schwarzem Hintergrund" 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>Im zweiten Teil unseres Rückblicks widmen wir uns unter anderem den Arbeiten
unseres <strong>Grafik- und Multimedia-Teams</strong>, das wieder über den gesamten Linux-Stack,
vom Kernel über mesa bis hin zu <em>Pipwire</em>, <em>Weston</em> und <em>Webkit</em> eine ganze
Reihe an Bugfixes, Erweiterungen und Anpassungen untergebracht hat, um die
Anforderungen aus verschiedensten Kunden-Projekten abzudecken.</p>
<p>Neben dem Entwickeln von Patchen ist natürlich auch der Kontakt mit der
Community und das 'Dranbleiben' an aktuellsten Themen rund um 'Embedded Linux'
für uns als Dienstleister ein Selbstverständnis.
Daher waren wir wieder auf zahlreichen <strong>Konferenzen und Veranstaltungen</strong> präsent,
teils nur als Teilnehmer, meist aber auch mit eigenen Vorträgen zu aktuellen
Themen, die wir in diesem Teil nochmal als Überblick auflisten.</p>
<div class="section" id="grafik-multimedia">
<h3>Grafik & Multimedia</h3>
<p>Neben dem GPU Kernel-Treiber <em>etnaviv</em> und der 3D Grafik-Bibliothek <em>mesa</em>, für
die wir auch in diesem Jahr diverse Optimierungen und Fehlerkorrekturen
eingebracht haben, gab es noch eine Reihe weiterer spannender Projekte im
Bereich Video und Audio an denen Pengutronix-Mitarbeiter mitgewirkt haben und
die wir im folgenden kurz vorstellen.</p>
<div class="section" id="pipewire">
<h4>PipeWire</h4>
<p>PipeWire findet bei uns in verschiedenen Projekten Verwendung, da es
ermöglicht, Video-Streams vergleichsweise einfach zwischen Applikationen zu
teilen.
So kann zum Beispiel eine Applikation ein Kamerabild auf dem Bildschirm
anzeigen, während eine andere Applikation dasselbe Bild enkodiert und
aufzeichnet.</p>
<p>Für diese Anwendungsfälle haben wir viele kleine Fehlerbehebungen in PipeWire
gemacht.
Unter anderem wurde von uns der JPEG-Support in der pipewiresink und das Laden
der <tt class="docutils literal">videotestsrc</tt> repariert.</p>
<p>Damit tragen wir dazu bei, dass PipeWire neben dem Routing von Audio-Streams
auch für Video-Streams geeignet ist.</p>
</div>
<div class="section" id="gstreamer">
<h4>GStreamer</h4>
<p>Auf der GStreamer Conference 2023 wurde das von uns entwickelte <em>uvcsink</em>
Element vorgestellt.
Das Element erlaubt es, ein UVC Gadget (also im Prinzip die Kamera-Seite einer
USB Kamera) mit einer GStreamer-Pipeline zu betreiben.
Man muss nur die entsprechenden Formate konfigurieren und eine Pipeline
starten, die die Videodaten von einer beliebigen Quelle an eine uvcsink
schickt.
Schon kann man auf einem anderen Rechner den Video-Stream wie bei einer ganz
normalen USB-Kamera empfangen.</p>
<p>Daneben haben wir natürlich auch bei GStreamer viele kleine Fehler behoben, die
bei den speziellen Anwendungsfällen unserer Kunden auftreten und an die vorher
niemand gedacht hat.</p>
</div>
<div class="section" id="webkit">
<h4>WebKit</h4>
<p>In Embedded-Linux-Systemen werden immer häufiger Browser zur UI-Darstellung benutzt.
Perfekt dafür geeignet ist WPE (<a class="reference external" href="https://wpewebkit.org/">https://wpewebkit.org/</a>) - ein WebKit-Port mit Fokus auf Embedded.</p>
<p>Die offensichtliche Eingabemethode ist dabei ein Touch-Display.
Beim Verarbeiten von Touch-Events haben wir einige Verbesserungen Upstream gebracht:</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>Die <a href="https://www.w3.org/TR/pointerevents/">Pointer-Event-API</a> erlaubt dabei größtmögliche Flexibilität, z.B. beim Interpretieren von Gesten.
Hier fehlte bisher Unterstützung von Touch-Events. <a href="https://github.com/WebKit/WebKit/pull/9688">Diese API konnten wir als neues Feature Upstream bringen</a>.</p>
<p>Alle Patche sind im aktuellen <a href="https://wpewebkit.org/release/">Stable-Release 2.42</a> enthalten.
Tipp: <a href="https://pengutronix.de/de/blog/2023-07-24-kernel-panic-board-on-fire-006-der-browser-im-fahrkartenautomaten.html">Folge #006 unseres Podcasts</a>
beschäftigt sich ebenfalls mit dem Thema "Embedded Browser".</p>
</div>
<div class="section" id="weston">
<h4>Weston</h4>
<p>Im November wurde Weston 13 released, der viele neue Features enthält, die von
uns entwickelt wurden.
Durch Multi-Backend Support und GL-Renderer-Support für VNC und PipeWire, sind
Anwendungsfälle, bei denen die Bildschirmausgabe gleichzeitig auf dem Netzwerk
verfügbar sein soll, deutlich effizienter und einfacher zu konfigurieren.</p>
<p>Eine detailliertere Übersicht über die neuen Features von Weston 13 gibt es im
Blogpost <a href="https://www.pengutronix.de/de/blog/2023-12-01.html">Was ist neu in Weston 13?</a>.</p>
</div>
</div>
<div class="section" id="vortrage-und-veranstaltungen">
<h3>Vorträge und Veranstaltungen</h3>
<p>Bei Pengutronix haben wir in diesem Jahr auf die Veröffentlichung von
Vortragsaufzeichnungen über unseren YouTube-Kanal verzichtet und präsentierten
stattdessen auf zahlreichen Veranstaltungen vor Ort.
Danke der professionellen Arbeit vieler Community-Events, gibt es einen
Großteil der Vorträge auf verschiedensten Plattformen zum Nachgucken für kalte
Wintertage.</p>
<p>Im <strong>Februar</strong> waren wir auf der <a href="https://archive.fosdem.org/2023/">FOSDEM</a> in Brüssel,</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> von 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> von 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> von 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> von Michael Olbrich</li>
<li><a href="https://archive.fosdem.org/2023/schedule/event/fpga_bitstreams/">"Building FPGA Bitstreams with Open-Source Tools"</a> von 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> von Uwe Kleine-König</li>
</ul>
<p>und auf dem <a href="https://pretalx.com/openembedded-workshop-2023/talk/3C8MFF/">OpenEmbedded Workshop</a> in Brüssel:</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> von Jan Lübbe</li>
</ul>
<p>Im <strong>März</strong> auf den <a href="https://chemnitzer.linux-tage.de/2023/en/">CLT</a> in Chemnitz:</p>
<ul class="simple">
<li><a href="https://media.ccc.de/v/clt23-188-einfache-vpns-mit-wireguard">"Einfache VPNs mit Wireguard"</a> von Rouven Czerwinski</li>
<li><a href="https://media.ccc.de/v/clt23-193-der-linux-kernel-entwicklungs-workflow">"Der Linux Kernel Entwicklungs-Workflow"</a> von Rouven Czerwinski</li>
<li><a href="https://media.ccc.de/v/clt23-102-mach-es-einfach-nutze-vim">"Vim - Mach es einfach!"</a> von 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> von 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> von 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> von 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> von 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> von 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-Stand auf der 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>Direkt im Anschluss waren wir, zusammen mit unserer Schwester-Firma <em>Linux
Automation GmbH</em>, mit einem Stand auf der <a href="https://www.embedded-world.de/">Embedded World</a> in Nürnberg vertreten und haben dort unsere
Demos zu Open-Source-FPGA-Tooling, Open-Source-Grafik auf dem Rockchip RK3568,
3D-Beschleunigung mit WPE WebKit, OTA-Field-Updates,
Hardware-Test-Automatisierung und T1L Ethernet präsentiert und viele
interessante Gespräche geführt.</p>
<p>Im <strong>Juni</strong> auf der <a href="https://events.linuxfoundation.org/archive/2023/embedded-open-source-summit/">EOSS</a> in Prag, Tschechien:</p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=IsT_29qJz7c">"Low level Ethernet specific magic for embedded devices"</a> von 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> von Johannes Zink</li>
<li><a href="https://youtube.com/watch?v=LzleI6t29fM">"Why are GPUs (not) fast - a trip through the driver stack"</a> von 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> von Enrico Jörns</li>
</ul>
<p>Im <strong>Juli</strong> auf dem Bosch-OSS-Day in Stuttgart:</p>
<ul class="simple">
<li>"Community Collaboration Patterns: Addressing Risk and Complexity" von Jan Lübbe</li>
<li>"From Vulnerable to Vigilant: A 10+ Year Roadmap for Embedded Software Maintenance" von Jan Lübbe</li>
<li>"Exploring RAUC: A Flexible Building Block for Embedded Linux Updates" von Rouven Czerwinski</li>
</ul>
<p>Im <strong>September</strong> auf der <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>auf der <a href="https://gstreamer.freedesktop.org/conference/2023/">gStreamer Conference</a> in A Coruña, Spanien,</p>
<ul class="simple">
<li>"Building your own USB camera with GStreamer" von Michael Grzeschik</li>
</ul>
<p>auf der <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?" von Johannes Zink</li>
</ul>
<p>und auf der <a href="https://embedded-recipes.org/2023/">Embedded Recipes</a> in Paris, Frankreich.</p>
<ul class="simple">
<li><a href="https://youtube.com/watch?v=ViaLmrrMhqk">"One Image to Rule Them All: Portably Handling Hardware Variants"</a> von Ahmad Fatoum</li>
</ul>
<p>Im <strong>Oktober</strong> auf der <a href="https://indico.freedesktop.org/event/4/">XDC</a> in A Coruña, Spanien:</p>
<ul class="simple">
<li><a href="https://www.youtube.com/watch?v=QhGJL4nKfAg">"Wayland Shells for Embedded Systems"</a> von Michael Tretter</li>
</ul>
<p>Im <strong>Dezember</strong> auf dem <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" von Bastian Krause</li>
</ul>
<p>Darüber hinaus haben wir die
<a href="https://ep2023.europython.eu">Euro Python</a>, die
<a href="https://kernel-recipes.org/en/2023/">Kernel Recipes</a> und die
<a href="https://programm.froscon.org/2023/">FrOSCon</a> genutzt, um uns mit den
Entwickler*innen aus der Community zu treffen und auszutauschen.</p>
</div>
</div>
<p>Im zweiten Teil unseres Rückblicks widmen wir uns unter anderem den Arbeiten
unseres <strong>Grafik- und Multimedia-Teams</strong>, das wieder über den gesamten Linux-Stack,
vom Kernel über mesa bis hin zu <em>Pipwire</em>, <em>Weston</em> und <em>Webkit</em> eine ganze
Reihe an Bugfixes, Erweiterungen und Anpassungen untergebracht hat, um die
Anforderungen aus verschiedensten Kunden-Projekten abzudecken.</p>2024-01-08T12:00:00+01:00tag:www.pengutronix.de,2024-01-05:/2024-01-04-rueckblick-auf-2023.htmlPengutronix: Rückblick auf 2023 - Teil I2024-01-05T22:00:00+01:00Enrico JörnsAhmad FatoumRoland HieberJan Lübbe<div class="section" id="pengutronix-ruckblick-auf-2023-teil-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="buntes Feuerwerk vor schwarzem Hintergrund" 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>Wieder ist ein spannendes aber auch herausforderndes Jahr vorüber, wir sind ein
Jahr näher am Y2038-Problem, OpenSSL 1.1.1 ist endgültig Geschichte, Kernel
v4.14 von 2017 wird in vier Wochen endlich abgekündigt, kommende LTS-Kernel nur
noch 2 Jahre unterstützt.
Die Relevanz von Linux, nicht nur im Embedded-Segment, steigt ungemein,
gleichzeitig steht die (Open Source) Software-Welt in Europa vor notwendigen
aber auch herausfordernden Umbrüchen, die in Form des Cyber Resilience Acts
ihre Schatten voraus werfen.</p>
<p>Eine gute Gelegenheit in diesem Trubel kurz inne zu halten, sich zu besinnen
und zurück zu schauen auf das vergangene Jahr 2023 und was es uns als
Pengutronix so beschert hat.</p>
<p>Wir starten den ersten Teil unseres Jahres-Rückblicks mit einer Übersicht über unsere wesentlichen
Beiträge zu Open Source-Projekte, allen voran natürlich dem <em>Linux-Kernel</em> in den
weiterhin der Großteil an Entwicklungsstunden der verschiedenen Projekte fließt.
Aber auch die von Pengutronix-Entwicklern federführend maintainten Projekte wie
<em>Barebox</em>, <em>RAUC</em> oder <em>labgrid</em> haben mitunter wegweisende Neuerungen oder
Erweiterungen erhalten, auf die wir kurz eingehen möchten.</p>
<p>In den zwei folgenden Teilen dieser Reihe werden wir dann unter anderem auf
unsere Aktivitäten im Bereich <em>Grafik und Multimedia</em> und die Entwicklungen
unserer Hardware-Firma <em>Linux Automation GmbH</em> zurück blicken.</p>
<div class="section" id="beitrage-zum-linux-kernel">
<h3>Beiträge zum Linux-Kernel</h3>
<p>Im Kernel haben in 2023 17 Entwickler aus unserem Team gut 2500 Änderungen an
über 4000 Dateien eingebracht, die thematisch sehr weit gefächert sind.
Zwischen Mini-Korrekturen für Rechtschreibfehler und großen,
subsystemübergreifenden Aufräumaktionen finden sich Fehlerkorrekturen, Cleanups
und Vereinfachungen, sowie Treiber für zuvor nicht unterstützte
Hardwarekomponenten und Ergänzungen in Device-Trees für neue sowie auch bereits
unterstützte Hardware.</p>
<p>Beispielsweise wurde von Oleksij Rempel der DSA-Treiber für die häufig
genutzten Microchip "KSZ"-Switche um Unterstützung für
<a class="reference external" href="https://lore.kernel.org/all/20231026051051.2316937-1-o.rempel@pengutronix.de/">Wake on LAN (WoL)</a>
und <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>
erweitert.</p>
<p>Unser Kollege Uwe Kleine-König hat zum Ende des Jahres die Maintenance für das
PWM-Subsystem vom langjährigen Maintainer Thierry Reding übernommen und wird
nach dem kommenden 6.7er Release dafür verantwortlich sein.</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>Auch 2023 ging der monatliche barebox-Release-Zyklus weiter und 1677 Änderungen
von 53 Autoren und Autorinnen, darunter 19 Pengutronix-Entwicklern, fanden damit den Weg
auf verschiedenste Geräte. Einige Highlights:</p>
<ul class="simple">
<li>Unterstützung neuer 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> und
<a class="reference external" href="https://lore.barebox.org/barebox/7b035953-f359-f616-9d90-df37da1890a1@pengutronix.de/">TI AM62x</a></li>
<li>Neue und überarbeitete Treiber, u.a. DSA-Treiber für weitere
<a class="reference external" href="https://lore.barebox.org/barebox/20230111132956.1153359-1-a.fatoum@pengutronix.de/">Microchip</a> und
<a class="reference external" href="https://lore.barebox.org/barebox/20230116134501.2006391-1-a.fatoum@pengutronix.de/">Realtek</a> Ethernet-Switches,
höherer Geschwindigkeitsmodus für
<a class="reference external" href="https://lore.barebox.org/barebox/20230417164255.1070012-1-a.fatoum@pengutronix.de/">eMMCs</a> und
initiale Unterstützung von <a class="reference external" href="https://lore.barebox.org/barebox/20230621090329.2652672-1-a.fatoum@pengutronix.de/">USB Type-C</a></li>
<li>Echter <a class="reference external" href="https://lore.barebox.org/barebox/20230303092131.3063587-1-s.hauer@pengutronix.de/">Multiplatform support</a>:
barebox kann nun, wie schon der Linux kernel, im selben Build verschiedene
Prozessorfamilien unterstützen, z.B. i.MX8M, AM62x und RK3568 zur selben Zeit</li>
<li>Secure-Boot Verbesserungen: Für den i.MX8M, ist verified boot (HAB) nun auch
einfach durch das normale Kconfig
<a class="reference external" href="https://lore.barebox.org/barebox/20231017145131.3069283-1-m.felsch@pengutronix.de/">konfigurierbar</a>.
Mit JSON Web-Tokens gibt es jetzt auch einen
<a class="reference external" href="https://lore.barebox.org/barebox/20231023143122.1760217-1-a.fatoum@pengutronix.de/">eingebauten Weg</a>,
signierte Unlock-Tokens im barebox auszuwerten, sodass Entwickler trotz
Secure-Boot mit einem signierten Token einzelne Geräte temporär freischalten
können.</li>
<li>Stackprotector support: Stack Korruptionen können nun <a class="reference external" href="https://lore.barebox.org/barebox/20230911150900.3584523-4-a.fatoum@pengutronix.de/">detektiert und gemeldet
werden</a></li>
</ul>
<p>Die wahrscheinlichen Highlights des v2024.01.0 Releases sind auch schon bekannt:
Der vorhandene Support für den STM32MP13 wurde <a class="reference external" href="https://lore.barebox.org/barebox/20231127064947.2207726-1-a.fatoum@pengutronix.de/">erweitert</a>
und <a class="reference external" href="https://lore.barebox.org/barebox/20231127063559.2205776-1-a.fatoum@pengutronix.de/">bidirektionale Kommunikation</a>
mit OP-TEE ist nun möglich, z.B. zum Schalten von Clocks, die ausschließlich
aus der TrustZone kontrollierbar sind.</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>Für RAUC, dem Open-Source-Embedded-Linux-Updater, haben wir dieses Jahr drei
Feature-Releases veröffentlicht:</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-03-07-rauc-v1-9-released.html">v1.9 im März</a>
hat eine neue InspectBundle-D-Bus-API hinzugefügt, mit der detaillierte
Informationen zu einem Bundle abgefragt werden können.
Dabei werden sowohl lokalen Bundle-Dateien als auch URLs auf einem HTTPS-Server
unterstützt.</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-07-01-rauc-v1-10-released.html">v1.10 im Juni</a>
brachte einerseits feingranularere Fortschritts-Meldungen während der Installation und
andererseits die Möglichkeit, den "Handlern" zusätzliche System-Informationen mitzugeben.</p>
<p><a href="https://www.pengutronix.de/en/blog/2023-07-01-rauc-v1-10-released.html">v1.11 im Dezember</a>
ermöglichte es schließlich, dem HTTPS-Update-Server zusätzliche
Header zu übermitteln (z.B. Geräte-Seriennummer, -Typ, -Variante).
Außerdem kann RAUC konfigurierbare Event-Logs erzeugen können, mit denen z.B. alle
Software-Installationen auf einem Gerät langfristig nachvollziehbar sind.</p>
<p>Neben den neuen Features haben wir die CI durch die Nutzung von Sanitizern
verbessert und RAUC in OSS-Fuzz integriert.
Nachdem wir im v1.9er Release meson als neues Buildsystem hinzugefügt haben,
wurde autotools mit dem aktuellen v1.11 Release entfernt.
Last, but not least, wurde die <a href="https://rauc.readthedocs.io/">Dokumentation</a>
weiter verbessert.
Vielen Dank an alle, die etwas zu RAUC beigetragen haben!</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>Die sichtbarste Änderung im Hardware-Control-Framework labgrid dieses Jahr ist
sicherlich <a href="https://github.com/labgrid-project/labgrid/pull/1155">das neue Logging</a>.
Damit sind die verschachtelten Schritte, die z.B. eine Testsuite durchführen
muss, um ein Board zu provisionieren, viel besser nachvollziehbar.
Nicht nur die Ausgabe wurde verbessert, auch die Eingabe per labgrid-client
geht dank <a href="https://github.com/labgrid-project/labgrid/pull/1055">Bash-Completion</a> jetzt noch leichter von
der Hand.
Dazu gehört auch die Angabe von Ressourcen-Namen, denn die unterstützen jetzt
<a href="https://github.com/labgrid-project/labgrid/pull/1111">alle relevanten Subcommands</a>.
So können Places mit mehreren Ressourcen des selben Typs einfach per
labgrid-client benutzt werden.
Neben der üblichen Mischung aus kleineren Features und Fixes, wächst die Liste
der <a href="https://labgrid.readthedocs.io/en/latest/configuration.html#drivers">Driver</a> und
<a href="https://labgrid.readthedocs.io/en/latest/configuration.html#resources">Ressourcen</a>
stetig.</p>
<p>labgrid-intern haben wir auf ein neues, <a href="https://github.com/labgrid-project/labgrid/pull/1077">datumsbasiertes Versionsschema</a> umgestellt. Das passt
besser zur kontinuierlichen Entwicklung des Projekts als die bisherige
semantische Versionierung. Ebenfalls intern, aber hoffentlich spürbar: wir
haben Coordinator und Client/Bibliothek/Pytest-Plugin/Exporter bei der
Installation getrennt. Das bringt einfacheres Abhängigkeitsmanagement mit sich.
Durch die unkompliziertere Installation kann labgrid noch besser z.B. als
Bibliothek benutzt werden.</p>
</div>
<div class="section" id="openembedded-yocto">
<h3>OpenEmbedded & Yocto</h3>
<p>Nachdem wir unseren Ansatz für einheitliche Nutzung von Signaturschlüsseln auf Hardware-Token
auf dem OE Workshop direkt nach der FOSDEM vorgestellt haben, wurde der dafür nötige Code im
<a href="https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/classes/signing.bbclass">meta-openembeded layer</a>
aufgenommen.</p>
<p>In oe-core haben wir, neben Version-Bumps, Typo-Fixes und
Dokumentationsanpassungen zum <tt class="docutils literal"><span class="pre">Upstream-Status</span></tt>-Feld von Patchen, auch erste
kleinere Aufräumarbeiten am Testcode rund um oe-selftest upstream gebracht.
Diese sind Teil unserer Bemühungen, der Community auch <em>barebox</em> als Bootloader
in oe-core bereit zu stellen.</p>
<p>Insgesamt haben wir dieses Jahr 22 Patche in meta-oe eingebracht.
In oe-core waren es mit knapp 42 zwar doppelt so viele, jedoch leider noch
weniger als dass es unserem eigenen Anspruch an Contributions gerecht wird.
Dieser Punkt kommt auf jeden Fall auf die Liste der guten Vorsätze für 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>Der Compiler-Wrapper in PTXdist ist dieses Jahr ein ganzes Stückchen strenger
geworden und filtert nun alle Zugriffe auf Pfade außerhalb des
BSP-Build-Verzeichnisses.
Dadurch wird das Build-System weiter unabhängig von dem Host-System, auf dem es
läuft, was zu erhöhter Reproduzierbarkeit von Build-Artefakten führt.</p>
<p>In den Makros zum Bauen von Python-Paketen gibt es nun Unterstützung für
Projekte, die pyproject.toml statt setup.py benutzen, was sich in letzter Zeit
zum neuen Standard für Python-Paketierung entwickelt hat.
Der Support für Rust-Software mit Cargo als Buildsystem wurde weiterhin ausgebaut.
Für eingebettete Geräte, die sich üblicherweise mehr als 10 Jahre im Feld
befinden, ist Y2K38-Kompatibilität zur Verarbeitung von Zeitstempeln jenseits
von 2038 wichtig.
In Verbindung mit der OSELAS.Toolchain 2023.07.0 bietet die glibc-Version 2.37
hierfür nun Unterstützung an.</p>
<p>Wie auch in den letzten Jahren drehte sich aber der Großteil der Änderungen in
PTXdist um die Aktualisierung von Software-Versionen und der Paketierung von
neuer Software.</p>
</div>
<div class="section" id="distrokit">
<h3>DistroKit</h3>
<p>In drei neuen Releases wurden dieses Jahr viele aktualisierte
Software-Versionen, Bugfixes, und auch einige neue Features in unsere
PTXdist-Referenz-Distribution <a class="reference external" href="https://www.pengutronix.de/de/software/distrokit.html">DistroKit</a> eingebracht.</p>
<p>Ein großer Teil der Patches drehte sich um die Integration unseres
Update-Frameworkes RAUC auf den Boards der
<a class="reference external" href="https://lore.distrokit.org/distrokit/20230828085804.293762-1-rhi@pengutronix.de/">v7a- und v8a-Plattformen</a>,
sowie die darauf aufbauende Mechanik, um zur Laufzeit eine
<a class="reference external" href="https://lore.distrokit.org/distrokit/20231213144750.1899431-1-rhi@pengutronix.de/">Datenpartition</a>
anzulegen, die unabhängig von den Systempartitionen beschrieben werden kann.
Kleinere Ergänzungen machen es nun außerdem möglich, ein System über
<a class="reference external" href="https://lore.distrokit.org/distrokit/20230502080646.94539-3-jbe@pengutronix.de/#Z31doc:testing.rst">Androids Fastboot-Protokoll</a>
statt von einer SD-Karte zu booten, oder ein einzelnes Barebox-Rezept für
<a class="reference external" href="https://lore.distrokit.org/distrokit/20230531114744.3281270-1-a.fatoum@pengutronix.de/">alle Boards der v8a-Platform</a> zu verwenden.
Als neu unterstützte Plattform ist das
<a class="reference external" href="https://lore.distrokit.org/distrokit/20230710050324.3004120-5-o.rempel@pengutronix.de/">Microchip SAMA5D3 EDS-Board</a>
hinzugekommen.</p>
</div>
<div class="section" id="umpf-universal-magic-patch-functionator">
<h3>umpf - Universal Magic Patch Functionator</h3>
<p>Starke Tools sind das Rückgrat produktiver Entwicklungsarbeit,
weil sie lästige Fleißarbeit und Flüchtigkeitsfehler vermeiden.
So sieht es auch mit unserer Patch-Verwaltung für Kunden-BSPs aus.
Dort wo Git beim Jonglieren vieler lange bestehenden Feature-Branches
an seine Grenzen stößt, setzt unser seit Jahren intern genutztes
Tool <cite>umpf</cite> an; es dient zur Verwaltung und zum Zusammenfügen von Git-basierten
Themen-Branches, besonders in komplexen und lange gepflegten Projekten wie
unseren Kunden-Kernel-Repositories.</p>
<p>Dieses Jahr haben wir uns im Sinne unserer Open-Source und
Mainline-First-Strategie dazu entschieden, dieses Tool als Open-Source-Software
zu veröffentlichen und somit nicht nur versierten Kunden, sondern vor allem auch
der interessierten Community die Möglichkeit zu geben, ebenfalls davon zu
profitieren.</p>
<p>In unserem Blog-Post <a href="https://www.pengutronix.de/de/blog/2023-08-29.html">umpf - Git on a New Level</a> geben wir einen tieferen
Einblick in die Funktionsweise und Nutzung von umpf.</p>
</div>
</div>
<p>Wieder ist ein spannendes aber auch herausforderndes Jahr vorüber, wir sind ein
Jahr näher am Y2038-Problem, OpenSSL 1.1.1 ist endgültig Geschichte, Kernel
v4.14 von 2017 wird in vier Wochen endlich abgekündigt, kommende LTS-Kernel nur
noch 2 Jahre unterstützt.
Die Relevanz von Linux, nicht nur im Embedded-Segment, steigt ungemein,
gleichzeitig steht die (Open Source) Software-Welt in Europa vor notwendigen
aber auch herausfordernden Umbrüchen, die in Form des Cyber Resilience Acts
ihre Schatten voraus werfen.</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.htmlWas ist neu in Weston 13?2023-12-01T00:00:00+01:00Michael TretterPhilipp Zabel<div class="section" id="was-ist-neu-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>Vergangenen Dienstag wurde <a href="https://lists.freedesktop.org/archives/wayland-devel/2023-November/043326.html">Weston 13.0</a>
released. Der Release enthält einige neue Features, die wir für unsere
Anwendungsfälle in Embedded Systems entwickelt und nach Upstream gebracht
haben. In diesem Blogpost wollen wir die für uns relevanten neuen Features —
Multi-Backend, OpenGL Renderer für die PipeWire und VNC Backends, und
Überlappende Outputs — erläutern und zeigen, wieso diese für Embedded wichtig
sind.</p>
<!-- TODO Ein Bild der 4-Video-Demo mit Fernwartung über VNC. -->
<div class="section" id="neue-features">
<h3>Neue Features</h3>
<p>Durch <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/578">Multi-Backend</a> ist es
möglich, ein System, bei dem sich Weston um die Ausgabe auf einem lokal
angeschlossenen Display kümmert, zusätzlich mit Fernwartung oder Streaming
auszustatten. Bisher war Weston darauf begrenzt, dass nur ein Backend
gleichzeitig geladen werden konnte und dadurch nur Outputs von einem Typ, zum
Beispiel DRM oder VNC, zur Verfügung standen. Da diese Einschränkung
aufgehoben wurde, kann Weston Outputs mit verschiedenen Typen erstellen. Damit
ist es möglich in einem Weston gleichzeitig DRM, VNC und PipeWire Outputs zu
betreiben. Für Embedded Systems, die in vielen Fällen sowieso Netzwerk haben,
ist Fernwartung ein willkommenes Feature.</p>
<p>Aufgrund relativ schwacher Hardware, ist es bei Embedded Systems wichtig,
möglichst immer hardwarebeschleunigt zu rendern. Bisher konnten das VNC und
das PipeWire Backend nur den Pixman Software-Renderer benutzen. Mit Weston 13
kann auch bei diesen Backends der <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1106">OpenGL-Renderer für das Rendern</a> benutzt
werden. Da Weston nur einen Renderer lädt, der für alle Backends genutzt wird,
erlaubt dies auch, im Multi-Backend Szenario den GL-Renderer für das
DRM-Backend weiter zu nutzen, wenn ein PipeWire oder VNC Output hinzukommt.
Damit können Zeichenoperation statt auf der CPU auf der GPU erledigt und
Hardware-Ressourcen besser ausgenutzt werden.</p>
<p>Die Unterstützung von <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1291">überlappenden Outputs ("overlapping outputs")</a> hat zwei
spannende Effekte auf unsere üblichen Anwendungsfälle. Zum Einen können
dadurch Hardware-Planes auch für Fenster, die auf mehreren Outputs angezeigt
werden, benutzt werden. Hardware-Planes erlauben in begrenztem Maß, das
Zusammenrendern von mehreren Fenstern auf dem Display-Pfad statt auf der GPU zu
erledigen und damit die GPU zu entlasten. Als Zweites wird es dadurch möglich,
den selben Desktop-Inhalt auf mehreren Outputs anzuzeigen. Bisher mussten
Outputs aufgrund von Einschränkungen beim Damage-Tracking immer komplett
voneinander getrennt sein, wodurch Workarounds nötig waren, um zum Beispiel ein
Fenster gleichzeitig über DRM und VNC anzuzeigen.</p>
</div>
<div class="section" id="ausblick">
<h3>Ausblick</h3>
<p>Aber die Arbeit wird nicht ausgehen. Folgende Features und Aufgaben stehen bei
uns auf dem Plan, um die Performance und Konfigurierbarkeit von Weston für
Embedded Systems weiter zu verbessern.</p>
<p>Bereits als Merge Request steht <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366">DMABUF-Support für das PipeWire-Backend</a> bereit.
Durch dieses Feature kann Weston mit GL gerenderte Frames direkt an PipeWire
übergeben und von da ohne Kopie an einen hardware-beschleunigten JPEG- oder
h.264-Encoder weitergereicht werden. Dadurch können Kopien von großen
Bilddaten entfallen, wodurch sich eine Performance-Verbesserung beim Streaming
und Recording ergibt.</p>
<p>Für das VNC-Backend wäre eine ähnliche Optimierung wünschenswert.
Dazu ist aber noch weiterer Support in Neat VNC nötig.</p>
<p>Außerdem sind im Moment die Konfigurationsmöglichkeiten für mehrere Outputs
sehr eingeschränkt. Hier fehlen noch Möglichkeiten, die Outputs per
Konfiguration (ähnlich dem Clone-Mode) oder auch programmatisch mit einem
Plugin auf dem Desktop zu positionieren und deren Größe zu bestimmen. Der
programmatische Teil könnte sich auch mit einer <a href="https://www.youtube.com/watch?v=qK2Emqp9t0g&t=14244s">hypothetischen Window
Management Infrastruktur</a>
kombinieren lassen. Auch möchte man die VNC und PipeWire Outputs zur Laufzeit
anlegen und entfernen können.</p>
<p>Nichtsdestotrotz ist Weston ein sehr geeigneter Wayland-Compositor für Embedded
Systems und es lohnt sich, die eigenen Systeme auf Weston 13 zu aktualisieren.</p>
</div>
</div>
<p>Vergangenen Dienstag wurde <a href="https://lists.freedesktop.org/archives/wayland-devel/2023-November/043326.html">Weston 13.0</a>
released. Der Release enthält einige neue Features, die wir für unsere
Anwendungsfälle in Embedded Systems entwickelt und nach Upstream gebracht
haben. In diesem Blogpost wollen wir die für uns relevanten neuen Features —
Multi-Backend, OpenGL Renderer für die PipeWire und VNC Backends, und
Überlappende Outputs — erläutern und zeigen, wieso diese für Embedded wichtig
sind.</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>
Neben einer umfassenden Dokumentation von <strong>umpf</strong> ist auch der Quellcode in
unserem <a href="https://github.com/pengutronix/umpf/blob/master/README.rst">Github-Repository</a>
zu finden.</blockquote>
</div>
</div>
<p>Moderne Softwareentwicklung ohne begleitende
<a href="https://git-scm.com/">Versionsverwaltung wie Git</a> ist heutzutage
unvorstellbar - Änderungen am Quellcode sollen schließlich nachvollziehbar
dokumentiert und beliebige Verssionsstände jederzeit einfach reproduziert
werden können. Für Arbeiten an komplexeren Projekten wie etwa dem BSP ("Board
Support Package") eines eingebetteten Systems mit mehreren Entwicklungssträngen
skaliert ein bloßes Aufeinanderstapeln der einzelnen Änderungen jedoch nicht.</p>
<p>Häufig werden ausgehend von einem gemeinsamen Softwarestand parallel
verschiedene Funktionalitäten entwickelt, müssen Back-Ports integriert und für
Upstream gedachte Arbeiten separat verwaltet werden. Die dazu notwendige
thematische Aufteilung bei der Entwicklung neuer Patches für das BSP geschieht
daher in der Regel auf voneinander unabhängigen Zweigen in separaten Git
Branches.</p>
<p>Kompliziert wird es mit diesem Modell allerdings bei der anschließenden
Zusammenführung von mehr als zwei Branches, etwa, um das Gesamtprojekt testen zu
können oder zur Veröffentlichung eines Releases. Das manuelle Mergen der
einzelnen Zweige ist so aufwendig wie fehleranfällig und kollidiert mit den
möglichst kurzen Testzyklen iterativer Entwicklungsmodelle.</p>
<div class="section" id="branches-sinnvoll-zusammenfuhren">
<h3>Branches sinnvoll zusammenführen</h3>
<p>Unter Anderem, um diesen letzten Schritt zu vereinfachen und aus einer Auswahl
von Topic Branches reproduzierbar einen einzelnen Patch Stack generieren zu
können, haben wir den <strong>Universal Magic Patch Functionator (umpf)</strong> als
quelloffene Erweiterung für die lokale Git-Installation entwickelt.</p>
<p>Mit <em>umpf</em> lässt sich innerhalb der gewohnten Git Infrastruktur und über mehrere
Git Branches ("Topic Branches") hinweg eine lineare Patch-Serie generieren,
deren Abhängigkeiten dabei konserviert werden.</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>Mit umpf werden mehrere parallele Topic Branches zu einer seriellen
Patch-Serie kombiniert. Dank der Referenzierung der jeweiligen HEADs können
die zugrundeliegenden Branches jedezeit reproduzierbar in ihrem Zustand zum
Zeitpunkt des Tags wiederhergestellt werden.</p>
</figcaption>
</figure>
</div><p>Diese Abfolge von Commits wird durch einen regulären Git Tag beschrieben, der
von <em>umpf</em> um Referenzen zu den enthaltenen Topic Branches
ergänzt wird. Ein solcher <em>utag</em> vereint somit mehrere Eigenschaften:</p>
<ul class="simple">
<li>Der Marker beinhaltet einen Datumsstempel und ist dadurch <strong>eindeutig
zuordbar</strong>.</li>
<li>Es kann ein <strong>linearer Patch Stack</strong> als Patch-Serie exportiert werden.</li>
<li>Der Stand der eingebundenen Branches zum <em>umpf</em>-Zeitpunkt wird konserviert.
Spätere auch tiefgreifende Änderungen eines Zweiges (z.B. Force-Pushes nach
Bug-Fixes) haben dadurch keinen Einfluss auf den <em>utag</em>, weswegen der
tatsächliche Entwicklungsstand zum Tagging-Zeitpunkt problemlos
<strong>wiederhergestellt und nachvollzogen werden kann</strong>.</li>
<li>Durch die Archivierung der enthaltenen Branches können deren eventuelle
Abhängigkeiten untereinander mit <strong>normalen Git-Werkzeugen</strong> nachvollzogen
werden.</li>
<li>Durch Heuristik wird die Art des Projektes erkannt und passend ein
Datumsstempel integriert - bspw. als EXTRAVERSION in einem Makefile. Dies
ermöglicht später eine <strong>eindeutige Identifikation</strong> auch des bereits
kompilierten und ausgelieferten Softwarestands.</li>
</ul>
<p>Die Erstellung eines <em>utags</em> und seiner linearen Patch-Serie ist dabei relativ
unkompliziert und setzt neben <em>umpf</em> lediglich ein bestehendes Git Projekt
voraus. <em>umpf</em> selbst ist ein Bash Skript und bedient sich jener Werkzeuge, die
Git selbst zur Verfügung stellt. Deshalb können durch <em>umpf</em> generierte Tags und
Merges im Anschluss von jeder normalen Git Installation verarbeitet werden. Ein
<em>utag</em> wird folglich auch regulär mittels <code>git push</code> dem bereits
bestehenden Repository hinzugefügt und kann analog dazu über <code>git
checkout</code> wieder aufgerufen werden.</p>
<p>Um einen <em>utag</em> erzeugen zu können benötigt <em>umpf</em> drei Parameter, die sich zum
Beispiel in Form einer <em>useries</em>-Textdatei oder über Aufruf von <code>umpf
init</code> übergeben lassen:</p>
<ul class="simple">
<li><strong>base</strong>: Der Ausgangspunkt, auf dem die spätere Patchserie aufbauen soll. Die
<em>umpf-base</em> ist meistens ein Upstream Commitish, etwa ein Release Tag (bei
Linux z.B.: "v6.3").</li>
<li><strong>name</strong>: Der eigentliche Name des <em>umpfs</em>, der später auch Teil des <em>utags</em>
wird. Es empfiehlt sich, diesen von der <em>base</em> abzuleiten, bspw.
"6.3/release-name".</li>
<li><strong>topic</strong>: Die eigentlichen Git-Branches (<em>Topic Branches</em>) werden mit je
einem vorangestellten <code># umpf-topic:</code> angeführt. Sie sollten selber auf
dem <em>base</em> commit aufbauen, um Komplikationen zu vermeiden. Es ist daher
ratsam, Branches mit einem anderen Ausgangspunkt als die <em>umpf-base</em> zuerst
auf ebendiese zu re-basen.</li>
</ul>
</div>
<div class="section" id="integration-von-backports">
<h3>Integration von Backports</h3>
<p>Gerade bei Arbeiten mit Upstream-Projekten kommt es immer wieder vor, dass
Bugfixes oder Funktionserweiterungen von dritter Seite eingepflegt werden müssen.
Die Stärke von <em>umpf</em> ist hier, dass solche Änderungen in einem eigenen Branch
gepflegt werden können und sie nicht weiter mit den Arbeiten am eigenen Projekt
interferieren.</p>
<p>Zuverlässig funktioniert diese Branch-Integration bei <em>umpf</em> allerdings nur,
wenn der Ausgangscommit vergleichbar ist: Topic Branches für bspw. <code>v5.15</code>
und <code>v5.16</code> können in der Regel problemlos durch <em>umpf</em> zusammen
verarbeitet werden. Ein weiterer Branch basierend etwa auf <code>v6.2</code> wird
wegen der umfangreichen allgemeinen Unterschiede im Code allerdings zu
Komplikationen beim <em>umpfen</em> führen.</p>
<p>Um Bugfixes und sonstige Backports zu integrieren ist es daher empfehlenswert,
diese mit ihrem eigenen Topic Branch einmalig auf die <em>umpf-base</em> zu re-basen.</p>
</div>
<div class="section" id="behandlung-von-merge-konflikten">
<h3>Behandlung von Merge Konflikten</h3>
<div class="ptx-sidebar">
<div class="title">
Git Performance
<div class="corner"></div>
</div>
<div class="body">
<blockquote>
Sehr große Git-Projekte, wie etwa der Linux Kernel, benötigen ob ihrer
zahlreichen Commits entsprechend viel Rechenleistung für die Verarbeitung.
Beschleunigen lässt sich dies durch
<a href="https://git-scm.com/docs/git-commit-graph">git commit-graph</a>.</blockquote>
</div>
</div>
<p><em>umpf</em> kann selbstständig keine Merge-Konflikte auflösen. Die händische
Konfliktlösung während des <em>umpfens</em> ist zwar möglich und bspw. bei der Arbeit
mit Device-Trees manchmal unvermeidlich, sollte sich jedoch auf ein Minimum
beschränken.</p>
<p>Die Lösungen zu den einzelnen Konflikten können allerdings mittels
<a href="https://git-scm.com/book/de/v2/Git-Tools-Rerere">git-rerere</a>
gespeichert und im Wiederholungsfalle dadurch automatisiert aufgelöst werden.
Die zu integrierenden Branche sollten trotzdem, falls nötig, im Vorfeld eines
<em>umpfs</em> bereits entprechend umstrukuriert und aufgeräumt worden sein.</p>
</div>
<div class="section" id="lineare-serie-generieren">
<h3>Lineare Serie generieren</h3>
<p>Die so erstellte <em>useries</em> kann nun benutzt werden, um aus ihr einen <em>utag</em>
abzuleiten und alle eingetragenen Entwicklungsstränge in einem gemeinsamen
Release Tag vereinen zu lassen:</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> wird nun alle Branches in der Reihenfolge, wie sie in der <em>useries</em>
eingetragen wurden, auf der angegebenen <em>umpf-base</em> stapeln. Dabei wird auch
ein Autosquash durchgeführt, sodass Fixup-Commits aufgelöst werden und
nicht in den finalen Patchstack gelangen.</p>
<p>Ein Beispiel, wie ein solcher <em>utag</em> in Git dargestellt wird, kann in der
folgenden Abbildung betrachtet werden. Hierbei handelt es sich um einen so
genannten <strong>qualifizierten umpf</strong>, da dieser alle notwendigen Informationen zur
vollständigen Rekonstruktion beinhaltet:</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>Ein "qualifizierter" <em>umpf</em> Tag (<em>utag</em>) wie er von Git gesehen wird.</p>
</figcaption>
</figure>
</div><ul class="simple">
<li><strong>umpf-base</strong>: Der Ausgangscommit. Meist ist dies ein Upstream-Tag.</li>
<li><strong>Patch Stack</strong>: Commits der Topic Branches, gestapelt auf die <em>umpf-base</em>.
Die Reihenfolge der Branches entspricht jener, wie sie <em>umpf</em> übergeben
wurden.</li>
<li><strong>References</strong>: Der Zustand der integrierten Branches zum Zeitpunkt des
<em>umpf</em>-ens. Dieser Zustand wird im Commit des <em>utag</em> über die HEADs der Zweige
referenziert und dadurch konserviert, sodass selbst eine nachträgliche
Änderung eines Branches keine Auswirkung hat, sollte der <em>utag</em> zu einem
späteren Zeitpunkt erneut ausgechecked werden. Die Referenzierung bewirkt
außerdem, dass die <a href="https://git-scm.com/docs/git-gc">Git Garbage Collection</a>
die vermeintlich verwaiste Konstellation im Repository belässt. Die
Reproduzierbarkeit des <em>utag</em> bleibt somit langfistig gegeben.</li>
<li><strong>utag</strong>: Ein regulärer Git Tag, in dem die integrierten Branches sowie die
jeweils neusten Commit-IDs (HEADs) zum Zeitpunkt des <em>umpf</em>-ens hinterlegt
sind.</li>
<li><strong>Release Tag</strong>: Ein weiterer regulärer Git Tag. Dieser wird für die
Generierung einer Patch-Serie referenziert. Der Commit beinhaltet ggf. eine
Modifikation des Projektcodes, um einen Datumsstempel zu integrieren.</li>
</ul>
<p>Das abschließende Exportieren des Patchstacks erfolgt über den Befehl
<code>umpf format-patch</code>. Der Export kann mit Parametern variiert werden: Ein
angehängtes <code>-bb</code> erzeugt eine zu Yocto-Projekten kompatible Patch-Serie,
mit <code>-p</code> kann der Zielpfad festgelegt, und mit <code>-u</code> das
Überschreiben einer eventuell bereits vorhandenen Serie veranlasst werden.
Weitere Hinweise liefert <code>umpf --help</code>.</p>
</div>
<div class="section" id="umerge">
<h3><em>umerge</em></h3>
<p>Anstelle eines <em>utags</em> können wir auch ohne vorhandene <em>useries</em> durch den
Aufruf von <code>umpf merge</code> schrittweise durch händisches einfügen der
einzelnen Topic Branches einen <em>umerge</em> aufbauen. Hierzu genügt es, mittels
<code>git checkout</code> auf den Stand der erwünschten <em>umpf-base</em> zu wechseln um im
Anschluss mit <code>umpf merge</code> gezielt die benötigten Branches nachzuladen:</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>Diese Zusammenführung von mehreren Zweigen ähnelt einem <em>Octopus Merge</em>, welcher
bei Git für das gleichzeitige Mergen von mehr als zwei Branches genutzt
werden kann. Anders als bei Git bleibt nach einem <code>umpf merge</code> jedoch
analog zum <em>utag</em> die Herkunft der hinzugekommenen Commits erhalten: Die
zugrundeliegenden Branches werden in ihrem Zustand zum Zeitpunkt des <em>umerge</em>
durch einen zusätzlichen Eintrag in der Commit-Nachricht des Merges
referenziert. Dadurch kann zu einem beliebigen späteren Zeitpunkt die Herkunft
der einzelnen Commits - also die ursprünglichen Namen ihrer Branches sowie deren
Historie - nachvollzogen werden.</p>
<p>Ein <em>umerge</em> kann auch direkt mit einer <em>useries</em>-Datei erzeugt werden. Hierzu
genügt der Aufruf von <code>umpf build ./useries</code>.</p>
<p>Ein <em>umerge</em> bietet sich vorallem für die iterative Entwicklung an, bei der alle
Topic Branches eines Projekts benötigt werden, um bspw. hardwarenahe Entwicklung
am Kernel. Zusätzliche Änderungen am Quellcode können dann einfach auf den
<em>umerge</em> aufgesetzt und getestet werden. Im Anschluss lassen sich durch Aufruf
von <code>umpf distribute</code> die neu erzeugten Patche interaktiv einem der
ursprünglichen Zweige zuordnen und werden von <em>umpf</em> dort direkt integriert.</p>
<p><code>umpf distribute</code> kann auch genutzt werden, wenn die Commits nicht auf
einem <em>umerge</em>, sondern stattdessen auf einem <em>utag</em> gestapelt wurden.</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>Mit <em>umerge</em> können Abhängikeiten zwischen den Topic Branches einer
einzelnen <em>useries</em> genutzt werden.</p>
</figcaption>
</figure>
</div><p><em>umerges</em> können allerdings auch direkt in Projekten Verwendung finden, wenn
Abhängigkeiten zwischen den einzelnen Topic Branches bestehen. Durch das
<em>Stacking Feature</em> von <em>umpf</em> wird bei der späteren Verarbeitung der auf einem
<em>umerge</em> aufbauende Zweig dann regulär in die linearisierte Abfolge der Commits
integriert. Dabei ist zu beachten, dass der Eintrag des fraglichen Branches in
der <em>useries</em> Datei nicht vor den Zweigen, von denen er abhängt, eingefügt
werden darf; die Reihenfolge der Nennung ist hier ausschlaggebend.</p>
<p>Da der <em>umerge</em> den Zustand der Basiszweige für den abhängigen Branch
konserviert, werden nachträgliche Arbeiten an diesen auch nicht auf bereits
bestehende <em>umerges</em> übertragen. Dies kann beim anschließenden Genrerien eines
neuen <em>utags</em> zu Konflikten führen, wenn dieser mit einem älteren
<em>umerge</em> erzeugt werden soll. In einem solchen Fall dürfen sich nachträgliche
Änderungen an den Basiszweigen nicht auf direkte Abhängigkeiten des darauf
aufbauenden Branches auswirken.</p>
</div>
</div>
<div class="section" id="warum-wir-umpfen">
<h2>Warum wir umpfen</h2>
<p>Bei Pengutronix haben wir uns auf Embedded Linux, und damit auf die Arbeit am
Linux Kernel und den assoziierten Projekten spezialisiert. Im Rahmen unserer
"Mainline First"-Strategie bringen wir dabei die in unseren Projekten
erarbeiteten Funktionalitäten so früh wie möglich in die offiziellen
Upstream-Kanäle ein. Dies bringt zwar langfristig viele Vorteile mit sich -
wie etwa Sicherstellung des hohen Qualitätsstandards unseres Codes durch
Community Review - bedeutet auf der anderen Seite aber auch, dass die
Verwaltung der zum Projekt gehörenden Patches nicht nur eine direkte
Integration in unsere spezifischen BSPs ermöglichen, sondern eben auch den
Anforderungen von Upstream genügen muss. Dies setzt eine saubere Trennung des
jeweiligen Topic Branches vom restlichen Projekt voraus.</p>
<p>Der Anstoß zur Entwicklung von <em>umpf</em> kam letztendlich aus unserer Arbeit an der
Treiberentwicklung für eingebettete Systeme: Moderne SoCs decken heutzutage ein
unglaublich breites Spektrum an Implementierungen und Funktionalitäten ab;
zugleich werden nach dem Baukasten-Prinzip aber oftmals baugleiche Komponenten
(sog. "intellectual property cores" bzw. "IP-Cores") genutzt - auch
herstellerübergreifend. Entsprechend haben wir deshalb bei uns spezifische
Treiber-Branches aufgebaut, die sich ohne weitere Anpassungen über mehrere
unserer Integrationsprojekte hinweg verwenden lassen.</p>
<p>Das direkte Arbeiten am Linux-Kernel mit seinen hunderten von Branches und
fortwährender Upstream-Entwicklung ist natürlich ein Paradebeispiel dafür, wie
umfangreich ein mit Git verwaltetes Projekt werden kann. Aber auch
wesentlich kleinere Projekte profitieren spätestens ab dem zweiten eingeführten
Branch von einer Automatisierungshilfe wie <em>umpf</em>.</p>
<p>Auch, wenn eine Erweiterung wie unser <strong>Universal Magic Patch Functionator</strong>
Grenzen mit Blick auf die tatsächlich mögliche Komplexität eines Git
Repositories aufweist, so befähigt <em>umpf</em> uns trotzdem seit Jahren erfolgreich
dazu, bei einer Vielzahl von Projekten eine ganze Reihe verschiedener
Patchstacks sauber zu verwalten und den generellen Versionierungsaufwand in
dieser Beziehung überschaubar zu halten.</p>
<p>Wir haben uns nun entschlossen, dieses Tool unter MIT-Lizenz der Open Source
Gemeinde <a href="https://github.com/pengutronix/umpf/">zur Verfügung zu stellen</a>
- und wir freuen uns wie immer über eine rege Beteiligung!</p>
</div>
<p>Moderne Softwareentwicklung ohne begleitende
<a href="https://git-scm.com/">Versionsverwaltung wie Git</a> ist heutzutage
unvorstellbar - Änderungen am Quellcode sollen schließlich nachvollziehbar
dokumentiert und beliebige Verssionsstände jederzeit einfach reproduziert
werden können. Für Arbeiten an komplexeren Projekten wie etwa dem BSP ("Board
Support Package") eines eingebetteten Systems mit mehreren Entwicklungssträngen
skaliert ein bloßes Aufeinanderstapeln der einzelnen Änderungen jedoch nicht.</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/de/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/de/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/de/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 ein paar Stunden beginnt die 18. <a class="reference external" href="https://froscon.org/">FrOSCon</a>
an der Hochschule Bonn-Rhein-Sieg.
Pengutronix ist wieder mit einem kleinen Team vor Ort.
An einem der Partner-Stände zeigen wir wieder einige unserer Aktivitäten in der
Open Source Community.
Dafür bringen wir unseren <a class="reference external" href="https://www.youtube.com/watch?v=FCdkBli2kJ4">labgrid Demonstrator</a>
und die <a class="reference external" href="https://video.fosdem.org/2023/UD2.120%20(Chavanne)/fpga_bitstreams.webm">FPGA Demo</a>
mit.</p>
<p>Wir freuen uns auf bekannte und neue Gesichter und zahlreiche interessante
Gespräche!</p>
</div>
<p>In ein paar Stunden beginnt die 18. <a class="reference external" href="https://froscon.org/">FrOSCon</a>
an der Hochschule Bonn-Rhein-Sieg.
Pengutronix ist wieder mit einem kleinen Team vor Ort.
An einem der Partner-Stände zeigen wir wieder einige unserer Aktivitäten in der
Open Source Community.
Dafür bringen wir unseren <a class="reference external" href="https://www.youtube.com/watch?v=FCdkBli2kJ4">labgrid Demonstrator</a>
und die <a class="reference external" href="https://video.fosdem.org/2023/UD2.120%20(Chavanne)/fpga_bitstreams.webm">FPGA Demo</a>
mit.</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/de/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 ist Pengutronix' Framework der Wahl für Software zur Abwicklung unserer Geschäftsprozesse.
Diese internen Werkzeuge bieten zudem auch immer die Gelegenheit neuere Entwicklungen im Django-Universum auszuprobieren.</p>
<p>Grund genug sich dieses Jahr auch einmal in der Django-Community umzusehen,
am besten auf der diesjährigen DjangoCon Europe, die in Edinburgh, Schottland stattfand.
Die inzwischen gut etablierte Community-Konferenz bot insgesamt drei Tage mit Talks zu zahlreichen Aspekten der Django-Entwicklung,
gefolgt von einem zweitägigen Entwicklungssprint für das Django-Projekt selbst.</p>
<p>Besonders sehenswerte Talks waren zum Beispiel
Wilhelm Klopps <a href="https://pretalx.com/djangocon-europe-2023/talk/YJQ8HR/">gelungene Übersicht zum Thema Testing und Test-Utilities</a>
und Dawn Wages’ <a href="https://pretalx.com/djangocon-europe-2023/talk/DJF7SF/">großartiger Beitrag zu verschiedenen Persönlichkeitstypen in Open Source Projekten</a>,
den besten Wegen diese zu integrieren und zu motivieren
und generellen Handreichungen zur Gestaltung eines gesunden Open Source Community-Projekts.</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>Das Django-Pony und sein schottischer Cousin</p>
</figcaption>
</figure>
</div><p>Außerdem gab es Präsentationen zu interessanten Anwendungen des Django-Frameworks,
zum Beispiel <a href="https://www.aura.radio/">AURA</a>, einem <a href="https://pretalx.com/djangocon-europe-2023/talk/9MBQEB/">Werkzeug zur automatisierte Sendungsplanung für freie Radios</a>
oder dazu, wie eine Django-App so weit hochskaliert werden kann,
dass damit das <a href="https://pretalx.com/djangocon-europe-2023/talk/PYFUGF/">Backend eines WhatsApp basierten Informationsdienstes</a> betrieben werden konnte,
der während der Corona-Pandemie fast 15 Millionen Nutzer in Südafrika mit Gesundheitsinformationen versorgte.</p>
<p>Bewährte Themen wie Performance-Verbesserung oder Query-Optimierung haben inzwischen durch Ziele wie Green Computing an zusätzlicher Bedeutung gewonnen.
Andrew Aikman bot hierzu einen <a href="https://pretalx.com/djangocon-europe-2023/talk/PXBRGK/">umfassenden Überblick</a>,
der alle Aspekte von Query-Optimierung bis zu effizienter Wasserkochernutzung abdeckte.</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>Der große Vortragssaal</p>
</figcaption>
</figure>
</div><p>Carlton Gibson präsentierte mit <a href="https://pypi.org/project/neapolitan/">neapolitan</a> („better than vanilla“) einen vielversprechenden Ansatz zum <a href="https://pretalx.com/djangocon-europe-2023/talk/P9M8BL/">schnellen Bootstrappen CRUD-orientierter Django-Projekte</a>.</p>
<p>Besondere Erwähnung gebührt Daniele Procida’s Talk <a href="https://pretalx.com/djangocon-europe-2023/talk/KFGC7M/">„The programmer’s imagination“</a>,
der die versammelte Community mit kurzweiligen Ansichten zur allgemeinen Entzauberung der Computernutzung und dem zunehmenden Aufkommen „servilen“ Designs unterhielt.</p>
<p>Herzlichen Dank an die Organisatoren und Freiwilligen Helfer dieser rundum gelungenen Konferenz!</p>
<p>Bei Interesse, die <a href="https://2024.djangocon.eu/">nächste DjangoCon</a> findet 2024 in Vigo, Italien statt!</p>
</div>
<p>Django ist Pengutronix' Framework der Wahl für Software zur Abwicklung unserer Geschäftsprozesse.
Diese internen Werkzeuge bieten zudem auch immer die Gelegenheit neuere Entwicklungen im Django-Universum auszuprobieren.</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>Nach der Corona-Pause finden am 11.+12.03.2023 die Chemnitzer Linux-Tage
in diesem Jahr wieder vor Ort statt, und das Pengutronix Team ist mit
acht (!) Vorträgen im Programm vertreten.</p>
<p>Auf den ersten Blick ist das vielleicht ein bisschen verwunderlich,
schließlich sind die CLT nicht gerade eine Konferenz mit unseren
"Kernthemen" rund um Embedded Linux in der Industrie. Aber wer die CLT
kennt, weiß, dass hier der "Open Source Spirit" mit ungebrochenem Elan
einfach <em>lebt</em>: Ein Event organisiert mit lauter engagierten
Freiwilligen, mit jeder Menge Herzblut und vielen, vielen Stunden
Arbeit, die man als Besucher und als Referent einfach spürt und wo wir
auch als Firma seit vielen Jahren gerne hinfahren. Und nicht zuletzt
trifft man dort viele nette Leute aus der Community und manchmal auch
den ein- oder anderen möglichen neuen Mitarbeiter. Schließlich suchen
wir immer Leute, die Open Source "leben", sich in den Tiefen von Linux
gut auskennen all dies nicht nur nach Feierabend machen möchten.</p>
<p>Aber auch bei Pengutronix gibt es nicht nur Kernel-Entwickler. Das sieht
man nicht zuletzt daran, dass unsere Vorträge aus allen möglichen
Themenfeldern kommen; schließlich setzen wir Linux nicht nur auf
Embedded Geräten unserer Kunden ein, sondern auch überall in unserem
Tagesablauf:</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, Assistentin der Geschäftsführung)</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, Grafikteam)</li>
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2023/de/programm/beitrag/188">Einfache VPNs mit Wireguard</a> (Rouven Czerwinski, Kernelteam)</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, Kernelteam)</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, Kernelteam)</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, Integrationsteam)</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, Hardwareteam)</li>
</ul>
<p>Wir freuen uns auf unser interessantes Publikum!</p>
</div>
<p>Nach der Corona-Pause finden am 11.+12.03.2023 die Chemnitzer Linux-Tage
in diesem Jahr wieder vor Ort statt, und das Pengutronix Team ist mit
acht (!) Vorträgen im Programm vertreten.</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>Die Pengutronix Crew ist wieder mit einer größeren Gruppe auf dem Weg zur
FOSDEM in Brüssel! Und auch in diesem Jahr sind wir wieder auf der Suche nach
vielen spannenden Diskussionen mit den Entwicklern der verschiedensten Open
Source Komponenten - vom Linux Kernel über Debian bis hin zu KiCAD, FreeCAD
etc...</p>
<p>Daneben gibt es dieses Mal ganze 8 Vorträge aus unserem Team!</p>
<div class="section" id="unsere-talks-auf-der-fosdem">
<h3>Unsere Talks auf der 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="und-beim-oe-workshop">
<h3>Und beim 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>Wir freuen uns über viele neue Kontakte, und ganz besonders über Leute, die
Lust haben, in Zukunft mit uns gemeinsam an vielen spannenden Embedded Linux
Aufgaben zu arbeiten!</p>
</div>
</div>
<p>Die Pengutronix Crew ist wieder mit einer größeren Gruppe auf dem Weg zur
FOSDEM in Brüssel! Und auch in diesem Jahr sind wir wieder auf der Suche nach
vielen spannenden Diskussionen mit den Entwicklern der verschiedensten Open
Source Komponenten - vom Linux Kernel über Debian bis hin zu KiCAD, 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/de/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.htmlRückblick auf 20222023-01-10T10:00:00+01:00Leonard GöhrsEnrico JörnsMichael OlbrichJohannes Zink<div class="section" id="ruckblick-auf-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="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>Bei Pengutronix und in der Embedded-Linux-Welt im Allgemeinen passieren
natürlich das ganze Jahr über spannende Dinge, aber so ein Übertrag im Datumsfeld
ist schon eine großartige Gelegenheit sich mal zurück zu lehnen und davon
zu erzählen.</p>
<p>In den groben Kategorien <em>Kernel</em>, <em>Open Source-Software</em>, <em>Hardware</em> und
<em>Öffentlichkeitsarbeit</em> wollen wir daher einen Überblick geben, was 2022 so bei
Pengutronix interessantes passiert ist.</p>
<p>Da Pengutronix ohne ihn nur ein Embedded-…-Dienstleister wäre statt eines
Embedded-Linux-Dienstleisters machen den Anfang unsere Beiträge zum Linux-Kernel,
insbesondere zum PWM-Subsystem.</p>
<p>In der Kategorie <em>Open Source Software</em> geht es um den Bootloader <em>Barebox</em>
und das DistroKit BSP, die gelernt haben Raspberry Pi 4 Boards im 64Bit-Modus
zu betreiben, und die PTXdist Distribution, die um viele Convenience-Features
ergänzt wurde, um z.B. die Entwicklung in IDEs zu verbessern.
Auch in dieser Kategorie geht es um die Lab-Automatisierungssoftware Labgrid,
die jetzt mit noch mehr Automatisierungshardware sprechen kann und auch
architekturell stets weiter entwickelt wird.
Last but definitely not least freuen wir uns unsere Software-Updating-Software
RAUC auch ganz ohne unser Zutun in verschiedenen kommerziellen Produkten
wiederzufinden, ein gutes Zeichen für ein gesundes Open-Source-Projekt.</p>
<p>Auch in der Pengutronix/Linux Automation GmbH-Hardwarewelt gab es,
auch wenn uns die Chip-Shortage noch immer sehr bremst,
einige Entwicklungen.
Z.B. wird unsere Entscheidung, das Open Hardware Projekt <em>candleLight</em>
(ein USB-zu-CAN-Adapter mit ganz hervorragendem Linux-Treibersupport)
in Serie zu produzieren und zu verkaufen, gut angenommen.
Aber auch bei unseren Eigenentwicklungen hat sich einiges getan, so gibt es
jetzt USB zu 10Base-T1L Ethernet Adapter und den USB-Mux im
<a href="https://shop.linux-automation.com">Linux Automation GmbH Shop</a>
zu kaufen und auch das LXA TAC bewegt sich Stück für Stück zur Marktreife.</p>
<p>Den Abschluss des Rückblicks macht unser Ende des Jahres gestarteter
<a href="https://www.pengutronix.de/de/tags/kernel-panic-podcast.html">Podcast</a>
mit Gruselgeschichten aus der Embedded Hard- und Softwareentwicklung.
In bisher zwei Folgen können Sie bei ihrer nächsten längeren Bahn- oder
Autofahrt mehr über spekulative Ausführung in Prozessoren (und wie sie schief
gehen kann) und andere knifflige Fehlerfälle lernen als Sie (und wir) je wollten.</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 den sechs Kernel-Releases (v5.16 bis v6.1), die es dieses Jahr gab, haben
wir mehr als 800 Patche für verschiedenste Subsysteme beigesteuert.</p>
<p>Eine Änderung, die es noch gegen Ende des Jahres in den Kernel geschafft hat,
dürfte ins Besondere auch über die Embedded-Community hinaus interessant
sein: Dem Realtek RTW88-Treiber wurde USB-Support hinzu gefügt.
Damit werden nun einige neue WiFi-USB-Sticks von Linux unterstützt.</p>
<p>Allerdings braucht es noch ein wenig Geduld, denn die Änderung wird erst Teil
des kommenden v6.2-Release von Linux sein.</p>
<p>Eine andere nützliche Änderung USB betreffend hat es dagegen schon in das
v6.0-Release geschafft:
Mit dem neuen <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-Interace</a>
können einzelne Ports von USB-Hubs nun kontrolliert im Kernel ein- und ausgeschaltet werden.
Bei Hubs, die Power-Schalten unterstützen, wird damit auch die
Spannungsversorgung abgeschaltet.
Letzteres war bisher nur isoliert mit dem Tool
<a class="reference external" href="https://github.com/mvp/uhubctl">uhubctl</a> möglich, allerdings ohne den
Port-Status im Kernel zu ändern, was zu inkonsistenten Zuständen führte.</p>
<p>Mit einer von uns eingebrachten <a class="reference external" href="https://github.com/mvp/uhubctl/pull/450">Änderung</a> nutzt uhubctl nun aber auch das
neue Sysfs-Kernel-Interface.</p>
<div class="section" id="pwm-subsystem">
<h4>PWM Subsystem</h4>
<p>Die Maintanance im PWM-Subsystem des Kernels war in 2022 geprägt von
Aufräumarbeiten und Vereinheitlichungen.
Prominent sticht dabei heraus, dass das PWM-Framework nur noch die seit 2016
implementierte
<a href="https://git.kernel.org/linus/5ec803edcb703fe379836f13560b79dfac79b01d">atomic updates-Abstraktion</a>
für Hardware-Treiber unterstützt, mit dessen Hilfe Konfigurationsänderungen mit
einem einzigen API-Call getätigt werden können.
Damit können (mit der passenden Implementierung des Hardware Treibers und der
passenden Hardware) ungewollte Spannungsausschläge beim Umkonfigurieren des PWM
verhindert werden.
2022 wurde endlich mal die Altlast alle Treiber auf dieses Modell zu konvertieren
angepackt und mit der Änderung
<a href="https://git.kernel.org/linus/0829c35dc5346e90f428de61896362b51ab58296">pwm: Drop support for legacy drivers</a> abgeschlossen.</p>
<p>Eine Umstellung, die noch nicht komplett vollzogen ist, ist, dass Nutzer der
PWM-API auch die oben beschriebene atomic API verwenden.
Das ist eines der nächsten Ziele.</p>
</div>
</div>
<div class="section" id="open-source-software">
<h3>Open Source-Software</h3>
<div class="section" id="barebox">
<h4>Barebox</h4>
<p>Auch Barebox wird fleißig weiter entwickelt und so gibt es einige neu
unterstütze 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 im 32bit- und 64bit-Modus</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 und Verbesserungen:</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>Mit verbesserten TrustZone-Support können einige neuere SoCs einzelne Blöcke ihrer
Hardware entweder der Normal World oder der Secure World zuweisen.
Während in der Normal World beispielsweise der Bootloader und Linux laufen,
kann dann der Zugriff auf grundlegende Infrastruktur wie Clocks, Resets und
Regulatoren dann nur noch aus der Secure World erfolgen.
Da Treiber in der Normal World dennoch mit Teilen dieser Hardwarekomponenten
kommuniziere müssen, wurde von ARM SCMI (System Control and Management Interface)
als standardisiertes Interface eingeführt.
Auch die Treiber in Barebox müssen daher mit der Secure World, z.B. der ARM Trusted Firmware,
über die entsprechenden Secure Monitor Calls kommunizieren können,
dafür wurde entsprechender Support in Barebox hinzugefügt.</p>
<p>Durch den DSA (Distributed Switch Architecture) Support in Barebox ist es nun möglich,
einen Switch an das xMII-Interface eines SoCs anzuschließen und dadurch mehrere
Netzwerkports an einem Gerät auch schon im Bootloader zu unterstützen, beispielsweise
für Netboot.
Die einzelnen Switchports werden dabei als separate virtuelle
Netzwerkinterfaces dargestellt und können separate Netzwerkkonfigurationen
gesetzt bekommen.</p>
<p>Um die vorhandene Netzwerkbandbreite für TFTP Downloads optimal ausnutzen zu
können, unterstützt TFTP in Barebox nun auch die
<a href="https://www.barebox.org/doc/latest/filesystems/tftp.html#rfc-7440-windowsize-support">Windowsize-Option aus RFC7440</a>.
Durch sorgfältiges Tuning der Parameter kann dadurch bei TFTP Downloads
ein Speedup um den Faktor 4-30 erreicht werden.</p>
<p>Da Python2 bereits seit einiger Zeit abgekündigt wurde, setzten die Tools in
Barebox nun komplett auf Python3.</p>
</div>
<div class="section" id="distrokit">
<h4>DistroKit</h4>
<p>Benutzer unseres Beispiel-BSPs <a class="reference external" href="https://www.pengutronix.de/de/software/distrokit.html">DistroKit</a> durften sich 2022
über 90 Patche freuen.
Neben Updates auf die Greatest-und-Latest Releases verschiedener Komponenten
unterstützt DistroKit jetzt zwei weitere Boards: Den <em>Raspberry Pi 4</em> und das
<em>Radxa Rock 3-A</em>.</p>
<p>Auch an bereits existerenden Boards hat sich was getan: Für die STM32MP1-Boards
wird jetzt das neue FIP-Boot-Format unterstützt und alle ARMv7-A-kompatiblen
Raspberry Pi Boards werden nun mit dem selben Image unterstützt, egal ob Raspberry
Pi 2, 3 oder 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 der Embedded-Board-Control-Library labgrid haben wir dieses Jahr
Resource- und Driver-Support für einige neue Anwendungsfälle gemergt, u.a. für</p>
<ul class="simple">
<li><a href="https://github.com/labgrid-project/labgrid/pull/933">Geräte im DFU-Modus</a>,</li>
<li><a href="https://github.com/labgrid-project/labgrid/pull/959">Netzwerkgeräte im Android-Fastboot-State</a> und</li>
<li><a href="https://github.com/labgrid-project/labgrid/pull/996">Proxy-Support für mehr Power-Backends</a>.</li>
</ul>
<p>Neben einer Vielzahl von Bugfixes und anderen Features wurde labgrids
Dokumentation überarbeitet und einige Code-Beispiele werden seither per CI getestet.
Unter der Haube haben wir auf <a href="https://github.com/labgrid-project/labgrid/pull/1001">pyproject.toml</a> umgestellt.
Ein <a href="https://github.com/labgrid-project/labgrid/pull/1045">CI-Job für Releases</a>
soll uns in Zukunft häufigere Releases erleichtern.</p>
<p>Als Nächstes wird die <a href="https://github.com/labgrid-project/labgrid/pull/1042">Authentifizierung zwischen Coordinator, Exporter
und Client umgestellt</a> werden
(die bisherige Authentifizierung wird noch eine Zeit lang unterstützt bleiben).
Das ebnet uns den Weg zur Aufteilung von Abhängigkeiten vom Coordinator
(aktuell Crossbar) und labgrid selbst.
Das Ziel ist, ungepinnte Abhängigkeiten zu ermöglichen.
Versionskonflikte von Abhängigkeiten sollen damit zur Ausnahme werden.</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>Neben der üblichen Pflege der ganzen Pakete, die bei einem Embedded-Linux
Buildsystem wie <em>PTXdist</em> unabdingbar ist, gab es dieses Jahr vor allem
Verbesserungen bei der User-Experience.</p>
<p>Mit den neuen Befehlen <tt class="docutils literal"><span class="pre">fast-bsp-report</span></tt> und <tt class="docutils literal"><span class="pre">full-bsp-report</span></tt> lassen sich
yaml-Dateien erstellen, die jede Menge Informationen zum BSP beinhalten.
Details zu den Paketen wie Version, Lizenz und Patche, aber auch die verwendete
Toolchain und was für Images erzeugt werden.
Daraus kann dann mit weiterem Tooling z.B. ein Lizenz-Report erzeugt werden.
Und es gibt auch schon ein <a href="https://github.com/pengutronix/ptxdist-ide-integration">kleines Tool</a>
was daraus die notwendigen Informationen holt, um mit VisualStudioCode Applikationen für das BSP entwickeln zu können.</p>
<p>Für viele Pakete erzeugt PTXdist jetzt eine <tt class="docutils literal">compile_commands.json</tt> Datei.
Die kann von <em>Language Servern</em> wie clangd verwendet werden um zum Beispiel die
richtigen Header zu finden.
Das macht das Editieren von Code mit Editoren und IDEs, die einen Language
Server verwenden, deutlich komfortabler.
Voraussetzung dafür ist, dass das Buildsystem des Pakets Support dafür bietet.
Aktuell sind dies alle CMake- und Meson-basierten Pakete, der Linux Kernel und Barebox.</p>
<p>Optional kann PTXdist jetzt zu allen Binaries eine sogenannte <em>MiniDebugInfo Section</em> hinzufügen.
Das ist eine extrem reduzierte Form der Debugsymbole, die gerade dafür reicht, Funktionsnamen aufzulösen.
Damit können dann Applikationen wie systemd-coredump zur Laufzeit Backtraces erstellen und loggen, auch wenn
die normalen Debugsymbole fehlen.
Sehr praktisch um im Feld bei Fehlern mehr Informationen im Log abzulegen ohne
grössere Datenmengen in Form Coredumps zu archivieren.</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>Für das von Pengutronix verwaltete Update-Framework RAUC war das vergangene Jahr
geprägt von einer Reihe interessanter Entwicklungen im Bereich OTA-Updates.</p>
<p>Besonders stolz sind unsere Maintainer, die das Projekt mit viel Herzblut voran
treiben, dass es RAUC in der Zwischenzeit auch ohne das Zutun von Pengutronix
in viele populäre Produkte geschafft hat, wie etwa die
<a href="https://www.collabora.com/news-and-blog/news-and-events/portable-linux-gaming-with-the-steam-deck.html#qcom1409">Spielekonsole 'Steam Deck' von Valve</a>
oder als Teil von <a href="https://www.heise.de/select/ct/2022/27/2223808321839973008">Linux4ICE in die Anzeigen der ICEs</a>.</p>
<p>In 478 Patchen, verteilt auf 3 Releases, wurden, basierend auf dem 2020
eingeführten neuen 'verity' Bundle-Format, drei grundlegende Features implementiert:</p>
<p>So unterstützt RAUC erstmals ohne externe Tools das
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#http-streaming">Streamen von Update-Bundles über HTTP(S)</a>.
Damit gehört die Notwendigkeit eines Zwischenspeichers für Update-Artefakte auf dem Zielsystem der Vergangenheit an.
Da auch heutzutage Übertragungsbandbreiten immer noch oft limitiert, teuer oder instabil sind, haben wir mit dem Konzept der
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#adaptive-updates">'adaptiven Updates'</a>
den Grundstein für verschiedene Methoden zur delta-artigen Übertragung gelegt.
Das beste daran: dank der Möglichkeit von RAUC, wahlfreien Zugriff auf das Bundle zu haben, geschieht dies weitgehend transparent.
Mit 'block-hash-index' wurde eine erste Methode zum Chunken und differentiellen Updates Block-Device-Images geschaffen.</p>
<p>Da Updates auch sensible Daten oder Applikationen enthalten können und sowohl
die Transportwege als auch die Ablageorte für OTA Updates nicht immer vollständig
abgeschottet werden können, gab es schon des Öfteren den Wunsch,
in RAUC Update-Bundles auch verschlüsselt übertragen zu können.
Diese Jahr wurde auch dieser Punkt im Rahmen eines Projektes umgesetzt.
Mit <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#bundle-encryption">crypt-Bundles</a>
können Updates nun vollständig und für eine Große Anzahl individueller
Empfänger-Systeme verschlüsselt werden, während es weiter möglich bleibt
sie für Streaming und "Adaptive Updates" zu nutzen.</p>
</div>
</div>
<div class="section" id="neue-hardware-entwicklungen">
<h3>Neue Hardware-Entwicklungen</h3>
<p>Zusammen mit unserem Partner-Unternehmen <a class="reference external" href="https://linux-automation.com/de/">Linux Automation GmbH</a> haben wir unseren Hardware-Werkzeugkasten
erweitert, auch wenn die Entwicklung und vor allem die Produktion in Zeiten
von knappen Chips und elektronischen Bauteilen sehr viel Geduld erfordert.</p>
<div class="section" id="candlelight">
<h4>candleLight</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>Wir sind ja ein bisschen überrascht von dem Erfolg, den das Video
<a href="https://www.youtube.com/watch?v=JqTBzDN7VOk">"CAN Protocol Reverse Engineering with Wireshark"</a>
von Leonard auf Youtube hat und freuen uns, dass uns aus der Community Anfragen
zu Varianten und Verbesserungen rund um den dort verwendeten Open Hardware USB-zu-CAN-Adapters <em>candleLight</em> erreichen.</p>
<p>Für eine bessere Handhabung hat Chris Fiege daher zum Beispiel ein
<a href="https://linux-automation.com/de/products/candlelight.html">3D-Druck Gehäuse</a> entworfen.</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>Wer uns dieses Jahr auf einer Messe oder Konferenz getroffen hat, konnte vielleicht schon einen Blick auf das LXA TAC,
den <a href="https://www.linux-automation.com/de/products/lxa-tac.html">Linux Automation GmbH Test Automation Controller</a>,
erhaschen. Aber auch bei zukünftigen Messen wird es dazu noch ausreichend Gelegenheit geben.
Wer mehr als nur einen Blick erhaschen möchte, wird sich allerdings noch etwas gedulden müssen,
denn durch die schon seit 2020 bestehenden Probleme in der Bauteilbeschaffung wird sich die Serienproduktion noch etwas verschieben.</p>
<p>Die Wartezeit bis zur Produktion gibt uns Gelegenheit die Softwareseite mit Feinschliff und Politur zu versehen.
Zukünftige KäuferInnen können sich also auf einiges freuen:</p>
<ul class="simple">
<li>Saubere Labgrid-Integration der verschiedenen Features.</li>
<li>Ein offenes und einfach anpassbares Yocto-Layer als Basis für eigene Betriebssystem-Images, inklusive Anleitungen um z.B. eigene Konfigurationsdateien direkt im Image auszuliefern. (Offizielle vorgebaute Images wird es aber natürlich auch geben)</li>
<li>Einen System-Management-Deamon, der das Gerät per Webinterface und API steuerbar macht.</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>Lange war es Mux-Mäuschen still um unsere USB-Muxe, aber wie heißt es so schön?
"Was lange wärt, wird endlich gut!" Im Dezember 2022 haben wir die ersten
Geräte aus der Fertigung erhalten und konnten sie an Kunden weitergeben.</p>
<p>Mit den USB-Muxen erweitern wir unsere Möglichkeiten in der Testautomatisierung auf USB-Schnittstellen.
Detailliertere Informationen gibt es in dem <a href="https://linux-automation.com/media/pages/products/usb-mux/Datasheet_USB-Mux.pdf">Datenblatt</a></p>
<p>Die Fertigung weiterer Geräte folgt, sodass wir den USB-Mux im nächsten Jahr im breiteren Einsatz sehen.</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>Der neue 10Base-T1L Ethernet-Standard erlaubt Übertragungsraten von 10MBit/s über ein einzelnes
Aderpaar. Wer sich jetzt in die 1980er und die Zeit der Vampirklemmen zurückerinnert fühlt,
sei beruhigt: 10Base-T1L bringt einige Verbesserungen gegenüber der Technologie von damals.
10Base-T1L erlaubt Punkt-zu-Punkt Ethernet-Verbindungen von Geräten über Distanzen von bis zu
1.5km-2km bei niedrigem Leistungsbedarf.</p>
<p>10Base-T1L ist auf bestem Wege sich als <em>Industrial</em>-Ethernet-Standard für lange Distanzen zu
etablieren.</p>
<p>Der USB-T1L-Adapter ist ein Werkzeug für Embedded-EntwicklerInnen, die 10Base-T1l basierte
Produkte sowohl zeitnah, als auch möglichst nahe am tatsächlichen Produkt entwickeln wollen.
Dazu ist der USB-T1L als firmwareloses Gerät designed; Der Linux-Kernel des angeschlossenen
Geräts übernimmt selbst die Ansteuerung und Konfiguration des auf dem Gerät verbauten 10Base-T1L Phy.</p>
<p>Eine Besonderheit des USB-T1L ist, dass es unser erstes in-house produziertes Gerät für den externen Verkauf darstellt.
Der USB-T1L ist das Gerät mit dem wir unsere neue Pick&Place-Maschine eingeweiht haben.
Diese Anschaffung ermöglicht uns zukünftig schneller Prototypen zu fertigen und unsere Entwicklungszyklen zu
beschleunigen. Fingers crossed, dass bald auch die Bauteilverfügbarkeit besser wird.</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>Auf dem Weg zur multimedialen World-Domination können wir nun neben unserem Blog, Microblogging
und unserem <a href="https://www.youtube.com/pengutronix">YouTube-Kanal</a> einen
weiteren Meilenstein verzeichnen: einen eigenen Podcast!</p>
<p>Im Podcast "Kernel Panic - Board on Fire" (eine Anspielung an den gefürchteten Linux "Kernel Panic",
Single Board Computer und die berühmt-berüchtigte Fehlermeldung "lp0 on fire") soll es darum gehen
Lagerfeuergeschichten aus der Welt der Embedded-Software und -Hardware zu erzählen.</p>
<p>Bei diesen Lagerfeuergeschichten geht es zum Beispiel um monatelange Fehlersuchen durch die
verschiedenen Subsysteme eines Geräts um schlussendlich das richtige "Funktionier-Bit" zu finden.
Da die Code-Änderungen aus diesen Suchen oftmals unscheinbare Einzeiler sind wollen wir im
Podcast insbesondere den Suchprozess mit all seinen Wendungen beleuchten.</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">Folge 1</a> - 2022-11-24 "Speculative Execution und ein Execute Never Bit":</th></tr>
<tr class="field"><td> </td><td class="field-body">Ahmad Fatoum erzählt eine Geschichte, die damit beginnt, dass die Hintergrundbeleuchtung eines
Geräts schon im Bootloader eingeschaltet werden soll, sich dann für einige Monate in den
Eigenheiten der Programmausführung auf Prozessoren verläuft und schlussendlich in einer Hand
voll Zeilen Code resultiert.</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">Folge 2</a> - 2022-12-24 "Wachhunde und (nicht so) ideale Bauelemente":</th></tr>
<tr class="field"><td> </td><td class="field-body">Leonard Göhrs erzählt von einem Gerät, das sich dann und wann mal neu startet, und davon wie
er die verschiedenen Gründe gefunden hat die nicht Ursache dieses Problems sind.
Es geht um Watchdogs, Übertemperatur, nicht ganz ideale elektrische Bauelemente und auch ein
bisschen um Reverse-Engineering auf Hardwareebene.</td>
</tr>
</tbody>
</table>
</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">
Stickdaten
<div class="corner"></div>
</div>
<div class="body">
<table border="1" class="docutils">
<colgroup>
<col width="26%"/>
<col width="74%"/>
</colgroup>
<tbody valign="top">
<tr><td>Datenblatt:</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>Stickdatei (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>Das Motto unseres diesjährigen Weihnachtsgrußes lautete "Send Patches".
Dafür hat uns Anna vom <a href="https://kleinerwolkendrache.de">Atelier *Kleinerwolkendrache*</a>
einen wundervollen Patch erzeugt.
Wer keinen unterm Tannenbaum hatte, darf gerne die folgende Stickdatei nutzen
um sich einen eigenen zu basteln.</p>
<div><div class="clearfix"></div></div><p>Das gesamte Team von Pengutronix wünscht allen Kunden, Contributorn, Hackern
und Freunden der Linux World-Domination einen guten und erfolgreichen Start in
das Jahr 2022!..</p>
<p>... und möglichst wenig off-by-one-Fehler!</p>
</div>
</div>
<p>Bei Pengutronix und in der Embedded-Linux-Welt im Allgemeinen passieren
natürlich das ganze Jahr über spannende Dinge, aber so ein Übertrag im Datumsfeld
ist schon eine großartige Gelegenheit sich mal zurück zu lehnen und davon
zu erzählen.</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>Im März letzten Jahres habe ich auf der Konferenz "Embedded Recipes"
<a href="https://embedded-recipes.org/2022/talks/weston-multi-backend-screen-recording-streaming-and-remote-control/">über unsere Arbeiten am Wayland-Kompositor Weston gesprochen</a>
und die gleichzeitige Nutzung mehrerer Backends demonstriert, wobei eine
Weston-Instanz ihre Inhalte über unterschiedliche Pfade ausgibt, z.B.:</p>
<ul class="simple">
<li>mit dem DRM-Backend auf einem lokalen Monitor,</li>
<li>mit dem neuen VNC-Backend über das <a href="https://www.rfc-editor.org/rfc/rfc6143">Remote Framebuffer Protocol</a> an einen anderern Rechner, auf dem
ein VNC-Client läuft,</li>
<li>mit dem neuen PipeWire-Backend an eine separate PipeWire-Anwendung,
die das Bild z.B. zum Video-Streaming oder zur Aufnahme in eine Datei
komprimieren kann.</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="der-mainline-zustand">
<h3>Der Mainline-Zustand</h3>
<p>Während die nötigen Bausteine für Multi-Backend-Unterstützung und die Ausgabe
über das PipeWire-Backend bis auf bereits integrierte vorbereitende Änderungen
(<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>)
immer noch unter Review bzw. in Arbeit sind
(<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>),
ist das VNC-Backend mittlerweile in den main-Branch aufgenommen worden
(<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>Das erlaubt es, einen Weston-Kompositor ohne lokale Anzeige laufen zu lassen,
mit dem man sich z.B. über Port 5900 mit einem VNC-Client verbinden kann. Dank
der verwendeten <a href="https://github.com/any1/neatvnc">Neat VNC</a>
Server-Bibliothek werden Verschlüsselung per TLS und Authentifizierung über den
lokalen Nutzeraccount unterstützt:</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>Die Vorbereitung von TLS-Schlüssel und -Zertifikat funktioniert genau so wie beim
bereits vorher von Weston unterstützten RDP-Backend, mit dem die Ausgabe über
das Remote Desktop Protocol an Windows-Rechner übertragen werden kann (Auszug
aus der "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="ausblick">
<h3>Ausblick</h3>
<p>Neben der Multi-Backend-Funktionalität sind weitere Änderungen am VNC-Backend
im Flug, die den VNC-Client zur Reduktion der Latenz den Cursor selbst zeichnen
lassen (<a href="https://github.com/any1/neatvnc/pull/67">#67</a>,
<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/984">!984</a>),
die Nutzung des OpenGL-Renderers mit dem VNC-Backend erlauben
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/881">!881</a>),
oder die Konfiguration der Framebuffergröße vereinfachen
(<a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1072">!1072</a>).</p>
<p>Wir arbeiten weiter daran, die ausstehenden Änderungen für Reviewer einfacher
handhabbar zu machen und Stück für Stück in Form zu bringen, um schließlich auf
dem main-Branch einen Weston Kompositor zu haben, der gleichzeitig auf dem
lokalen Monitor ausgeben und via VNC ferngesteuert werden kann:</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>Noch etwas weiter in der Zukunft liegen mögliche Verbesserungen der Hardware-
Beschleunigung. So könnte etwa Neat VNC die Renderbuffer vom Weston
GL-Renderer <a href="https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/880#note_1575260">direkt übergeben</a>
bekommen und hardwarebeschleunigte JPEG- oder h.264-Kompression implementieren.</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>Im März letzten Jahres habe ich auf der Konferenz "Embedded Recipes"
<a href="https://embedded-recipes.org/2022/talks/weston-multi-backend-screen-recording-streaming-and-remote-control/">über unsere Arbeiten am Wayland-Kompositor Weston gesprochen</a>
und die gleichzeitige Nutzung mehrerer Backends demonstriert, wobei eine
Weston-Instanz ihre Inhalte über unterschiedliche Pfade ausgibt, z.B.:</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>Nach längerer Zeit mit nur Online-Events findet 2022 auch die <em>Netdev 0x16</em>,
eine Konferenz rund um die technischen Aspekte von Linux Networking,
hybrid statt - online und vor Ort in Lissabon.</p>
<div class="section" id="tag-1">
<h3>Tag 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.8b0a4a243297c265eb492669acaf56ff.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>Auch bei der <em>Netdev 0x16</em> zeigt sich bereits am ersten Tag gleich morgens
schon, wie sehr eine Teilnahme vor Ort den Austausch der Entwickler fördert.
Schon vor Beginn des eigentlichen Konferenzprogramms mit Diskussionsrunden und
Breakout Sessions wird bereits direkt im Foyer an den Kaffeetischen diskutiert.
Wenig erstaunlich zeigt sich auch hier, dass die Verfügbarkeit von Netzwerk-
Hardwarebausteinen ohne offene Dokumentation sowohl für Entwickler,
als auch für Endanwender eine erhebliche Herausforderung darstellt.
Die oft nicht öffentliche Dokumentation von Hardwarekomponenten stellt dabei
auch Projekte wie <a href="https://www.dent.dev">DENT</a> oder
<a href="https://www.openvswitch.org/">Open vSwitch</a> vor die Herausforderung, jenseits
der Referenzplattformen Hardware-Support zur Verfügung zu stellen.
Oft läuft zwar auf der eigentlich im Feld befindlichen Hardware Linux, oft aber
in sehr alten Versionen, die aufgrund von Firmwareblobs oder wegen nicht
standardisierter Schnittstellen nicht gut upgedated werden können.
Ideal wäre, so ist man sich an dieser Stelle einig, eine Auswahl gut
dokumentierter Switch-ICs in verschiedenen Leistungsklassen und von
verschiedenen Herstellern, und ein guter Support dieser Hardware in mainline
Linux. Damit wäre es sowohl für Hersteller von whitebox-Hardware, also
generischen Hardwaremodulen, als auch für die Hersteller von Endgeräten möglich,
den Anwendern im Feld stets aktuelle und gut gepflegte Softwarestände für
entsprechende Geräte auszuliefern.</p>
<div class="section" id="introduction-to-time-synchronization">
<h4>Introduction to time synchronization</h4>
<p>In der ersten Session des Tages erklärt Maciek Machnikowski die präzise
Zeitsynchronisation mehrerer Systeme über eine Netzwerkverbindung mittels PTP.
Das "Precision Time Protocol", oder eben kurz PTP ist in IEEE1588 standardisiert
und ermöglicht die eine konfigurationsfreie Synchronisation mehrerer Systeme
über Netzwerk im Nanosekundenbereich.</p>
<p>Nach einer Einführung in die Motivation führte Maciek kurz in die verschiedenen
Komponenten ein, die in einem Linux-System für die präzise Erfassung von
Zeitpunkten zuständig sind (die sog. PTP Hardware Clock, oder kurz PHC),
sowie die verschiedenen Pfade, über die im Kernel die für den PTP-Dämon
notwendigen Informationen bis in den Userspace transportiert werden.</p>
<p>Einen größeren Teil seines Talks widmet Maciek praktischen Beispielen und Tools
aus der ptp4l-Suite, die verwendet werden:</p>
<ul class="simple">
<li><tt class="docutils literal">ptp4l</tt>, der Haupt-Dämon, der die Synchronisation von Leader und Follower-
Clock (für die älteren unter uns: Grandmaster und Slave) sowie die Abhandlung
des Best Master Clock Algorithm BMCA implementiert</li>
<li><tt class="docutils literal">ts2phc</tt>, mit dem Time Events, etwa die PHC auf Pulse per Second (PPS) Events
aus einer präzisen Uhr (z.B. einem GNSS-Empfänger) in die PTP Hardwareclock
synchronisiert werden.
<tt class="docutils literal">ts2phc</tt> unterstützt zudem das Parsen von NMEA-Strings, die von GNSS-Empfängern
über UART verschickt werden und die Time of Day enthalten.</li>
<li><tt class="docutils literal">phc2sys</tt>, um die Systemzeit auf die PTP Hardware Clock zu synchronisieren</li>
<li><tt class="docutils literal">pmc</tt> um Debugging Informationen aus den verschiedenen Komponenten auszulesen</li>
<li><tt class="docutils literal">timemaster</tt> zur Synchronisation von PTP und NTP</li>
<li><tt class="docutils literal">phc_ctl</tt> zum Debugging der PTP Hardware Clock</li>
</ul>
<p>Nach diesem sehr praxisnahen Teil geht Maciek kurz auf die Unterschiede der
verschiedenen Profiles von PTP ein, die in ptp4l unterstützt werden.
Er erläutert, dass alle praxisrelevanten Profile in ptp4l unterstützt werden,
dass aber einige wenige Features gewissen Einschränkungen unterliegen.</p>
<p>Zum Abschluss seines Talks geht Maciek am Beispiel eines einfachen Setups noch
kurz auf die Einschränkungen und häufige Schwierigkeiten bei Aufbau eines PTP-
Setups ein und gibt einen kurzen Ausblick auf das bevorstehende Release von
ptp4l 4.0.</p>
<p>Nach der Mittagspause mit üppigem Lunchpaket stehen Talks auf dem Programm,
die für Embedded-Anwendungen nur von eingeschränkter Bedeutung sind,
dennoch aber einen guten Überblick über die Vielfalt der Anforderungen im
Network-Subsystem des Kernels geben.</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 diesem Workshop erläuterte Jamal Hadi Salim die Grundlagen von P4 und die
die Integration von P4 in den Linux Kernel als P4TC.
P4 steht für das "Programming Protocol-independent Packet Processors" Ökosystem,
einer Programmiersprache für Packet Forwarding Planes in Netzwerkgeräten,
also einer Programmiersprache, mit der beschrieben werden kann, wie
Netzwerkpakete direkt in Hardware an ihr Ziel weitergeleitet werden können,
ohne dabei CPU-Last zu erzeugen.</p>
<p>Während P4 schon seit einiger Zeit existiert und sich auch als Industriestandard
für die Beschreibung der Packet Forwarding Plane herausgestellt hat, ist bislang
kein direkter Support dafür im Kernel verfügbar.
Mit P4TC soll nun der Kernel um die Möglichkeit erweitert werden -analog zu BPF-
externe P4-Skripte nachzuladen.
Diese werden in Kombination mit einer Beschreibung der Hardware-Capabilities
dann entsprechend so kompiliert, dass möglichst viele Aufgaben in Hardware,
typischerweise Smart NICs, Neural Accelerators oder Mesh-Processors,
ausgeführt werden, während der verbleibende Teil der Aufgaben transparent in
Software übernommen wird.</p>
<p>Eine weitere Motivation für die Initiatoren des Projekts bei Intel war, dass mit
P4TC Traffic Control Features implementiert werden können, ohne dafür
Kernelmodules kompilieren zu müssen, was im Datacenter-Umfeld aus verschiedenen,
teils regulatorischen, teils organisatorischen Gründen bisher gewisse Hürden
bedeutet habe.</p>
<p>Weiter würde man sich so das aufwändige Mainlining des Traffic Control
Offloading ersparen, was jedoch in der anschließenden Diskussion auf ein sehr
gemischtes Echo stieß.
Auch aus den Reihen des FRR zeigte sich hier noch Diskussionsbedarf, da für eine
effiziente Implementierung für häufig verwendete Routen das Hardware-Offloading
verwendet werden sollte, während für seltener verwendete Routen oft kein Platz
in den beschränkten Ressourcen der Hardware vorhanden ist. Um die vorhandenen
Ressourcen optimal auszunutzen wäre dafür ein Kommunikationskanal zwischen dem
Routing-Daemon im Userspace und P4TC nötig. Es zeichnet sich ab, dass an dieser
Stelle noch Erweiterungen des Offload-Flags in switchdev erforderlich werden.</p>
</div>
<div class="section" id="rdma-programming-tutorial">
<h4>RDMA programming tutorial</h4>
<p>Im letzten Talk des Tages wurde von Roland Dreier anhand von Beispielen die
Grundlagen der Remote DMA und die Programmierung von Anwendungen gegen dieses
Framework erläutert.</p>
<p>RDMA ist ein primär aus der Big Data- und Datacenter-Welt stammendes Feature,
das schon seit etlichen Jahren das Übertragen von Speicherinhalten über das
Netzwerk ermöglicht, ohne dass dabei die CPUs des angesprochenen Speichers
explizit Code ausführen müssen. Es wird also über das Netzwerk remote auf RAM
zugegriffen, ähnlich eines lokalen DMA-Zugriffes.</p>
<p>Nach einer Einführung über die verschiedenen Ausprägungen von Asynchronous
Queues gab Roland einen Überblick über die Eingliederung in die verschiedenen
Subsysteme des Kernels und die verwendeten Abstraktionen.</p>
<p>Da verschiedene Implementierungen in Layer 2 und Layer 3 existieren, ist die
Verwendung von RDMA nicht mehr auf die wohl populärste Implementierung
Infiniband beschränkt, mit rxe steht im Kernel eine Soft-roCE-Implementierung
zur Verfügung, die über gewöhnliches Ethernet verwendet werden kann.</p>
<p>Nach einem kurzen Überblick über die Userspace Libraries librdmacm zum
Verbindungsaufbau und libibverbs für die eigentlichen Requests und Datapath
Operations zeigte Roland anhand einiger Code Snippets, wie eine Applikation
über RDMA Speicher mit einem lokalen Prozess oder einem entfernten Device
austauschen kann.</p>
<p>Für Details empfiehlt sich, die Beispiele aus dem Repository
<a href="https://github.com/linux-rdma/rdma-core">RDMA Core</a> zu analysieren.</p>
</div>
</div>
<div class="section" id="tag-2">
<h3>Tag 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><div class="section" id="xdp-workshop">
<h4>XDP Workshop</h4>
<p>Der zweite Tag der NetDev 0x16 begann mit einem Workshop zu XDP.
Der Express Data Path ist eine Möglichkeit, mittels eBPF (extended Berkeley
Packet Filter) für Netzwerkpakete bereits sehr früh nach dem Empfangsinterrupt
zu entscheiden, ob das Paket verworfen, in den Netzwerkstack weitergegeben, oder
zurück an eine Netzwerkkarte weiter geschickt werden soll.</p>
<p>Zudem können Pakete an einem großen Teil des Netzwerkstacks vorbei direkt in den
Userspace geschleust werden, um für spezielle Anwendungen mit hohem Durchsatz
die Performance zu steigern.</p>
<p>Im Workshop wurden die aktuellsten Änderungen Entwicklungen in diesem Umfeld
vorgestellt, etwa Dynamic Pointers von Joanne Kong, die damit für Meta eine
Möglichkeit implementiert hat, um auch Daten interagieren zu können,
deren Größe zur Compilezeit eines BPF-Programms noch nicht bekannt ist.</p>
<p>Auch zu den anderen Themen, wie die XDP_Hints zur besseren Annotation von
XDP-Puffern mit Metadaten oder die Arbeit von Zhan Xue (Intel),
um mit XDP_REDIRECT zu Pakete direkt in Hardwarebeschleuniger,
etwa für Kryptographie,
umleiten zu können,
wurde lebhaft diskutiert.</p>
<p>Aus der Sicht eines Embedded-Entwicklers ist diese Technologie sehr spannend,
insbesondere Anwendungen wie die Dekompression von Videostreams über
Netzwerkverbindungen in entsprechenden Hardwarebeschleunigern drängt sich
förmlich auf.</p>
<p>Ob die Infrastruktur hier alle erforderlichen Anbindungspunkte zur Verfügung
stellt, wird zu beobachten bleiben,
aber es ist sehr spannend hier zu überlegen,
welche weitere Anwendungen die hier vorgestellten Entwicklungen ermöglichen
könnten.</p>
<p>Auch hier zeigt sich wieder die Stärke der Entwicklung in einer lebendigen
Community, bei der Experten aus verschiedenen Hintergründen zusammen kommen,
und gemeinsam Design und Entwicklung der Subsysteme vorantreiben.</p>
<p>In den Kaffeepausen spinnen sich diese Überlegungen im gemeinsamen Gespräch fort.
Dies ist eine wertvolle Ergänzung zu den sonst üblichen Diskussionen auf den
Mailing Lists und ermöglicht einen direkteren und schnelleren Austausch von
Meinungen, Erfahrungen und Ideen.</p>
<p>So hatte ich heute beispielsweise die seltene Möglichkeit,
mit einigen Entwicklern, die wie ich an TSN (Time Sensitive Networking)
arbeiten, über die aktuellen Entwicklungen zu FRER (Frame Replication and
Duplicate Elimination for Reliability) und Implementierungsvarianten
aktueller RFCs (Request for Comments) aus den DetNet (Deterministic Networking)
Workinggroups der IETF zur redundanten Datenübertragung von Echtzeitdaten in
Netzwerken zu diskutieren.</p>
</div>
<div class="section" id="frr-workshop">
<h4>FRR Workshop</h4>
<p>In der zweiten Session des Tages zeigten die Entwickler von FRRouting die
aktuellen Entwicklungen und Verbesserungen an der Free Routing Protocol Suite.
Mobashshera Rasool von VMWare präsentierte die Designentscheidung und den
Support für MLD (Multicast Listener Discovery) und PIM (Protocol Independent
Multicast), die nun für IPv4 und IPv6 über den pimd daemon in FRR verfügbar
sind, nachdem der dafür benötigte technische Unterbau bereits seit Kernelversion
4.19 in mainline ist.</p>
<p>Dank der Arbeit von Dr. Olivier Dugeon von Orange Innovation Network ist in FRR
nun auch Segment Routing verfügbar.
Dabei kann an ein Netzwerkpaket eine Liste mit Segment Identifiers angehängt
werden, die den Pfad des Pakets durch das Netzwerk bestimmen.
Im Gegensatz zu regulären Routing-Algorithmen kann so eine Mehrzahl ringfreier
Pfade durch ein Netz aufgespannt werden,
um beispielsweise redundante Pakete über mehrere Routen zu schicken und so dem
Ausfall von Links in Echtzeitanwendungen zu begegnen.
Diese Technologie wird bereits jetzt in verschiedenen kommerziellen Routern
implementiert, diese sind voll kompatibel zur Implementierung in FRR.</p>
<p>Auch für Embedded ergeben sich im Zusammenspiel mit DetNet viele interessante
Praxisanwendungen, beispielsweise das explizite Aufspannen redundanter
Echtzeitlinks in einem Netz.
Sicherlich wird es nicht lange dauern, bis auch für diese Anwendungen Segment
Routing in freier Wildbahn gesichtet wird.</p>
<p>Abschließend gab Donald Sharp einen Überblick über die aktuellen Entwicklungen
und einen Ausblick auf die Features im nächsten FRR-Release.
Neben vielen inkrementellen Verbesserungen, Bugfixes und einer kontinuierlich
gesteigerten Codequalität wurden dabei besonders die Bemühungen von Donatas
Abraitas erwähnt,
die kontinuierlichen Änderungen im BGP (Border Gateway Protocol) nachzupflegen.</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>Nach dem Mittagessen hielt Oleksij Rempel von Pengutronix gleich zwei Talks.
In "Network view of embedded specific challenges for non-embedded network
developers" gab Oleksij einen Überblick über verschiedene Praxisbeispiele aus
dem Arbeitsalltag eines Kernelhackers mit Fokus auf Embedded Hardware.</p>
<p>Oleksij führte dabei zuerst die Unterschiede zwischen Embedded und nicht-
Embedded-Anwendungen aus.
Obwohl die Grenzen zunehmend verschwimmen, gibt es im Embedded-Umfeld einige
speziellere Einschränkungen wie beispielsweise Power Constraints oder maximale
Initialisierungszeiten von Verbindungen.
Analog zur Aufweichung der Grenze zwischen embedded Devices und nicht-embedded
devices werden auch im Embedded-Umfeld Feld- und Onboard-Busse wie CAN zunehmend
durch Ethernet ersetzt.
Dennoch zeigt sich, dass für embedded Usecases und Anforderungen oft erheblich
von herkömmlichen IT-Usecases abweichen.
Als Beispiel nennt Oleksij die fq_codel queuing discipline,
die für TCP gut einsetzbar ist, sich beim Einsatz für CAN-Busse
aber als sehr problematisch herausstellt.
Da Linux zunehmend auch in embedded-Anwendungen eingesetzt wird,
sollten Entwickler auch für die besonderen Anforderungen dieses Umfelds
sensibilisiert werden.
Als weiteres Beispiel führt Oleksij die verschiedenen Feldbusse im
Automotive-Umfeld auf, von denen nur CAN mainline ist,
die aber zunehmend durch Ethernet ersetzt werden.
Aufgrund der abweichenden Anforderungen bilden sich jedoch auch hier vom Default
abweichende Substandards, etwa Base-T1 über Twisted Pair, aus.
Dies ist vor allem der Optimierung und Reduktion von Kosten, Performance und
Energieverbrauch geschuldet.
Weitere Anforderungen ergeben sich aus den Timing Requirements der Anwendungen,
zum Beispiel kann für Automotive-Anwendungen keine Autonegotiation verwendet
werden, da dieser Vorgang zu lange dauert,
ein Link muss binnen weniger Millisekunden aktiviert werden.
Hierfür müssen bestehende Konfigurationsinterfaces erweitert werden.</p>
<p>Als weiteres Beispiel nennt Oleksij Explosionsgeschützte Bereiche.
In diesen ist die Energiemenge in einem System auf eine bestimmte Menge
begrenzt, was auch Netzwerkverbindungen vor besondere Herausforderungen stellt.
Mit 10Base-T1L kann die Amplitude des Links auf 1.0Vpp begrenzt werden,
was den Einsatz in einer explosionsgefährdeten Umgebung erlaubt.
Support für diesen Standard wurden aktuell im Kernel hinzugefügt,
erfordern aber Änderungen, um beispielsweise Verbindungen mit Gegenstellen zu
unterbinden, die 2.4Vpp-Links in der Autonegotiation annoncieren.</p>
<p>Ein weiteres Beispiel ist eine spezielle Implementierungsvariante für
Linkredundanz, bei der mehrerer Phys an eine MAC angebunden werden.
Hierfür existiert keine passende Abstraktion im Kernel, es findet daher aktuell
auf der Mailingliste eine Diskussion diesbezüglich statt.
Eine weitere Variante dieser Anwendung ist die Anbindung mehrerer Phys an einem
MAC, um in Layer 1 verschiedene Standards unterstützen zu können.</p>
<p>Ähnliche Herausforderungen ergeben sich aus den Kommunikationsketten von
MDIO-Links für SFP-Cages.</p>
<p>Anhand dieser Beispiele zeigt Oleksij, welche Auswirkungen die Anforderungen
im Kernel haben.
Teils können für die Umsetzung der Anforderungen bereits vorhandene
Schnittstellen erweitert werden,
jedoch ist teils auch erforderlich,
komplett neue Schnittstellen im Kernel zu schaffen.</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 seinem direkt darauf folgenden zweiten Talk erklärt Oleksij,
wie Link Diagnostics in Ethernet implementiert werden kann.</p>
<p>Oft wird Link Diagnostics,
also die Erkennung von Fehlern in den physical links,
etwa defekte Kabel, Stecker, usw.,
von Hardwareherstellern nicht als wichtiges Feature angesehen.
Die Beiträge hierzu im Kernel stammen daher meist von individual contributors,
oftmals Hobbyisten.
Gerade im Feld ist jedoch genau dieses Feature in vielen Anwendungen dringend
erforderlich.
Oleksij führt aus, dass sehr viele verschiedene Fehlermodi existieren
(Kurzschlüsse, Erdschlüsse, Kabelbrüche, etc der verschiedenen Kabeladerpaare).</p>
<p>Mit dem Kommando</p>
<blockquote>
ethtool -t eth0</blockquote>
<p>kann ein Selbsttest von MAC und PHY durchgeführt werden,
womit in einem aktuellen Kernel der Phy in den Loopback-Modus geschaltet wird.
Dadurch können Fehler in der Strecke zwischen MAC und PHY erkannt werden.</p>
<p>Mit dem Kommando</p>
<blockquote>
ethtool --cable-test eth0</blockquote>
<p>kann ein grundlegender Kabeltest durchgeführt werden.</p>
<p>Über das Kommando</p>
<blockquote>
ethtool eth0 | grep -i sqi</blockquote>
<p>kann bestimmt werden, ob der Phy zu eth0 die Bestimmung des Signal Quality
Index (SQI) unterstützt.</p>
<p>Der Selftest kann bezüglich seiner Funktionalität noch erweitert werden,
was allerdings eine Kommunikationsmöglichkeit zum Linkpartner erfordert.</p>
<p>Weiter funktionieren cable tests meistens nur gut, wenn die Gegenstelle
ausgeschaltet ist, da ansonsten die Fast Link Pulses (FLPs) der
Autonegotiation das Messergebnis verfälschen.</p>
<p>Um zu zeigen, wie diesem Problem abgeholfen werden kann,
erklärt Oleksij zunächst,
wie ein Kabeltest mittels Time Domain Reflectometry (TDR) funktioniert.
Dazu wird vom Phy ein Pulse auf ein Kabel angelegt,
dessen Ausbreitung und Reflexion der Phy ausmisst.
Anhand des Messegebnisses kann zwischen Kabelbruch, Kurz- oder Erdschluss und
korrekt funktionierenden Kabeln unterschieden werden.
Die Abtastrate des Phys bestimmt dabei die Präzision der Messung,
üblich ist eine Messgenauigkeit von 80 cm.</p>
<p>Anschließend erklärt Oleksij,
dass für die Autonegotiation ebenfalls Pulse auf den Link angelegt werden,
die die Messergebnise der TDR verfälschen können.</p>
<p>Oleksij schlägt vor, das Autonegotiation-Flag "remote fault" in den Fast Link
Pulses zu verwenden, das eine Sendepause in der Autonegotiation erzwingt.
In der entstehenden Stille könnte eine Messung mit TDR vorgenommen werden.
Da die Autonegotiation Pulse bei einer niedrigeren Frequenz arbeiten als der
reguläre Ethernet Link, ist die Wahrscheinlichkeit groß,
dass diese auch noch bei einem gewissen Beschädigungsgrad des Links bei der
Gegenstelle ankommen.
Im Link Code Word der FLP der Autonegotiation könnten Bit 13("RF) und Bit 15
("NP") hierfür verwendet werden.
Das RF-Flag (Remote Fault) indiziert dabei einen allgemeinen Fehler,
das NP-Flag ("Next Page") dient dazu, noch weitere Pages zu ergänzen,
um präzisere Anforderungen zu kommunizieren.</p>
<p>Hierfür müsste eine vendor specific Message verwendet werden.</p>
<p>Oleksij hat einen ersten
<a href="https://lore.kernel.org/all/20220608093403.3999446-1-o.rempel@pengutronix.de/">Patch</a>
hierfür auf die Netdev Mailinglist geschickt und
lädt zum allgemeinen Review und zur Diskussion ein.</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>Zum Abschluss der Vorträge habe ich noch meinen eigenen Talk gehalten.
In diesem Talk habe ich die grundlegenden Anforderungen an Echtzeitnetzwerke
zusammengefasst: Zeitsynchronisation, Maximale Übertragungsdauern und Quality of
Service, also die garantierte Übertragung von priorisierten Inhalten.
Ich habe dann Implementierungsversuche mit herkömmlichem Ethernet der
Implementierung mittels TSN gegenübergestellt und erläutert,
mit welchen Migrationsstrategien man im Feld befindliche Systeme systematisch
upgraden kann, bis ein System voll TSN-fähig ist.</p>
<p>Zum Abschluss meines Talks habe ich die Entwickler motiviert, mehr
Dokumentation, Beispiele und Tests zu ergänzen,
um Systemingenieure und Endanwender besser in die Lage zu versetzten,
diese neuen Technologien auch einzusetzen.</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>Nach Ende der Talks ergab sich beim Social Event noch die Möglichkeit,
sich mit Maintainern und Entwicklern auszutauschen und die Menschen hinter den
Postings auf der Mailinglist kennenzulernen.</p>
</div>
</div>
<div class="section" id="tag-3">
<h3>Tag 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>Der dritte Tag der Netdevcon steht im Zeichen des Datacenter Networking.
Obwohl die Anforderungen für diese Anwendung deutlich von den meisten
Embedded Usecases abweichen, ermöglichen die Talks zu diesen Themen einen
spannenden Blick über den Tellerrand.</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 seiner Keynote stellt John Ousterhout vor,
warum TCP sich zwar verbreitet hat,
aber für Datacenter-Anwendungen eigentlich relativ ungeeignet ist.</p>
<p>Er zeigt ausführlich, dass die grundlegenden Eigenschaften des Protokolls den
fundamentalen Anforderungen an diese relativ spezielle Workload diametral
gegenüberstehen,
weshalb es nicht möglich ist,
TCP nennenswert für diese Anwendung zu verbessern oder zu erweitern.</p>
<p>Aus den Ergebnissen seiner Forschung hat seine Arbeitsgruppe das HOMA-Protokoll
entwickelt,
dessen Vorteile ausführlich diskutiert und mit Messergebnissen demonstriert
wurden.
Obwohl bereits für die aktuelle Softwareimplementierung gegenüber TCP für
typische Datacenter-Workloads Performanceverbesserungen um mehr als eine
Größenordnung erreicht werden können,
wird zum Erreichen der in Line-Rate, also der theoretisch verfügbaren Bandbreite,
auch für HOMA ein Hardwareoffloading in den Netzwerkkarten nötig werden.</p>
</div>
<div class="section" id="homals-tunneling-messages-through-secure-segments">
<h4>HomaLS: Tunneling messages through secure segments</h4>
<p>Im Folgetalk zeigt Tianyi Gao, wie HOMA-Segmente analog zu DCTCP-Segmenten
verschlüsselt werden können.
Er präsentiert einen Prototyp seiner Implementierung für Hardwareoffloading auf
Mellanox CX16 und stellt erste Messungen vor,
die bereits jetzt schon 20% Verbesserung gegenüber den üblichen DCTCP
Implementierungen erreichen.</p>
</div>
<div class="section" id="dcpim-lowlatency-highthroughput-receiverdriven-transport-protocol">
<h4>dcPIM: Low–latency, High–throughput, Receiver–driven Transport Protocol</h4>
<p>Im darauf folgenden Talk wurde ein erster Ausblick auf die Herausforderungen für
Link Speeds >200Gbps, sog. Terabit-Links, in Datacenters gegeben.
Anhand von Messungen wurde verdeutlicht, dass die Hauptquelle von Latenzen dabei
die Residence Time in Switches ist.
Bei Terabit-Ethernet benötigen kleine Netzwerkpakete nur wenige Mikrosekunden um
versendet zu werden, weshalb die Switchqueues erheblich beim Datendurchsatz ins
Kontor schlagen.
Da die Architektur von Datacenters und die Datenflüsse dort selbst wie die
Architektur eines Switches aussehen, schlagen Qizhe Cai und Rachit Agarwal daher
vor,
die in Switches zur Lösung dieses Problems bereits verwendete Methode des
Parallel Iterative Matching zur Variante Datacenter Parallel Iterative Matching
(dcPIM) weiterzuentwickeln, die in einem iterativen Prozess eine optimale
Zuordnung von Datenströmen auf Links und Ressourcen vornimmt.</p>
<p>Da das mathematische Modell dahinter gut erforscht ist, schnell konvergiert und
zudem keine Änderungen an den verwendeten Protokollen oder APIs erforderlich
sind,
gehen die Autoren davon aus, dass sich dieser Ansatz reibungslos deployen lässt.</p>
<p>Nach diesem eher theorielastigen Vormittag mit vielen Anwendungsfällen, die sehr
weit von den üblichen Embedded-Usecases meiner täglichen Arbeit entfernt sind,
ergab sich beim Mittagessen einige interessante Kontakte und Diskussionen, unter
anderem mit Entwicklern aus dem WiFi-Stack, die am Ende im gemeinsamen Review
eines 5 Jahre alten Proof of Concept Codes endete, der überraschend gut auf die
aktuellen Multilink-Erweiterungen in den aktuellen Iterationen der Wifi-Standards
anwendbar ist.</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>Nach der Mittagspause zeigte Alexander Aring in seinem Talk, wie über mehrere
physische oder virtuelle Maschinen eines Rechnerclusters verteilt mit trace-cmd
zeitsynchronisiert Traces aufgezeichnet,
ins slog2sdk-Format umgewandelt und mittels jumpshot analysiert werden können,
um das DLM lock protocol in einer GANTT-ähnlichen Darstellung leichter
untersuchen zu können.</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>In ihrem Talk zeigten Nishanth Shyamkumar, Piotr Raczynski, Dave Cremins,
Michal Kubiak und Ashok Sunder Rajan,
wie sie ein klassisches Setup einer 4G Basisstation von Proprietärer Software
auf proprietärer Hardware mit proprietären Betriebssystemen (was in der
Telekommunikationsindustrie über lange Jahre so üblich war) auf Standard-Server
umstellen konnten,
indem sie die Softwarekomponenten für mehrere Basisstationen in Docker-
Containern laufen ließen.</p>
<p>Die Hauptherausforderung dabei stellte die effiziente Anbindung der einzelnen
Container an die Netzwerkhardware des Hostsystems dar,
was jedoch mit SRIOV und AF_XDP zero copy gut gelöst werden konnte.</p>
<p>Dies ermöglicht,
die Infrastruktur auf erheblich günstigerer Hardware zu betreiben
und dadurch beim Ausrollen und im Betrieb von Mobilfunkinfrastruktur erheblich
Kosten zu sparen.</p>
<p>Hier lassen sich wohl auch erste Lehren für die effiziente Anbindung von
Hardware in Containern ziehen, die auch für Embedded-Anwendungen relevant werden
könnten,
sodass dieser Talk nicht nur wegen der 20-fachen Performancesteigerung im
Vergleich zur initialen Trivialimplementierung sehr spannend war.</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 und Namrata Limaye
zeigten in ihrem Talk, wie sich mit P4 unter Zuhilfenahme von einer
Infrastructure Processing Unit (IPU) erhebliche Performancezugewinne beim
Layer2 Forwarding, Routing und VxLAN erreichen lassen.</p>
<p>Vermutlich werden sich die bei unseren Kunden üblichen Anforderungen nie in dem
hier avisierten Durchsatz- und Performancebereich bewegen,
dennoch ist es spannend zu beobachten, wie hier mit neuen Ideen dem Ende von
Moore's Law ein Schnippchen geschlagen werden soll.</p>
</div>
<div class="section" id="high-performance-programmable-parsers">
<h4>High Performance Programmable Parsers</h4>
<p>Der letzte Talk des Tages von Tom A. Herbert wiederum zeigte einen interessanten
Lösungsansatz für ein Problem,
das auch im embedded-Umfeld durchaus häufig zu beobachten ist.
Recht häufig müssen Netzwerkpakete geparst,
also die einzelnen Felder in einem Datenframe analysiert werden,
um aus einem Paket alle erforderlichen Informationen zu extrahieren.</p>
<p>Die dafür nötige Software, ein sogenannter Parser,
wird konventionell meistens händisch implementiert,
was ein sehr mühsames und dadurch langwieriges Verfahren ist.</p>
<p>Tom stellt in seinem Talk vor, wie mit der CPL, der Common Parser Language,
in einem json File deklarativ ein Protokoll beschrieben werden kann.
Aus dieser Beschreibung kann dann ein Parser erzeugt werden, der über die
kparser Infrastruktur später im Kernel zum Parsen von Netzwerkpaketen verwendet
werden kann.
In Kombination mit XDP und eBPF kann so ein eintreffendes Paket einfach und
effizient untersucht,
und an den Netzwerkstack oder über den Express Data Path an den betreffenden
Empfänger weitergeleitet werden.</p>
<p>Zum Abschluss zeigt Tom, wie sich Hardwareoffloading über P4 auch in dieser
Infrastruktur einbinden lässt,
jedoch sind dafür noch einige Herausforderungen zu meistern.
Ich bin gespannt, ob wir schon bald auch im ein oder anderen Projekt von dieser
Technologie Gebrauch machen können,
und dadurch für unseren Kunden deutlich Entwicklungszeit einsparen können.</p>
</div>
</div>
<div class="section" id="tag-4">
<h3>Tag 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>Der vierte Tag der NetDev 0x16 sammelte Talks zu vielen verschiedenen Themen aus
dem Netzwerkumfeld, und war daher besonders abwechslungsreich.</p>
<div class="section" id="when-regular-expressions-meet-xdp">
<h4>When regular expressions meet XDP</h4>
<p>Im ersten Talk des Tages erklärte Ivan Koveshnikov, wie er bei
GCore DDoS-Protection für Game Traffic mit regex im XDP implementiert.
Da für diese Anwendung vor allem kleine UDP-Pakete zu parsen sind,
die zudem sehr regelmäßige Strukturen aufweisen,
bietet sich ein Parsing mit regex an.</p>
<p>Zum regex matching setzen sie die BSD-Lizensierte Engine Hyperscan ein,
die oft auch für deep packet inspection verwendet wird und bereits für das
hochperformante scannen von Netzwerkpaketen optimiert ist.
Für eine effiziente Implementierung von Regex in eBPF-Programmen sind aufgrund
der Größe der Regex und wegen Limitierungen von eBPF bezüglich der Verfügbarkeit
von Vector Instructions (XDP läuft in einem SoftIRQ-Kontext, wo die FPU-
Instructions nicht verfügbar sind),
verschiedene Anpassungen am Kernel notwendig.
Ivan erklärt, dass sie daher das Speichern und wiederherstellen des FPU state
in SoftIRQs implementiert haben, was allerdings erfordert,
Interrupts und Preemptions auszuschalten, sobald FPU load/store instructions
verwendet werden.
Dadurch sind auch die Vector instructions verfügbar und der regex parser kann
sehr effizient in einem eBPF Helper ausgeführt werden.</p>
<p>Zur Konfiguration können entweder eBPF maps verwendet werden,
die zwar bereits Synchronisation mitbringen,
aber eine fixe Größe der Einträge erzwingen und applikationsspezifisch sind,
oder Einträge in einem configfs.</p>
<p>Wegen der größeren Flexibilität eines configFS haben sie sich für diese
Implementierungsvariante entschieden.</p>
<p>Anschließend präsentierte Ivan einige Benchmarks,
die sie im Fall der XDP_DROP (also für verworfene Pakete) und XDP_TX
(also für weitergeleitete Pakete) erreichen konnten.</p>
<p>Für Pakete größer als einige Hundert Bytes Payload kann ihre Lösung invalide
Pakete "at line rate" verwerfen,
also so schnell wie das angebundene Netzwerk,
die Weiterleitung der für gut befundenen Pakete ist etwas aufwändiger.
Hier sieht Ivan noch Verbesserungspotential,
obwohl das neue System bereits schon jetzt erfolgreich produktiv eingesetzt
werden kann.</p>
<p>Am Ende seines Talks ruft Ivan die Hersteller von Netzwerkkarten dazu auf,
die Interaktion von XDP mit Hardwareoffloading zu verbessern,
da in den Treibern oft nur DPDK (Dataplane Development Kit)-Support,
aber keine oder nur unzureichende Unterstützung für XDP vorgesehen wurde.
Besonders die XDP Hints sieht er hier als einen möglichen Weg,
diese Situation zu verbessern.</p>
<p>Ivan stellt seinen Code auf <a href="https://github.com/G-Core/linux-regex-module">Github</a>
zur Verfügung und motiviert die Zuhörer, ihre eigenen Messungen durchzuführen.</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>Im anschließenden Talk wurde die Forschungsarbeit von Qizhe Cai, Midhul
Vuppalapati, Jaehyun Hwang, Christos Kozyrakis, und Rachit Agarwal vorgestellt.
Sie stellten nach einem Upgrade ihres Netzwerklabors von 10GBit auf agreggierte
100GBit Links fest,
dass sich aus der grundlegenden Struktur des Netzwerkstacks Beschränkungen der
Performance für schnelle Links ergeben.</p>
<p>Die zugrundeliegende Architektur mit einem Pipelinekonzept ist nur schwer zu
optimieren, da die Anforderungen für langlebige Datenflüsse und kurze
Datenbursts Änderungen an sehr vielen verschiedenen Stellen erfordern,
die viele Querabhängigkeiten haben.</p>
<p>Sie schlagen daher vor,
die grundlegende Architektur ähnlich dem Linux Storage Subsystem mit loosely
coupled layers zu implementieren.</p>
<p>In einem ersten Prototyp,
den sie auf <a href="https://github.com/Terabit-Ethernet/NetChannel">Github</a> bereits
veröffentlicht haben,
konnten sie bereits sehr beeindruckende Performancezuwächse erreichen.</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>PJ Waskiewicz stellte anschließend die Besonderheiten der Anforderungen an die
Netzwerkinfrastruktur für High-Speed-Trading vor.
Diese Welt liegt hinter einem Schleier aus Geschäftsgeheimnissen verborgen,
dennoch konnte PJ strukturiert die Grundzüge dieser sehr ungewöhnlichen Welt
vermitteln.
Während die Anbindung an die Börsenplätze noch mit konventionellen 10Gbps
Ethernet-Links erfolgt,
werden die Entscheidungen über die zu tätigenden Käufe und Verkäufe in High
Performance Computing Clustern getroffen,
in welchen die entsprechenden Inferenzmodelle teils in Software,
teils in Hardware ausgeführt werden.</p>
<p>In beiden Fällen sind hohe Performance,
niedrige Latenz,
besonders aber deterministische und vorhersagbare Latenz der
Netzwerkkommunikation absolut unabdingbar,
um Wartezeiten zu vermeiden.
Diese würden letztlich zu schlechteren Ergebnissen in den Finanztransaktionen
führen.</p>
<p>Auf Seite des Betriebssystems zeigte PJ,
wie die auch bei vielen Embeddedanwendungen durchgeführten Optimierungen, etwa
der Einsatz von RT_PREEMPT,
CPU Isolation,
Interrupt Pinning,
Wahl geeigneter CPU Power States usw.
nicht nur die Average Case und Median,
sondern auch die Worst Case Performance erheblich verbessern.
Eine erstaunliche Erkenntnis für diesen speziellen Anwendungszweck ist der
Verlust von Determinismus durch die SoftIRQs im Empfangspfad,
was in dieser Anwendung schlicht durch permanentes Polling umgangen wird.</p>
<p>Im Bereich der High Performance Computing Cluster herrscht auch heute noch RDMA
als Kommunikationsmedium der Wahl, oft über Infiniband, vor.
Hier erhofft PJ sich insbesondere von io_uring und XDP weitere
Performancesteigerungen.
Es wird mittlerweile immer schwieriger,
erfahrene Entwickler und Administratoren für diese Technologien zu finden
oder neu auszubilden, zudem ist Infiniband als Nischenprodukt extrem teuer.
PJ wirft daher die Frage auf,
in wieweit RoCE oder iWARP die genannten Anforderungen erfüllen können,
besonders bei converged Networks,
also im Mischbetrieb mit konventionellem Ethernettraffic.</p>
<p>Auch neue Kandidaten wie HOMA werden in der Industrie mit großem Interesse
untersucht, jedoch muss weiter eine so niedrige Latenz wie möglich und ein
minimaler Jitter gewährleistet sein.</p>
</div>
<div class="section" id="merging-the-networking-worlds">
<h4>Merging the Networking Worlds</h4>
<p>Nach diesem so interessanten wie speziellen Talk diskutieren David Ahem und
Shrijeet Mukherjee in ihrem Talk über eine Kombination von Berkeley Sockets,
insbesondere für den Zugriff auf die Control PLane,
mit RDMA bzw. einer Verbs-basierten Kommunikation in der Data Plane.
Sie argumentieren, dass damit die Vorteile aus diesen beiden Welten für
hochperformante Datenübertragung im Netzwerk vereint werden könnten.</p>
<p>Nach den Verschiedenen Talks, in denen die Ablösung der "alten Welt" durch
eine bessere Zukunft postuliert wurde,
ist dieser Ansatz,
gut funktionierende und bekannte Infrastruktur zu behalten und das beste aus
beiden Welten zu vereinigen, -
zumindest aus Ansatz eines altgedienten Programmierers -
eine sehr angenehme Aussicht. Evolution statt 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 präsentiert die Ergebnisse ihrer Forschungsarbeit zur
Optimierung von TCP congestion control für die Kommunikation über geostationäre
und Low Orbit Satelliten.</p>
<p>Die Algorithmen, mit denen TCP die verwendeten Packetgrößen und Datenraten an
die verfügbaren Links anpasst,
skalieren per default nicht gut für diese Art von Link,
was wohl vor allem an den vergleichsweise langen Paket-Roundtriptimes über den
Satelliten-Link liegt.
Mit ihrer Forschungsarbeit konnte Maryam jedoch Parametersätze finden, die auch
mit den bereits implementierten Algorithmen eine deutlich bessere Performance
erreichen.</p>
</div>
<div class="section" id="the-tsn-building-blocks-in-linux">
<h4>The TSN building blocks in Linux</h4>
<p>Anschließend gab Ferenc Fejes vom Ericsson Research Traffic Lab nach einer
kurzen Einführung in die verschiedenen Standards zum Thema Time Sensitive
Networking eine ausführliche Übersicht über den aktuellen Stand der
Implementierung der einzelnen Komponenten in Linux.</p>
<p>Er zeigte dabei nicht nur die verwendeten Kernelkomponenten,
sondern stellte auch die dazugehörigen Userspace-Interfaces zur Konfiguration
sowie Möglichkeiten zum Hardwareoffloading vor.</p>
<p>Neben eigenen Messungen für einige der Komponenten zeigte er Beispiele für die
Konfiguration und diskutierte die noch offenen Themen,
beispielsweise die Anbindung der einzelnen Komponenten an
Netzwerkkonfigurationsprotokolle über entsprechende Daemons und Services.</p>
<p>Auch sollten seiner Ansicht nach dringend Selbsttests und Verifikationstools
implementiert werden,
um Anwender bei der Inbetriebnahme zu unterstützen,
eine Forderung der ich mich sehr gerne und sehr nachdrücklich anschließe.</p>
<p>Zum Schluss unterstrich Ferenc noch einmal,
dass durch die Verfügbarkeit von TSN-fähiger Switchhardware in den Switchdev-
und DSA-Frameworks bereits heute die entsprechende Hardware
als first class citizens unterstützt werden,
und dass auch das Hardwareoffloading bereits jetzt gut in die bestehende
Infrastruktur integriert werden kann
(und teils sogar bereits integriert ist).</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>Im darauf folgenden Talk demonstrierten Roopa Prabhu und Rohith Basavaraj,
wie sie in der Data Processing Unit DPU,
einem Hardwarebeschleuniger von Nvidia ein Hardwareoffloading von E-VPN
implementieren und dabei
erstaunliche Performance erreichen konnten.</p>
</div>
<div class="section" id="state-of-the-union-in-tcp-land">
<h4>State of the union in TCP land</h4>
<p>Im letzten Talk des Tages fasste Eric Dumazet die Entwicklungen des letzten
Jahres im Linux TCP-Stack zusammen.
Neben einer Verbesserungen im Bereich der Security handelt es sich dabei
primär um Performanceverbesserungen.</p>
</div>
<div class="section" id="kernel-selftests-und-switch-testing">
<h4>Kernel Selftests und Switch Testing</h4>
<p>Nach dem offiziellen Teil der Veranstaltung trafen sich noch einige Entwickler
vor Ort mit per Videocall zugeschalteten Kollegen aus Hildesheim,
um Strategien für In-Kernel-Selftest für Switches und eine Strategie für
Hardwaretests von Switches zu diskutieren.</p>
<p>Ein Prototyp aus der diesjährigen Pengutronix Techweek fand dabei regen Anklang,
und wir hoffen schon bald mit Integration neuer Exporter in Labgrid den Baustein
auch für andere Entwickler in der Community mit Testinfrastruktur unterstützen
zu können.</p>
</div>
</div>
<div class="section" id="tag-5">
<h3>Tag 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.bcd1e9bb891c9e00df8929c5e36c0e9d.jpg"/>
</a><figcaption itemprop="caption description" style="
width: 300px;
"><p>CC-BY: Johannes Zink</p>
</figcaption>
</figure>
</div><p>Der leider schon letzte Tag der NetDev 0x16 begann
nach den mittlerweile schon gewohnten Gesprächen beim ersten Kaffee des Tages
auf den Fluren des Centro de Congressos do Instituto Superior Técnico mit einem
Einblick in die aktuellen Entwicklungen bei 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 diesem Talk erläutert Antonio Quartulli die aktuellen
Optimierungsbestrebungen bei OpenVPN.
OpenVPN implementiert klassisch sowohl Control Plane als auch Data Plane für
VPN-Verbindungen im Userspace,
was zwar große Freiheit in der Implementierung bietet,
gegenüber einer Implementierung der Data Plane im Kernel allerdings auch
erhebliche Performance-Einbußen bedeutet.</p>
<p>Der zu verschlüsselnde Netzwerktraffic wird dabei bisher von den Anwendungen
(z.B. Webbrowser) durch ein tun-Device,
also ein Layer3-Tunneldevice,
in den Kernel,
und wieder zurück in die OpenVPN-Applikation im Userspace geschickt.</p>
<p>Diese verschlüsselt die Daten und schickt diese wieder in den Kernel,
der die Daten über den Netzwerkstack aufs Netz und damit an den VPN-Server
schickt.
Jedes Datenpaket muss daher doppelt durch die Kernel-Userspace-Boundary,
was zu erheblichen Performanceeinbußen gegenüber in-Kernel-Implementierungen
(wie wireguard, a.d.A.) führt.</p>
<p>Neben der Tatsache, dass die OpenVPN Applikation singlethreaded ist
und daher nicht von den mittlerweile oft reichlich verfügbaren Prozessorkernen
Gebrauch machen kann,
führt das dazu,
dass die Performance von OpenVPN mittlerweile deutlich hinter den in Hardware
verfügbaren Bandbreiten zurückbleibt.
Da die Codebase von OpenVPN bereits etwas in die Jahre gekommen ist,
hat Antonio nicht den Userspace-Code optimiert sondern untersucht,
wie sich dieses Problem durch ein Offloading der Data Plane in den Kernel
weitgehend lösen lässt.
Da in der Praxis proprietäre Erweiterungen der Control Plane, also dem Auf- und
Abbau sowie Management von Verbindungen gängige Praxis sind ("BYOV" - bring your
own VPN),
wird die Control Plane weiter im Userspace gehalten, während das Verschlüsseln
mittel Kernel Crypto API und das Kapseln der Netzwerkdaten im DCO (Data Channel
Offload) implementiert werden.
Das DCO ist ein virtual Device Driver, der per Netlink API konfiguriert wird und über Standard-
APIs Daten mit dem Userspace austauscht.</p>
<p>Als Besonderheit wird,
im Gegensatz zur bisherigen Implementierung, die für den peer-to-multipeer-Modus
(Server Modus) eine komplette Routing-Tabelle im Userspace hält, nun auch die
Routing Table des Kernels verwendet,
die lediglich um die erforderlichen more specific routes erweitert wird.</p>
<p>Ob sich diese Optimierungen mit Wireguard mithalten können, wird zu beobachten
bleiben,
tragen aber auf jeden Fall dazu bei,
die Performance-Lücke zwischen OpenVPN und Wireguard wieder
zu verkleinern.</p>
<p>Die von Antonio vorgestellte Lösung ist bereits jetzt voll funktionsfähig,
das Data Channel Offload ist auf <a href="https://github.com/OpenVPN/ovpn-dco">Github</a>
verfügbar.
Um sie in OpenVPN2 zu verwenden zu können muss der aktuelle Masterbranch
verwendet werden,
die Änderungen werden jedoch bald auch in der OpenVPN Version 2.6 releast.</p>
</div>
<div class="section" id="nvmetcp-offload-implementation-and-performance-gains">
<h4>NVMeTCP Offload – Implementation and Performance Gains</h4>
<p>Shai Malin und Aurelien Aptel stellen in ihrem Talk Optimierungen an NVMe-TCP
vor.
NVMe-TCP ist ein Protokoll zur Anbindung von Storage über TCP,
Darin wird jede Storage Queue über einen TCP socket angebunden,
auf dem Lese- und Schreiboperationen,
die entsprechend über einen Command Identifier (CID) gekennzeichnet werden,
in eine remote-System getunnelt werden können.</p>
<p>Um eine möglichst hohe Performance zu erreichen,
dürfen Server ein Reordering vornehmen,
um kleine Requests längeren Zugriffen vorzuziehen.
Die Datenintegrität wird über eine Prüfsumme (CRC) gewährleistet.</p>
<p>Nach einer sehr kurzen Einführung in dieses ungewöhnliche Thema erklären
Shai und Aurelien,
dass in der aktuellen Implementierung,
trotz verschiedener Optimierungen,
die größte Performancebremse das Kopieren von empfangenen Daten ist.
Auch die CRC-Validierung nimmt erheblich Rechenzeit in Anspruch und ist daher
ein attraktives Optimierungsziel.</p>
<p>Da die NVMe-TCP PDUs zudem über mehrere TCP Segments verteilt sein können
(oder mehrere NVMe-TCP PDUs in einem TCP Segment enthalten können),
ist ein trivialer Zero-Copy-Ansatz hier nicht zielführend.</p>
<p>Stattdessen schlagen sie die DDP (Direct Data Placement) Infrastruktur vor.
Die Grundidee ist, für Protokolle wie NVMe-TCP,
die auf Request-Response-Paaren basieren,
dedizierte vorallozierte Buffer zu verwenden.</p>
<p>Da die Daten der NIC bereits per DMA in diese dedizierten Buffer kopierten
werden,
kann auf diesen mit geringerem Aufwand analysiert werden,
ob ein Hardware Offloading möglich ist.</p>
<p>Wird dieser Ansatz mit beispielsweise CRC-Offloading kombiniert,
lassen sich für NVMe-TCP Performancegewinne von bis zu 58% bezüglich erreichter
Bandbreite bei gleichzeitig um bis zu 20% niedrigerer CPU-Last erreichen.</p>
<p>Als lessons learned empfahlen Shai und Aurelian den Zuhörern,
mit perf und flamegraphs sorgfältige Messungen durchzuführen,
um Performanceoptimierungen zunächst auf den teuersten Operationen einer
kompletten Kette durchzuführen.</p>
<p>In ihrem Fall stellten sie beispielsweise fest, dass die Kontext Switches,
die durch die Interrupts bei jedem UMR Event pro PDU ausgelöst wurden,
zu erheblichen Performanceeinbußen führten.
Durch die Annahme,
dass das Offloading opportunistisch sei und man nicht auf completion zu warten
habe,
konnten sie erhebliche Verbesserungen herbeiführen.</p>
<p>Weiter erklärten sie, dass coalescing von Paketen für das Offloading,
also die Ausführung von Offloading-operationen für mehrere Pakete auf einmal,
zu erheblichen Performancezugewinnen gegenüber dem Offloading für Einzelpakete
führte.
Wenn das Offloading für die jeweiligen Einzeloperationen
(hier CRC-Berechnung und DDP)
getrennt durchgeführt wird,
lassen sich Pakete besser poolen,
was erneut die Performance steigert.</p>
<p>Um das Offloadings ideal auf den realen Anwendungsfall optimieren zu können
empfehlen sie,
echten Traffic mit TCPDump und Wireshark auf die statistische Verteilung der
vorhandenen Paketgrößen zu untersuchen.</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 und Pedro Tammela stellen in ihrem Talk die
Ergebnisse ihrer Performanceanalyse für verschiedene Varianten von TLS auf x86
vor.
Sie vergleichen die Performance für uTLS (also im Userspace),
verschiedene Varianten von kTLS (im Kernel - mit und ohne Plattformoptimierung)
sowie mit und ohne Hardware-Offloading.</p>
<p>Während für größere Datenströme wenig überraschend kTLS mit Offloading einen
nennenswerten Vorteil bietet,
ist der für das Offloading erforderliche Overhead für kurze Datenströme größer
als der zu erzielende Performancezuwachs, sodass aktuell für kurze Streams uTLS
zu bevorzugen ist.</p>
<p>Die Autoren stellen ausgiebige Messungen vor und demonstrieren,
wie sie den Performance-Overhead mit ftrace bis hin zum Setzen der Offloading
Socketoptions zurückverfolgen konnten.
Während die direkten Ergebnisse dieses Talks wohl weniger für die Embedded-
Entwicklung fühle ich mich sehr an ein Mantra meines Mentors erinnert,
das ich mir auch in Zukunft weiter sehr zu Herzen nehmen möchte:
<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>Justin Iurman und Benoit Donnet demonstrieren in ihrem Talk,
dass die zunehmende Migration von monolithischen Services hin in eine verteilte
Microservices-Architektur besonders auch das Debugging und die
Performanceanalyse vor besondere Herausforderungen stellt.</p>
<p>Application Performance Management (APM) und verteiltes Tracing
(z.B. openTelemetry) wählen hier den Ansatz,
bisher bekannte Tracing-Infrastruktur,
wie sie aus der Applikationsentwicklung schon lange bekannt ist und verwendet
wird,
nun verteilt über ein Netzwerkcluster auszurollen und synchronisiert über die
gesamte Genese eines Requests über alle beteiligten Layer und Microservices zu
tracen.
Eine besondere Herausforderung sind hierbei unter anderem die Zeitspannen,
da beispielsweise ein HTTP-Request eine verhältnismäßig große Round-Trip-Time
gegenüber einem einzelnen Funktionsaufruf hat.
Weiter stellt die Korrelation von Netzwerktraffic auf Funktionsaufrufe eine
besondere Herausforderung dar,
da die verteilten Aufrufe über mehrere Subkomponenten der Architektur verfolgt
und zusammengesetzt werden müssen.
Die Autoren schlagen vor,
dafür generische Identifier in den Netzwerkpaketen zu verwenden,
die über die verschiedenen Schichten propagiert werden könnten,
jedoch trifft dieser Vorschlag in der anschließenden Diskussion und auch bei der
Publikation entsprechender Drafts in der IETF auf erheblichen Widerspruch,
da für den Vorteil der besseren Tracebarkeit erhebliche Overheads in Kauf
genommen werden müssten.
Aus diesem Grund laden die Autoren zu einer offenen Diskussion ein,
um gemeinsam alternative und weniger invasive Lösungen für diese Anforderung zu
suchen.</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>Im letzten regulären Talk der Konferenz erklärt Oleksij Rempel von Pengutronix,
wie er ein Framework für Power Delivery over Media Dependent Interface
geschaffen und mittlerweile bis nach net-next, also mainline gebracht hat.</p>
<p>Den meisten dürfte Power over MDI als PoE,
also Power over Ethernet,
bekannt sein,
jedoch wurde das ursprüngliche Standardset in der IEEE mehrfach erweitert und
auch auf andere Layer1-Implementierungen wie Base100x-T1 ausgeweitet.</p>
<p>Oleksij erklärt,
dass nicht nur die Vielfalt
(und wie bei der IEEE oft üblich fehlende kostenlose Verfügbarkeit)
der Standards,
sondern auch die Vielfalt an Namen für die einzelnen Komponenten eine
Herausforderung für die Schaffung einer generischen Infrastruktur im Kernel und
der Userspace-API darstellten.</p>
<p>Weiter sind für die einzelnen Standards verschiedene Optionale und
Verpflichtende Funktionskomponenten sowie Kommunikationswege vorgesehen,
beispielsweise um Leistungsverfügbarkeit out-of-band zum Netzwerktraffic
zwischen Komponenten auszuhandeln.</p>
<p>Oleksij wählte daher den Ansatz,
eine möglichst minimale Implementierung nach Mainline zu bringen.
Insbesondere sein Ansatz,
nur für ihn auch testbare Komponenten von Power over MDI zu integrieren,
und später weitere Aspekte nachzureichen,
ist ein sehr nachvollziehbarer und sinnvoller Ansatz.
Aus diesem Grund ist aktuell im Framework nur der PoDL PSE support implementiert,
also der Power Sourcing Equipment (Energiequelle) für PoDL (Power over DataLine
für Base-T1).
Dafür kann bereits jetzt der Admin State des PSE pro Port kontrolliert werden,
dies muss aus naheliegenden Gründen unabhängig vom link admin state passieren.
Sobald sich die uapi dafür stabilisiert hat wird Oleksij auch support in ethtool
nachreichen.
Einen Proof-of-Concept hat er bereits jetzt implementiert und demonstrierte ihn
im Rahmen seines Talks.</p>
<p>Als nächste Schritte sieht Oleksij die Implementierung der Classification,
also Out-of-Band-Aushandlung der genauen PoMDI-Implementierung,
sowie Interfaces an das power delivery framework,
um die zur Verfügung stehende Leistung zwischen den Hardware Ports eines
PSE-Devices aufteilen zu können oder auch einzelne Ports priorisiert versorgen
zu können.
Auch die Ergänzung der Gegenseite
(PD, also Powered Device)
ist ein weiterer Schritt,
um entsprechend des zur Verfügung stehenden Power Budgets beispielsweise im
System Diagnosedaten zur Verfügung stellen zu können oder den Energieverbrauch
an die gelieferten Energiemengen anpassen zu können.</p>
<p>Auch hofft Oleksij, bald schon PoE im Kernel unterstützen zu können.</p>
</div>
<div class="section" id="outreachy">
<h4>Outreachy</h4>
<p>Anschließend präsentierte Roopa Prabhu das <a href="https://www.outreachy.org/">Outreachy</a>
-Programm für networking-Projekte.
Outreachy vermittelt Praktika in Opensource-Projekten und setzt Mentorship
Programs auf,
wobei besonderer Fokus darauf liegt,
in diesen Projekten unterrepräsentierte Personengruppen zu unterstützen.</p>
<p>Als Beispiel für ein gelungenes Outreachy-Praktikum präsentierte Jaehee Park
das Ergebnis ihrer Arbeit im vergangenen Sommer,
in dem sie in verschiedenen Stellen Netzwerkstack Optimierungen vorgenommen hat,
etwa der Nutzung von AVX2-Extension für ein beschleunigtes Nullen von skb-
Strukturen,
der beschleunigten Ausführung und Verbesserung von Selbsttest oder
Verbesserungen für Gratious Arps.</p>
</div>
<div class="section" id="closing-ceremony">
<h4>Closing Ceremony</h4>
<p>Mit der Closing Ceremony endete die NetDev 0x16.
Nebst viel Lob für die Organisatoren und Sprecher wurde hier sehr offen über die
Herausforderungen des Hybrid-Events diskutiert.
Es ist erfrischend, in einer Community arbeiten zu dürfen,
die sich ihrer Stärken und Herausforderungen bewusst ist,
und auch vor Schwierigkeiten nicht zurückschreckt und offen diskutiert,
wie Dinge verbessert werden können.</p>
</div>
</div>
</div>
<p>Nach längerer Zeit mit nur Online-Events findet 2022 auch die <em>Netdev 0x16</em>,
eine Konferenz rund um die technischen Aspekte von Linux Networking,
hybrid statt - online und vor Ort in Lissabon.</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/de/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/de/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/de/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 - Tag 42022-09-17T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-tag-4">
<p>Freitag war der letzte Tag der ELC-E 2022 und somit auch der Tag des
traditionellen <em>ELC-E Closing Games</em>. Tim Bird berichtete gewohnt
kurzweilig über den aktuellen Stand der Embedded Linux World (Universe?)
Domination. Und natürlich gab es auch am letzten Tag einige interessante
Vorträge.</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) stellte in meinem ersten Vortrag des letzten
Tages die Ideen hinter dem Oniro Projekt der Eclipse Foundation vor. Die
Grundidee ist, eine gemeinsame und offene Basis sowohl für kleine IoT
Systeme auf Basis von Zephyr wie auch für große Systeme mit Linux
bereitzustellen. Das Projekt möchte nicht das Rad neu erfinden, sondern
so viel wie möglich "best practice" zusammenstellen. Linux Systeme
werden bei Oniro mit Hilfe von Yocto und der Clang-Toolchain
zusammengebaut. Ein eigener System Services Layer stellt dabei die
Dienste für Device Management bereit, und es gibt einen separaten Layer
für die Kundenapplikation. Oniro nutzt unser Update-Framework <em>RAUC</em> für's
Field Upgrade, bietet aber auch Raum für andere Systeme. Neben der
Runtime-Plattform kümmert sich Oniro auch um Infrastrukturthemen wie
GitLab, LAVA, eine OpenChain basierte Software Supplychain und andere
Tools. Alles in allem brachte der Vortrag wenig Neues, stellt aber eine
gute Sammlung aktueller Best Practices zusammen.</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 leitete im Anschluss eine BoF-Session zum Thema <em>Automated
Testing und Board Farming</em>. Für uns bei Pengutronix braucht man in den
Board Farmen für gewöhnlich interaktiven Entwickler-Zugang auf die
Hardware-under-Test (vom Büro aus oder aus dem Homeoffice), daneben
benötigt aber auch das CI-System Zugriff auf die Embedded-Geräte.
Unsere Labs haben jeweils 16 Lab-Plätze für Embedded-Geräte in einem 19"
Rack, in dem auch ein Test-Server, ein Ethernet-Switch und Technik für
den Zugang zu den seriellen Konsolen bereitstehen. Diese haben uns in
der Vergangenheit jeweils eine Menge Ärger bereitet, und zwar sowohl die
alten 19" Serial-Server als auch die aktuelle Generation auf Basis von
USB-Seriell-Wandlern. Bis 2020 gab es in unseren Labs ein
GPIO-Schalt-System auf Basis von OneWire, das heute zugunsten von CAN
basierten IO-Boards abgelöst wurde. Etliche Automatisierungsaufgaben
werden mittels CAN und über separate Multiplexing-Devices abgewickelt.</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>Die Gruppe diskutierte, wie die jeweils im Einsatz befindlichen Testlabs
aussehen. Tim Bird erklärte, dass er sich vor allem für Power Control
interessiert. Viele der Teilnehmer haben festgestellt, dass USB keine
stabile Basis für Automatisierungsgeräte ist, und versuchen, die
Technologie möglichst zu vermeiden, was aber in der Praxis schwer
funktioniert. Diverse Leute nutzen <em>Sonof WiFi</em>-Steckdosen oder <em>Gude Power
Switches</em> aus dem IT Bereich. Ein Mitarbeiter von TI berichtete über ein
Lab mit 40 Racks, ein anderes mit 300 Ports, betrieben mit OpenTest und
labgrid. Dort wurden die neuen Möglichkeiten, auch Kameras und Display-Tests
in Labgrid einzubinden, interessiert aufgenommen. Ein Teilnehmer
berichtete von einem Framegrabber-Board, das auch Keyboard- und
Maus-Events simulieren kann, so dass sich bei x86 sogar das BIOS
fernsteuern lässt. Von anderer Seite wurde PicoKVM (GitHub) empfohlen.
Oleksij Rempel berichtete über unsere Aktivitäten, auch Linux-basierte
Switche und generell Netzwerk-Geräte mit Hilfe von Labgrid zu testen.
Aus dem Publikum kam auch der Hinweis auf YKUSH, ein Gerät, mit dessen
Hilfe sich kaputte USB-Devices physikalisch resetten lassen. Rouven
Czerwinski berichtete über einen kürzlich von Pengutronix gemainlineten
Linux-Patch, mit dessen Hilfe sich einzelne USB-Ports abschalten lassen, wenn
die Hardware diese Funktionalität unterstützt.</p>
<p>Die Diskussion beschäftigte sich sodann mit der Frage, welche Testsuiten
bei den Teilnehmern im Einsatz sind. Bei Pengutronix sind dies in den
meisten Fällen in pytest geschriebene Testsuiten, die direkt auf das
jeweilige Gerät zugeschnitten sind. Die TI-Leute nutzen eine vom Linux
Test Project geforkte Variante. Oleksij Rempel berichtete, dass es oft
schwierig ist, Standard-Testsuiten direkt in Produktivumgebungen zu
integrieren. Auch zum Testen von WiFi und Bluetooth sind Lösungen im
Einsatz: So haben unsere Racks bei Pengutronix je ein WiFi- und
Bluetooth Gerät pro Rack, gegen das sich die einzelnen Geräte ggf.
testen können.</p>
<p>Aus dem Publikum kam die Frage, ob es in labgrid möglich ist, in einem
einzelnen Test mehrere labgrid-Places zu nutzen; dies ist (unter anderem mit
<em>reservations</em>) der Fall.</p>
<p>Für die Fortsetzung der Diskussion wurde auf die automated-testing
Mailingliste verwiesen.</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)
berichteten über den Einsatz von Linux in der Raumfahrt. Sie haben
herausgefunden, dass es bereits an diversen Stellen Open Source Software
gibt, jedoch sind noch nicht so viele Linux-Projekte in
Raumfahrtanwendungen präsent. Somit haben sie das <em>Linux4Space</em>-Projekt
gegründet und versuchen dort, die Anforderungen aus diversen ESA-Standards
zu erfüllen.</p>
<p>Ein Bereich, der zunächst naheliegend ist, sind die sogenannten <em>CubeSat</em>
Mini-Satelliten: Dies sind Satelliten mit 10x10x10 cm³, auf denen
jeweils ein Controller sowie diverse Anwendungen installiert sind. Der
Bau eines solchen Satelliten ist derweil recht einfach geworden, aber
der Start ist weiterhin sehr teuer. Da diese Art Hardware zunehmend
besser zugänglich ist, gibt es hier einen großen Bedarf an
Zusammenarbeit.</p>
<p>Der Betrieb eines Linux Computers im Weltraum bedeutet, dass diverse
Anforderungen zu erfüllen sind; glücklicherweise haben die
Raumfahrtagenturen dazu aber bereits Standards erarbeitet. Die größte
Herausforderung liegt im Bereich der Strahlungsresistenz, aber auch mit
einem kleinen Powerbudget will umgegangen sein. Generell ist es bei
diesen Geräten schwierig, sie fernzusteuern. Die
Gruppe hat in einer ECSS-E-ST-10-06 Requirements Specification die
bisher bekannten Anforderungen zusammengetragen.</p>
<p>Auf solchen Satelliten werden die meisten Systeme redundant ausgeführt,
da die Elektronik bei einem Strahlungseinschlag sehr schnell
ausgeschaltet werden kann. Es gilt, verschiedene verbreitete
Schnittstellen wie SpaceWire oder SpaceFibre zu unterstützen.
Dateisysteme werden in der Regel read-only betrieben.</p>
<p>Das Projekt ist noch recht neu, es gibt aber schon einige Protokolle der
letzten Sitzungen, die auf <a class="reference external" href="https://linux4space.org">linux4space.org</a>
verlinkt sind. Es wird an einem Demo Setup für einen Stratosphärenballon
auf Basis eines Raspberry Pis gearbeitet. Weiterhin arbeitet das Team an
einem Referenzboard auf Basis eines ARM Prozessors. Für die
Kommunikation gibt es ein spezielles CubeSat Protokoll.</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>Im nächsten Vortrag wurde von Pierre Blanc (RedHat) über den Podman
Container- (oder besser: Pod-) Manager berichtet. Das Design ist sowohl
rootless als auch daemonless und somit vergleichsweise sicher. Pierre
startete seinen Vortrag mit einem Überblick über die Historie der
Container-Technologie und berichtete dann über die Möglichkeiten zum
Umgang mit Container Images. Hat man erstmal ein passendes
Container-Image gefunden, kann man es starten und mit Netzwerkports
kommunizieren. Der Zugriff auf Daten erfolgt über in den Container
gemountete Verzeichnisse. Im Gegensatz zu z.B. Docker ist es nicht
nötig, Podman als Root laufen zu lassen.</p>
<p>Bei Pods handelt es sich um Gruppen von Containern, aus denen ein
gemeinsamer Anwendungsfall zusammengestellt wurde. Damit können auch
Applikationen verwaltet werden, die aus mehreren Diensten bestehen.</p>
<p>Weiterhin stellte Pierre diverse Sicherheitsfeatures und weitere
hilfreiche Tools aus dem Podman Ökosystem vor, z.B. buildah und skopeo.</p>
<p>Mit Hilfe von 'podman machine' ist es in aktuellen Versionen auch
möglich, nicht nur Container, sondern auch virtuelle Maschinen zu
verwalten.</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>Nach dem Mittagessen stellten Lucian Balea & Benoît Jeanson vom
französischen Stromnetzbetreiber RTE die Open Source Strategie der LF
Energy Gruppe der Linux Foundation vor: Die Idee ist es, eine auf Open
Source basierende Grid Software Control Architektur zu bauen. Bei einer
Analyse wurde festgestellt, dass es im Zuge der Energiewende notwendig
ist, die Strukturen auf ein mehr dezentrales System hin zu verändern, in
dem eine zunehmend größere Anzahl an Akteuren unterwegs ist. Dadurch
steigt die Komplexität. Als Painpoints wurden Interoperabilität,
Modularität, Updatebarkeit, Kosteneffizienz und die allgemeine
Geschwindigkeit bei Innovationen identifiziert. Die beteiligten Firmen
haben sich dann angeschaut, wie andere Industriezweige diese Probleme
angehen und kamen - Überraschung! - zu der Erkenntnis, dass Open Source
zur Lösung der Probleme beitragen kann. Das war der Auslöser zur
Zusammenarbeit im LF Energy Projekt.</p>
<p>Auf der Softwareseite wurde mit OperatorFabric, GridExchangeFabric und
PowSyBl gestartet und eine Architektur um diese Projekte herum
entworfen; derzeit tummeln sich 18 Open Source Projekte im
Architekturdiagramm, wobei es in einigen Teilanwendungsfeldern jedoch
noch weiße Flecken auf der Landkarte gibt. Neben der Software wurde aber
vor allem die Kollaboration in der Community von den beteiligten
Unternehmen als sehr hilfreich identifiziert. Das Projekt sucht noch
weitere Mitstreiter.</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) versuchten im nächsten
Vortrag, das Publikum zu motivieren, Upstream-Komponenten statt der
jeweiligen Downstream-Software (Stichwort: Vendor-BSPs) der Chiphersteller zu
verwenden. Dazu wird es später noch einen separaten Bericht geben.</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) leitete eine BoF-Session über Open Source
RISC-V. Die RISC-V Architektur ist nicht wie teils von vielen angenommen
selbst Open Source, sondern nur "Open Specification", aber es ist
durchaus möglich, damit auch Open Source-Hardware zu erstellen. In
letzter Zeit gibt es mehrere Ansätze, auch für die Community einen
Zugang zu den Halbleiterprozessen der großen Hersteller zu ermöglichen,
z.B. bei chipflow.io. Auch in der Industrie werden diverse Ansätze
für Open Source Prozessoren verfolgt, z.B. SweRV, Core-V und 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>Freitag war der letzte Tag der ELC-E 2022 und somit auch der Tag des
traditionellen <em>ELC-E Closing Games</em>. Tim Bird berichtete gewohnt
kurzweilig über den aktuellen Stand der Embedded Linux World (Universe?)
Domination. Und natürlich gab es auch am letzten Tag einige interessante
Vorträge.</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 - Tag 32022-09-16T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-tag-3">
<p>Das Convention Centre liegt direkt am Liffey, nur wenige Minuten Fußweg
von der O'Connell Bridge, Temple Bar und dem Trinity College entfernt.
Ein Besuch auf der ELC-E ist immer auch eine gute Gelegenheit,
interessante Städte in Europa kennenzulernen. Und hier ist auch schon
mein Bericht der Talks, die ich am Tag 3 gehört habe.</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>Im ersten Vortrag des Donnerstags stellte Ulf Lilleengen (Red Hat) das
<a class="reference external" href="https://drogue.io">Drogue IoT</a> Projekt vor. Es ist in Rust
geschrieben und kümmert sich um die Bereiche</p>
<ul class="simple">
<li>Continuous Integration,</li>
<li>Continuous Testing und</li>
<li>Continuous Development.</li>
</ul>
<p>Die Devices, um die es ihm geht, sind Mikrocontroller, auf denen kein
Linux läuft und bei denen die Update-Mechanismen in die Applikation
integriert sind. Sie sind in der Regel über ein Wireless Netzwerk
angebunden, z.B. WiFi, LoRaWAN, LTE-M oder Bluetooth, und werden von den
Herstellern mit vielen unterschiedlichen Entwicklungsumgebungen
ausgeliefert. Ein Problem beim Update ist, dass einige der Funksysteme
Beschränkungen bei der Air Time haben: So dauert es bei einer
Firmware-Größe von 64 KiB z.B. bei LoRaWAN drei Tage, bis ein Gerät ein
vollständiges Update von einem Standard-Gateway empfangen hat. Damit das
Gerät failsafe ist, wird zumindest ein minimaler Bootloader benötigt,
der über den Funkkanal ein neues Image beschaffen kann.</p>
<p>Die Kommunikation im Drogue IoT Framework funktioniert über REST
Schnittstellen und eine Vielzahl von API Endpoints. Man kann Devices in
Gruppen zusammenfassen, und verschiedene Protokolle können zur
Kommunikation genutzt werden. Zum Update fragt das Gerät bei einem
Delivery System an, z.B. bei HawkBit. Der Vortrag schloss mit
einer Demo, in der ein MicroBit Controller im Feld geupdatet wurde.</p>
<p>Die meisten der vorgestellten Komponenten passen nicht in unser übliches
Embedded Linux Umfeld, aber bei den verwendeten Tools gibt es schon das
eine oder andere, das einen genaueren Blick wert ist, z.B. Keycloak (für
das Identity Management) oder die eingesetzten Kommunikationsprotokolle.</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>Im nächsten Vortrag beleuchtete George Kiagiadakis (Collabora) aktuelle
Fragestellungen rund um immer komplexer werdende Kameras. Moderne
Kameras haben z.B. mehr als einen Sensor-Chip, Algorithmen zur
Kombination der daraus erzeugten Bilder und eine Vielzahl an
Hardware-Einheiten, die aus verschiedenen Datenquellen letztlich ein
Bild oder einen Videostream machen, teils auch unter Zuhilfenahme von
AI Beschleunigern. Es stellt sich heraus, dass die dafür benötigten
Pipelines immer komplexer werden. Typischerweise werden solche Szenarien
heute mit libcamera abgedeckt, aber es gibt ungeklärte Fragen:</p>
<ul class="simple">
<li>Wie kombiniert man die Daten von verschiedenen Geräten?</li>
<li>Kann man das Processing splitten, z.B. in Container?</li>
<li>Wie realisiert man eine gute "divide and conquer" Strategie?</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>Zu diesem Zweck wurde das Pipewire Projekt gestartet, das einen Multi
Process, Ressource Sharing, Low Latency Multimediabus bereitstellt. Es
gibt einen Graphen, in dem die einzelnen Prozessierungsschritte auf
verschiedene Prozesse aufgeteilt werden. Der Graph wird von WirePlumber
aufgesetzt, einem scriptbaren Daemon, der die vorhandenen Geräte
herausfindet und passend miteinander verbindet.</p>
<p>In seiner Demo zeigte George einen Face Detection Algorithmus. Weiterhin
existiert ein praktisches Tool zur Anzeige der erzeugten Graphen. Eine
weitere Demo zeigte, wie man ein Videoplayback mit zwei synchronisierten
Ausgabedisplays hinter einem gemeinsamen Videodecoder realisieren kann.</p>
<p>Der Vortrag ergab einen guten Überblick über Pipewire; auch bei
Pengutronix nutzen wir Pipewire zunehmend mehr in den Multimedia
Projekten unseres Grafikteams.</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>Laura Nao (Collabora) berichtete über die Herausforderungen aus
Collaboras Testlabor. Die Firma betreibt in Cambridge ein Labor mit 158
Geräten, davon 32 unterschiedlichen Gerätetypen, die von 15 Servern und
der üblichen Kombination aus Netzwerkswitchen, Debug Interfaces,
USB-Hubs etc. kontrolliert werden. Die meisten eingesetzten Geräte sind
64-Bit-ARM-Chromebooks, wobei es oft mehr als ein Gerät von einer Sorte
gibt. Die Boards werden in 19" Racks montiert. Das Setup hört sich sehr
ähnlich zu dem an, das wir bei Pengutronix als LAVA Lab betreiben;
allerdings sind die meisten unserer Labs eher mit industrieller Hardware
bestückt.</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>Ein üblicher Testlauf startet mit dem Einschalten eines Prüflings; es
startet der Bootloader, der Bootvorgang wird abgebrochen, Kernel und
Ramdisk werden übertragen, dann wird der Bootvorgang fortgesetzt, das
System bootet, das Testsystem loggt sich ein, startet eine Reihe von
Testscripten, und schließlich wird das Board am Ende wieder
ausgeschaltet. Die Konfigurationsfiles sind YAML-Files, die mit Jinja 2
getemplatet werden. Mittels eines Health-Jobs wird sichergestellt, dass
das Lab selber gut funktioniert. Kernel-Log-Informationen werden mit
einem Script aus dem Syslog gezogen. Ein GitLab-Runner ermöglicht, Jobs
zu erzeugen. Neu ins Labor gehängte Geräte durchlaufen zunächst ca. 1000
Health Checks, bevor sie in den regulären Testbetrieb gehen.</p>
<p>Der Testflow für die Chromebook-Applikationen sieht schon sehr anders
aus als bei normalen Linux-Applikationen. Da allgemein das Testen auf
Chrome-OS schwierig ist, ersetzt Collabora es durch ein normales Linux.</p>
<p>Das Lab selbst ist in einen Staging- und einen Produktionsbereich
getrennt. Auch die Upstream-Kernel werden im Staging-Bereich getestet.
Lediglich bereits releasete Versionen werden im Produktionsbereich
getestet.</p>
<p>Auch Kernel CI und Mesa CI Streams laufen auf dem Lab. Dabei ist das
Ziel, die Upstream-Entwickler mit Testergebnissen zu versorgen und somit
Fehler in der Revisionskontrolle so früh wie möglich aufzudecken. Die
Mesa Tests sind noch relativ neu, dort werden auf x86 Pre-Merge
Conformance Tests gemacht.</p>
<p>Auf dem Lab laufen sehr viele Jobs, somit kann auch eine Menge
schiefgehen. So kann es vorkommen, dass die Hardware Probleme hat, ab und zu
fallen auch Server aus, oder es schlagen Firmware-Bugs zu. Da z.B. Mesa
die Aufnahme neuer Features von positiven Testergebnissen abhängig
macht, ist es für die Betreuer des Testlabs wichtig, Infrastruktur-Fails
von echten Testfehlern zu unterscheiden.</p>
<p>Einige Erkenntnisse:</p>
<ul class="simple">
<li>Robuste Health Checks sind sehr wichtig.</li>
<li>Infrastruktur-Fehler müssen sauber detektiert werden.</li>
<li>Nur mit genügend redundanten Devices ist eine gute Testabdeckung
möglich.</li>
<li>Es werden dauerhaft zwei Personen benötigt, um das Labor vor Ort zu
betreuen.</li>
</ul>
<p>Je größer das Lab wächst, desto mehr Platz, Komponenten aber auch
Manpower wird zu dessen Betrieb benötigt.</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>Auch für uns bei Pengutronix ist das Thema "Erneuerbare Energien"
derzeit spannend, und es gibt Pläne, die entsprechende Infrastruktur mit
möglichst vielen Open Source Komponenten zu betreiben. Insofern gab der
Bericht von Kai-Uwe Hermann und Piet Gömpel (PIONIX GmbH) einen
interessanten Einblick in die Welt der Ladestationen für Elektroautos.</p>
<p>EVerest ist ein Softwarestack für Auto-Ladeinfrastruktur. Es stellt sich
heraus, dass das Thema Ladeinfrastruktur überraschend komplex ist. Eine
Ladestation besteht in der Regel aus Leistungselektronik und einem
Controller für die Ablaufsteuerung (oft mit Linux). Es sind diverse
unterschiedliche Standards beteiligt, sowohl auf der Stecker- als auch auf
der Kommunikationsseite. Zwischen dem Controller und dem Cloud-Backend
wird das OCPP Protokoll gesprochen, von dem es in der Praxis mehr als
150 Dialekte gibt, aber auch andere Protokolle wie IEC631100, MQTT und
andere. Es gibt Bestrebungen für "plug-and-charge", aber dafür wird eine
komplexe Authentifizierung benötigt, so dass es in der Praxis noch fast
keine Implementierungen gibt.</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>Ein weiterer Themenkomplex beschäftigt sich mit der Interaktion zu
anderen Komponenten in einer lokalen Ladeinfrastruktur, z.B. wenn man
dann laden möchte, wenn die Sonne gerade scheint und eine lokale PV
Anlage Solarstrom erzeugt. Nimmt man diesen Komplex hinzu, gibt es eher
noch viel mehr Protokolle, die eine Rolle spielen. Ähnlich ist es im
Bereich der Grid-Kommunikation.</p>
<p>Alles in allem war das Fazit: Es gibt zu viele Standards, und es werden
eher noch mehr. Da man diese Sorte Probleme nicht durch <a class="reference external" href="https://xkcd.com/922">Hinzufügen
eines weiteren Standards</a> beheben kann, versucht das
EVerest Projekt, eine Community Referenzimplementierung bereitzustellen.
Es sollen so viele Hardware-Plattformen wie möglich unterstützt werden,
ohne dass das Rad neu erfunden werden muss. Die Codebase ist in C++
geschrieben und unter der Apache 2.0 Lizenz auf GitHub veröffentlicht.
Für eine einfache Konfiguration gibt es eine Web-Applikation. Derzeit
wird OCPP in der Version 1.6 unterstützt - hier ist der Stack
Feature-Complete, wohingegen an Version 2.0 derzeit gearbeitet wird.</p>
<p>Das Projekt gibt es nun seit zwei Jahren, es gibt eine Mailingliste und
regelmäßige Meetings. Die Demo-Setups laufen auf Hardware von der Phytec
und Mahle, aber es gibt derzeit noch keine marktfertigen Lösungen.</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 arbeitet für die Carl Cloos Schweißtechnik GmbH, einen
Hersteller von industriellen Schweißrobotern. In 2021 startete er die
Migration eines Roboters auf Preempt-RT.</p>
<p>Die existierenden Roboter-Controller bestehen aus einem selbst
entwickelten PC, auf dem ein CAN-Bus, EtherCAT und ein Satz an
Servomotoren als EtherCAT Slaves betrieben werden. Die Axen laufen dabei
in einem "cyclic synchronous position mode" (CSP): Auf einem 1-4 ms
Buszyklus stellt das System für alle Axen neue Zielpositionen bereit.
Ein Motion Planner läuft auf einem Takt von 8...16 ms, wobei für den
schnelleren Bustakt interpoliert wird. Mittels eines physikalischen
Modells wird die Dynamik des Roboters simuliert.</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>Die Codebasis besteht aus 3 Millionen Lines-of-Code. Ursprünglich wurde
diese mal in PL/M geschrieben und später auf C portiert. Es gibt nach
wie vor 386 Assembler-Code und ANSI C, eine alte MFC GUI und eine neue
Qt GUI (leider noch nicht Feature-Complete). Es gibt die übliche
Technical Debt in der Codebase, es haben Mitarbeiter die Firma verlassen,
und dabei ist auch Wissen verlorengegangen.</p>
<p>Im Jahr 2021 wurde mit KEBA gesprochen, da es dort einen recht
vielversprechenden D3 Automation Controller mit 32 Bit Debian Linux gab,
der eine integrierte Safety Lösung mitbrachte. Dadurch, dass auf diesem
System die Möglichkeit bestand, alle Software auf einem System laufen zu
lassen, konnten bereits eine ganze Reihe proprietärer Lizenzen
eingespart werden. Jetzt war der Zeitpunkt günstig, so dass der Referent
seinem Team vorschlug, in einem 6-Wochen Sprint eine Portierung auf
Linux zu probieren. Dabei war ein wichtiger Aspekt, dass sich alle
beteiligten Kollegen (auch Nicht-Linux-Entwickler) mit einer
Entscheidung für eine Linux-Portierung wohlfühlen sollten. Überraschend
gab es im Team Konsens, das Projekt zu starten.</p>
<p>Die komplette API wurde im Userspace als Shared Library implementiert,
so dass die eigentliche Applikation nicht angefasst werden musste.
Zunächst wurden Headerfiles nachimplementiert, dann mussten alle
Funktionen implementiert werden, die vom Linker als fehlend ausgegeben
wurden. Gleichzeitig begannen die GUI Entwickler mit der Migration der
Oberfläche. An ein paar wenigen Stellen (IPC auf physikalischem
Speicher) wurde letztlich doch die Applikation verändert.</p>
<p>Am Ende des 6-Wochen-Zeitraums war die Applikation so weit portiert,
dass sie starten konnte; auch eine rudimentäre GUI war soweit
funktionstüchtig, jedoch noch nicht abgeschlossen. Das Team war sich
darüber im Klaren, dass man bei dem Projekt eine Menge gelernt hatte und
der Ansatz generell der Richtige ist. Weiterhin ergab sich ein gutes
Gefühl dafür, wie viel Arbeit der Rest der Portierung noch sein könnte.
Selbst die bislang an Windows gewöhnten Entwickler waren mit der Arbeit
mit Visual Studio zufrieden, so dass es wiederum eine gemeinsame
Entscheidung gab, die Aktivitäten fortzuführen. Leider wurde der
Abschluss des Projekts dann durch die Chipkrise ausgebremst.</p>
</div>
</div>
<p>Das Convention Centre liegt direkt am Liffey, nur wenige Minuten Fußweg
von der O'Connell Bridge, Temple Bar und dem Trinity College entfernt.
Ein Besuch auf der ELC-E ist immer auch eine gute Gelegenheit,
interessante Städte in Europa kennenzulernen. Und hier ist auch schon
mein Bericht der Talks, die ich am Tag 3 gehört habe.</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 - Tag 22022-09-15T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-tag-2">
<p>Das Dublin Convention Centre ist riesig - es gibt mehr als genug Platz
für die vielen Teilnehmer des Open Source Summit. Zum Glück wird es die
Vorträge nach der Konferenz auf YouTube geben, so dass es nicht schlimm
ist, wenn man vor Ort nicht alle Vorträge hören kann. Hier ist mein
Bericht zu den Vorträgen, die ich am zweiten Konferenztag gehört habe.</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>Ein wichtiger Aspekt von Open Source ist die Zusammenarbeit in der
Community - oft auch zwischen direkten Wettbewerbern im gleichen
Marktsegment. Somit war in diesem Jahr bemerkenswert, dass der Vortrag
über Testautomatisierung mit labgrid nicht von Pengutronix, sondern von
Christopher Obbard (Collabora) gehalten wurde.</p>
<p>Zu Beginn stellte Chris fest, dass es oft vorkommt, dass die Entwickler
zunächst mal "etwas auf einem Board ausprobieren" müssen, wobei das
Board sich in einem Labor an einem anderen Standort befinden kann. Somit
ist es für die Collabora Entwickler (wie für uns auch) ein Usecase, ein
Board an einem entfernten Standort neu zu flashen. Das lokale Lab in
Chris' Homeoffice besteht aus ca. 10 Boards, die auch mal schnell
umkonfiguriert werden müssen; es kommt dabei auf einen geringen
Stromverbrauch sowie einen leisen Betrieb (WAF!) an. Sein Lab nutzt als
Controller einen Raspberry Pi 4 mit USB-Seriell-Wandlern für die
Konsolen. Dabei traten ähnliche Probleme mit der Robustheit von USB auf,
wie wir sie aus unseren Labs auch kennen. Weiterhin gibt es einen
Netzwerkswitch. Die Software-Installation auf dem Raspi erfolgte mittels
Ansible.</p>
<p>In Sachen Software war sein erster Versuch LAVA, jedoch fand Chris
schnell heraus, dass LAVA vor allem für automatische Testläufe und nicht
für interaktive Benutzung designt wurde. Der Pflegeaufwand für ein LAVA
Lab stellte sich als hoch heraus, und insbesondere die Turnaround-Zeiten
zur Ausführung eines einzelnen Jobs sind sehr hoch. Somit war LAVA für
ein Home Lab mit interaktiver Benutzung und einem Fokus auf Entwicklung
nicht gut geeignet.</p>
<p>Im interaktiven Betrieb ist die Kontrolle über die Stromversorgung zum
Ein- und Ausschalten der Boards ebenso wichtig wie das Flashen und
Starten neuer Software. Dies waren auch die Anforderungen, die uns bei
Pengutronix beim Design von Labgrid als pythonbasiertes
Testautomatisierungsframework wichtig waren. Bei Labgrid kümmert sich
der Controller um den Zustand des Systems und die Kommunikation zu den
verschiedenen Exportern, an die wiederum die Test-Devices angeschlossen
sind. Dabei abstrahiert Labgrid Stromversorgungs-Schnittstellen und
serielle Interfaces. Für Chris stellte es sich als ein Vorteil heraus,
dass man mit Labgrid sehr einfach Lab-Hardware beschreiben kann.
Dadurch, dass es möglich ist, einen Laborplatz zu locken, ist auch ein
Mischbetrieb zwischen einem Continuous Integration System und
interaktivem Betrieb möglich. Zum Schalten von 230 V Geräten nutzt er
Sonoff WiFi Steckdosen, die über MQTT angesteuert werden. Die
automatischen Tests werden von GitLab CI gesteuert.</p>
<p>Alles in allem scheint Chris mit seinem Lab sehr zufrieden zu sein; als
derzeitige Schwäche wurde identifiziert, dass es nicht möglich ist,
Files auf den Exporter hochzuladen. Alles in allem war gut zu sehen,
dass auch andere Nutzer mit unseren Open Source Projekten zufrieden
sind.</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>In meinen zweiten Vortrag des Tages berichtete Drew Mosley (Toradex)
über seine Erfahrungen mit OpenEmbedded in Containern. Seiner Erfahrung
nach sind Container ein handlicher Mechanismus zum Packagen von Software
und zum Ausliefern auf Embedded Systeme, ohne dass es Abhängigkeiten zum
Entwicklungshost gibt. Container nutzen Kapselungs-Features des Kernels,
wobei es auf dem Zielsystem innerhalb des Containers nur Userspace und
keinen eigenständigen Kernel gibt. Nach Drews Erfahrung machen es
Container Registries wie Docker Hub sehr einfach, beliebige Software
ohne größere Schmerzen zu installieren.</p>
<p>Allerdings bleibt als Hauptfrage bestehen, wie die Container erstellt
werden; dabei ist das Problem, dass man ggf. Containern anderer Leute
hinreichend vertrauen muss. Zudem beinhalten die üblichen
Standard-Container eine Menge Software, die in einer konkreten Anwendung
ggf. gar nicht benötigt wird. Deshalb ist OpenEmbedded nach seiner
Erfahrung ein gutes Werkzeug, um sehr kleine und maßgeschneiderte
Container zu erstellen.</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>Leider musste der "How Automotive Grade Linux UCB Transitioned to Make
Use of Flutter"-Vortrag abgesagt werden. Der nächste Talk von
Ngonidzashe Mombeshora konnte aufgrund von Visa-Problemen leider auch
nicht vor Ort, sondern nur im Stream gehalten werden.</p>
<p>Ngonidzashe stellte vor, dass der Vorteil von Mobiltelefon-Netzwerken
zur Steuerung von Drohnen darin besteht, dass diese nahezu überall auf
der Welt bereits ausgerollt sind. Allerdings ist es zur Steuerung von
Drohnen in Echtzeit nötig, eine sehr geringe Latenz in der Kommunikation
zu erreichen. Zu deren Optimierung hat er an der Uni ein SDR basiertes
4G Mobiltelefonienetzwerk aufgebaut - mit einem Raspberry Pi mit SDR Hat
und einer Reihe von Docker-Containern mit der nötigen Software. In einem
zweiten Schritt wurde ein 5G Testbed aufgesetzt. Damit ließen sich 90/30
MBit/s Down-/Uplink Raten mit 5 ms Latenz erreichen. Allerdings stellte
sich auch heraus, dass sich in regulären kommerziellen Netzwerken leider
nur schlechtere Latenzen realisieren lassen. Immerhin konnte er in seinem
Testnetz einen realen Testflug mit MavLink als Telemetrieprotokoll
durchführen.</p>
<p>Alles in allem ein beeindruckendes Ergebnis, wobei das Setup
insbesondere von akademischem Interesse ist.</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 meinem letzten Vortrag des zweiten Tages berichtete Matthias Lüscher
(Schindler AG) von seinen Aktivitäten, eine IoT Flotte mittels git zu
managen. Sein Open Source Projekt <a class="reference external" href="https://www.get-edi.io">edi</a> hat
sich zur Aufgabe gemacht, so viele Schritte wie möglich zum Bauen,
Verwalten und Ausrollen von Embedded Linux Systemen zu automatisieren.
Er nutzt Debian für die Pakete, erstellt damit Mender Update Images und
rollt sie zunächst in ein Testfeld aus, in dem das Resultat mittels
Testinfra getestet wird. Funktioniert alles wie gewünscht, erhält er ein
qualifiziertes Image für das Target Device.</p>
<p>Um einen "golden image"-Ansatz zu vermeiden, nutzte Matthias
debootstrap, startet das resultierende Image im QEMU und baut dort die
nötigen Änderungen und fehlenden Konfigurationen mittels Ansible ein.
Testinfra hat sich für ihn als ein praktikabler Ansatz für Tests in
pytest herausgestellt; dabei könnnen die Tests auf einer
Entwicklungsmaschine laufen und gegen ein Embedded System testen.</p>
<p>Als Demo zeigte Matthias einen edi-Workflow mittels oben skizzierter
Toolchain, der einen Raspberry Pi in eine GitHub Action Runner
verwandelt. Der resultierende Action Runner registriert sich selbst bei
GitHub. In einem weiteren Beispiel entstand ein Kiosk Terminal, dem man
mittels 6 Zeilen Ansible Code die anzuzeigende URL konfigurieren konnte.</p>
<p>Der Ansatz funktioniert nicht nur mit einzelnen Devices, sondern auch
mit ganzen Geräteflotten. Die Testflotte, die Matthias zu Hause
betreibt, besteht aus unterschiedlichen Devices, vom Raspberry Pi 2 bis
hin zu aktuellen MX8M Evalkits. Die Flotte wird auf verschiedene git-Branches
abgebildet: Alle Entwicklung findet auf einer Development-Branch
statt; auf einer Main-Branch werden komplettere Features
gesammelt, die dann in eine Canary-Branch auf eine realistische, aber in
erreichbarer Nähe befindliche Feldgeräteflotte ausgerollt wird. Wenn es
dort keine Ausfälle gibt, wird in das echte Produktionsumfeld
ausgerollt. Dabei schauen die Clients jeweils über Mender, ob es neue
Daten für sie gibt.</p>
<p>Es bietet sich an, die Geräte im Feld via Monitoring zu überwachen; dann
bekommt man auch mit, wenn z.B. Geräte gerade offline sind, wenn es neue
Updates oder Konfiguration für sie gibt. Sehr große Flotten sollten die
Informationen vermutlich besser nicht aus einem Git Repository via
Ansible ziehen, sondern auf eine Datenbank ausweichen. Zumindest für
kleine Flotten funktioniert aber der Workflow mit git und Ansible
hinreichend gut.</p>
<p>In Summe hat sich die verwendete Toolbox als sehr mächtig herausgestellt.
Für den Fall, dass die einzelnen Tools nicht zu den eigenen Bedürfnissen
passen, kann man sie auch einzeln gegen vergleichbare andere tauschen,
z.B. indem man Yocto statt Debian verwendet.</p>
</div>
<div class="section" id="booth-crawl">
<h3>Booth Crawl</h3>
<p>Traditionell gibt es in jedem Jahr den Booth Crawl, auf dem diverse
Projekte ihre Embedded Linux Demos vorstellen. Leider gab es in diesem
Jahr nur 6 Demos von drei Gruppen, unter anderem von Pengutronix. Hoffen
wir, dass es im nächsten Jahr wieder mehr Demos gibt - die Demos sind
immer ein Highlight.</p>
<p>Das Pengutronix Team zeigte das Labgrid Test Automation Framework, einen
Prototypen des LXA Test Automation Controllers (TAC), das RAUC Update
Framework sowie unsere aktuellen Mainlining-Aktivitäten für die
Unterstützung der Grafik auf Rockchip-SoCs. Wie in jedem Jahr gab es eine
Vielzahl interessanter Gespräche mit einem interessanten Publikum.</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>Das Dublin Convention Centre ist riesig - es gibt mehr als genug Platz
für die vielen Teilnehmer des Open Source Summit. Zum Glück wird es die
Vorträge nach der Konferenz auf YouTube geben, so dass es nicht schlimm
ist, wenn man vor Ort nicht alle Vorträge hören kann. Hier ist mein
Bericht zu den Vorträgen, die ich am zweiten Konferenztag gehört habe.</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 - Tag 12022-09-14T10:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2022-tag-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>Nach zwei Jahren, in denen es nur Online Konferenzen gab, trifft sich in
diesem Jahr die Embedded Linux Community zum ersten Mal wieder zur
jährlichen <em>Embedded Linux Conference Europe</em> in Dublin, Irland. Seit
vielen Jahren ist die ELC-E Teil des Open Source Summits der Linux
Foundation; sie ist die größte Veranstaltung ihrer Art, bei der sich die
Entwickler des Linux Kernels und des angrenzenden Core-Ecosystems
treffen und über aktuelle und zukünftige Entwicklungsthemen diskutieren.</p>
<p>Das Pengutronix Team flog am Sonntag mit 14 Entwicklern nach Dublin; die
Konferenz findet hybrid statt, so dass die zu Hause gebliebenen Kollegen
zumindest an den Vorträgen online teilnehmen können (wenn auch ohne die
berühmten Beer Events und anderen Gelegenheiten zum Socializen ;).
Parallel zur ELC-E fand in Dublin auch die Linux Plumbers Conference
statt.</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>Im ersten unserer Vorträge auf der ELC-E gab Rouven Czerwinski am
Dienstag einen Überblick über den Bootprozess auf der ARM64 Plattform.
Der Vortrag war Teil der neuen "Embedded Essentials"-Serie: Die Idee
dabei war, gerade neuen Teilnehmern einen Überblick über mehr
allgemeinere und nicht so hoch spezialisierte Themenbereiche zu geben.
Das Konzept scheint aufzugehen - der Vortragssaal war gut gefüllt.</p>
<p>Im Gegensatz zu ARM32, wo am Bootprozess im Wesentlichen der Bootloader
und der Kernel beteiligt sind und nur zwei Exception-Level relevant
sind, sind auf ARM64 weitere Komponenten involviert.</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>Die erste Stufe besteht aus dem ROM-Code (BL1), dessen Aufgabe das Laden
der weiteren Stufen vom Massenspeicher ist; dieser Teil ist weiterhin
herstellerspezifisch. Hier gibt es für Entwicklungszwecke einen
Mechanismus zum Laden über serielle Schnittstellen. Die zweite Stufe
(BL2) besteht dann entweder aus einem U-Boot SPL, einem barebox PBL oder
einer TF-A.</p>
<p>Die ARM Trusted Firmware (TF-A) implementiert eine Reihe von
standardisierten Firmware Runtime Services, z.B. PSCI oder SCMI. Leider
ist die TF-A unter der MIT Lizenz lizensiert, was die Hersteller nicht
dazu zwingt, ihren Sourcecode auch immer zu veröffentlichen oder durch
ein etabliertes Review-Verfahren (wie z.B. beim Kernel üblich)
qualitätszusichern. Neben dem Secure Boot-Mechanismus stellt die TF-A
auch das DDR Link Training, das Frequency Scaling und das Power State
Coordination Interface (PSCI) zur Verfügung.</p>
<p>SCMI, das System Control and Memory Interface, kümmert sich um das An-
und Abschalten von CPU Cores sowie um die Takte; diese Dienste müssen in
der TF-A implementiert werden, da es z.B. passieren kann, dass Linux
einen Takt nicht benötigt, die Secure World jedoch schon.</p>
<p>Der eigentliche Bootloader startet dann in Exception Level 2 und wertet
dann in der Regel den Open Firmware Devicetree aus und stellt die
bootloaderüblichen Mechanismen bereit, um einen Kernel zu beschaffen und
zu starten.</p>
<p>Im Gegensatz zu ARM32 gibt es keinen standardisierten Dekompressor im
Kernel, so dass der Bootloader diese Aufgabe übernehmen muss. Im
Anschluss werden die Interrupts maskiert, der Standard Timer
initialisiert und der Kernel an eine definierte Adresse geladen. Die MMU
und die Data Caches werden abgeschaltet, die Adresse des Devicetrees in
Register 0 geladen und der Kernel angesprungen.</p>
</div>
<div class="section" id="all-attendees-reception">
<h3>All Attendees Reception</h3>
<p>Wie in 2015 (als die ELC-E zum letzten Mal in Dublin war), fand die
Teilnehmer-Party im Guiness Storehouse statt. Das Gebäude ist eine nette
Location, allerdings ist es aufgrund der Tatsache, dass durch die
gemeinsame Veranstaltung mit dem Open Source Summit auch viele
Entwickler aus komplett anderen Themenfeldern wie Cloud, Kubernetes und
Hyperledger dabei sind, immer etwas schwierig, neue Embedded-Leute auf
der Veranstaltung zu finden.</p>
<p>In jedem Fall war der Abend eine nette Gelegenheit, Kontakte zu pflegen
und herauszufinden, was die anderen Embedded Linux Entwickler in den
Corona-Jahren so alles getrieben haben, während ein persönliches Treffen
nicht möglich war.</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>Nach zwei Jahren, in denen es nur Online Konferenzen gab, trifft sich in
diesem Jahr die Embedded Linux Community zum ersten Mal wieder zur
jährlichen <em>Embedded Linux Conference Europe</em> in Dublin, Irland. Seit
vielen Jahren ist die ELC-E Teil des Open Source Summits der Linux
Foundation; sie ist die größte Veranstaltung ihrer Art, bei der sich die
Entwickler des Linux Kernels und des angrenzenden Core-Ecosystems
treffen und über aktuelle und zukünftige Entwicklungsthemen diskutieren.</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/de/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.htmlKonferenzen 2021: Ein Rück- und Ausblick2022-01-18T17:00:00+01:00Marie Mann<div class="section" id="konferenzen-2021-ein-ruck-und-ausblick">
<p>Neben den Verbesserungen rund um Embedded-Linux-Software und der Weiterentwicklung
des Linux-Kernels hat das Team von Pengutronix im letzten Jahr die
Gelegenheit genutzt, dass viele Konferenzen vom eigenen Schreibtisch aus erreichbar
waren.
Dadurch konnten wir unsere Erfahrungen und Ideen noch breiter mit der Community
teilen und auch an Konfrenzen Teilnehmen, die für uns sonst Flugstunden entfernt
lägen.</p>
<p>Für die Statistik-Nerds unter uns: Wir waren auf</p>
<ul class="simple">
<li>10 Konferenzen mit</li>
<li>15 Vorträgen vertreten und haben</li>
<li>18 <a class="reference external" href="https://www.youtube.com/pengutronix">YouTube</a>-Videos veröffentlicht</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>Traditionell trifft sich die Open Source Community für ihr Jahrestreffen
Anfang Februar in Brüssel an der Université libre de Bruxelles (ULB).</p>
<p>Doch 2021 mussten Bier und Waffeln aufgrund der noch anhaltenden Corona-Pandemie
am heimischen Schreibtisch verzehrt werden.
Der Austausch fand über Online-Vorträge und das dezentralisierte Messaging Protokoll
"Matrix" statt.</p>
<p>Aufgrund der anhaltenden Pandmie ändert sich daran auch im Februar 2022 erstmal
nichts und so werden selbstverständlich hoffentlich auch diesmal wieder viele Waffeln
in der heimischen Küche gebacken.</p>
<div><div class="clearfix"></div></div><p><strong>Unsere Beiträge:</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>Nächster Termin</td>
<td>5. + 6. Februar 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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 des Workadventure</p>
</figcaption>
</figure>
</div><p>Die CLT haben vom Chaos Computer Club gelernt und in 2021 das Hörsaalgebäude
in einem Workadventure gepixelt.</p>
<p>Das Ergebnis war ein richtiges Konferenzerlebnis, bei dem sich Menschen
spontan auf dem Gang begegnen und unterhalten konnten.
An allen Ecken überraschten liebevoll gestaltete Details oder Teilnehmer,
die Videos von ihren Meerschweinchen streamten.</p>
<p>Ergänzt wurde die virtuelle Welt durch zahlreiche Vorträge und Räume im
Konferenzsystem "Big Blue Button", in denen Workshops oder Lightening Talks
angeboten wurden.</p>
<p>Wir freuen uns auf die Umsetzung in 2022 und werden wieder mit dem <em>Pengutronix
Quiz</em> mit Fragen rund um Linux, Open Source und Embedded-Themen dabei sein.</p>
<table border="1" class="docutils">
<colgroup>
<col width="32%"/>
<col width="68%"/>
</colgroup>
<tbody valign="top">
<tr><td>Nächster Termin</td>
<td>12. + 13. März 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>"Die <strong>building IoT</strong> ist die Fachkonferenz für IT-Profis, die Anwendungen und
Produkte im Internet der Dinge und im IIoT entwickeln."</p>
<p>Wir bedanken uns für die hervorragende Betreuung der Speaker während der
Konferenz und für die interessante Themenauswahl.
Wir freuen uns, die Building IoT auch zukünftig zu begleiten.</p>
<p><strong>Unsere Beiträge:</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>Nächster Termin</td>
<td>10. + 11. Mai 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>Das monatliche Online-Konferenzprogramm des Open Source Automation Development Lab (OSADL)
ist mittlerweile ein fester Bestandteil im Terminkalender des Pengutronix Teams.</p>
<p>In den Editionen werden diverse Themen Rund um den Bereich von Open Source
Software im industriellen Umfeld besprochen und diskutiert.</p>
<p>Der Aufbau folgt dabei dem Schema:
Einstieg in das Thema durch einen Überblicksvortrag, gefolgt von einem
Expertenvortrag und anschließender Diskussion.</p>
<p><strong>Unser Beitrag:</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>Nächster Termin</td>
<td>26. Januar 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>Das <strong>Live Embedded Event</strong> ist ein weiteres Format, das während der Pandemie
entstanden ist, um die Embedded Community im virtuellen Raum zu versammeln.</p>
<p>Da die Konferenz von unseren Mitstreitern aus Frankreich initiiert und
ausgerichtet wird, wird die Konferenz gemischt in französischer und
englischer Sprache abgehalten.</p>
<p><strong>Unser Beitrag:</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>Nächster Termin</td>
<td>18. Mai 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>"Über 2.000 Aktionen bundesweit und 4.325 Stunden Programm in ganz Deutschland
und im virtuellen Raum. Das war der Digitaltag 2021!"</p>
<p>Wir haben uns für Hildesheim mit der Frage beschäftigt, wie man eine
Stadt zur "Smart City" wandeln kann. Hierzu haben wir uns zunächst mit
LoRaWAN als technischen Baustein für ein smartes Hildesheim beschäftigt und
anschließend versucht herauszuarbeiten, was eine Smart City von Freifunk
als Communityprojekt lernen kann.</p>
<p><strong>Unser Beitrag:</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>Nächster Termin</td>
<td>24. Juni 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>Die FPGA-Conference richtet sich mit Fachvorträgen rund um die Entwicklung
von FPGAS vor allem an die Industrie.</p>
<p>Im Schwerpunkt standen dabei Supply Chain Security, AI und Edge Computing mit
einem besonderen Fokus auf konkreten Produktlösungen.</p>
<p><strong>Unser Beitrag:</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>Nächster Termin</td>
<td>05. - 07. Juli 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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: 200px;
"/>
</a><figcaption itemprop="caption description" style="
width: 200px;
"><p>Logo FrOSCOn: All rights reserved</p>
</figcaption>
</figure>
</div><p>Auch das Sommertreffen der deutschsprachigen Open Source Community fand
in 2021 als reine Onlineveranstaltung statt.</p>
<p>In den rund 36 Stunden umfassenden <a href="https://media.ccc.de/c/froscon2021">Vortragsaufzeichungen</a> werden beispielsweise Erfahrungen mit dem Arbeiten
im Homeoffice, Security-Schwachstellen oder Einstiegsmöglichkeiten in die Open-
Source-Entwicklung vermittelt.</p>
<p>Neu hinzugekommen ist die Kategorie "Woodworking instead of IT" über Hobbies
und Ausgleichsmöglichkeiten, die Vortragende während der
Corona-Kontaktbeschränkungen ausprobiert und entdeckt haben.</p>
<p><strong>Unser Beitrag:</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>Nächster Termin</td>
<td>voraussichtlich im Herbst 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>Die <strong>Embedded Linux Conference Europe</strong> (ELC-E) war dieses Mal nicht nur eine rein
europäische Konferenz, sondern erstmals eine hybride Veranstaltung in den USA mit
Gästen aus der ganzen Welt, vor Ort und über das Internet.</p>
<p>Verständlicherweise ist es schwer, allen Schlafgewohnheiten entgegen zu
kommen, wenn ein weltweites Publikum auf einer Konferenz zusammenkommt.
Durch ein spontan zur Verfügung gestelltes Jitsi, war ein fachlich fundierter
Austausch der Teilnehmer untereinander gut möglich, aber dennoch kann dies die
vielfältigen echten Diskussion und spontanen Treffen auf den Gängen kaum ersetzen.
Von daher freuen wir uns sehr, wenn wir uns bald auch wieder live auf der ELC-E
begegnen können.</p>
<p><strong>Unsere Beiträge:</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>Nächster Termin</td>
<td>13. - 16. September 2022</td>
</tr>
<tr><td>Link zur Veranstaltung</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>Der <strong>Embedded Software Engineering (ESE) Kongress</strong> beschreibt sich als Leitkongress
für die Embedded Industrie.
Der Kongress bietet neben einem ausführlichen Track im Bereich Management
und Teamführung auch Grundlagenvorträge in vielen relevanten Bereichen der Embedded
Entwicklung, wie Testautomatisierung und Code Quality.</p>
<p><strong>Unsere Beiträge:</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>Nächster Termin</td>
<td><ol class="first last arabic simple" start="5">
<li>bis 09. Dezember 2022</li>
</ol>
</td>
</tr>
<tr><td>Link zur Veranstaltung</td>
<td><a href="https://ese-kongress.de/">https://ese-kongress.de/</a></td>
</tr>
</tbody>
</table>
</div>
</div>
<p>Neben den Verbesserungen rund um Embedded-Linux-Software und der Weiterentwicklung
des Linux-Kernels hat das Team von Pengutronix im letzten Jahr die
Gelegenheit genutzt, dass viele Konferenzen vom eigenen Schreibtisch aus erreichbar
waren.
Dadurch konnten wir unsere Erfahrungen und Ideen noch breiter mit der Community
teilen und auch an Konfrenzen Teilnehmen, die für uns sonst Flugstunden entfernt
lägen.</p>2022-01-18T17:00:00+01:00tag:www.pengutronix.de,2022-01-01:/2022-01-01-pengutronix-kernel-contributions-in-2021.htmlDie Pengutronix Kernel-Beiträge in 20212022-01-01T13:46:36+01:00Robert Schwebel<div class="section" id="die-pengutronix-kernel-beitrage-in-2021">
<p>2022 hat begonnen, und obwohl Corona unsere Workflows stark verändert
hat, hat das Pengutronix Team auch in diesem Jahr wieder etliche
Beiträge zum Linux-Kernel geleistet. Das letzte Kernel-Release in 2020
war 5.10, das letzte in 2021 war 5.15 - schauen wir also, was sich
dazwischen bei uns getan hat.</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>Wie üblich sind die Beiträge, die Pengutronix zum Linux-Kernel
beisteuert, durch unsere Embedded Linux Projekte in der Industrie
getrieben: Unsere Kunden bauen Geräte, wir schauen uns an, welche der
benötigten Komponenten bereits im Kernel vorhanden sind und helfen dort,
wo Dinge fehlen. Manchmal bedeutet das, Patche von Mailinglisten
einzusammeln und so weit zu verbessern, bis sie startklar für Mainline
sind; manchmal müssen Treiber von Grund auf neu geschrieben werden, und
manchmal müssen Frameworks erst so weit verändert werden, dass bestimmte
Funktionalitäten überhaupt realisiert werden können.</p>
<p>Patch-Serien werden in der Regel zunächst so geschrieben, dass der Fokus
auf den Anforderungen des jeweiligen Projekts liegt; dann werden sie auf
den Mailinglisten gepostet und durch die Community und die Maintainer
begutachtet. Wenn ein Patch in Linux Mainline ankommt, hat er oft eine
monate- bis jahrelange Geschichte hinter sich.</p>
<p>Alles in allem haben 675 Patche von Pengutronix in der Phase zwischen
5.10 und 5.15 ihren Weg in den Kernel gefunden - mehr als 1,8 Patche pro
Tag. 15 Kollegen waren daran beteiligt:</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">Anz. Patche</th>
<th class="head">Autor</th>
<th class="head">Anz. Patche</th>
<th class="head">Autor</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>Dabei reflektiert die Anzahl der Patche allerdings selten den Aufwand,
der ins Mainlining gesteckt wurde. Verglichen mit früheren Jahren haben
wir es heute oft mit sehr viel komplexeren Patchserien zu tun,
insbesondere wenn es um Hardware wie Grafiksysteme oder Netzwerk-Themen
geht. Hier brauchen die Patchserien oft mehrere Review- und
Überarbeitungsrunden, bis sie in Mainline angekommen sind. Letztlich
geht es bei der Kernelentwicklung darum, Code mit extrem hoher Qualität
zu schreiben, und dies ist in vielen Fällen - selbst bei kleineren
Patchen - eine Menge Arbeit.</p>
<p>Für einen Überblick der bearbeiteten Themen schauen wir uns die größeren
Baustellen an:</p>
<ul>
<li><p class="first">Uwe Kleine-Königs Patche drehten sich überwiegend um das PWM-Subsystem:
116 von 202 Patchen kamen in diesem Bereich zustande. PWM
scheint auf den ersten Blick ein "einfaches" Thema zu sein, aber beim
genauen Hinsehen fand sich viel undefiniertes Verhalten zwischen den
verschiedenen Treibern. Viele Patche haben deshalb mit solchen
Unklarheiten aufgeräumt und den Kernel in diesem Bereich insgesamt
verbessert.</p>
<p>Andere Patche kamen aus dem Bereich NFC, Input, SPI, hwmon, firmware,
backlight, leds, tty, device tree, clock, i2c, rtc und dem Treiber-Core.
Viele der Baustellen kamen dabei während der Arbeit an anderen
Komponenten im Umfeld auf.</p>
</li>
<li><p class="first">Marc Kleine-Budde maintaint das Linux CAN-Subsystem, so dass es keine
Überraschung ist, dass 143 seiner 149 Patche aus diesem Bereich des
Kernels kommen. Viele Änderungen betreffen Performance-Verbesserungen
an einzelnen CAN-Treibern, die aus konkreten Kundenszenarien kommen.
Allein der Treiber für den MCP251x von Microchip (ein oft eingesetzter
CAN-Controller mit SPI-Schnittstelle) wurde mit 37 Patchen verbessert.
Aber auch viele andere Treiber (rcar, c_can, tcan4x5x, flexcan, at91,
hi311x, peak_usb, m_can) sowie das CAN-Subsystem insgesamt wurden
optimiert.</p>
</li>
<li><p class="first">Oleksij Rempel hat an vielen Themen rund um CAN / J1939 sowie im Bereich der
Ethernet-Switche und "moderner" Ethernet-Physik wie 10-Base T1s gearbeitet.</p>
</li>
<li><p class="first">Lucas Stach hat als Maintainer an Etnaviv, dem Open Source Treiber für
Vivante-GPUs, gearbeitet. Daneben entstanden Patche im Bereich clk,
power und gpcv2, die insbesondere im Rahmen der Arbeiten an den i.MX8M
Derivaten aufkamen.</p>
</li>
<li><p class="first">Michael Tretter hat hauptsächlich an der Xilinx Ultrascale-Familie und
an den "allegro" Video Encoder- und Decodertreiber auf diesen Chips
gearbeitet - eine große, komplexe Patchserie, die einen langen Weg bis
zur Aufnahme in den Kernel hinter sich gebracht hat. UltraScale hat
sich als eine hervorragende Plattform für kundenspezifisches
Video-Prozessing herausgestellt - ein Themenbereich, der bei vielen
Kunden zunehmend wichtig wurde.</p>
</li>
<li><p class="first">Philipp Zabel maintaint das Reset-Subsystem im Kernel. Daneben hat er
weiter an der CODA Einheit und weiteren i.MX Grafik- und Videothemen
gearbeitet.</p>
</li>
<li><p class="first">Michael Grzeschiks Aktivitäten lagen vor allem in zwei Bereichen: dem
KSZ8795 Ethernet-Switch und USB UVC.</p>
</li>
<li><p class="first">Ahmad Fatoum hat viele Bugfixes für i.MX8M beigesteuert, vor allem in
den Bereichen Taktversorgung, TF-A Schnittstelle und Deferred Probing.
Weiterhin hat er an STM32MP1, nvmem, dm crypt und Sensoren gearbeitet.</p>
</li>
<li><p class="first">Marco Felsch, Sascha Hauer, Jürgen Borleis, Rouven Czerwinski, Jan
Lübbe und Steffen Trumtrar waren mit SPI, ASoC, CODA, Ethernet
Controllern und Switches, PWM, I2C, Etnaviv, ecryptfs, Quota, NAND
Flash, ubifs, DMA auf i.MX, Regulatoren, OP-TEE und Netzwerk
Timestamping beschäftigt.</p>
</li>
<li><p class="first">Und schließlich hat unser Hardware-Kollege Leonard Göhrs seinen
ersten Patch als Fix für ein ALSA-Sound-Problem auf PowerPC in den
Kernel bekommen. :-)</p>
</li>
</ul>
<p>Wenn man sich die beeindruckende Liste aus 675 Patches anschaut und all
die Entwickler-Geschichten hinter sowohl kleinen Einzeiler-Patchen wie
auch großen Serien kennt, denke ich, dass wir insgesamt mit den
Ergebnissen aus 2021 zufrieden sein können. Es gab eine Menge
Interaktion mit anderen Kernel-Entwicklern und -Maintainern, und wir
haben eine Menge gelernt.</p>
<p>Last but not least wurden dabei eine ganze Menge Kundenthemen auf eine
nachhaltige Weise gelöst. Probleme, die in Mainline gefixt sind, werden
für andere Nutzer in Zukunft keine Schwierigkeiten mehr bereiten. Wir
würden also freundlichst darum bitten, dass Sie, wenn Sie auf ein
Problem stoßen, das wir (oder andere in der Community) bereits gelöst
haben, sich dadurch erkenntlich zeigen, dass Sie Ihre Patche in Zukunft
ebenfalls in Mainline bringen. :-)</p>
<p>Die Kernel-Historie geht zurück bis zur Version 2.5.0. Mit den Beiträgen
aus diesem Jahr haben wir inzwischen 6278 Patche in Mainline.</p>
<p>Ein Frohes Neues Jahr!</p>
</div>
<p>2022 hat begonnen, und obwohl Corona unsere Workflows stark verändert
hat, hat das Pengutronix Team auch in diesem Jahr wieder etliche
Beiträge zum Linux-Kernel geleistet. Das letzte Kernel-Release in 2020
war 5.10, das letzte in 2021 war 5.15 - schauen wir also, was sich
dazwischen bei uns getan hat.</p>2022-01-01T13:46:36+01:00tag:www.pengutronix.de,2021-12-02:/2021-12-02-qm-meets-ci.htmlQM meets CI - Entwicklerfreundliche Prozessdokumentation2021-12-02T14:00:00+01:00Marie Mann<div class="section" id="qm-meets-ci-entwicklerfreundliche-prozessdokumentation">
<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>Sketchnotes zu dem Vortrag</p>
</figcaption>
</figure>
</div><p>"Hey Marie, wie beantrage ich nochmal meinen Urlaub?" Da ich bei Pengutronix
in der Verwaltung und im Projektmanagement arbeite, kenne ich diese Art Fragen nur
zu gut, und seit ich unsere Prozesse aufschreibe, kann ich (endlich) auch einmal
mit "RTFM" antworten.
Prozesse sind Arbeitsabläufe, die immer wieder durchgeführt werden müssen,
manchmal in einem festen Intervall, manchmal nach Bedarf.</p>
<p>Als 2018 die Prozessdokumentation bei Pengutronix von Grund auf überarbeitet
wurde, stand vor allem die Frage im Raum, wie die MitarbeiterInnen an der
Entstehung der Prozesse beteiligt werden können.
Für die Dokumentation wurden Abläufe und Tools gewählt, die bereits bei der
Mehrheit der MitarbeiterInnen etabliert waren.</p>
<p>Dieser Beitrag stellt die gewählten Werkzeuge vor, zeigt das Vorgehen und
erläutert ergänzend zu dem Vortrag exemplarisch den Aufbau einer
Prozessbeschreibung.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/_9OMJyB5kBk"></iframe>
</div>
<p><em>Warum Prozesse aufschreiben?</em></p>
<p>Sobald ein Unternehmen groß genug ist, dass nicht mehr alle MitarbeiterInnen in
einem Raum sitzen und mitbekommen, an welchen Aufgaben gerade wie gearbeitet
wird, entsteht die Notwendigkeit, genau diese Abläufe aufzuschreiben.
Die Prozessdokumentation ermöglicht, das Wissen um die Abläufe festzuhalten und
Regeln aufzustellen.</p>
<p>Die Regeln werden zwar von der Geschäftsführung vorgegeben, sind aber für alle
MitarbeiterInnen einseh- und damit auch einforderbar.
Dies ermöglicht eine faire Behandlung aller MitarbeiterInnen.</p>
<p><em>Wie können MitarbeiterInnen mitgenommen werden?</em></p>
<p>Das Aufschreiben der Prozesse ist kein Selbstzweck, sondern dient dazu, dass
MitarbeiterInnen nachlesen können, wie zum Beispiel der Urlaub beantragt wird.</p>
<p>Oftmals sind die ProzessnutzerInnen die inhaltlichen Experten, da sie den
Prozess jeden Tag befolgen und damit leben.
Sie wissen am besten, wie ein Ablauf optimiert werden kann.
Allein dieser Umstand sollte Grund genug sein, die ProzessnutzerInnen in die
Gestaltung der Prozesse mit einzubeziehen:</p>
<ul class="simple">
<li>Die Prozesse können durch die NutzerInnen verbessert werden und</li>
<li>die Prozesse werden viel bereitwilliger befolgt, wenn sie den NutzerInnen
sinnvoll erscheinen.</li>
</ul>
<p>Der Einstieg in die Softwareentwicklung wird häufig mit einem Kochrezept
verglichen.
Man könnte ein Kochbuch auch als Prozessdokumentation bezeichnen:
Ein Prozess, wie z.B. das Kochen, hat einen Auslöser (Hunger) oder
Einstiegspunkt und beschreibt eine Reihe von Handlungsanweisungen.</p>
<p>Wenn die Prozessdokumentation der Quellcode ist, mit dem das Unternehmen läuft,
warum nicht die Werkzeuge aus der Softwareentwicklung nutzen, um die
Prozessdokumentation zu schreiben?</p>
<p>Bei Pengutronix wurde der Gedankengang ernst genommen, und die
Prozessbeschreibungen werden in Form eines Prozesshandbuchs mit den Mitteln der
Softwareentwicklung gestaltet.</p>
<p>Für die Umsetzung gab es folgende Anforderungen an die Prozesse und deren
Darstellung:</p>
<ul class="simple">
<li>Die Prozesse sollen einfach zugänglich sein,</li>
<li>die MitarbeiterInnen sollen eine Möglichkeit zur Mitarbeit haben und bei der
Gestaltung der Prozesse beteiligt werden,</li>
<li>die Prozesse unterliegen (daher) einem Freigabeprozess durch die
Geschäftsführung,</li>
<li>die Prozesse sollen regelmäßig auf ihre Aktualität geprüft werden.</li>
</ul>
<div class="section" id="werkzeuge-und-workflows">
<h3>Werkzeuge und Workflows</h3>
<p>Um die Anforderungen zu erfüllen und das Prozesshandbuch als "Softwareprojekt"
umzusetzen, werden sowohl Workflow als auch Tooling, die bereits im Unternehmen
etabliert sind, genutzt.
Beides soll im Folgenden kurz betrachtet werden.
Die Beschreibung wird dabei auf die wesentlichen Merkmale reduziert, die
notwendig für die Gestaltung der Prozessdokumentation sind.</p>
<div class="section" id="linux-kernel-workflow">
<h4>Linux-Kernel-Workflow</h4>
<p>Einer der wichtigsten und am weitesten verbreiteten Workflows bei Pengutronix
ist der, mit dem der Linux-Kernel entwickelt wird.</p>
<p>Der Linux-Kernel ist in verschiedene Subsysteme aufgeteilt, die in etwa mit
einzelnen Abteilungen eines Unternehmens vergleichbar sind.
Je nach Komplexität kann es weitere Subsysteme geben.
Mögliche Änderungen an dem Linux-Kernel (Bugfixes, neue Treiber, Verbesserungen
an der Code-Qualität) werden zunächst innerhalb des Subsystems diskutiert.
Für jedes Subsystem (dieses ist mit einer mittleren Managementebene
vergleichbar) ist ein Maintainer verantwortlich, der Tests durchführt und
prüft, ob die Qualitätsstandards eingehalten sind.
Wenn alles in Ordnung ist, fließen die Änderungen aller Subsysteme in die
nächste Version des Linux-Kernels ein.
Dieser wird von Linus Torvalds (dem Erstautor und Maintainer von Linux)
persönlich released.</p>
<p>Den beschriebenen Workflow haben wir für die Arbeit am Prozesshandbuch
adaptiert:
Änderungen an der Prozessdokumentation werden mit den jeweiligen
ProzessnutzerInnen diskutiert und anschließend an die Geschäftsführung zur
Freigabe gegeben.
Derzeit ist das Pengutronix-Prozesshandbuch-Projekt noch
klein genug, so dass auf das mittlere Management verzichtet werden kann.</p>
</div>
<div class="section" id="versionskontrolle">
<h4>Versionskontrolle</h4>
<p>Um diesen Workflow realisieren zu können, werden die Prozesse als
<a href="https://docutils.sourceforge.io/rst.htm">strukturierte Textdateien</a>
geschrieben, die <a href="https://git-scm.com/doc">versionskontrolliert</a>
verwaltet werden.
Der Release-Branch der Versionsverwaltung ist nur für die Geschäftsführung
schreibbar, so dass über ein neues Release des Prozesshandbuchs auch
gleichzeitig die Freigabe sichergestellt ist.</p>
<p>Der Vorteil von Dateien, die als reStructuredText (.rst) oder Markdown (.md)
geschrieben werden im Gegensatz zu nicht-textbasierten Formaten wie .docx oder
.odf, ist, dass die inhaltliche Änderung zusammen mit einem Zeitstempel und den
Autoren in einer Versionsverwaltung einfach verfolgt werden kann.
Zudem ermöglicht eine Versionsverwaltung neben der reinen Änderungsverfolgung
auch Beschreibungstexte, in denen festgehalten werden kann, warum eine Änderung
erfolgt und welche Entscheidungen zu der Prozessänderung geführt haben.</p>
</div>
<div class="section" id="web-darstellung">
<h4>Web-Darstellung</h4>
<p>So groß der Charme von Textdateien aus Sicht der Prozessschreibenden auch ist,
für die Prozessnutzenden kann die Benutzerfreundlichkeit verbessert werden.
Daher wird bei Pengutronix das quelloffene Software-Dokumentationswerkzeug
<a href="https://www.sphinx-doc.org/en/master/">Sphinx</a> eingesetzt, um eine
Webansicht zu generieren.
In dieser können die Prozesse sowohl direkt verlinkt werden als auch
Formulare, die zu einem Prozess gehören, als Download bereitgestellt werden.</p>
</div>
<div class="section" id="build-server">
<h4>Build-Server</h4>
<p>Mit Hilfe eines <a href="https://www.jenkins.io/">Build-Servers</a>
wird das aktuelle Release der Prozessdokumentation gebaut und als Webansicht
zur Verfügung gestellt.
Gleichzeitig ermöglicht der Build-Server die Nutzung von automatisierten Tests.</p>
<p>Bei Pengutronix wird beim Bauen durch den Build-Server unter anderem geprüft,
ob das Datum, an dem das nächste Prozessreview fällig wäre, überschritten
wurde.
Sofern dieser Fall eintritt, werden Erinnerungs-E-Mails verschickt, so dass der
Prozess zeitnah auf seine Aktualität hin überprüft werden kann.</p>
<p>Das Setup wurde hier nur schematisch beschrieben, da es nicht um konkrete
Produkte, sondern deren Einsatz zur Prozessdokumentation im Fokus steht.
Wichtig ist, dass eine Versionsverwaltung zur Änderungsverfolgung und ein
Buildserver für das "Continuous Testing" und "Continuous Deployment" verwendet
werden.</p>
</div>
<div class="section" id="struktur-einer-prozessbeschreibung">
<h4>Struktur einer Prozessbeschreibung</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>Webansicht der Pengutronix Prozessdokumentation (Ausschnitt)</p>
</figcaption>
</figure>
</div><p>Damit das Setup im vollen Umfang genutzt werden kann, ist es entscheidend, dass
im Vorfeld eine Struktur für das Handbuch und den Aufbau eines Prozesses
festgelegt wird.
Ein gutes Beispiel für die Gliederung der Prozesse und, wie so ein Handbuch
gestaltet werden kann, ist das <a href="https://about.gitlab.com/handbook/">"Company Handbook" von GitLab Inc.</a>.</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>Um etwas in die Praxis zu gehen, wird Ausschnittsweise die Struktur
eines Prozesses in der Prozessdokumentation von Pengutronix beschrieben sowie
exemplarisch ein Test vorgestellt.</p>
<p>Ein Prozess besteht aus drei Abschnitten: Der erste Abschnitt ist eine Tabelle,
in der Metadaten erfasst werden.
Wann wurde der Prozess zuletzt aktualisiert?
Wann ist das nächste Review fällig?
Gibt es einen Vorgänger-Prozess?
Welcher Prozess schließt sich an den aktuellen Prozess an?
Gibt es Formulare zum Download?</p>
<p>Der zweite Abschnitt enthält die eigentliche Prozessbeschreibung.
Für diese ist keine feste Form vorgegeben.
Damit der Prozess gut lesbar ist, werden weitere Strukturierungselemente, wie
Infoboxen oder Aufzählungen, verwendet.</p>
<p>Der dritte Abschnitt ist für allgemeine Informationen reserviert, die an die
Qualitätskriterien der ISO 9001 angelehnt sind.
Dabei sollen unter anderem folgende Fragen beantwortet werden:
Wer sind die ProzessnutzerInnen und -eigentümerInnen?
Wann wird der Prozess aktiviert?
Welche Anforderungen gibt es an die ProzessnutzerInnen und welche
Qualitätskriterien gibt es zur Erfüllung an den Prozess?</p>
<p>Die Struktur richtet sich zum einen an die ProzessnutzerInnen, damit die
Informationen möglichst leicht gefunden werden können.
Zum anderen erlaubt gerade die Metadaten-Tabelle den Einsatz von
Testautomatisierung.</p>
</div>
<div class="section" id="testautomatisierung">
<h4>Testautomatisierung</h4>
<p>Einer der wichtigsten Einsätze für die Testautomatisierung ist eine regelmäßige
Erinnerung, dass Prozesse einem Review unterzogen werden sollen.</p>
<p>Damit bestimmte Elemente, wie das nächste Review-Datum eines Prozesses, geprüft
werden können, muss sehr exakt angegeben werden, wo das Element zu finden ist.
Dafür eignet sich besonders die Tabellenstruktur.</p>
<p>Die Tests wurden hier in Python geschrieben und für das Parsen der Datei die
docutils-Library verwendet.
Das vorliegende Code-Beispiel zeigt den Test auf das Review-Datum eines
Prozesses.</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>Dieser Test besteht aus drei Testschritten:
Zunächst wird geprüft, ob die Tabellenspalte überhaupt gefunden wurde,
anschließend, ob das Datum dem erwarteten Format entspricht, und zuletzt, ob
dieses Datum in der Vergangenheit liegt.</p>
</div>
</div>
<div class="section" id="fazit">
<h3>Fazit</h3>
<p>Die Prozessdokumentation wird seit nunmehr drei Jahren bei Pengutronix in
dieser Form erfolgreich geführt und sowohl von EntwicklerInnen, Admins als auch
der Verwaltung (teilweise in eigenständig verwalteten Dokumentationen) genutzt.</p>
<p>Das Ziel, MitarbeiterInnen die Mitgestaltung an den Prozessen zu ermöglichen,
wurde erreicht.
Natürlich gilt für das Prozesshandbuch, wie für ein Softwareprojekt, dass es
niemals fertig ist.
Daher ist es auch für die Pflege der Prozessdokumentation wichtig, dass es eine
verantwortliche Person mit entsprechendem Zeitbudget gibt.</p>
</div>
</div><p>"Hey Marie, wie beantrage ich nochmal meinen Urlaub?" Da ich bei Pengutronix
in der Verwaltung und im Projektmanagement arbeite, kenne ich diese Art Fragen nur
zu gut, und seit ich unsere Prozesse aufschreibe, kann ich (endlich) auch einmal
mit "RTFM" antworten.
Prozesse sind Arbeitsabläufe, die immer wieder durchgeführt werden müssen,
manchmal in einem festen Intervall, manchmal nach Bedarf.</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-25:/2021-08-25-update-des-remotelab-equipments.htmlUpdate des Remotelab Equipments2021-08-25T11:38:19+01:00Leonard Göhrs<div class="section" id="update-des-remotelab-equipments">
<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 a Werbe-Blogpost, reads like a Werbe-Blogpost …
it probably is a Werbe-Blogpost!
Niemand möchte gerne Werbung lesen, und wir schreiben sie auch gar
nicht so gerne, aber wie alle stolzen Eltern möchten wir Ihnen
gerne die neuen Produkte vorführen, die unsere Unternehmens-Tochter,
die <a href="https://linux-automation.com">Linux Automation GmbH</a>,
frisch in ihren Shop aufgenommen hat. Mit diesen neuen Produkten
ergänzen wir, und vielleicht auch bald Sie, unsere
<a href="https://www.pengutronix.de/de/blog/2021-02-21-showcase-remote-working.html">Remotelab-Infrastruktur</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>Nicht alle Projekte booten von SD-Karten, manchmal werden Boards auch
über USB bespielt, starten von einer eMMC oder von NAND¹.
Um in diesem Fall den aktiven Boot-Modus umzuschalten,
müssen in der Regel einfach zwei Pins kurzgeschlossen,
oder ein Taster gedrückt werden.
Da dies nun gerade bei ständigen Tests schnell ermüdend wird,
gibt es nun eine elegante technische Lösung:</p>
<p>Der <a href="https://shop.linux-automation.com/lxatac_can_io-D01-R01-V01-C00">LXA IOBus 4DO-3DI-3AI</a>
erlaubt es, kleine elektrische Lasten zu schalten und
so z. B. automatisch, wo sonst händisch Jumper gesetzt werden müssten, zwischen
verschiedenen Bootmodi umzuschalten oder Resets auszulösen, die sonst per
Tastendruck durchgeführt werden. Außerdem kann der 4DO' genutzt werden, um
Versorgungsspannungen auszulesen oder digitales Status-Feedback einzusammeln
und in die Testautomatisierung zurückzuführen.</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 dem Blogpost <a href="https://www.pengutronix.de/de/blog/2021-05-25_the_lxa_iobus.html">Lab-Automatisierung mit LXA IOBus</a>
haben wir bereits von den Ideen berichtet, unsere Lab-interne Kommunikation von
USB auf CAN umzustellen.
Ein wiederkehrendes Problem dabei: Ein Consumer-Computer kann kein CAN.
In unseren Laborservern lösen wir dieses Problem in der Regel mit PCI-Express
CAN-Karten, aber für EntwicklerInnen-Laptops sind diese Karten zu klobig.</p>
<p>Stattdessen gefällt uns dafür das Open-Source
<a href="https://github.com/linux-automation/candleLight">candleLight-Projekt</a>
sehr gut.
So gut sogar, dass wir uns entschieden haben, es mit einem Raketenpinguin-Logo
zu versehen und als Produkt
<a href="https://shop.linux-automation.com/candlelight-D02-R01-V01-C00">in den Shop aufzunehmen</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>Die <a href="https://shop.linux-automation.com/Accessories/lxa_tools-S02-R01-V01-C00">RJ45-Matrix</a>
ist ein weiteres kleines, aber dennoch sehr feines Spielzeug aus der
LXA-Tools-Reihe.
Mit der RJ45-Matrix können per Lötbrücke oder beliebigen 0402 SMD-Bauteilen
Verbindungen zwischen allen Leitungen zweier RJ45-Buchsen hergestellt werden.</p>
<p>Wofür haben <em>wir</em> die RJ45-Matrix bisher verwendet?</p>
<ul class="simple">
<li>Als Breakout-Board für RJ45-Buchsen auf 2.54mm Pinheader.</li>
<li>Um Ethernet-Paare zwischen zwei Ethernet-Ports zu tauschen.</li>
<li>Um Zwei Ethernet-Geräte über 0402 Kondensatoren AC zu koppeln,
um direkt PoE-Spannungen einspeisen zu können.</li>
</ul>
<p>Welche Einsatzzwecke könnten <em>wir</em> uns noch vorstellen?</p>
<ul class="simple">
<li>Erzeugen von Loopback-Verbindungen, um z.B. sehr lange Zweidraht-Strecken
über sehr viel kürzere achtadrige Kabel zu testen.</li>
<li>Erzeugen von definiertem Cross-Talk durch Zusammenkoppeln der verschiedenen
Paare.</li>
<li>Einfügen von z.B. resistiven Verlusten in eine Leitung.</li>
</ul>
<hr class="docutils"/>
<p>¹ Welche Arten von Kopfweh NAND als Bootquelle erzeugen kann,
wäre ein tolles Thema für einen weiteren Blogpost.
Bis dahin merken Sie sich vielleicht: „Wenn möglich, vermeiden!“</p>
</div>
</div><p>If it looks like a Werbe-Blogpost, reads like a Werbe-Blogpost …
it probably is a Werbe-Blogpost!
Niemand möchte gerne Werbung lesen, und wir schreiben sie auch gar
nicht so gerne, aber wie alle stolzen Eltern möchten wir Ihnen
gerne die neuen Produkte vorführen, die unsere Unternehmens-Tochter,
die <a href="https://linux-automation.com">Linux Automation GmbH</a>,
frisch in ihren Shop aufgenommen hat. Mit diesen neuen Produkten
ergänzen wir, und vielleicht auch bald Sie, unsere
{{ link(path='blog/2021/2021-02-21_showcase-remote-working/post_de.rst', name='Remotelab-Infrastruktur', _content_path='blog/2021/2021-08-25_update-des-remotelab-equipments/post_de.rst', _content_lineno=7) }}.</p>2021-08-25T11: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.htmlLab-Automatisierung mit LXA IOBus2021-05-25T09:05:00+01:00Leonard Göhrs<div class="section" id="lab-automatisierung-mit-lxa-iobus">
<div class="ps-gallery single-image right" itemscope="" itemtype="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>Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen,
seitdem haben wir viele Normen gelesen,
Dinge über Webshops und den Alltag der Elektronikfertigung gelernt
und still und heimlich an neuen Produkten getüftelt.
Heute möchte ich das LXA IOBus-System vorstellen,
bestehend aus einem CAN-basierten Kommunikationsprotokoll,
einem zugehörigen Gateway-Server
und einer neuen Klasse an Linux Automation GmbH Produkten.
Zwei dieser neuen Produkte sind der Ethernet-Mux
und das 4DO-3DI-3AI Input/Output-Board.</p>
<p>Wir setzen immer dann auf den LXA IOBus,
wenn es darum geht Labor-Automatisierungsgeräte anzubinden,
die ohne hohe Datenraten auskommen.</p>
<p>Das erste Gerät dieser Art ist der Ethernet-Mux.
Er erlaubt das Multiplexen eines Ethernet-Ports auf einen von zwei anderen Ethernet-Ports.
So lässt sich ein zu prüfendes Embedded-Gerät (auch Device under test, oder DUT gennant)
ferngesteuert und vollkommen transparent mit einem von zwei Netzwerken verbinden.</p>
<p>Das zweite Gerät ist der LXA IOBus 4DO-3DI-3AI.
Der 4DO' erlaubt es kleine elektrische Lasten zu schalten und so z. B. automatisch,
wo sonst händisch Jumper gesetzt werden müssten,
zwischen verschiedenen Bootmodi umzuschalten oder Resets auszulösen,
die sonst per Tastendruck durchgeführt werden.
Außerdem kann der 4DO' genutzt werden,
um Versorgungsspannungen auszulesen
oder digitales Status-Feedback einzusammeln
und in die Testautomatisierung zurückzuführen.</p>
<p>Wenn Sie sich jetzt fragen,
was es mit dieser Labor-Automatisierung überhaupt auf sich hat,
schauen Sie doch mal bei unserem Artikel über unsere
<a href="https://www.pengutronix.de/de/blog/2021-02-21-showcase-remote-working.html">Remotelabs</a> vorbei,
in dem wir unsere zentralisierte Infrastruktur zur dezentralen Entwicklung an Embedded-Geräten beschreiben.</p>
<div class="section" id="iobus-das-protokoll">
<h3>IOBus - Das Protokoll</h3>
<p><em>Warum ein neues Protokoll zur Labor-Automatisierung einführen,
wenn es doch schon USB, Ethernet, Modbus und 1-Wire gibt?</em></p>
<ul>
<li><p class="first"><em>Warum nicht USB?</em> - Wir haben USB großflächig im Einsatz und auch schon ein
USB-basiertes Produkt auf dem Markt,
warum setzen wir nicht auch für den Ethernet-Mux und den 4DO' auf USB?
Die Antwort ist Zuverlässigkeit.
Unsere Remotelabs sind pro Rack mit jeweils 40 USB-Steckplätzen ausgestattet.
Wir betreiben bei Pengutronix momentan etwa acht voll ausgebaute Remotelabs.
Die Multiplikation dieser beider Zahlen bedeutet,
dass Probleme,
die pro Gerät vielleicht nur ein Mal pro Jahr auftreten,
uns fast täglich plagen.
Bei USB resultiert ein sich falsch verhaltendes Gerät oft genug im Ausfall eines ganzen Hubs,
was zu regelmäßiger Frustration führt.</p>
<p>Das soll nicht heißen,
dass wir USB von nun an den Rücken kehren wollen,
tatsächlich entwickeln wir auch weiter USB-basierte Geräte,
wenn wir auf die hohen Bandbreiten angewiesen sind.
Eines dieser neuen Produkte spricht sogar
<a class="reference external" href="https://www.linux-automation.com/de/products/usb-mux.html">USB auf all seinen Ports</a>,
aber das ist eine Geschichte für ein andermal.</p>
</li>
<li><p class="first"><em>Warum nicht Modbus?</em> - Modbus ist ein in der Industrieautomatisierung weitverbreitetes Protokoll
und es gibt eine breite Palette an verfügbaren Produkten zu akzeptablen Preisen.
Für die Entwicklung eigener Hardwarelösung halten wir das betagte Protokoll allerdings für zu wenig flexibel.
Und obwohl auch der IOBus eher für Anwendungen mit niedrigem Bandbreitenbedarf designed ist,
erscheinen uns die per Modbus erreichbaren Datenraten als unnötig einschränkend.</p>
</li>
<li><p class="first"><em>Warum nicht Ethernet?</em> - Ethernet erfordert Punkt-zu-Punkt-Verbindungen
zwischen Geräten und einem Switch mit eher klobigen Kabeln,
was einen breiten Einsatz in unseren Remotelabs erschwert.
Außerdem bedeutet der komplexe Protokollstack von Ethernet über IP bis hin zu TCP und darüber
einen vergleichsweise großen Softwareaufwand.
Für beide Probleme gibt es Lösungsvorschläge,
z. B. in Form von 10Base-T1S und CoAP.
Im Moment erscheint uns beides noch nicht für den Produktiveinsatz geeignet,
aber wir bleiben am Ball!</p>
</li>
<li><p class="first"><em>Warum nicht 1-Wire?</em> - Vor der Entwicklung des IOBus haben wir in unseren
Remotelabs selbst auf 1-Wire gesetzt,
sind nach einigen Jahren aber offensichtlich nicht mehr von dieser Entscheidung überzeugt.
Die proprietäre Natur des Protokolls und des Ökosystems machen sowohl die Fehlersuche
als auch Eigenentwicklungen schwierig.
Außerdem ist auch hier die maximale Datenrate eine unangenehme Einschränkung.</p>
</li>
</ul>
<p>Basierend auf diesen Lehren haben wir den LXA IOBus entwickelt.
Der IOBus basiert auf CAN und verschiedenen Teilen von CANopen,
einer Geräteabstraktionsebene für CAN.</p>
<p>CAN und CANopen haben unserer Auffassung nach einige Vorzüge:</p>
<ul class="simple">
<li><em>Grundsolide</em> - CAN wurde mit Blick auf sicherheitsrelevante Systeme
wie z. B. Autos entwickelt.
Remotlabs sind zwar kein sicherheitsrelevanter Bereich,
die Features,
die CAN so robust machen,
sind aber trotzdem ein großes Plus in diesem Szenario,
dazu gehören das automatische neu senden von verlorenen Nachrichten auf Hardwareebene
und der definierte Umgang mit,
aus Sicht des Busses,
kaputten Geräten,
der verhindert,
dass ein einziges Gerät den gesamten Bus zum Erliegen bringt.</li>
<li><em>Werkzeuge</em> - CAN genießt hervorragenden Support im Linux-Kernel und
dem gesamten umgebenden Ökosystem.
Entsprechend lassen sich CAN und CANopen beispielsweise in Wireshark analysieren und
CAN-Pakete können direkt mit Software,
die in den meisten Distributionen enthalten ist,
abgesendet und empfangen werden.</li>
<li><em>Multi-Drop Verkabelung</em> - CAN,
zumindest bei niedrigen Datenraten ist,
was die Verkabelung angeht,
wenig wählerisch.
So lässt sich ein ganzes Remotelab mit einem langen Flachbandkabel
ohne den Einsatz von Hubs und Switches
mit einem IOBus ausrüsten.
Auf das Flachbandkabel werden dazu einfach an den passenden Stellen
D-Sub 9 Buchsen aufgecrimpt
und von dort aus mit herkömmlichen D-Sub 9 Kabeln weiterverdrahtet.
Diese Bauweise erlaubt eine günstige Spannungs- und Datenversorgung der Knoten.</li>
<li><em>Plug and Play</em> - CANopen erlaubt es Knoten im Betrieb automatisch hinzuzufügen
und zu entfernen.
Der IOBus Server erkennt so direkt neu angeschlossene Geräte
und stellt sie zur Benutzung bereit.</li>
</ul>
<p>Bitte beachten Sie,
dass wir der Einfachheit halber nicht alle Aspekte von CANopen implementiert haben
und herstellerspezifische Geräteprofile nutzen.
Falls das zu Problemen bei der Integration unser IOBus-Geräte in ihre
Aufzugsteuerung oder ihren Müllwagen führen sollte,
schauen Sie gerne im Quellcode des IOBus-Server vorbei
und fragen Sie uns gern um Rat.</p>
</div>
<div class="section" id="iobus-der-server">
<h3>IOBus - Der Server</h3>
<p>Der <a class="reference external" href="https://www.linux-automation.com/de/products/lxa-iobus.html">IOBus Server</a>
ist die Schnittstelle zwischen Ihnen und dem IOBus.
Auf der IOBus-Seite nutzt er die Linux SocketCAN-API um mit den Geräten zu kommunizieren,
auf der anderen Seite stellt er einen HTTP-Server bereit.
Dadurch lassen sich die IOBus-Geräte sowohl per intuitivem Web-Interface bedienen
als auch aus Skripten heraus über die bereitgestellte 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 Überblick über die gefundenen Geräte.
Ein Klick auf eines der Geräte führt zur Detailansicht des Knotens.</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>Interaktive Detailansicht eines Knotens.
Ein Klick auf einen "Output" Knopf schaltet diesen aus/ein,
außerdem wird der Status der verschiedenen Eingänge angezeigt.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Der IOBus Server ist ein quelloffenes Projekt und bereits gut in das
<a class="reference external" href="https://www.pengutronix.de/de/software/labgrid.html">Labgrid</a>
Labor-Automatisierungsframework integriert.</p>
</div>
<div class="section" id="ethernet-mux">
<h3>Ethernet-Mux</h3>
<p>Der <a class="reference external" href="https://www.linux-automation.com/en/products/ethernet-mux.html">Ethernet-Mux</a>
erlaubt es,
einen an ein DUT angeschlossenen Ethernet-Port an
einen von zwei Ausgangsports weiterzuverbinden.
Diese Verbindung findet per analogen Hochfrequenzschaltern statt
und erlaubt einen Betrieb mit bis zu 1000Base-T-Geschwindigkeiten.
Außerdem erzeugt die Nutzung des Ethernet-Mux somit keine zusätzlichen Latenzen,
die ein Kabel nicht auch erzeugen würde.</p>
<p>Ein Beispiel Use-Case ist ein Testaufbau,
in dem ein DUT als Teil eines größeren Aufbaus getestet werden soll
und sowohl Zugriff auf ein Labornetzwerk mit TFTP-Server und SSH-Zugriff,
als auch zum Netzwerk,
in dem das DUT zum Einsatz kommen soll,
haben soll.</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>Der Ethernet-Mux im EMV-Test.
Zu sehen sind das CAN-basierte IOBus-Interface
und die verschiedenen Anschlüsse für Netzwerkkabel.
Das Klebeband hilft bei der Motivation zur Teilnahme am Test.</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>Der Ethernet-Mux nach dem erfolgreichen EMV-Test.
Bei diesen hervorragenden Testergebnissen braucht es auch kein Klebeband mehr.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
<div class="section" id="do-3di-3ai">
<h3>4DO-3DI-3AI</h3>
<p>Der <a class="reference external" href="https://www.linux-automation.com/de/products/lxa-iobus.html">LXA IOBus 4DO-3DI-3AI</a>,
oder 4DO',
ist unser erstes Gerät ohne "<em>Irgendwas-Irgendwas</em>-Mux" im Namen,
und das,
obwohl er als eine Art GPIO-Mux verwendet werden kann.</p>
<p>Der 4DO-3DI-3AI erweitert ein Remotelab um
vier digitale Ausgänge,
drei digitale Eingänge
und drei analoge Eingänge.
Die digitalen Ein- und Ausgänge sind galvanisch isoliert
und mittels Solid-State Relais implementiert,
was sie sehr flexibel einsetzbar macht.</p>
<p>Die analogen Eingänge sind nicht isoliert,
können aber genutzt werden,
um beispielsweise Versorgungsspannungen bis 12V zu messen.</p>
<p>Der Haupteinsatzzweck des 4DO' ist es,
automatisiert auf einem DUT Jumper-Verbindungen setzen und lösen zu können
und so beispielsweise Resets auszulösen
oder Bootmodi auszuwählen.
Außerdem können die Ausgänge genutzt werden,
um Tastendrücke zu simulieren,
indem Verbindungsleitungen direkt an die Beine eines Tasters gelötet werden.</p>
<p>Die Eingänge erlauben z. B. ein Feedback für automatische Tests,
die helfen können,
zwischen Erfolg und Misserfolg zu entscheiden.</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>Etwas über dreieinhalb Jahre sind seit unserer letzten Produktankündigung vergangen,
seitdem haben wir viele Normen gelesen,
Dinge über Webshops und den Alltag der Elektronikfertigung gelernt
und still und heimlich an neuen Produkten getüftelt.
Heute möchte ich das LXA IOBus-System vorstellen,
bestehend aus einem CAN-basierten Kommunikationsprotokoll,
einem zugehörigen Gateway-Server
und einer neuen Klasse an Linux Automation GmbH Produkten.
Zwei dieser neuen Produkte sind der Ethernet-Mux
und das 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>Eingebettete Systeme und IoT-Geräte robust und sicher im Feld updaten zu können
ist heute eine Kernanforderung jedes Produkts.
Das Update-Framework RAUC ist die Basis für eine moderne und zukunftsfähige
Lösung.
In diesem Showcase zeigen wir die Grundprinzipien eines ausfallsicheren
Update-Systems und wie Sie dieses mit Unterstützung von Pengutronix für Ihre
Plattform realisieren können.</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-Artefakte werden erstellt, kryptographisch signiert, und
over-the-air (OTA) ins Feld gebracht</p>
</figcaption>
</figure>
</div><p>Die grundlegenden Anforderungen an ein Update im Feld sind klar umrissen:
Das Update soll ausfallsicher eingespielt werden (<strong>reliability</strong>), das Gerät muss dabei
aber vor unbefugtem Zugriff geschützt bleiben (<strong>security</strong>).
Je nach Einsatzbereich stammt das Update von einem lokalen Medium (z.B.
USB-Stick) oder soll vollautomatisch über das Netzwerk ausgerollt werden
(<strong>deployment</strong>).</p>
<p>Neben diesen naheliegenden Anforderungen gibt es jedoch noch eine ganze
Palette weiterer Überlegungen und Entscheidungen, die in einer möglichst frühen
Projektphase getroffen werden sollten und wesentlich über Erfolg oder
Misserfolg des Projektes mit entscheiden.
Dazu später mehr…</p>
<div class="section" id="atomare-updates-und-fallback">
<h3>Atomare Updates (und Fallback)</h3>
<p>Das Zauberwort für ausfallsicheres Updaten von Systemen lautet <em>Atomizität</em>.
Das bedeutet: Es muss sicher gestellt sein, dass ein Update vollständig
erfolgreich eingespielt ist, bevor es zur Nutzung freigegeben wird.</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>Umschalten zwischen redunanten (A+B) Partitionen erlaubt atomares Updaten</p>
</figcaption>
</figure>
</div><p>Um das sicher zu stellen, verwendet man <em>redundate Boot-Partitionen</em> (auch
Dual-Copy- oder A+B-Ansatz genannt).
Dabei werden zwei vollkommen gleichwertige Systempartitionen benutzt, um
wechselseitig Updates durchzuführen.
Von der aktiven Partition wird in die Inaktive geschrieben und diese erst nach
erfolgreichem Abschluss des Schreibvorgangs als neue aktive Partition geschaltet.
Die Umschaltung zwischen den Partitionen erfolgt dabei im Boot-Loader.
Dies bietet auch einen Verfügbarkeitsvorteil: Das Update kann mit diesem Mechanismus
problemlos im Hintergrund der laufenden Anwendung durchgeführt werden ohne
diese zu unterbrechen.</p>
<p>Die Verwendung redundanter Partitionen erlaubt es dann optional, auch im Fehlerfall
des aktiven Systems auf das inaktive System zurück zu fallen und so die
Verfügbarkeit der Plattform deutlich zu verbessern.</p>
</div>
<div class="section" id="kryptographisch-gesicherte-updates">
<h3>Kryptographisch gesicherte Updates</h3>
<p>Da das Update-System den Austausch der Systemsoftware ermöglicht, handelt es
sich hier um einen besonders kritischen Bereich.
Um nicht-autorisierten Personen den Zugriff auf das System zu verweigern, muss
das Update bei der Erstellung kryptographisch signiert werden und vor der
Installation vom Zielsystem verifiziert werden.
Dafür eignen sich asymmetrische Methoden hervorragend, da hier nur die Schlüssel
zum Signieren geheim gehalten werden müssen, während der Schlüssel zum
Verifizieren ohne weiteren Aufwand auf dem Gerät abgelegt werden können.</p>
<p>Die Nutzung gängiger Standards wie <a class="reference external" href="https://de.wikipedia.org/wiki/X.509">X.509</a> erlaubt darüber hinaus prinzipiell
komplexere Hierarchien mit Entwicklungs-Schlüsseln, Pro-Geräte-Schlüsseln,
mehreren Signaturen, etc.</p>
</div>
<div class="section" id="weitere-anforderungen">
<h3>Weitere Anforderungen</h3>
<p>Der Teufel steckt oft im Detail, und so verhält es sich auch mit der
Entwicklung einer Update-Strategie.
Die technischen Vorgaben wie Prozessortyp, und Speichertechnologie müssen
ebenso berücksichtigt werden wie Anforderungen der Applikation und das Ökosystem in
dem das Gerät eingebunden ist.</p>
<p>Typische weitere Fragen, die sich dann ergeben sind</p>
<ul class="simple">
<li>Wie trennt man Daten und Logs vom Betriebssystem?</li>
<li>Wie migriere man Applikations-Daten nach einem Update?</li>
<li>Wie sieht eine sinnvolle Partitionierung des Speichers aus?</li>
<li>Ist es möglich den Bootloader sicher zu aktualisieren?</li>
<li>Wie soll sich das Gerät im Fehlerfall verhalten?</li>
<li>Wie erkennt das Gerät zuverlässig, dass ein Fehler vorliegt?</li>
</ul>
</div>
<div class="section" id="wie-konnen-wir-ihnen-helfen">
<h3>Wie können wir Ihnen helfen?</h3>
<p>Unser Integrations-Team beleuchtet mit Ihnen zusammen die offensichtlichen und
weniger offensichtlichen Fragen und Anforderungen an das Update-System und
entwickelt zunächst ein grundlegendes Update-Konzept, dass im weiteren
Projektverlauf nachgeschärft werden kann.</p>
<p>Mit <a class="reference external" href="https://rauc.io/">RAUC</a> gibt es bereits ein von Pengutronix gepflegtes und
vollkommen als Open-Source lizenziertes Update-Framework als Ausgangspunkt.
Dies erlaubt die Fokussierung auf das Wesentliche ohne das Rad neu erfinden zu
müssen.
Trotzdem ist die Abstimmung des Gesamtsystems auf die konkreten
Anforderungen des Kunden und der Einsatzumgebung alles andere als trivial und
umfasst die Konfiguration diverser Komponenten, die eng verzahnt ineinander
greifen müssen.</p>
<p>Auf Basis Ihres Board Support Packages (BSPs) implementiert unser Integrations-Team
ein redundantes Boot-Setup, konfiguriert alle notwendigen
System-Komponenten und bereitet alles so vor, dass Update-Artefakte erzeugen
und installieren können.</p>
<p>Benötigen Sie zusätzliche Funktionalität, die durch die existierenden
Komponenten nicht oder nicht vollständig abgedeckt ist, so erweitern wir diese
gerne für Sie. Das möglichst so, dass neue Features direkt in den
Hauptentwicklungszweig der Projekte zurück fließen können und sich nicht als
technische Schuld im Projekt anhäufen.</p>
<p>Im Rahmen der Klärung der Anforderung und dem konkreten individuellen
Aufsetzten der grundlegenden Update- und Boot-Loader-Konfiguration
unterstützt Sie Pengutronix unter anderem bei:</p>
<ul class="simple">
<li>Anpassen des Boot-Loaders für redundante Boot-Partitionen (barebox, U-Boot, Grub, UEFI)</li>
<li>Initiales Konfigurieren von RAUC im BSP (Yocto, PTXdist, Buildroot)</li>
<li>Abstimmen des Watchdog-Verhalten</li>
<li>Klärung von Security-/Verifizierungs-Verhalten</li>
<li>Klärung verwandter Themen wie Konfigurations-Management, Daten-Migration etc.</li>
<li>Integration in Kundenapplikation / Anbindung an Deployment-Infrastruktur</li>
<li>Rückfragen im weiteren Verlauf</li>
</ul>
<p>Die größten Fehler beim Design eines redundant bootenden Systems werden
übrigens oft bereits in der Frühphase des Projektes gemacht.
Gerne bewertet Pengutronix daher auf Basis von langjähriger Erfahrung für Sie
schon 'von Anfang an', ob die gewählte Hardware und insbesondere die verwendete
Speichertechnologie, das Power-Management oder der Prozessor, Risiken bergen.</p>
</div>
<div class="section" id="und-warum-rauc">
<h3>Und warum RAUC?</h3>
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Das 1.5.1-Release von RAUC <a class="reference external" href="http://rauc.io/pages/download.html">herunterladen</a></p>
</div>
</div>
<p>Mit RAUC steht ein modernes Open-Soure-Update-Framework bereit, dass durch
effiziente Nutzung etablierter Bibliotheken wie glib, OpenSSL und curl
eine schlanke und gut wartbare Codebasis bietet.
RAUC teilt sich dabei auf in einen Service, der auf der Zielplatform läuft und
dort die Update-Artefakte verifiziert und atomar installiert und einem Host-Tool mit
dem die Update-Artefakte (Bundles) erzeugt werden.</p>
<p>Mit der Reduzierung auf das Wesentliche und der Bereitstellung sowohl eines
Kommandozeilen-Tools als auch einer D-Bus-API lässt sich RAUC gut in bestehende
Kundenapplikationen integrieren.</p>
<p>Eine der wesentlichen Philosophien von RAUC ist die Beschreibung des
redundanten Boot-Verhaltens per Konfigurations-Datei direkt auf dem Gerät.
Dies lässt nicht nur eine Introspektierbarkeit des Systems zu, sondern erlaubt
auch generische Update-Artefakte zu erstellen.</p>
<p>Zusätzliche Features wie <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#pkcs-11-support">PKCS#11-Support</a> für das
Signieren von Bundles, Möglichkeiten der Neu-Signierung von Bundles oder das
Unterbringen von Intermediate-Zertifikaten in Bundles erlauben es, den
Sicherheitsanforderungen im professionellen Umfeld zu begegnen.</p>
<p>Für die im Feldeinsatz initial oft unterschätzten doch später oft dringend
notwendigen Updates des Boot-Loaders bietet RAUC für viele Anwendungsfälle die
Möglichkeit, diese ebenfalls vollkommen <a class="reference external" href="https://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader">atomar durchzuführen</a>.</p>
</div>
<div class="section" id="wie-lassen-sich-ota-updates-umsetzen">
<h3>Wie lassen sich OTA-Updates umsetzen?</h3>
<p>Wenn im Unternehmen bereist eine Deployment-Infrastruktur vorhanden ist
oder auf eine gehostete Lösung gesetzt werden soll, kann RAUC mit Hilfe eines einfachen
Dienstes, der Anfragen der Infrastruktur annimmt und RAUC über D-Bus oder
Kommandozeile aufruft, getriggert werden.</p>
<p>Für OTA-Update in eigener (self-hosted) Infrastruktur bietet sich das
Open-Source-Projekt <a class="reference external" href="https://www.eclipse.org/hawkbit/">hawkBit</a> an.
Dieses bietet eine umfangreich konfigurierbare Lösung für Geräteverwaltung,
Deployment-Scheduling und Feedback.</p>
<p>Die Anbindung an RAUC ist, dank existierender Clients im RAUC-Projekt, spielend
leicht umzusetzen.
Mit dem <a class="reference external" href="https://github.com/rauc/rauc-hawkbit-updater">rauc-hawkbit-updater</a>
steht hier eine solide in C geschriebene Client-Komponente zur Verfügung, die
mittels REST mit der Device (DDI) API von hawkBit und via D-Bus mit RAUC
interagiert.</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 interagiert mit hawkBit über den rauc-hawkbit-updater</p>
</figcaption>
</figure>
</div><div class="clearfix"></div></div></div><strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i> Zurück zur Messeseite
</a>
</strong></div>
</div>
<p>Eingebettete Systeme und IoT-Geräte robust und sicher im Feld updaten zu können
ist heute eine Kernanforderung jedes Produkts.
Das Update-Framework RAUC ist die Basis für eine moderne und zukunftsfähige
Lösung.
In diesem Showcase zeigen wir die Grundprinzipien eines ausfallsicheren
Update-Systems und wie Sie dieses mit Unterstützung von Pengutronix für Ihre
Plattform realisieren können.</p>2021-02-26T15:00:00+01:00tag:www.pengutronix.de,2021-02-26:/2021-02-26-showcase-i-mx8mp.htmlShowcase: Grafik auf i.MX8MP2021-02-26T13:56:37+01:00Lucas Stach<div class="section" id="showcase-grafik-auf-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>Die Inbetriebnahme der Grafikausgabepipeline auf dem <em>i.MX8M Plus</em> (kurz i.MX8MP)
ist ein aktuelles Beispiel dafür, wie Open Source und Upstream-Treiber für GPUs
und Displayeinheiten Aufwand und Risiko im Projekt reduzieren können.</p>
<div class="section" id="historischer-hintergrund-der-grafiktreiber">
<h3>Historischer Hintergrund der Grafiktreiber</h3>
<p>Die Grafik-Möglichkeiten auf eingebetteten Systemen haben sich über die letzten
Jahre stark verändert. Wir werfen zuerst einen Blick auf die Historie der
Grafikhardware und der zugehörigen Software.</p>
<p>Anfangs hatten eingebettete Systeme, wenn überhaupt, nur sehr eingeschränkte
Möglichkeiten der Grafikausgabe. Meist konnten sie nur simple LC-Displays
ansteuern und die gesamte Arbeit des Bildaufbaus musste von der CPU geleistet
werden, da es keinerlei Hardwarebeschleunigung gab. Einerseits war dies sehr
praktisch, da die CPU sehr flexibel ist und die Treiber
für die simplen Hardwareeinheiten zu schreiben keinen großen Aufwand bedeutete:
Treiber mussten nichts anderes tun als ein mit Bilddaten gefülltes Stückchen
Speicher mit dem richtigen Timing auf den Datenbus des Displays zu legen.
Andererseits setzte die begrenzte Rechenpower der CPU der Grafik sehr klare
Grenzen. Der eigentliche Zweck des Geräts darf nicht beeinträchtigt werden,
und der ist selten nur die Anzeige schöner Grafik.</p>
<p>Vor etwa 15 Jahren, als Moore's Gesetz noch in voller Geschwindigkeit in
Kraft war, wurde es schließlich möglich komplette Grafikbeschleuniger (GPUs)
in die passenden Größen-, Stromaufnahme- und Kostengrenzen der Welt der
eingebetteten Systeme zu schrumpfen. Da die GPUs nun die Hauptlast der
Generierung der Bilddaten für die Anzeige übernahmen, wurde es möglich viel
ansprechendere grafische Oberflächen zu bauen, während gleichzeitig auf der
CPU wieder Zeit für andere Aufgaben frei wurde.</p>
<p>Dies hatte allerdings auch seinen Preis: die Komplexität der Treibersoftware
für diese GPUs übersteigt die der bisherigen simplen CPU-Algorithmen bei
weitem. Außerdem herrscht im GPU-Geschäft ein starker Konkurrenzdruck, mehrere
Firmen versuchen hier GPUs für den Einsatz in eingebetteten Systemen zu
verkaufen. Dies führte dazu, dass die meisten Firmen in diesem Geschäft sich
entschlossen ihre Treibersoftware closed-source anzubieten. Das soll
vermeiden, dass versehentlich wesentliche Details ihrer Hardware, welche sie
von der Konkurrenz abheben sollen, nach außen dringen.</p>
</div>
<div class="section" id="probleme-mit-closed-source-treibern">
<h3>Probleme mit closed-source Treibern</h3>
<p>Eingebettete Systeme haben einige besondere Anforderungen, da sie meist für
einen sehr speziellen Anwendungsfall gebaut werden, den sie mit maximaler
Kosteneffizienz erfüllen müssen. Dadurch bleibt meist wenig Spielraum, um
Ineffizienz in der Verarbeitungspipeline der Geräte mit roher Rechenpower zu
kompensieren, d.h. die Software muss stark auf den Anwendungsfall hin
optimiert werden. Außerdem sind viele dieser Geräte für eine lange
Anwendungszeit im Feld ausgelegt. Da immer mehr dieser Geräte auch mit dem
Internet verbunden sind, ist ein einfaches Update der Software zur
Behebung von funktionalen oder sicherheitsrelevanten Problemen von
entscheidender Bedeutung.</p>
<p>Diese Anforderungen sind sehr schwer zu erfüllen, wenn sich closed-source
Komponenten im System befinden, über welche man keine Kontrolle hat. Auch
wenn der Hersteller der GPU in der Lage und willens ist notwendige
Änderungen an der Treibersoftware auszuführen, so kann dies doch eine sehr
lange Zeit in Anspruch nehmen. Dies kann dazu führen, dass das Gerät nicht
zum angepeilten Zeitpunkt im Markt platziert werden kann und dadurch die
Verkaufsaussichten reduziert werden. Auch kann diese Abhängigkeit zur Folge haben,
dass notwendige Updates an anderen Systemkomponenten (z.B. Linux-Kernel,
Basissystembibliotheken) deutlich erschwert werden, da
diese sich auf die closed-source Komponenten auswirken.</p>
</div>
<div class="section" id="welche-alternativen-gibt-es">
<h3>Welche Alternativen gibt es?</h3>
<p>Das <a href="https://www.pengutronix.de/de/services/open-source-multimedia.html">Pengutronix Grafikteam</a>
hat langjährige Erfahrung bei der Erstellung von Open-source-Treibern für
diese Hardwareeinheiten.</p>
<p>Für uns begann diese Geschichte, als einige unserer Kunden
das Risiko einer Closed-source-Komponente im Herzen ihres Produkts nicht dulden
wollten.
So begannen wir gemeinsam eine Open-Source-Alternative zu den bestehenden
Lösungen der GPU-Hersteller zu schaffen. Die i.MX-Produktlinie von NXP ist
in der Medizintechnik und in der Industrie sehr beliebt, da sie sehr viele der
dort geforderten Features abdecken kann. Beginnend mit dem i.MX6 integrieren
diese SoCs GPUs vom Hersteller VeriSilicon (ehemals Vivante). Einige
Freiwillige in der Free-Software-Bewegung hatten bereits begonnen diese GPUs
per Reverse-Engineering zu dokumentieren. Diese Bewegung ist unter dem Namen
<a href="https://www.github.com/etnaviv">Etnaviv</a> bekannt. Pengutronix
hat sich diesen Aktivitäten angeschlossen und dabei geholfen eine
hochqualitative Alternative zum Herstellertreiber zu entwickeln.</p>
<!-- FIXME: Picture of i.MX8M video demo. -->
<p>Inzwischen ist der Etnaviv-Treiber in einer ganzen Reihe von eingebetteten
Systemen zu finden. Von Medizingeräten, über In-flight-Entertainment-Systeme,
bis hin zu Bedieneinheiten in Industriemaschinen und Fahrzeugen. Alle Teile
des Etnaviv-Treibers sind als Open Source verfügbar, was jedem ermöglicht
diesen zu verbessern oder anzupassen. Das eliminiert das Risiko einer
Abhängigkeit von einem einzelnen Hersteller. Natürlich ist Pengutronix
als starker Partner mit sehr viel Erfahrung in diesem Bereich immer daran
interessiert Anwendern bei Anpassung und Fehlerbehebung behilflich zu sein.</p>
<p>Der Etnaviv-Treiber ist in die vorhandenen Frameworks, wie DRM im Linux-Kernel
und Mesa auf der Userspace-Seite, eingebunden. Damit ist der Treiber sehr nah
am generischen Linux-Desktop-Grafikstack, wodurch die damit ausgestatteten
eingebettete Systeme weniger speziell werden und sich meist sehr ähnlich
zu einem Desktop-Linux-System verhalten.</p>
</div>
<div class="section" id="i-mx8mp-gpu-inbetriebnahme-mit-upstream-treibern">
<h3>i.MX8MP GPU Inbetriebnahme mit upstream Treibern</h3>
<p>Vor kurzem erhielt das Pengutronix Grafikteam den Auftrag die GPU auf dem
<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-visio">NXP i.MX8M Plus</a>
, welcher sich aktuell im Vorserien-Stadium befindet, in Betrieb zu nehmen.
Dieses SoC ist sehr interessant für viele Industriegerätehersteller, da die
i.MX8M-Linie den technischen Nachfolger der sehr beliebten i.MX6 Linie
darstellt. Ein sehr großer Teil der Software für diese ältere Linie, welche
über die letzten 10 Jahre geschrieben und verbessert wurde, kann für den
i.MX8M wiederverwendet werden. Dadurch reduziert sich der Aufwand für die
Basisinbetriebnahme des Systems signifikant. Zudem bietet der
i.MX8MP einige sehr interessante Features wie <em>CAN FD</em> und <em>TSN Ethernet</em>.</p>
<p>Die GPU auf diesem SoC ist eine leicht abgewandelte Variante des GC7000L,
welche auf dem bereits schon unterstützten i.MX8MQ SoC zu finden ist.
Während einige <a href="https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255">kleine Anpassungen</a>
nötig waren um den Open-Source-Treiberstack auf dieser speziellen GPU in
Betrieb zu nehmen, belief sich der Aufwand unseres Grafikteams für
diese Anpassungen auf weniger als eine Woche. An dieser Stelle
zahlt sich die große Erfahrung des Teams in diesem Bereich aus.</p>
<p>Zögern Sie nicht uns anzusprechen, wenn Sie Unterstützung bei einem
neuen oder bestehenden Projekt mit Grafik Ein- oder Ausgabe benötigen!</p>
<!-- FIXME: picture/youtube video i.MX8MP -->
<strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Zurück zur Messeseite
</a>
</strong></div>
</div><p>Die Inbetriebnahme der Grafikausgabepipeline auf dem <em>i.MX8M Plus</em> (kurz i.MX8MP)
ist ein aktuelles Beispiel dafür, wie Open Source und Upstream-Treiber für GPUs
und Displayeinheiten Aufwand und Risiko im Projekt reduzieren können.</p>2021-02-26T13:56:37+01:00tag:www.pengutronix.de,2021-02-24:/2021-02-23-showcase-time-sensitive-network.htmlShowcase: Preempt RT und Time Sensitive Networking2021-02-24T11:30:00+01:00Holger Assmann<div class="section" id="showcase-preempt-rt-und-time-sensitive-networking">
<div class="ptx-sidebar">
<div class="title">
Schon J. R. R. Tolkien wusste...
<div class="corner"></div>
</div>
<div class="body">
<p>"Echtzeit ist nie zu spät, ebensowenig zu früh. Sie passiert genau
dann, wenn sie es beabsichtigt."</p>
</div>
</div>
<p>Heutzutage verfügen selbst einfache und günstige Mikrocontroller über
ausreichend Rechenleistung, um zeitkritische Aufgaben im industriellen
Umfeld zu bearbeiten. Sind jedoch die Aktoren und Sensoren in einer
größeren Anlage verteilt und sollen mittels Ethernet vernetzt werden,
ist der tatsächliche Verarbeitungszeitpunkt eines Ereignisses nicht ohne
weiteres vorhersehbar. Linux mit Preempt RT und ein Netzwerk mit <em>Time
Sensitive Networking</em> (TSN) Funktionalitäten kann hier Abhilfe schaffen.</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/pQvtk6vEdrY"></iframe>
</div>
<p>Verzögerungen bei der Übertragung der Daten können dabei sowohl
innerhalb der Systeme als auch auf dem Übertragungsweg entstehen, wenn
etwa kritische Daten von mehreren Quellen gleichzeitig übertragen
werden. Je mehr moderne eingebettete und vernetzte Systeme zu schnellen
Berechnungen und Datenverarbeitung in der Lage sind, desto mehr stellt
sich nicht nur die Frage, ob das System "<em>schnell genug</em>" arbeitet,
sondern ob die Ergebnisse auch "<em>rechtzeitig</em>" ankommen.</p>
<p>Der Einsatz von komplexen Netzwerk-Stacks auf Basis von 'Standard'-Ethernet ist
in vielen Fällen ein Grund für einen Wechsel von einem Mikrocontroller zu einem
Mikroprozessor samt vollwertigem
Linux-Betriebssystem. Die Echtzeiteigenschaften auf dem System stellt
dabei der Preempt RT Mechanismus im Linux-Kernel sicher, und auch für
die zeitkritische Datenübertragung wandern derzeit zunehmend mehr
TSN-Features in den Kernel.</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>Demonstrator mit schwebender Papierschlaufe</p>
</figcaption>
</figure>
</div><p>Das Thema TSN ist sehr heterogen und besteht aus einer Vielzahl von
einzelnen Technologien: Einerseits stehen noch nicht alle bereits
standardisierten Verfahren schon unter Linux zur Verfügung, andererseits
werden aber auch nicht alle Mechanismen für jede Anwendungen benötigt.</p>
<p>Um tiefergehende Einblicke in die technischen Detailfragen zu erlangen,
die sich während des Entwicklungsprozesses stellen, haben wir bei
Pengutronix einen TSN-Demonstrator entwickelt:</p>
<p>Die "Schwebende Kugel" ist ein beliebtes Experiment, bei dem das
Grundkonzept eines <a href="https://de.wikipedia.org/wiki/Regler#PID-Regler">PID-Regelkreises</a> demonstriert wird.
Zur Durchführung wird ein Magnet an einem leichten Objekt (z. B. einer
Papierschlaufe) befestigt. Dieses wird dann im Feld eines
Elektromagneten zum Schweben gebracht: Ein Sensor erfasst die Position
der Kugel und meldet sie an einen Regler, welcher wiederum den Strom
durch den Elektromagneten entsprechend auf einen konstanten Abstand zum
Sensor einstellt. Richtig umgesetzt schwebt die Kugel in einem
Gleichgewicht, solange der Aufbau mit Strom versorgt wird.</p>
<p>Zur Simulation eines mittels TSN Ethernet vernetzten Systems werden
Sensor, Aktor und Regler jeweils auf Einplatinencomputern auf Basis des
<a href="https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html">STM32MP1</a>
betrieben, auf denen ein aktueller Linux-Kernel (5.11) mit Preempt RT
läuft. Die Geräte sind mittels Ethernet verbunden, das <em>Precision Time
Protocol</em> (PTP) wird zur Synchronisation der Uhren der Teilnehmer
verwendet.</p>
<div class="section" id="ziele">
<h4>Ziele</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>Schematische Darstellung des Versuchsaufbaus</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 im Betrieb</p>
</figcaption>
</figure>
</div><p>Im Demonstrator-Aufbau treten verschiedene Latenzen im Regelprozess der
Position der Papierschlaufe auf:</p>
<ul class="simple">
<li>Die vom Sensor gesammelten Informationen müssen vom ersten System
verarbeitet werden.</li>
<li>Das Datenpaket muss dann seinen Weg durch das Netzwerk und zum Board
mit der Controller-Software finden.</li>
<li>Der Regler muss den nächsten Zustand des Elektromagneten berechnen und
dabei die Systemressourcen des Boards mit anderen Programmen und
Diensten teilen.</li>
<li>Die resultierenden Werte müssen wiederum über das Netzwerk gesendet
werden, um schließlich das System des Aktors zu erreichen und im
richtigen Moment angewandt zu werden.</li>
</ul>
<p>Um trotz auftretender Verzögerungen die Position der Kugel regeln zu
können, müssen die Aktionen der einzelnen Komponenten in Echtzeit
aufeinander abgestimmt werden.</p>
<p>Die PID-Regelschleife ist deshalb wie folgt realisiert:</p>
<ul class="simple">
<li>Durch den Einsatz von PTP (IEEE 802.1AS) werden die internen Uhren der
Systeme auf weniger als einer Mikrosekunde genau synchronisiert.</li>
<li>Latenz-Anomalien innerhalb der Software wurden analysiert und behoben.</li>
<li>Der Positionssensor wird synchron zum PTP-Timer ausgelesen und mit
Zeitstempeln versehen; die Daten benötigen dabei etwa 600 µs vom
Sensor bis zum Aktor.</li>
<li>Der PID-Regler läuft mit einer Frequenz von 1,25 kHz / 800 µs.</li>
<li>Schließlich muss die Software des Aktors dafür sorgen, dass der neue
Zustand des Elektromagneten zum richtigen Zeitpunkt angewendet wird.</li>
</ul>
<p>Das Ergebnis ist auf den Bildern zu sehen.</p>
</div>
<div class="section" id="nachste-schritte">
<h4>Nächste Schritte</h4>
<p>Der Demonstratoraufbau gibt einen ersten Einblick in die verschiedenen
Techniken rund um TSN unter Linux. Bei der Entwicklung wurden derzeit
aktuelle SoCs auf ihre TSN-Eigenschaften untersucht: Nicht alle
Mechanismen stehen dabei auf jeder Hardware zur Verfügung, sodass das
SoC passend zur jeweiligen Aufgabe ausgesucht werden muss. Auf der
Software-Seite gibt es ebenfalls noch Verbesserungsmöglichkeiten - viele
der eingesetzten Techniken sind noch jung und entwickeln sich von Kernel
zu Kernel schnell weiter. Es empfiehlt sich daher, eine aktuelle
Linux-Version einzusetzen.</p>
</div>
</div>
<div class="section" id="wie-kann-pengutronix-bei-tsn-projekten-helfen">
<h3>Wie kann Pengutronix bei TSN-Projekten helfen?</h3>
<div class="ptx-sidebar">
<div class="title">
Mehr zu TSN und PTP
<div class="corner"></div>
</div>
<div class="body">
<p>Die Kollegen bei OSADL führen fortlaufend Performance-Messungen zu RT- und
TSN-Anwendungen durch. Bei Interesse sei ihr Artikel
"<em>Real-time Ethernet (TSN) synchronization analysis</em>" empfohlen.
(<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>Das Pengutronix Kernel-Team kann Industriekunden bei der Entwicklung von
TSN-Systemen beraten und mit Entwicklungsdienstleistungen unterstützen.
Eine wichtige Aufgabe ist dabei die Weiterentwicklung und Anpassung des
Linux Kernels an die Anforderungen des Kundenprojekts, etwa durch neue
Treiber für Switch-Chips und für TSN-Features in Netzwerkhardware.</p>
<p>Zu Beginn eines Projekts stehen die Evaluierung geeigneter Hardware- und
Systemkomponenten im Mittelpunkt. In späteren Projektphasen können
kritische Bereiche des Systems durch Software-bedingte Latenzen
ausgebremst werden, die von unseren Kernel-Entwicklern lokalisiert und
behoben werden.</p>
<strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Zurück zur Messeseite
</a>
</strong></div>
</div>
<p>Heutzutage verfügen selbst einfache und günstige Mikrocontroller über
ausreichend Rechenleistung, um zeitkritische Aufgaben im industriellen
Umfeld zu bearbeiten. Sind jedoch die Aktoren und Sensoren in einer
größeren Anlage verteilt und sollen mittels Ethernet vernetzt werden,
ist der tatsächliche Verarbeitungszeitpunkt eines Ereignisses nicht ohne
weiteres vorhersehbar. Linux mit Preempt RT und ein Netzwerk mit <em>Time
Sensitive Networking</em> (TSN) Funktionalitäten kann hier Abhilfe schaffen.</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">
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/EvwyuVYZM-Q"></iframe>
</div>
<p>Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit
Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere
Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine
Flut von Prototypen auf den Schreibtischen unserer Entwickler.
Spätestens wenn im Team an einem Prototypen gearbeitet werden
soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird,
muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz
verkabelt werden.
Erschwerend kommt hinzu, dass die Entfernung zwischen unseren
Entwickler-Schreibtischen durch die aktuelle Homeoffice-Situation,
nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.</p>
<p>In diesem Artikel möchten wir Ihnen unsere, ursprünglich für
<em>Continous Testing</em> entwickelte, Remotelab-Infrastruktur vorstellen,
die uns Entwicklung an zentral aufgebauten Prototypen fast ohne Personal vor Ort
ermöglicht.</p>
<p>Unsere Remotelabs sind Racks, in denen wir unsere Embedded Boards betreiben und auf
die unsere Entwickler Remote-Steuerungsmöglichkeiten haben. Sobald der
Remote-Zugriff auf die Hardware gegeben ist, lässt sich dieser auch
automatisieren und ermöglicht so die Ausführung automatischer Tests.</p>
<div class="section" id="ein-paar-worte-zum-continuous-testing">
<h3>Ein paar Worte zum Continuous Testing</h3>
<p>Tatsächlich ist die Möglichkeit kontinuierlich und automatisiert
Tests durchführen zu können eine der Hauptantriebsfedern für unsere
stetige Weiterentwicklung von <a href="https://labgrid.org">labgrid</a>
(unserem Software-Framework zur Ansteuerung von Hardware-Komponenten)
und Professionalisierung der Remotelab-Infrastruktur.</p>
<p>Die Vorteile des Continuous Testing möchten wir Ihnen in unserem
<a href="https://www.pengutronix.de/de/blog/2021-02-21-showcase-continuous-testing.html">Showcase: Continuous Testing</a> näherbringen.</p>
</div>
<div class="section" id="wie-konnen-wir-ihnen-helfen">
<h3>Wie können wir Ihnen helfen?</h3>
<p>Die volle Kontrolle über Ihr Entwicklungs-Board zu haben, ohne es tatsächlich
vor Ort zu haben zu müssen, kann, nicht nur in Pandemie-Zeiten, ein
entscheidender Faktor für die Effektivität und Flexibilität der Entwicklung
und damit auch der Wettberwerbsfähigkeit sein.</p>
<p>Auch, wenn wir als Dienstleister im Software-Umfeld Ihnen zwar keine fertig aufgebaute
Remotelab-Infrastruktur verkaufen können, so möchten wir trotzdem unsere langjährige
Erfahrung mit Ihnen teilen und stehen Ihnen gerne bei der Beratung und
Einrichtung zur Seite:
Egal ob es darum geht, nur das Remote-Arbeiten zu ermöglichen, oder Ihre
Test-Hardware in labgrid abzubilden, Teststrategien auszuarbeiten und Tests zu
entwickeln, oder labgrid in ihre Prozesse zu integrieren: Sprechen Sie uns
gerne an!</p>
<p>Als Kunde profitieren Sie von unserer Remotelab-Infrastruktur natürlich auch
ohne den Schritt zum <em>eigenen</em> Remotelab. Sollten Sie uns eine (für die effiziente Entwicklung meist zwingend erforderlichen)
Prototypen-Hardware zur Verfügung stellen, integrieren wir diese in
unsere Remotelab-Infratstruktur. So steht ihre Hardware unserem
Entwicklerteam zu jedem Zeitpunkt im Produktzyklus mit wenigen
Tastendrücken zur Verfügung.</p>
<p>Mittlerweile haben wir diverse Remotelabs aufgebaut und eingerichtet.
Deshalb möchten wir im Folgenden unsere Komponentenauswahl vorstellen und
unsere Erfahrung mit Ihnen teilen.</p>
</div>
<div class="section" id="aus-welchen-komponenten-besteht-ein-remotelab">
<h3>Aus welchen Komponenten besteht ein Remotelab?</h3>
<div class="section" id="zoll-rack">
<h4>19-Zoll-Rack</h4>
<p>Die tragende Komponente unseres Remotelabs: Wir verwenden ein 19" TE
Netzwerkschrank von Rittal. Besonders praktisch ist dabei der Einsatz von
Transportrollen - so bleibt die Hardware von allen Seiten zugänglich.
Um die Prototypen zu schützen, wird jeder Einlegeboden mit einem ESD-Regalbelag
ausgelegt. Außerdem ermöglichen Kabelführungsschienen ein (zumindest anfangs)
aufgeräumtes Remotelab. Zwei passende Steckdosen für Rackmontage liefern den
nötigen Strom für die weiteren Infrastruktur-Komponenten.</p>
</div>
<div class="section" id="netzwerkswitch">
<h4>Netzwerkswitch</h4>
<p>Unsere Lieblinge in dieser Kategorie sind die CBS350-24P-4G von Cisco,
da sie PoE-fähig, leise und gemanagt sind.
Durch den Einsatz von PoE wollen wir den Bedarf an Einzel-Netzteilen in
zukünftigen Hardware-Eigenentwicklungen minimal halten.
Die Verwendung von Managed-Switches erlaubt es uns auf mögliche
spezielle Anforderungen der Kundenhardware an das Netzwerk-Setup zu reagieren.</p>
<p>Außerdem ist es für uns wichtig, dass die Switches im Betrieb leise sind,
da sich die Remotelabs mitunter in Entwicklerbüros befinden.</p>
</div>
<div class="section" id="kleiner-server">
<h4>Kleiner Server</h4>
<p>Zur Verwaltung der Geräte im Remotelab wird jeweils ein kleiner Server
benötigt. Die Hardware-Anforderungen für diesen labgrid-Knoten sind recht
gering. Wir achten bei der Auswahl auf folgende Aspekte:</p>
<ul class="simple">
<li><strong>Leiser Betrieb</strong> -- Unsere Remotelab-Server nutzen PC Engines APU.2E4
und sind somit komplett lüfterlos.</li>
<li><strong>Stabiles USB</strong> -- Große USB-Installationen, wie sie unsere Remotelabs sind,
bergen unserer Erfahrung nach viel Potenzial für Frustration. Die internen
USB-Controller der APU.2E4 und unsere zusätzlich verbauten EXSYS EX-49010-2
Controller haben sich im Betrieb als vergleichsweise zuverlässig gezeigt.</li>
<li><strong>CAN-Bus-Integration</strong> -- Zur Kommunikation mit unserer in-house entwickelten
Hardware versuchen wir, wenn es geht, auf USB zu verzichten und setzen stattdessen
auf CAN. Entsprechend verbauen wir CAN-FD-Fähige miniPCIe-Karten von Peak System,
die vier unabhängige CAN-Busse zur Verfügung stellen.</li>
</ul>
</div>
<div class="section" id="schaltbare-steckdose">
<h4>Schaltbare Steckdose</h4>
<p><em>Have you tried turning it off and on again?</em> --
Der einfachste Weg zum Hardware-Neustart ist das Anschalten der
Versorgungsspannung, beispielsweise über Netzwerk-Steckdosen, die
vollautomatisch durch labgrid angesteuert werden können. Als günstige
Alternative für kleinere Aufbauten sammeln wir auch erste Erfahrungen mit über
WLAN schaltbaren Einzel-Steckdosen. Für den Einsatz im Remotelab, wo viele
Geräte angesteuert werden sollen, verwenden wir GUDE 8080-Steckdosenleisten,
für einzelne Geräte experimentieren wir mit Steckdosen des Herstellers SONOFF,
die mit der freien Tasmota-Firmware bespielt werden.</p>
</div>
<div class="section" id="usb-hubs">
<h4>USB-Hubs</h4>
<p>USB ist in der Embedded-Entwicklung fast unumgänglich, wir nutzen es
zur Kommunikation mit der Hardware und zum Einspielen der Software.
Bei der Suche nach verlässlichen USB-Hubs gilt es es Produkte
von verschiedenen Herstellern auszuprobieren.
Wir haben gute Erfahrungen mit den 10-Port-Hubs UA0096 von LogiLink gemacht.</p>
<p>Ein interessanter Anwendungsfall, der durch diese Hubs leider nicht
abgedeckt wird, ist das ein- und abschalten der Versorgungsspannung
einzelner Ports mittels <a class="reference external" href="https://github.com/mvp/uhubctl">uhubctl</a>.</p>
</div>
<div class="section" id="wlan-router">
<h4>WLAN-Router</h4>
<p>Um Bluetooth und WLAN-Funktionalitäten der Embedded-Hardware testen zu können,
verfügt jedes Remote-Lab über einen eigenen WLAN-Router, der mit der freien
OpenWRT-Firmware bespielt ist.
Dieser Router ist weder mit dem Internet, noch mit einem anderen Netzwerk
verbunden und dient lediglich dem Test des Verbindungsaufbaus in
automatischen Tests.</p>
</div>
<div class="section" id="serielle-konsole">
<h4>Serielle Konsole</h4>
<p>Zur Anbindung der seriellen Konsolen der Embedded-Geräte nutzen wir
einfache USB-Seriell-Wandler, auf denen vorzugsweise ein CP210x-Chip von
Silicon Labs verbaut ist. Dieser Chip erlaubt es auf einfache Weise in
jedem USB-Seriell-Wandler eine eindeutige ID zu hinterlegen.
Wir beschriften jeden USB-Seriell-Wandler mit seiner programmierten
ID und behalten so auch mit über einem Dutzend Wandler pro Lab den Überblick.</p>
</div>
<div class="section" id="ferngesteuertes-setzen-von-jumper-pins">
<h4>Ferngesteuertes Setzen von Jumper-Pins</h4>
<p>Um möglichst flexibel Reset- oder Boot-Options-Jumper setzen und lösen
zu können, sind potenzialfreie Schalter hilfreich. Hier setzen wir auf
per OneWire oder CAN angebundene Eigenentwicklungen.
Alternativ bieten sich aber auch per USB gesteuerte Relais, oder
professionelle Modbus-basierte Geräte an.</p>
</div>
</div>
<div class="section" id="der-zugriff-aus-der-ferne-unsere-labgrid-integration">
<h3>Der Zugriff aus der Ferne: Unsere labgrid-Integration</h3>
<p>Um das Remotelab vollständig nutzen zu können, reicht die Hardware alleine
nicht aus. Für die Steuerung der Embedded-Boards vom Entwickler-PC und
als Grundlage für Tests und Entwicklung auf echter Hardware kommt bei
Pengutronix das Open-Source Werkzeug <a href="https://labgrid.org">labgrid</a>
als Abstraktionsschicht zum Einsatz.</p>
<p>labgrid stellt für automatisierte Tests genau so wie für die interaktive
Arbeit eine intuitive und zugleich vielseitige Schnittstelle zum Arbeiten
mit Embedded-Linux-Geräten zur Verfügung.</p>
<div class="ptx-sidebar">
<div class="title">
Mehr Informationen zu labgrid
<div class="corner"></div>
</div>
<div class="body">
<p>Unser Kollege Chris Fiege hat auf der FOSDEM 2021 den Talk
"<em>About the joy and tears of testing Embedded Devices</em>"
zu unserer bisher vierjährigen Erfahrung mit labgrid-Tests gehalten.</p>
<p>Schauen Sie gerne einmal vorbei, um einen Überblick über
die verschiedenen labgrid-Komponenten und -Arbeitsweisen zu bekommen.
(<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>Es gibt verschiedene Möglichkeiten, um über labgrid auf die laufenden
Geräte zuzugreifen, z.B.:</p>
<ul class="simple">
<li><strong>Serielle-Konsole</strong> -- Diese steht fast immer zur Verfügung, auch schon früh
im Bootprozess, ist aber weniger komfortabel als der …</li>
<li><strong>… Zugriff über Netzwerk und ssh</strong> -- Dieser ist Besonders im späteren
Entwicklungsprozess sehr komfortabel. Es können mehrere Verbindungen gleichzeitig
geöffnet und auch Dateien übertragen werden.</li>
<li><strong>Display ablesen über eine Webcam</strong> -- Eine klare Ausnahme, aber auch
durch labgrid unterstützt. Diese Variante ist besonders relevant während der
Treiberentwicklung und der Entwicklung grafischer Applikationen.</li>
</ul>
<div class="section" id="wie-kommt-die-software-auf-das-embedded-board">
<h4>Wie kommt die Software auf das Embedded-Board?</h4>
<p>Das ist von der Entsprechenden Hardware abhängig und davon, welche
Teile des Systems getestet werden sollen.</p>
<p>Eine Option ist das Laden der Systemdaten über das Netzwerk durch den Bootloader.
Eine Andere die Nutzung eines Programmier-Adapters des Prozessorherstellers oder
das Einspielen der Software über USB.</p>
<p>Hier bei Pengutronix nutzen wir, wenn möglich, allerdings den <a href="https://shop.linux-automation.com/usb_sd_mux-D02-R01-V02-C00-en">USB-SD-Mux</a>, der
eine Micro-SD-Karte zwischen dem Remotelab-Server und der Hardware
hin und her schalten kann.
Das ermöglicht einfaches Einspielen eines kompletten Firmware-Images samt
Bootloader.</p>
<strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Zurück zur Messeseite
</a>
</strong></div>
</div>
</div><p>Zur Projektarbeit mit unseren Kunden gehört die Arbeit mit
Prototypen-Hardware. Da wir grundsätzlich parallel für mehrere
Kunden an vielen verschieden Projekten arbeiten, bedeutet das eine
Flut von Prototypen auf den Schreibtischen unserer Entwickler.
Spätestens wenn im Team an einem Prototypen gearbeitet werden
soll oder längere Zeit nicht aktiv an einem Projekt gearbeitet wird,
muss die Hardware regelmäßig umgezogen und am neuen Arbeitsplatz
verkabelt werden.
Erschwerend kommt hinzu, dass die Entfernung zwischen unseren
Entwickler-Schreibtischen durch die aktuelle Homeoffice-Situation,
nicht wie gewohnt in Metern, sondern in Kilometern gemessen wird.</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>Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss
ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung
hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex.
Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an
einem versionskontrollierten <em>Board Support Package</em> (BSP) mit kontinuierlichen
Updates und Tests auf dem neuesten Mainline-Linux-Kernel.</p>
<p>Aber lassen Sie uns zuerst einen Blick auf die Komplexität und die
Kundenbedürfnisse werfen.</p>
<div class="section" id="es-war-einmal">
<h3>Es war einmal...</h3>
<p>Vielleicht haben Sie von folgendem Szenario gehört, vielleicht kennen Sie es
nur zu gut...</p>
<p>Der Zeitplan ist eng und es werden Abkürzungen genommen. Beim Update
kollidieren einige Komponenten miteinander, einige werden behoben und einige
bleiben unverbessert. Im besten Fall werden einige Sicherheitsprobleme
identifiziert und die Korrekturen zurückportiert. Eine andere Komponente wurde
vor langer Zeit geforkt, um ein damals neues Hardware-Feature zu unterstützen,
aber jetzt, Jahre später, kollidieren diese Änderungen mit dem aktuellen Stand
des Upstream-Projekts und erfordern viel Aufwand, um sie in Einklang zu
bringen. Der Großteil wurde durch das initiale Board Support Package des
Herstellers bereitgestellt, aber jetzt liegt das Interesse des Herstellers auf
zukünftigen Produkten und der Gewinnung neuer Kunden. Personalwechsel beim
Anbieter und im eigenen Unternehmen führen dazu, dass das Wissen über einige
der obskuren Wege verloren geht und die Fehlersuche immer mehr Zeit in Anspruch
nimmt.</p>
<div class="ptx-sidebar">
<div class="title">
Mehr Informationen zu Entwick-lungszyklen im Linux Kernel
<div class="corner"></div>
</div>
<div class="body">
<p>Unser Kollege Robert Schwebel hat auf dem ESE-Congress 2020 mit
"<em>Komplexe Systeme mit Mainline Linux beherrschen</em>"
einen Vortrag zum Thema gehalten.
(<a href="https://www.youtube.com/watch?v=Shi0-McBQ18">Youtube</a>)</p>
</div>
</div>
<p>Da der wichtigste Stakeholder nahezu abwesend ist, belasten alle Entscheidungen
der Vergangenheit diejenigen, die noch die derivative Software im Feld warten.
Während ihre Zahl den Hardware-Anbieter immer noch motiviert, Produktionsläufe
zu planen, wird die Wartungslast immer noch von jedem allein getragen, da
Probleme individuell identifiziert und gepatcht werden.</p>
<p>Als ob das nicht schon genug wäre, wird es bei einer ausreichend langen
Produktlebensdauer immer schwieriger, Ersatz für die Hardware-Komponenten zu
finden, was den Aufwand für die Software-Wartung noch erhöht.</p>
<p>Obwohl der Trend zu immer komplexerer Software und der Bedarf an Konnektivität
und Sicherheit dieses Problem verschärft, ist es keineswegs eine neue
Erkenntnis. Die Auswirkung von technischen Schulden ist bekannt, aber die
Folgen der Abwägung zwischen schnellem Prototyping und "richtigem" Tun werden
meist erst viel später spürbar.</p>
</div>
<div class="section" id="wie-konnen-wir-ihnen-helfen">
<h3>Wie können wir Ihnen helfen?</h3>
<p>Als Embedded-Linux-Dienstleister hat Pengutronix im Laufe der Jahre viel
Erfahrung darin gesammelt, Kunden bei der Restrukturierung technischer Schulden
zu helfen.</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>Wir wissen, dass ein langfristig wartbares Produkt bei den allerersten Ideen
und Entscheidungen beginnt. Wir wissen auch, dass die Entwicklung von Hardware
und Software Hand in Hand gehen muss. Deshalb möchten wir Ihnen so früh wie
möglich bei einem Projekt helfen, d.h. wir überprüfen Schaltpläne und beraten
Sie bei Komponentenentscheidungen.</p>
<p>Während die Hardware-Abteilung einen Prototyp entwickelt, muss auch die
Software-Architektur entworfen werden. Wir helfen Ihnen, auf Basis eines
aktuellen Yocto oder PTXdist Build-Systems, ein Board Support Package zu
erstellen, das genau auf Ihre Hardware zugeschnitten ist und Ihren
Bedürfnissen entspricht. Wir ergänzen fehlende Treiber und Softwarekomponenten
in einer testgetriebenen Entwicklung und stellen sicher, dass Ihr BSP
reproduzierbar, gut strukturiert und auf dem aktuellen Stand der Technik ist.</p>
<p>Sobald Ihr Produkt verkauft wird, helfen wir Ihnen, es durch
<a href="https://www.pengutronix.de/de/blog/2021-02-21-showcase-continuous-testing.html">kontinuierliche Tests</a> und <a href="https://www.pengutronix.de/de/blog/2021-02-19-showcase-field-updating.html">sichere
Updates</a> zu pflegen.</p>
</div>
<div class="section" id="machbarkeitsstudie-linux-automation-mc-1">
<h3>Machbarkeitsstudie: Linux-Automation MC-1</h3>
<p>Unser technischer Demonstrator ist für eine breite Palette von Anwendungsfällen
konzipiert: Es könnte ein Bedienfeld zur Überwachung Ihrer häuslichen
Infrastruktur sein (wie Ihre Solarpaneele oder Türklingeln). Es könnte ein
Informations- oder Unterhaltungssystem in Ihrem Fahrzeug sein oder alles
andere, was Sie sich vorstellen möchten.</p>
<p>Daher war Display-Unterstützung eine Voraussetzung, ebenso wie eine
Netzwerkverbindung, denn alle IoT-Geräte brauchen eine Netzwerkverbindung ;-)
Und wenn wir eine Netzwerkverbindung haben, können wir Power over Ethernet
nutzen, um das Gerät mit Strom zu versorgen.</p>
<p>Eine letzte Anforderung: Das Board soll klein genug sein, um in die Rückseite
des Displays zu passen.</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 mit einem OSD32MP1 in der Mitte
der Platine, unterhalb eines Displays.</p>
</figcaption>
</figure>
</div><p>In Zusammenarbeit mit unserem Schwesterunternehmen <a href="https://linux-automation.com">Linux Automation GmbH</a> und unseren Partnern <a href="https://octavosystems.com/">Octavo Systems</a> und <a href="https://www.bopla.de/">Bopla</a>
präsentieren wir einen Proof of Concept für die <em>Design for
Mainline</em>-Strategie.</p>
<p>Unser Embedded Board enthält nur handelsübliche Komponenten, die von
Mainline-Linux-Treibern gut unterstützt werden.</p>
<p>Daher betrug der anfängliche Aufwand für das Design der Schaltung für diesen
Prototyp nur etwa zwei Wochen und eine weitere Woche, um den gesamten
Software-Stack zu erstellen. Möglich wurde dies durch eine durchdachte Auswahl
der Komponenten, die wir Ihnen an dieser Stelle vorstellen wollen:</p>
<ul class="simple">
<li>Mögliche SoCs werden nicht nur nach ihrem Funktionsumfang, Preis und ihrer
Verfügbarkeit bewertet, sondern auch nach der Offenheit der Dokumentation
und dem vorhandenen Upstream-Support. Für diesen PoE-gespeisten
Display-Controller erfüllt der STM32MP1 alle Kriterien.</li>
<li>Der OSD32MP1x
macht es einfach, eine Brücke zwischen der IT und der physischen Welt zu
schlagen. Wenn man eMMC-Speicher hinzufügt, hat man bereits einen
vollwertigen Linux-Computer; auf einer Platine mit geringer Lagenzahl.</li>
<li>Upstream-Support in den Linux Kernel wurde für das Board durch die Projekte
ARM Trusted Firmware und Barebox Bootloader eingebracht. Es müssen keine
Software-Komponenten gepatcht werden, um ein Linux-System zum Laufen zu
bringen.</li>
<li>Ein BSP sammelt Konfigurationsparameter und endgültige Versionen
aller verwendeten Softwarekomponenten. Softwareversionen können auch nach
Jahren noch reproduziert werden.</li>
<li>Das BSP baut auf etablierten und von einer breiten Community geschützten
Build-Systemen wie Yocto oder PTXdist auf, wo viele Firmen und Enthusiasten <em>gemeinsam</em> an
der Aktualisierung der verschiedenen Komponenten
arbeiten und dabei die Kompatibilität aufrechterhalten.</li>
<li>Die von <a href="https://www.pengutronix.de/de/blog/2021-02-26-showcase-i-mx8mp.html">Etnaviv</a> betriebene Grafikpipeline, die von Pengutronix im
Linux-Kernel gepflegt wird, bietet dem Anwender eine vertraute Umgebung:
Grafik-Toolkits, ähnlich wie sie auf einem Standard-Linux-Desktop-PC
eingesetzt werden.</li>
<li>Neue Software wird kontinuierlich auf das Board aufgespielt und Testsuiten
laufen, um Regressionen während der Entwicklung abzufangen.</li>
<li>Um den Kernel-Entwicklern so früh wie möglich Rückmeldung über Regressionen
zu geben, kann das Board zusätzlich in die weltweite <a href="https://git.lavasoftware.org/lava/lava/-/merge_requests/1438">KernelCI-Infrastruktur</a> integriert,
die die Linux-Kernel-Maintainer informiert, wenn neue Patches zu Problemen
auf der jeweiligen Hardware führen.</li>
</ul>
<strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Zurück zur Messeseite
</a>
</strong></div>
</div><p>Ein Firmware-Upgrade ist fällig. Eine neu implementierte Funktion muss
ausgerollt, eine Sicherheitslücke gepatcht oder neue Hardware-Unterstützung
hinzugefügt werden. Die Software ist zwar leistungsfähig, aber komplex.
Pengutronix' Strategie, mit dieser Komplexität umzugehen, ist die Arbeit an
einem versionskontrollierten <em>Board Support Package</em> (BSP) mit kontinuierlichen
Updates und Tests auf dem neuesten 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">
<!-- Narrativ dieses Blogposts:
Die Linux Software-Welt verändert sich schnell. Aber
man muss schon funktionale- und sicherheitsupdates mitnehmen.
Wir bieten entwicklungsbegleitendes Testen und darauf aufbauend
Wartung an.
Damit stellen wir Qualität sicher und vereinfachen das Aktualisieren
von Systemen und geben mehr Vertrauen in diese Updates.
Zielgruppe:
Technische Entscheider, die Einfluss darauf nehmen können,
wie Projekte ausgestaltet werden.
Wie werden diese erreicht?
Es werden bekannte Probleme angesprochen und versucht dazu Lösungen
zu bieten.
Ein Praxisbeispiel soll den Showcase abrunden :-) -->
<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>Einblick in den Serverraum, von dem die Tests ausgeführt werden.</p>
</figcaption>
</figure>
</div><p>In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind
Bugfixes.
Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines
modernen Linux-Systems sind.
Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle
Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System
aktuell zu halten.
Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen
oder Inkompatibilitäten entstehen.</p>
<div class="section" id="wie-konnen-wir-ihnen-helfen">
<h3>Wie können wir Ihnen helfen?</h3>
<p>Durch den Einsatz von <em>Continuous Testing</em> (CT) auf echter Hardware
sind wir in der Lage, auftretende Probleme früh zu erkennen und zu beheben.
Unsere Entwicklungsprojekte bestehen im Wesentlichen aus zwei Phasen:</p>
<div class="section" id="initiale-produktentwicklung">
<h4>Initiale Produktentwicklung</h4>
<p>Viele Projekte beginnen mit einer initialen Entwicklungsphase:
In dieser unterstützen wir Sie bei der Inbetriebnahme Ihrer Hardware, sowie
dem Aufbau eines <em>Board Support Packages</em> (BSP), das genau auf Ihre Hardware
zugeschnitten ist.
In dieser Phase entwickeln wir zum Beispiel fehlende Treiber, ergänzen
Softwarekomponenten um fehlende Funktionen oder optimieren die Bootzeit
Ihres Geräts.
In dieser Phase werden Softwarekomponenten in der Regel ständig auf die neusten
Versionen aktualisiert.
Gleichzeitig bieten wir Ihnen aber auch an für Ihre Hardware und Ihr BSP
Tests zu entwickeln.
Diese überprüfen entwicklungsbegleitend die Kernfunktionen des Systems.
Diese Phase endet in der Regel mit dem Release Ihres Produkts.</p>
</div>
<div class="section" id="langfristige-wartung">
<h4>Langfristige Wartung</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>Darüber hinaus bieten wir Ihnen eine dauerhafte Wartung Ihres BSPs an:
Wir aktualisieren regelmäßig (z.B. mehrmals pro Jahr) Ihr System und
stellen mit den Tests sicher, dass die Funktionen weiterhin gegeben sind.</p>
<p>Durch die anschließende Wartung entstehen Ihnen wesentliche Vorteile:
Sollte es durch eine Softwarekomponente zu einem Fehler Ihres Produkts kommen,
oder eine Sicherheitslücke auftauchen, steht Ihnen ständig ein aktuelles System
zur Verfügung.
Hierdurch sind Ihnen kurze Release-Zyklen möglich.
Gleichzeitig sind die Änderungen von Update zu Update geringer, sodass die
tatsächlichen Aufwände für die Pflege geringer ausfallen.</p>
<p>Sprechen Sie uns hierzu gern an:
Wir erstellen mit Ihnen ein auf Ihre Anforderungen zugeschnittenes
Entwicklungs- und Wartungskonzept für Ihre Betriebssystemkomponenten.</p>
</div>
</div>
<div class="section" id="beispiel-aus-dem-alltag">
<h3>Beispiel aus dem Alltag</h3>
<p>Im folgenden Beispiel setzt ein Kunde für sein Produkt auf <em>Verified Boot</em>.
Dabei wird durch eine Kette von kryptographischen Operationen
sichergestellt, dass nur ein vom Hersteller signiertes Betriebssystem
auf einem Gerät ausgeführt werden kann.
Dabei überprüft die jeweils aktive Komponente (z.B. der Bootloader), ob die
nächste zu ladende Komponente (z.B. der Linux Kernel) eine gültige
Signatur besitzt.
Nur wenn dies der Fall ist, wird die jeweilige nächste Komponente auch ausgeführt.</p>
<div class="ptx-sidebar">
<div class="title">
Mehr Informationen zu Verified Boot
<div class="corner"></div>
</div>
<div class="body">
<p>Unser Kollege Marc Kleine-Budde hat auf der ELC Europe 2016 mit
"<em>Verified Boot: From ROM to Userspace</em>"
einen Vortrag zum Thema gehalten.
(<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>Die Verified-Boot-Kette, von der Konfiguration des ROM-Codes des Prozessors,
über den Bootloader, den Linux Kernel, bis hin zum Userspace werden bei diesem
Kunden durch uns ins BSP integriert und gewartet.</p>
<div class="section" id="testfall">
<h4>Testfall</h4>
<p>Die beschriebene Verifikation in dieser Kette wird durch eine Reihe von Tests
sichergestellt.
Dazu gehören u.a. die Verifikation des <em>FIT Images</em>, welches Linux-Kernel und
Device-Tree enthält, als auch der Test des <em>dm-verity</em> geschützten Dateisystems.
Hierzu wird das FIT Image subtil verändert und anschließend versucht das System
zu booten.
Ein weiterer Test verändert die Datei des init-Prozesses im dm-verity
geschützten Dateisystem.
Der Test erwartet, dass Lesen und Ausführen dieser Datei fehlschlägt und somit
Verified-Boot korrekt funktioniert.</p>
<p>Während dieses Tests werden als Seiteneffekt verschiedene Funktionen des Bootloaders
<a href="https://barebox.org">barebox</a> getestet: Es werden Images zwsichen
Partitionen kopiert, Dateisystem eingehangen/verändert und das Auslösen des
Watchdogs getestet.</p>
</div>
<div class="section" id="fehlerfall">
<h4>Fehlerfall</h4>
<p>Während eines Wartungs-Updates des BSP wurde nun der Bootloader aktualisiert und
der zuvor besprochene Testfall ist fehlgeschlagen.
Die gute Nachricht: Die Verified-Boot-Funktionen haben weiterhin funktioniert:
Das manipulierte System wurde nicht gebootet.</p>
<p>Aber: Der Test hat zwei Fehler in barebox aufgedeckt:
Der eine Fehler trat beim Kopieren auf <em>POSIX device-files</em> auf
(<a href="http://lists.infradead.org/pipermail/barebox/2020-August/033626.html">Fix von Sascha Hauer</a>).
Der andere Fehler betrifft den Watchdog
(<a href="http://lists.infradead.org/pipermail/barebox/2020-August/033645.html">Fix von Ahmad Fatoum</a>),
der das System nach dem provozierten Fehler in der Verified-Boot-Kette hätte
zurücksetzen sollen.</p>
<p>Beide Fehler wurden durch den Test aufgedeckt und die Fixes ins BSP integriert,
bevor der neue Softwarestand zum Kunden ausgeliefert wurde.</p>
<strong>
<a href="https://www.pengutronix.de/de/messe.html">
<i class="fas fa-arrow-left fa-1x"></i>
Zurück zur Messeseite
</a>
</strong></div>
</div>
</div>
<p>In den Linux-Kernel wandern jedes Jahr etwa 70.000 Patche, viele davon sind
Bugfixes.
Das Gleiche gilt für die meisten anderen Open-Source-Projekte, die Teil eines
modernen Linux-Systems sind.
Um von der Arbeit in der Community profitieren zu können, bleibt als sinnvolle
Strategie, ständig auf dem neusten Softwarestand aufzusetzen und das System
aktuell zu halten.
Natürlich können bei dieser Menge an Änderungen auch neue Fehler hinzukommen
oder Inkompatibilitäten entstehen.</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-LED-Weihnachtsbaum2020-12-08T15:52:53+01:00Holger AssmannLeonard GöhrsMarie Mann<div class="section" id="pengutronix-led-weihnachtsbaum">
<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 Bausatz</p>
</figcaption>
</figure>
</div><p>Draußen wird es kälter - und auch die Tage werden kürzer.
Um diese dunkle Zeit zum Jahresende etwas aufzuhellen, haben wir bei
Pengutronix uns deshalb den PTX-Christmas-Tree als kleines
Bastelprojekt ausgedacht.</p>
<p>Wenn Sie unseren Baum bei sich zu Hause nachbauen möchten, können Sie
<a href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/ptx-christmas-tree_laser.svg">hier eine Schablone</a> zum Aussägen
und <a href="https://www.pengutronix.de/media/blog/2020/2020-12-08_soldering-christmastree/ptx-christmas-tree.pdf">eine kurze Anleitung (en)</a> herunterladen.
Im Folgenden möchten wir Ihnen nun Schritt für Schritt und in viel zu vielen
Worten den Zusammenbau erläutern.</p>
<div><div class="clearfix"></div></div><p>Die Bastelanleitung zeigen wir in folgendem Video
(oder Sie lesen einfach weiter):</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="vorbereitungen">
<h3>Vorbereitungen</h3>
<p>Sie benötigen nach unserer Vorlage neben dem Baum noch folgende Komponenten:</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 Einzelteile</p>
</figcaption>
</figure>
</div><ul class="simple">
<li>2 bedrahtete Widerstände à 150 Ω</li>
<li>1 Halter für Knopfzellen CR2032, Kontakte zur Seite herausgeführt</li>
<li>1 Knopfzelle CR2032 zu 3 V</li>
</ul>
<p>An Werkzeug empfehlen wir:</p>
<ul class="simple">
<li>Lötkolben und Lötzinn</li>
<li>Seitenscheider</li>
<li>Pinzette</li>
<li>(doppelseitiges) Klebeband</li>
<li>Helfende Hände (aus bis zu einem weiteren Haushalt)</li>
</ul>
<p>Zur seelischen Unterstützung eignen sich Kakao und Plätzchen sehr gut;
zu Glühwein würden wir erst nach Vollendung des Baus raten.</p>
</div>
<div class="section" id="schritt-widerstande">
<h3>1. Schritt: Widerstände</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>Die Beine der Widerstande werden umgebogen.</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>Die Widerstände werden durch die vorgesehenen Löcher gesteckt.</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>Der PTX-Christmas-Tree wird umgedreht</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Die beiden Widerstände befreien wir zunächst von ihren Klebestreifen
durch einfaches Abziehen derselben. Danach müssen wir die metallenen
Beinchen so in Form bringen, dass sie gut durch die vorgesehenen
Löcher im Weihnachtsbaum passen. Als Hilfswerkzeug kann man hierfür
zum Beispiel einen Stift mit der Dicke des Lochabstands nehmen:
Dort die Widerstände quer auflegen und die Beine beidseitig
rechtwinklig abknicken. Die so präparierten Bauteile im Anschluss von
vorne durch den Baum stecken, dass sie entsprechend der Markierungen
zum liegen kommen.</p>
</div>
<div class="section" id="schritt-batteriehalter">
<h3>2. Schritt: Batteriehalter</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>Der Batteriehalter wird mittels doppelseitigem Klebeband befestigt.</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>Die Beine der Widerstände, die dem Batteriehalter am nächsten sind,
werden zu diesem hingebogen und festgelötet.</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>Die überstehenden Beine der Widerstände werden abgeschnitten</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Um einen Ankerpunkt für unsere Komponenten zu schaffen, platzieren wir
nun den Batteriehalter in der Nähe des "Baumstammes" und fixieren ihn
mit einem Streifen doppelseitigem Klebeband.</p>
<p>Als nächstes nehmen wir nun je das Bein der Widerstände, welches dem
Halter am nächsten gelegen ist, und biegen es in dessen Richtung.
Dabei muss der Widerstand, welcher näher an der "Baumkrone" liegt, mit
dem Minus- und der andere Widerstand mit dem Pluspol des Halters
verbunden werden.</p>
</div>
<div class="section" id="schritt-leds">
<h3>3. Schritt: 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>Der PTX-Christmas-Tree mit den LEDs in Ausrichtung der Polung.</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>Rückseite des PTX-Christmas-Trees mit durchgesteckten LEDs.</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>Die Beine der LEDs werden zu dem Widerstand bzw. Batteriehalter gebogen
und festgelötet.</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>Die überstehenden Beine der LEDs werden abgeschnitten.</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Mit den LEDs verfahren wir ähnlich wie mit den Widerständen. Hier
haben die Beinchen aber bereits den passenden Abstand, sodass wir sie
direkt durch ihre Löcher stecken können. Achten Sie dabei unbedingt
auf die Polarität der Bauteile: Das etwas längere Beinchen der LED
steht für die Anode (den Pluspol) und wird später direkt mit dem
Batteriehalter verbunden, während die kürzeren Kathoden (Minuspol) an
die Widerstände gelötet werden.</p>
<p>Für die richtige Kontaktierung führen wir deshalb zunächst die LED an
der Tannenspitze von vorne und mit dem längeren Beinchen links, die
andere LED mit dem längeren Beinchen unten durch die Löcher.</p>
<p>Für eine gute Lötverbindung richten wir jetzt die verbliebenen
Widerstandsbeine möglichst parallel zu den nächstgelegenen
LED-Beinchen aus und achten auf eine große Kontaktfläche.</p>
<p>Das andere Bein der näher am Batteriehalter sitzenden LED verbinden
wir nun noch mit dessen Pluspol und das letzte verbliebene Bein der
anderen LED mit dem durch die Mitte verlaufenden und bereits
befestigten Bein des einen Widerstands.</p>
<p>Nach der vollständigen Verlötung aller Beine und Kontakte müssen wir
nur noch die restlichen Überstände abschneiden und die Batterie gemäß
ihrer Polung in den Halter schieben.</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>Die Batterie wird in den Batteriehalter geschoben.</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>Leuchtender PTX-Christmas-Tree</p>
</figcaption>
</figure>
</div><div style="clear: both"></div><p>Unser resultierendes, kleines Kunstwerk eignet sich durch das
verbleibende Loch gut, um es in einem stimmigen Umfeld mit
aufzuhängen.</p>
</div>
</div>
<p>Draußen wird es kälter - und auch die Tage werden kürzer.
Um diese dunkle Zeit zum Jahresende etwas aufzuhellen, haben wir bei
Pengutronix uns deshalb den PTX-Christmas-Tree als kleines
Bastelprojekt ausgedacht.</p>2020-12-08T15:52:53+01:00tag:www.pengutronix.de,2020-11-19:/2020-11-19-pengutronix-at-lee.htmlPengutronix auf dem Live Embedded Event2020-11-19T11:05:47+01:00<div class="section" id="pengutronix-auf-dem-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>Jetzt, wo sich durch die COVID-19-Pandemie alle an die Digitalisierung
und Online-Konferenzen gewöhnt haben, war es noch nie so einfach, eine
Konferenz zu organisieren und alle Experten und Interessierten aus einem
Bereich für wenige Stunden des intensiven Ideenaustauschs zusammenzuholen.</p>
<p>Das haben sich auch einige französische Firmen aus der Embedded Branche
gedacht und das
<a href="https://liveembedded.virtualconference.com/#/event">Live Embedded Event</a>
ins Leben gerufen.</p>
<p>Das Live Embedded Event findet am Donnerstag, den 03. Dezember statt und
eine Teilnahme ist mit einer <a href="https://liveembedded.virtualconference.com/#/register">kostenfreien Registrierung</a> möglich.</p>
<p>Zu dem Event trägt unser Kollege Chris Fiege bei und erläutert die Vorteile der
Testautomatisierung.</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">Konferenz-Programm</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>Jetzt, wo sich durch die COVID-19-Pandemie alle an die Digitalisierung
und Online-Konferenzen gewöhnt haben, war es noch nie so einfach, eine
Konferenz zu organisieren und alle Experten und Interessierten aus einem
Bereich für wenige Stunden des intensiven Ideenaustauschs zusammenzuholen.</p>2020-11-19T11:05:47+01:00tag:www.pengutronix.de,2020-11-19:/2020-11-19-pengutronix-auf-dem-ese-kongress.htmlPengutronix auf dem ESE-Kongress2020-11-19T08:30:58+01:00<div class="section" id="pengutronix-auf-dem-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>Auch der <a href="https://www.ese-kongress.de">Embedded Software Engineering Kongress</a>
findet dieses Jahr online statt, und wir möchten die Chance nutzen, diesen als
Event-Partner zu unterstützen, mit Leuten ins Gespräch zu kommen und
gleichzeitig ein paar interessanten Vorträgen zu lauschen.</p>
<p>Die ganze Konferenz über werden ein paar unserer Entwickler aus verschiedenen
Bereichen im Chat der Event-Platform verfügbar sein.
Außerdem bieten wir auf der Pengutronix-Partner-Seite ein paar aktuelle
Informationen über unsere Dienstleistungen und unterstützte Open Source
Projekte.
Bleistifte können wir zwar nicht verteilen, aber unsere Pengutronix News #30.1
können als <a class="reference external" href="https://www.pengutronix.de/pengutronix-news-30.1.pdf">pdf</a> gerne im Vorbei-Schlendern
angeschaut und eingesteckt werden :-)</p>
<p>Bereits am 27.11. gibt es im Vorfeld des Kongresses die kostenfrei buchbare
<a href="https://express.converia.de/frontend/index.php?page_id=16101">ESE Pre-Conference</a>.
Bei dieser wird Robert Schwebel erklären, wie einfach es sein kann,
komplexe Embedded-Systeme mit Mainline-Linux zu beherrschen.</p>
<table border="1" class="docutils">
<colgroup>
<col width="6%"/>
<col width="94%"/>
</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">Konferenz Programm</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>Auch der <a href="https://www.ese-kongress.de">Embedded Software Engineering Kongress</a>
findet dieses Jahr online statt, und wir möchten die Chance nutzen, diesen als
Event-Partner zu unterstützen, mit Leuten ins Gespräch zu kommen und
gleichzeitig ein paar interessanten Vorträgen zu lauschen.</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/de/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 Partitionierung2020-10-15T14:52:10+01:00Jürgen BorleisJan Lübbe<div class="section" id="emmc-hardware-partitionierung">
<p>Wenn ein Embedded-System für eine lange Lebensdauer vorgesehen ist, ist es nötig,
sich mit der Applikation und der darunter liegenden Hardware auseinanderzusetzen -
damit beide zusammen eine hohe Langzeitstabilität erreichen.</p>
<p>Damit sind an dieser Stelle keine Software-Aktualisierungen gemeint, die
vorhandene Fehler in der Software beheben sollen. Hier geht es darum, das
notwendige Speichermedien ihrer Physik entsprechend so genutzt werden, dass eine
hohe Zuverlässigkeit und Lebensdauer des Gesamtsystems erreicht werden.</p>
<p>Die <em>Zuverlässigkeit</em> betrifft beispielsweise die dauerhafte Fähigkeit des Systems,
bis zu einem bestimmten Applikationszustand starten zu können.</p>
<p>Die <em>Lebensdauer</em> betrifft beispielsweise die Fähigkeit des Systems, das vorhandene
Speichermedium nicht zu schnell zu verschleißen.</p>
<p>Beide Anforderungen müssen sich nicht widersprechen. Je nach Applikation tun sie
aber genau das in der Realität - sehr oft auch unbemerkt.</p>
<div class="section" id="emmc-was">
<h3>eMMC…was?</h3>
<p>Zunächst verfügt eine <em>eMMC</em> intern über einen einzigen Speicher-Pool. Im Gegensatz
zu ihrer bekannteren Schwester, der <em>SD-Karte</em>, stellt eine <em>eMMC</em> diesen Gesamtspeicher
in mehreren sog. <em>Hardware-Partitionen</em> nach außen hin bereit.</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="2046x948" href="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/Übersicht-eMMC.png" itemprop="contentUrl">
<img alt="" itemprop="thumbnail" src="https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/Übersicht-eMMC.thumb.4923f504243f1f4d1778539a24309f82.png"/>
</a><figcaption itemprop="caption description" style="
width: 800px;
"><p>Übersicht Aufteilung des Gesamtspeichers in <em>Hardware-Partitionen</em></p>
</figcaption>
</figure>
</div><p>Die hier skizzierten <em>Hardware-Partitionen</em> sind in einem laufenden Linux-System
als voneinander unabhängige Geräte nutzbar. Den beiden <em>Boot</em>-Hardware-Partitionen
kommt eine besondere Bedeutung beim Starten des Systems zu. Auf ihren Inhalt
kann von der CPU aus mit einem vereinfachten Protokoll zugegriffen werden.
Das beschleunigt das Laden und Starten eines Bootladers. Sie sind bei manchen
<em>eMMC</em>-Geräten in der Kapazität konfigurierbar. Die <em>RPMB</em>-Hardware-Partition
(RPMB: <em>Replay Protected Memory Block</em>) wiederum dient gänzlich anderen Zwecken
und wird wie die <em>Boot</em>-Hardware-Partitionen in diesem Artikel nicht weiter
betrachtet. Nur die <em>User Data Area</em>-Hardware-Partition (<em>UDA</em>) wird in den meisten
Applikationen zur Laufzeit des System intensiv genutzt. Und genau aus dieser
intensiven Nutzung leiten sich Einschränkungen für die eingangs erwähnten
Anforderungen an das System ab.</p>
<p>Hinweis: Der Begriff <em>Hardware-Partition</em> hat zunächst nichts mit den
ansonsten bekannten Partitionen in einer Partitionstabelle (MBR oder GPT) zu tun, die
beispielsweise mit dem Kommando <tt class="docutils literal">fdisk</tt> angelegt und verwaltet werden.
Letztere können <strong>zusätzlich</strong> Anwendung finden.</p>
</div>
<div class="section" id="ein-typisches-szenario">
<h3>Ein typisches Szenario</h3>
<p>In einer Applikation wird eine <em>eMMC</em> eingesetzt, und die beiden Entwicklungsziele
<em>hohe Zuverlässigkeit beim Starten des Systems</em> und eine <em>hohe Lebensdauer beim Speichern
von Daten</em> sollen beide gleichermaßen gewährleistet sein.</p>
<p>Im laufenden System sind die von der <em>eMMC</em> bereitgestellten Hardware-Partitionen
wie folgt "sichtbar":</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>Wer schon einmal mit <em>eMMC</em> in seinem System gearbeitet hat, wird diese
<em>Device-Nodes</em> sicher kennen.</p>
</div>
<div class="section" id="ein-erster-ansatz">
<h3>Ein erster Ansatz</h3>
<p>Um die <em>Zuverlässigkeit</em> zu gewährleisten, startet das System den Bootlader aus
einer der genau für diesen speziellen Zweck vorgesehenen <em>Boot</em>-Hardware-Partitionen.
Danach wird ein Linux-basiertes System von der regulären
<em>UDA</em>-Hardware-Partition geladen und gestartet und dieses wiederum
nutzt einen Teil der <em>UDA</em>-Hardware-Partition als ihr Root-Dateisystem.</p>
<p>Um sicherzustellen, dass das System auch immer starten kann, wird nun die
<em>UDA</em>-Hardware-Partition noch weiter unterteilt und das eigentliche
Root-Dateisystem ausschließlich lesend verwendet.
Ein zweiter Bereich ist während der Laufzeit beschreibbar, so dass
beispielsweise Konfigurationen, Log-Dateien und sonstige Daten ständig und
dauerhaft gespeichert werden können. Diese Aufteilung erfolgt beispielsweise mit
dem Kommando <tt class="docutils literal">fdisk</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="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>Erster Ansatz durch Aufteilung der <em>UDA</em>-Hardware-Partition</p>
</figcaption>
</figure>
</div><p>Im laufenden System ist nun die von der <em>eMMC</em> bereitgestellte <em>UDA</em>-Hardware-Partition
wie folgt "sichtbar":</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 für das RootFS, nur lesend</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p2</tt></td>
<td>Partition zum Schreiben von Daten</td>
</tr>
</tbody>
</table>
<p>Diese Ansatz klingt durchaus plausibel und kann aber während der Lebensdauer des
Systems trotzdem dazu führen, dass das Gerät unbrauchbar wird, da es nicht
mehr aus dem RootFS starten kann. Die Ursache liegt darin, dass das darunter
liegende Speichermedium von dieser Aufteilung in einen Lese-Bereich und
einen Schreib-Bereich nichts weiß. Es behandelt die gesamte
<em>UDA</em>-Hardware-Partition als einen Bereich. Da wir hier über eine <em>eMMC</em> sprechen
und in dieser Flash-Speicher zum Einsatz kommt, kommen Techniken zum Nivellieren
des Verschleiß' dieser Art Speichertechnologie zum Einsatz ("wear leveling").</p>
<p>Unter Verschleiß werden viele physikalische Effekte zusammengefasst, die durch
wiederholtes Beschreiben der Flash-Blöcke entstehen.
Obwohl die genauen Ursachen und Auswirkungen recht komplex sind, reicht uns hier
eine starke Vereinfachung: Nach jedem weiteren Schreib-Zyklus verlieren die einzelnen
Speicherzellen ihre elektrische Ladung schneller und können irgendwann gar nicht
mehr beschrieben werden.
Je nach eingesetzter NAND-Technologie werden hunderttausende (SLC) oder nur
wenige tausend (TLC/QLC) Zyklen erreicht.
Neben dem "wear leveling" werden weitere Techniken eingesetzt, um mit diesen
Effekten umzugehen. Dazu gehören: Fehlerkorrektur-Codes (ECC), regelmäßige
Korrekturen im Hintergrund ("scrubbing") und ein Vorrat an Reserve-Blöcken.</p>
<p>Für diese Nivellierung wird üblicherweise der gesamte
Speicherbereich genutzt, da so insgesamt die höchste Zahl an Schreibzyklen erreicht wird.
Der eigentlich als Lese-Bereich gedachte Teil für das
Root-Dateisystems wird so mit der Zeit auf bereits stärker genutzte Blöcke
verschoben, im folgenden Bild angedeutet über die umlaufenden Pfeile.</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>Verschleiß-Nivellierung über den verfügbaren Speicher hinweg</p>
</figcaption>
</figure>
</div><p>Somit können sich Effekte, die durch das Schreiben von Daten auf die schreibbare
Partition ausgelöst werden, auch auf die nur-lese-Partition des Root-Dateisystems
auswirken.
Beispielsweise kann ein System, das vergleichsweise viel geschrieben hat,
wenn es für einige Monate ausgeschaltet bleibt, Fehler durch den beschleunigten
Ladungsverlust nicht mehr rechtzeitig erkennen und korrigieren.
Somit sind weder die gewünschte Lebensdauer noch die Zuverlässigkeit
für das Root-Dateisystem gesichert.</p>
</div>
<div class="section" id="besserer-ansatz-mittels-emmc-partitionierung">
<h3>Besserer Ansatz mittels eMMC-Partitionierung</h3>
<p><em>eMMCs</em> bieten neben den separaten Boot-Partitionen weitere Hardware-Partitionen
an. Diese sind bei Auslieferung der <em>eMMC</em> immer deaktiviert und müssen in einem
manuellen Schritt zunächst konfiguriert werden. Zu beachten ist an dieser Stelle,
dass sich diese Konfiguration der <em>eMMC</em> nicht mehr rückgängig machen lässt. Es sei
also angeraten, diese Art der Konfiguration vorher sorgfältig zu planen. Auch
kann sich dabei die Gesamtkapazität der <em>eMMC</em> reduzieren. Dazu später mehr.</p>
<p>Ziel dieser <em>eMMC</em>-Konfigurationsüberlegungen ist es also, der <em>eMMC</em> "mitzuteilen",
wie man sie gedenkt zu nutzen.</p>
<p>Um den verfügbaren Speicherbereich aufzuteilen, bietet eine <em>eMMC</em> mehrere
Varianten an:</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" oder "non-persistent")</li>
</ul>
</li>
</ul>
<p>Dabei ist zu beachten, dass der <a class="reference external" href="http://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf">Standard</a> nicht
definiert, was die Attribute genau bedeuten.
Für <em>enhanced</em> wird als Beispiel eine bessere Zuverlässigkeit genannt.
Darüber hinaus heißt es "The definition of enhanced storage media should be
decided upon by each system manufacturer, and is outside the scope of this
standard."
In der Praxis bedeutet <em>enhanced</em> oft, dass ein SLC-Modus verwendet wird.
Letztendlich kommt es jedoch auf den jeweiligen Hersteller der eMMC an, so
dass es sich lohnt, die entsprechenden Dokumente zu studieren.</p>
<div class="section" id="enhanced-user-data-area">
<h4>Enhanced User Data Area</h4>
<p>Die <em>EUDA</em> führt zu einer internen Änderung des <em>eMMC</em>-Verhaltens im Bereich der
<em>UDA</em>. Nach außen hin verhält sich die <em>eMMC</em> weiterhin gleich (bis auf die
ggf. reduzierte Kapazität).</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>Definieren eines EUDA-Bereichs</p>
</figcaption>
</figure>
</div><p>Nun sind die beiden Bereiche nicht nur aus applikativer Sicht getrennt, sondern
auch die <em>eMMC</em> <strong>weiß</strong> um diese Trennung und behandelt sie entsprechend
unterschiedlich. Zu beachten ist bei dieser Konfiguration, dass nun mittels
einer regulären Partitionierung auch aus applikativer Sicht die Partition mit
dem schreibbaren Dateisystem hinter der <em>EUDA</em> beginnt. Hier
gilt es also bei Anwendung von beispielsweise <tt class="docutils literal">fdisk</tt> die Partitionsgrößen
sorgfältig auf die Hardware-Größen einzustellen.</p>
<p>Wie zuvor angedeutet, ändert sich bei dieser Konfiguration nichts an den nach
außen sichtbaren Partitionen:</p>
<table border="1" class="docutils">
<colgroup>
<col width="30%"/>
<col width="70%"/>
</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 für das RootFS, nur lesend (auf der EUDA)</td>
</tr>
<tr><td><tt class="docutils literal">/dev/mmcblk0p2</tt></td>
<td>Partition zum Schreiben von Daten</td>
</tr>
</tbody>
</table>
<p>Ob das wear leveling wie im Bild angedeutet tatsächlich UDA und EUDA getrennt
verwaltet, lässt sich nur mit der passenden Dokumentation für das eMMC-Modell
beantworten.</p>
</div>
<div class="section" id="general-purpose-partitions">
<h4>General Purpose Partitions</h4>
<p>Das Konfigurieren einer <em>General Purpose Partition</em> führt im Gegensatz zu einer
<em>Enhanced User Data Area</em> zu einer Abtrennung eines Speicherbereichs und deshalb
nach außen hin zu einem weiteren Gerät.
Beim Anlegen der GPP kann wiederum zwischen den <em>default</em> oder <em>enhanced</em>
Speichermodi gewählt werden.
Dabei muss die Bedeutung von <em>enhanced</em> für UDA und GPPs nicht identisch sein.</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>Definieren einer <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>An dieser Stelle braucht es Unterstützung auf der Software-Seite, um
die separate <em>GPP</em> nutzen zu können. Die Bootlader Barebox und U-Boot sowie der
Linux-Kernel verfügen über diese Unterstützung.</p>
<p>Aus Linux-Sicht ist die <em>GPP</em> als <tt class="docutils literal">/dev/mmcblk0gpp0</tt> nun ein eigenständiges
Gerät und auch innerhalb der <em>eMMC</em> unabhängig von der <em>UDA</em> (weiterhin
verfügbar als <tt class="docutils literal">/dev/mmcblk0</tt>).
In der Nutzung gibt es aber keinen Unterschied. Auch die <em>GPP</em> kann nun partitioniert
und formatiert werden. Am Ende entsteht zur Laufzeit dieser Zusammenhang:</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 für das Lese-Root-Dateisystem</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 für das Schreib-Dateisystem</td>
</tr>
</tbody>
</table>
<p>Neben dem Konfigurieren des Speichers unterstützen eMMCs noch weitere Optionen,
um die zukünftige Nutzung jedes Speicherbereichs zu definieren. Damit kann die
eMMC die intern verfügbaren Strategien zur Daten- und Speicherbehandlung genauer
an die erwartete Nutzung anpassen.</p>
<p>Dazu in einem späteren Artikel mehr.</p>
</div>
</div>
</div>
<p>Wenn ein Embedded-System für eine lange Lebensdauer vorgesehen ist, ist es nötig,
sich mit der Applikation und der darunter liegenden Hardware auseinanderzusetzen -
damit beide zusammen eine hohe Langzeitstabilität erreichen.</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 auf der Embedded Linux Conference Europe2020-09-07T16:46:04+01:00Chris Fiege<div class="section" id="pengutronix-auf-der-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>Das <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/program/schedule/">Programm</a>
der diesjährigen Embedded Linux Conference Europe (ELCE) wurde in den
letzten Tagen veröffentlicht.
Wie auch in den letzten Jahren beteiligt sich Pengutronix auch dieses Mal
mit Vorträgen zu aktuellen Themen.</p>
<p>Die ELCE findet in diesem Jahr nicht, wie letztes Jahr angekündigt, in Dublin
statt, sondern wird als virtuelle Konferenz veranstaltet.
Dies macht es besonders Einsteigern in die Embedded-Linux-Welt einfach, einen
Blick in diese Konferenz zu werfen.
Die <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/register/">Registrierung</a>
ist noch möglich.</p>
<p>Die folgenden Talks von Pengutronix haben es in das Programm geschafft:</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>Montag, 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 zum Programm</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>In diesem Talk stellt Ahmad den <a href="https://barebox.org/">barebox</a> Bootloader als Schweizer Taschenmesser für die
Inbetriebnahme, Entwicklung und den Betrieb von Embedded-Geräten mit Linux vor.</p>
<p>Barebox wurde ursprünglich als stärker strukturierter Fork von U-Boot gestartet,
der ein an den Linux-Kernel angelehntes Treiber-Modell bot.
Ahmad geht in seinem Talk auf grundlegende Design-Entscheidungen wie die
POSIX/Linux API, virtuelle Dateisysteme, Unterstützung zuverlässiger Updates
sowie weitere Features von Barebox ein.</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>Montag, 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 zum Programm</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>In diesem Talk möchte Michael beim Thema Bootzeit-Optimierung einen Schritt
zurücktreten und den Blick auf das große Ganze richten.
Das Thema soll explizit nicht sein, einen weiteren Talk über
eine Detailoptimierung zu halten, die in der realen Welt doch nur selten so
eingesetzt werden kann.</p>
<p>Stattdessen wird sich dieser Talk dem Thema mit typischen Anforderungen nähern
und dabei auch Eigenschaften wie Sicherheit und Zuverlässigkeit nicht aus den
Augen verlieren. Hierbei stellt Michael die möglichen Abwägungen zwischen diesen
Eigenschaften vor. Zuletzt wirft Michael noch einen Blick auf
bootzeit-relevante Anforderungen an das Hardwaredesign.</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>Dienstag, 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 zum Programm</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 für i.MX6 SoCs ist bereit für den produktiven Einsatz! Damit steht nun
eine offene TrustZone-Implementierung für eine große Bandbreite von Geräten zur Verfügung.
Rouven zeigt in seinem Talk auf, wie OP-TEE auf i.MX6 genutzt werden kann, um
die Sicherheit zu verbessern, und gibt gleichzeitig einen Überblick über die neuen Features.</p>
<p>Rouven stellt hierzu zwei unterschiedliche Trusted Applications vor, die
sicher Daten speichern oder TPM-Funktionalität zur Verfügung stellen können.</p>
</div>
<div class="section" id="the-state-of-ptxdist-roland-hieber">
<h3>The State of PTXdist (Roland Hieber)</h3>
<p>Mittwoch, 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 zum Programm</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> ist seit über 16 Jahren ein Build-System für eingebettete Linux-Systeme.
Mit den monatlichen Releases werden nicht nur Wartungsaufgaben durchgeführt,
sondern auch regelmäßig neue Funktionen aufgenommen.
Hierzu zählen zum Beispiel die Unterstützung für Kconfig-Deltas, BSP-Layer,
Infrastruktur für das kryptographische Signieren von Images, sowie
reproduzierbare Build-Artefakte.</p>
<p>Roland stellt in seinem Talk die grundsätzlichen Konzepte hinter PTXdist sowie
die aktuellen Funktionen vor und richtet sich dabei gleichermaßen an neue und
erfahrene Nutzer.</p>
</div>
</div>
<p>Das <a href="https://events.linuxfoundation.org/embedded-linux-conference-europe/program/schedule/">Programm</a>
der diesjährigen Embedded Linux Conference Europe (ELCE) wurde in den
letzten Tagen veröffentlicht.
Wie auch in den letzten Jahren beteiligt sich Pengutronix auch dieses Mal
mit Vorträgen zu aktuellen Themen.</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 – Vorstellung unserer Remote-Infrastruktur2020-03-30T00:00:00+01:00Enrico JörnsMarie Mann<div class="section" id="flattenthecurve-vorstellung-unserer-remote-infrastruktur">
<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>Auch Tux hilft, die Kurve abzuflachen</p>
</figcaption>
</figure>
</div><p>Die Corona-Krise hat uns alle, sowohl als Privatpersonen als auch als Firmen,
plötzlich ziemlich hart getroffen und stellt unsere gesamte Gesellschaft vor
neue Herausforderungen.
Wir als Pengutronix möchten uns bei denjenigen bedanken, die in
systemkritischen Berufen arbeiten und unsere alltägliche Versorgung
sicherstellen.</p>
<p>Aber es wird auch eine Zeit nach der Krise geben, und unsere Gesellschaft wie
auch die Wirtschaft werden sich erholen – somit ist es für uns keine Option,
einfach unsere Arbeit niederzulegen.
Selbstverständlich möchten wir dabei verantwortungsbewusst handeln und den
größtmöglichen Schutz für unsere Kollegen und Angehörigen gewährleisten.</p>
<p>Daher haben wir vor zwei Wochen kurzerhand fast alle Mitarbeiter ins Homeoffice
geschickt, um die Ansteckungsgefahr innerhalb der Firmenräume so gering wie nur
möglich zu halten.</p>
<p>Obwohl wir einige wenige Kollegen haben, die auch in Nicht-Krisenzeiten
vollzeit <em>remote</em> arbeiten, befindet sich der Großteil der Kollegen
normalerweise in unserem Büro in Hildesheim.
Dort trifft man sich gerne an der zentralen Kaffeetheke, um über technische
Probleme zu diskutieren, Ideen auszutauschen oder auch mal, um einfach locker
zu quatschen.
Daher ist es für die meisten von uns ebenfalls eine ungewohnt neue Situation,
isoliert und von zu Hause aus zu arbeiten.</p>
<p>Wegen der grundlegend vorhandenen Strukturen war es uns möglich, unsere
Infrastruktur in kurzer Zeit so zu erweitern, dass alle Kollegen innerhalb
eines Tages (inklusive Bildschirme tragen) wieder arbeitsfähig waren und mit
ihren eigentlichen Aufgaben fortfahren konnten.</p>
<p>Aus Gründen, die irgendwo zwischen Bequemlichkeit von Entwicklern und der
überlegenen Effizienz eines vollautomatisierten Setups liegen, haben wir über
die Jahre viele Aufgaben im Bereich der Embedded-Entwicklung automatisiert oder
schon mit einem softwareseitigen Zugriff ausgestattet.
Aber auch bei uns gibt es einige Tätigkeiten, die vor Ort erledigt werden
müssen (wie Pakete annehmen oder Kabel an einigen Boards umstecken), sodass
täglich ein Kollege in unserem Büro die Stellung hält.</p>
<p>Obwohl die meisten unserer Arbeitsabläufe bereits an die Remote-Arbeit
angepasst waren, mussten wir sie doch hier und da erweitern, um den
zusätzlichen Herausforderungen zu begegnen, die sich ergeben, wenn plötzlich
<em>alle</em> Kollegen aus der Ferne arbeiten.</p>
<p>Wir möchten an dieser Stelle gerne unsere Erfahrungen teilen, die uns helfen
den Mitarbeitern trotz physikalischer Distanz ein produtkives und
sozial kommunikatives Arbeiten zu bieten.</p>
<div class="section" id="remote-arbeit-auf-softwareebene">
<h3>Remote-Arbeit auf Softwareebene</h3>
<p>Um unsere tägliche Arbeit zu ermöglichen, haben wir eine größere Serverfarm,
auf der wir unsere Infrastruktur aufsetzen und via SSH zugreifen können.
Sämtliche unserer Projekte (Quellcode wie auch
das dazugehörige Projektmanagement) verwalten wir in Git-Repositories, was
uns nebenbei eine hervorragende Nachverfolgbarkeit von Änderungen ermöglicht.</p>
<div class="ptx-sidebar">
<div class="title">
Vortrags-Empfehlungen
<div class="corner"></div>
</div>
<div class="body">
<ul class="simple">
<li><a class="reference external" href="https://chemnitzer.linux-tage.de/2018/de/programm/beitrag/328">OpenSSH für Anfänger und Fortgeschrittene [de]</a></li>
<li><a class="reference external" href="https://media.ccc.de/v/gpn19-126-plain-text-die-unertrgliche-leichtigkeit-des-seins">Plain Text: Die unerträgliche Leichtigkeit des Seins [de]</a></li>
<li><a class="reference external" href="https://media.ccc.de/v/froscon2019-2332-managementwerkzeuge_aus_der_open-source-entwicklung">Managementwerkzeuge aus der Open-Source-Entwicklung [de]</a></li>
</ul>
</div>
</div>
<p>Das Kompilieren von Code und das Bauen der Board Support Packages ist natürlich
ziemlich ressourcenhungrig und braucht eine Menge Rechenleistung, die wir über
einen <a href="https://www.pengutronix.de/de/blog/2018-09-13-fixing_icecc.html">ICECC
Compiling-Cluster</a> und den besagten SSH-Zugriff bereitstellen können.</p>
<p>Gerade weil wir diese Infrastruktur schon seit Jahren nutzen, pflegen und
weiterentwickeln, konnten unsere Kollegen schnell zu Hause ihre Rechner starten
und einfach (fast) wie gewohnt weiterarbeiten.</p>
</div>
<div class="section" id="remote-conversation">
<h3>Remote Conversation</h3>
<div class="section" id="internet-relay-chat-irc-und-e-mail">
<h4>Internet Relay Chat (IRC) und E-Mail</h4>
<p>Nach wie vor sind IRC und E-Mail unsere beliebtesten und wichtigsten
asynchronen Kommunikationswerkszeuge.</p>
<p>In Zeiten, in denen (gefühlt) jede Woche eine neue Messaging-App erscheint, die
noch bessere Kommunikationsmöglichkeiten verspricht, mag IRC ein wenig
angestaubt erscheinen.
Für unsere Entwickler gehört der IRC aber allein deswegen schon zum Tagesgeschäft,
weil er in vielen Open-Source-Projekten oft die bevorzugte Variante ist, um
miteinander im Chat zu diskutieren.</p>
<p>Außerdem lässt sich der Dienst einfach auf eigener Infrastruktur betreiben und
mit diversen simplen Clients nutzen, sodass unsere Mitarbeiter nicht gezwungen sind,
(private) Smartphones für wichtige Kommunikation zu nutzen. Außerdem hat IRC
den großen Vorteil, dass man nicht durch eine Flut von Bildern und Videos, die
einen nicht wirklich interessieren, aus der Arbeit gerissen wird. ;-)</p>
<p>Unsere übliche projektbezogene Kommunikation läuft nach wie vor über
Mailinglisten.</p>
</div>
<div class="section" id="voice-chat-dank-mumble">
<h4>Voice-Chat dank 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>Wir nutzen bereits seit längerem <a class="reference external" href="https://www.mumble.info/">Mumble</a>,
einen Open-Source VoIP-Chat-Server, um uns mit unseren remote arbeitenden
Kollegen zu unterhalten. Diese bei gemeinsamen Onlinespielen gebräuchliche
Konferenzsoftware ist nun unsere virtuelle Kaffeetheke geworden.
Über Mumble können wir sowohl unsere regelmäßigen Stand-Up-Meetings in
großer Runde fortsetzen als auch in kleineren Gruppen themenbezogene
Diskussionen starten.</p>
<p><strong>Empfehlung:</strong> bei einer dauerhaften Konferenzschaltung – unabhängig von der
Softwarelösung – die persönlichen Einstellungen auf <em>Push To Talk</em> setzen.
Eure Gesprächspartner werden es Euch danken.</p>
</div>
<div class="section" id="zeigen-und-erklaren-jitsi">
<h4>Zeigen und Erklären – 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>Trotz aller bisher gut funktionierender Kommunikation reicht es manchmal nicht
aus, nur miteinander zu reden.
Bei der gemeinsamen Arbeit ist es zwischendurch hilfreich und wichtig,
gemeinsam auf einen Bildschirm oder ein Stück Hardware zu schauen – oder
doch in das Gesicht, um die Person gegenüber besser zu verstehen.</p>
<p>Für diese Fälle haben unsere Admins einen
<a class="reference external" href="https://jitsi.org/">Jitsi-Server</a> aufgesetzt.
Die ersten vorsichtigen Erfahrungen mit der im Browser laufenden Videokonferenz
sind selbst bei längeren Konferenzschaltungen
mit einigen wenigen Teilnehmern auch bei geringer Bandbreite recht
vielversprechend.
Wir planen, in den nächsten Tagen noch einige Performance-Tests durchzuführen.</p>
<div><div class="clearfix"></div></div></div>
</div>
<div class="section" id="remote-arbeit-an-hardware">
<h3>Remote-Arbeit an Hardware</h3>
<p>Einer der großen Unterschiede zwischen Pengutronix und vielen anderen
Software-Entwicklungsdienstleistern ist,
dass wir sehr viel direkt auf und mit Hardware arbeiten (zum Beispiel,
um Linux-Kernel-Treiber weiterzuentwickeln oder zu testen).
Das bedeutet aber auch, dass unsere Kollegen Zugang zu den
Entwicklungsboards brauchen.</p>
<p>Im Moment profitieren wir davon, dass sich die Remote-Arbeit im Homeoffice
technisch nicht sonderlich von unserem bisherigen alltäglichen Arbeiten
unterscheidet.</p>
<p>Sobald ein Kundenboard bei uns initial in Betrieb genommen ist,
hängen wir es in eines unserer <em>Remote-Labs</em>.
Über die dazugehörige SSH-Infrastruktur können die Entwickler direkt von ihrem
Arbeitsplatz aus die Stromversorgung schalten, auf die serielle Konsole
zugreifen oder sich per Netzwerkzugang mit dem Board verbinden.
Aber vor allem ermöglichen unsere <em>Remote-Labs</em> uns die Testautomatisierung.</p>
<div class="section" id="unser-remote-setup">
<h4>Unser Remote-Setup</h4>
<p>Wir haben in den letzten Jahren sowohl softwareseitig als auch mit spezialisierter
Hardware viel Aufwand in Technik investiert, die das Remote-Arbeiten
an unseren Kunden-Boards ermöglicht.
Mit dem nun folgenden Einblick in unsere Arbeitsumgebung hoffen wir, auch andere
zu inspirieren:</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 an einem Remote-Lab</p>
</figcaption>
</figure>
</div><p>Jedes <em>Remote-Lab</em> besteht aus den folgenden Komponenten:</p>
<ul class="simple">
<li>einem über das Netzwerk kontrollierbaren Power Switch (Gude oder netio),</li>
<li>einem über Ethernet kontrollierbaren Seriellen Server
(siehe <a class="reference external" href="https://tools.ietf.org/html/rfc2217">RFC 2217</a>),</li>
<li>einem Netzwerkswitch und</li>
<li>einem kleinen Server.</li>
</ul>
<p>Einige Remote-Labs haben außerdem</p>
<ul class="simple">
<li>eine CAN-Infrastruktur, für erweriterte Schaltaufgaben (IO)</li>
<li>USB-Hubs, um USB-Geräte zu kontrollieren.</li>
</ul>
<p>Unser Open-Source-Hardware-Automatisierungstool
<a href="https://www.pengutronix.de/de/software/labgrid.html">labgrid</a>
ist dann die Komponente, die Hard- und Software verbindet, indem sie die
physikalischen Ressourcen abstrahiert und auf den Monitor der Entwickler
bringt.</p>
<p>Dafür läuft auf dem kleinen Server in jedem Remote-Lab ein 'labgrid exporter',
der automatisch eine
virtuelle "Ressource" für jede verfügbare Fernsteuer-Hardware im Lab anlegt.
Das kann dann zum Beispiel ein Powerswitch, eine serielle Konsole, ein USB-Gerät,
oder ein CAN-IO sein.</p>
<p>Diese Ressourcen lassen sich zu sog. Plätzen gruppieren,
wodurch sich Ressourcen unter einem einfachen, abstrakten Namen, wie bspw.
"mein_entwicklungsboard", zusammenfassen lassen.</p>
<p>Jeder Entwickler kann nun eine lokale Instanz des labgrid-Clients benutzen,
um zum Beispiel Plätze zu sperren, ein Board neu zu starten oder per
serieller Konsole auf dieses zuzugreifen.</p>
<p>Auf einer zentralen VM läuft ein 'labgrid coordinator'.
Dieser koordiniert die Zugriffe von den
labgrid-Clients auf die Ressourcen der 'labgrid exporter'.</p>
<p>Der Unterschied, ob die Hardware nun von den Schreibtischen im Büro oder per
SSH aus dem Homeoffice gesteuert wird, ist dabei so minimal, dass sich nun
der Aufwand, den wir in den Aufbau dieser Infrastruktur gesteckt haben, bezahlt
macht.</p>
</div>
<div class="section" id="hilfreiche-tools">
<h4>Hilfreiche 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>Trotzdem gibt es immer noch Tätigkeiten, die sich in der Embedded-Entwicklung
nicht so einfach automatisieren lassen.
Ein Beispiel wäre, eine SD-Karte mit einem neuen Softwarestand zu bespielen und diese
wieder in das Board zu stecken.
Zumindest für diesen Fall hat unser Partner <a class="reference external" href="https://linux-automation.com">Linux Automation GmbH</a> den <a class="reference external" href="https://shop.linux-automation.com/index.php?route=product/product&product_id=50">USB-SD-Mux</a>
entwickelt.</p>
<p>Der USB-SD-Mux ist eine kleine Platine, die an einem Ende wie eine µSD-Karte
geformt ist und am anderen Ende einen µSD-Karten-Slot enthält.
Der USB-SD-Mux wird nun anstelle einer µSD-Karte in das Board geschoben, und
die eigentliche µSD-Karte wird in den USB-SD-Mux gesteckt.
Der USB-SD-Mux wird mittels USB-Kabel mit einem Host-PC verbunden und kann
so die Karte zwischen dem Host-PC und unserem Board („Device under Test“)
umschalten.
Im Host-PC erscheint die SD-Karte als ein ganz normaler USB-Massenspeicher und
kann dort einfach neu beschrieben werden.</p>
<p>Da uns selbst noch zahlreiche weitere Automatisierungen fehlen, sind bereits
die nächsten Werkzeuge in der Entwicklungs- und Testphase. Darunter sind der
ETH-Mux, der Ethernet schalten wird (um die Kabel nicht mehr abziehen und neu
stecken zu müssen), und ein USB-OTG-Mux, der das Stecken eines USB-Sticks
simuliert.
Dazu bald mehr… :-)</p>
<p>Obwohl wir das Gefühl haben, dass unsere Remote-Infrastruktur gut aufgestellt
ist und wir keine Probleme haben, weiter zu arbeiten, hoffen wir doch darauf,
dass wir uns bald wieder an der Kaffeetheke treffen können und wir die
Krise gut überstehen.</p>
<p>Bleibt gesund!</p>
</div>
</div>
</div><p>Die Corona-Krise hat uns alle, sowohl als Privatpersonen als auch als Firmen,
plötzlich ziemlich hart getroffen und stellt unsere gesamte Gesellschaft vor
neue Herausforderungen.
Wir als Pengutronix möchten uns bei denjenigen bedanken, die in
systemkritischen Berufen arbeiten und unsere alltägliche Versorgung
sicherstellen.</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.htmlLizenzmanagement mittels ptxdist make license-report2020-02-25T00:00:00+01:00Felicitas Jung<div class="section" id="lizenzmanagement-mittels-ptxdist-make-license-report">
<div class="alert alert-warning" role="alert">
Dieser Blogpost soll als Übersicht für Menschen dienen, die bisher wenig
Kontakt zu Open Source und Free Software hatten.
Mögliche Ungenauigkeiten wurden für das einfachere Verständnis in Kauf genommen.
Für den Post wird einerseits der automatisch generierte PTXdist License-Report
verwendet, aber andererseits auch mal manuell in die Lizenzen geschaut, um ein
vollständigeres Bild zu bekommen.
</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 kommt standardmäßig mit einem Werkzeug, welches das Lizenzmanagement
erleichtert: <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>.
Hiermit lässt sich ein Lizenzreport als PDF erstellen, welcher aus dem
verwendeten BSP alle auffindbaren Lizenzen herausfiltert.
Die Generierung und Befolgung des Lizenzreports sollte als Mindestanforderung
mit viel Raum für weitergehende Lizenzpflege verstanden werden.</p>
<div class="section" id="lizenzreport-erstellen">
<h3>Lizenzreport erstellen</h3>
<p>Zunächst muss in das Wurzelverzeichnis des BSP gewechselt werden, in unserem
Fall ist das <tt class="docutils literal">~/DistroKit</tt>.
Das können wir überprüfen, indem wir schauen, ob die Symlinks
<tt class="docutils literal">selected_platformconfig</tt> und <tt class="docutils literal">selected_ptxconfig</tt> in diesem Verzeichnis
auffindbar sind.
Existieren die Symlinks nicht, kann PTXdist jedoch auch im
<tt class="docutils literal">~/DistroKit/configs</tt>-Verzeichnis suchen.
Lediglich wenn auch dort keine Informationen zur Plattform und keine PTXconfig
auffindbar sind, kann der Befehl nicht ausgeführt werden.
Anschließend wird der Befehl <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt> aufgerufen.</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit $ ptxdist make license-report
</pre></div>
</div><p>In meinem Fall musste ich zuvor die Pakete <tt class="docutils literal">graphviz</tt>, <tt class="docutils literal">dot2tex</tt> und
<tt class="docutils literal"><span class="pre">texlive-xetex</span></tt> nachinstallieren.
Sind alle Voraussetzungen gegeben, sammelt PTXdist alle Lizenzinfos der
Pakete zusammen, die im BSP gebaut werden.
Dies sind die Variablen <tt class="docutils literal"><PKG>_LICENSE</tt> und <tt class="docutils literal"><PKG>_LICENSE_FILES</tt> einer jeden
Paketdefinition, die entweder lokal im BSP oder im
PTXdist-Installationsverzeichnis unter <tt class="docutils literal"><span class="pre">rules/<pkg>.make</span></tt> zu finden sind.
Es meldet schließlich:</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>Der Lizenzreport liegt im Unterverzeichnis der verwendeten Plattform und dort
unterhalb von <tt class="docutils literal">report</tt>.
Es interessiert uns gerade nur der <tt class="docutils literal"><span class="pre">license-report.pdf</span></tt> (der Report für die Tools
ist für das fertig gebaute BSP, in welchem die Tools keine Anwendung mehr finden,
nicht interessant), also schauen wir ihn an:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>~/DistroKit $ evince platform-v7a/report/license-report.pdf
</pre></div>
</div><p>Bitte den Disclaimer auf der ersten Seite beachten:</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 class="ps-gallery single-image right" itemscope="" itemtype="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></div>
<div class="section" id="umgang-mit-dem-lizenzreport">
<h3>Umgang mit dem Lizenzreport</h3>
<p>Schauen wir uns das Paket BusyBox an:</p>
<p>Der Lizenzreport hat für BusyBox die Lizenz GPLv2-only gefunden.
Das bedeutet, dass zur Verwendung von BusyBox die Bedingungen der GPLv2 erfüllt
werden müssen.
Aufgrund des Zusatzes -only darf nicht stattdessen auf GPLv3 ausgewichen werden.
Befolgt man dauerhaft die Anforderungen der GPLv2, hat man für dieses Paket die
Arbeit bereits beendet.</p>
<p>Schauen wir uns jedoch das Paket systemd an, so fällt auf:</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>Der Lizenzreport hat also Komponenten von systemd gefunden, welche unter GPLv2+
lizenziert sind, jedoch auch Komponenten, die unter LGPLv2-only lizenziert sind.
Wenn die beabsichtigte Verwendung zufällig ohnehin konform mit beiden Lizenzen
ist, sind wir auch hier bereits am Schluss.
Das ist natürlich der ideale Zustand.</p>
<p>Im anderen Fall muss geprüft werden, ob die Komponenten ausgelassen werden können,
die unter Bedingungen lizenziert sind, die man nicht erfüllen kann oder will.</p>
</div>
<div class="section" id="die-komponenten-von-hand-analysieren">
<h3>Die Komponenten von Hand analysieren</h3>
<p>Schauen wir uns beispielsweise an, welche Komponenten von systemd im BSP
überhaupt verwendet werden:</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>Den Befehl mit der Tabulator-Taste vervollständigen, nachdem jeweils die ersten
Zeichen eingegeben wurden.</p>
<p>In den dort liegenden Komponenten von systemd findet sich obenan jeweils ein
Lizenz-Header, der erklärt, unter welcher Lizenz die jeweilige Komponente
lizenziert ist.
Zum Beispiel <em>könnte</em> man die Komponente <tt class="docutils literal">.mkosi/mkosi.debian</tt> weglassen.
Nehmen wir mal für Erklärungszwecke an, dass das etwas ist, was man tun wollen
würde.
Wenn man dann bei Erstellung des BSP diese Komponente auslässt, gegebenenfalls
also aktiv ausschaltet, müssen die Lizenzbedingungen hierfür nicht erfüllt werden.
Das würde natürlich nicht so viel ändern, da auch die anderen <tt class="docutils literal">.mkosi</tt>-Dateien
unter LGPLv2 lizenziert sind.
Um die LGPL zu vermeiden, müsste man sogar alle Komponenten von <tt class="docutils literal">.mkosi</tt>
auslassen.
Und natürlich ist noch viel mehr LGPL in systemd verbaut.
Vielleicht willst du dir das mal anschauen:</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>Das grept rekursiv nach den Buchstaben <tt class="docutils literal">LGPL</tt>.
Achtung, grep ist case-sensitive, also Groß- und Kleinschreibung beachten.
Weil die Buchstabenfolge <tt class="docutils literal">LGPL</tt> üblicherweise nur im License-Identifier
verwendet wird, bekommt man eine gute Übersicht darüber, welche Komponenten unter
einer Version der LGPL lizenziert sind.
Du könntest stattdessen auch nach einer besonderen Version der LPGL greppen,
versuche zum Beispiel <tt class="docutils literal"><span class="pre">LGPL-v2</span></tt>.
Beachte dabei aber, dass nicht alle Entwickler die gleiche Syntax verwenden, zum
Beispiel findet man <tt class="docutils literal">LGPL v2.1</tt> (ohne den Bindestrich zwischen <tt class="docutils literal">L</tt> und <tt class="docutils literal">v</tt>)
in <tt class="docutils literal">src/udev/ata_id/ata:id.c</tt>.
Für die schlichte Suche nach LGPL ist es, wie erwartet, sehr viel.
Nur die letzten paar Ergebnisse:</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>Vielleicht möchtest du die genaue Anzahl an Ergebnissen wissen, zum Beispiel zur
Abschätzung der Arbeitszeit:</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 meinem Fall ganze:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>2162
</pre></div>
</div><p>Oder du suchst nach <tt class="docutils literal">GPL</tt>, was auch in der Buchstabenfolge <tt class="docutils literal">LGPL</tt> beinhaltet
ist.
Wenn du nur nach der GPL greppen willst, brauchst du ein wenig RegExp-Magie:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>grep '^GPL\|[^L]GPL' -R
</pre></div>
</div><p>Oder suche direkt nach den 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>Eine Wortzählung bringt uns auf eine Gesamtheit von <tt class="docutils literal">2224</tt> (registrierten)
License-Identifiers für die Version von systemd, die ich in meinem BSP verbaut
habe, wobei manche Dateien gegebenenfalls die Buchstabenfolge <tt class="docutils literal">License Identifier</tt>
nicht exakt beinhalten.</p>
<p>Diese Arbeit nimmt dir der Befehl <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt> ab und gibt
dir einen guten Überblick über die Lizenzen der verwendeten Komponenten,
bei bekannten Open-Source-Lizenzen sogar einschließlich Lizenztext.
Es ist recht komfortabel, ein einfach zu lesendes PDF zu haben, was einem sagt,
welches Programm im BSP welche Lizenzen beinhaltet.
Das erlaubt dir, dich auf die verbleibenden problematischen Stellen zu
konzentrieren.
Der Lizenzreport benötigt jedoch natürlich korrekte Angaben und kann daher das
individuelle Lizenzmanagement durch einen Menschen nicht ersetzen.</p>
<p>Wenn bei einem bereits bestehenden BSP nachträglich bestimmte Lizenzen vermieden
werden sollen oder müssen, kann der Lizenzreport als Ausgangspunkt genutzt werden.</p>
</div>
</div>
<p>PTXdist kommt standardmäßig mit einem Werkzeug, welches das Lizenzmanagement
erleichtert: <tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt>.
Hiermit lässt sich ein Lizenzreport als PDF erstellen, welcher aus dem
verwendeten BSP alle auffindbaren Lizenzen herausfiltert.
Die Generierung und Befolgung des Lizenzreports sollte als Mindestanforderung
mit viel Raum für weitergehende Lizenzpflege verstanden werden.</p>2020-02-25T00:00:00+01:00tag:www.pengutronix.de,2020-02-25:/2020-02-25-open-source101.htmlFürchte nicht den offenen Quellcode - 1x1 des Lizenzmanagements2020-02-25T00:00:00+01:00Felicitas Jung<div class="section" id="furchte-nicht-den-offenen-quellcode-1x1-des-lizenzmanagements">
<div class="alert alert-warning" role="alert"><p>Dieser Blogpost soll als Übersicht für Menschen dienen, die bisher wenig
Kontakt zu Open Source und Free Software hatten.
Kleinere Ungenauigkeiten wurden für das einfachere Verständnis in Kauf genommen,
die Feinheiten lernt man erfahrungsgemäß durch die Nutzung von Open Source
Programmen und Free Software.</p>
<p>Der Text konzentriert sich auf das deutsche Urheberrecht, insbesondere das anglo-
amerikanische Copyright ist hiervon grundlegend verschieden.
Die resultierenden Folgen, nämlich Lizenzen, werden jedoch vergleichbar
gehandhabt, weswegen auch nicht-deutsche Software in der Regel gleich behandelt
werden kann.</p>
</div><div class="section" id="warum-gibt-es-lizenzen">
<h3>Warum gibt es Lizenzen?</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="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 als Justizia mit Augenbinde und Schwert</p>
</figcaption>
</figure>
</div><p>Computerprogramme und Code sind urheberrechtlich geschützt, in Deutschland lässt
sich dieser Schutz nicht umgehen oder ausschalten.
Das Urheberrecht gewährt grundsätzlich nur demjenigen, der das Werk geschaffen
hat ("Urheber"), die Rechte an dem Werk.
Mithin dürfte nur der Entwickler den von ihm geschriebenen Code verwenden,
verändern und verbreiten.</p>
<p>Dieses Verwertungsrecht kann der Urheber jedoch ganz oder teilweise an andere
Personen abtreten, zum Beispiel an den Arbeitgeber (welcher dadurch jedoch nicht
Urheber wird).
Daraus ergibt sich, dass Urheber/Autor und Rechteinhaber durchaus voneinander
verschiedene Personen sein können.</p>
<p>Ausgangspunkt des derzeitigen Urheberrechts ist, dass niemand außer dem
Rechteinhaber das Werk vervielfältigen, verbreiten, bearbeiten oder eine
entsprechende Genehmigung an eine andere Person erteilen darf.
Der Urheber müsste also mühsam individuelle Ausnahmen vereinbaren.
Viele Menschen waren mit dieser strikten Regulierung unzufrieden, Code sollte
frei und ohne Notwendigkeit für individuelle Kontaktaufnahme durch jeden oder
aber zumindest die Nutzer des Programms veränderbar sein, so wie beispielsweise
ein Fahrrad auch durch jeden, der berechtigten Zugriff auf dieses Fahrrad hat,
veränderbar ist.</p>
<p>Da ein Verzicht auf das Urheberrecht jedoch u.a. in Deutschland nicht möglich ist,
wurde das Tool des Urheberrechts, die Lizenzen, für den jeweiligen Code so
ausgestaltet, dass jeder grundsätzlich alle Rechte eingeräumt bekommt (Free
Software).
Um Code überhaupt verbreiten und verändern zu können, ist jedoch auch die
Veröffentlichung des Codes notwendig: Open Source ist die Lösung.</p>
</div>
<div class="section" id="free-and-open-source-software">
<h3>Free and Open Source Software</h3>
<p>Open Source bedeutet im Wortsinne zunächst einmal, dass der Code öffentlich
einsehbar ist.
Nicht zwangsläufig muss dies über ein Versionsverwaltungstool geschehen, auch
wenn dies häufig der Fall ist, auch die Bereitstellung des Codes auf
Nutzeranfrage hin, ohne nennenswerte weitere Bedingungen erfüllen zu müssen,
kann als Open Source verstanden werden.
Ist der Code dauerhaft einsehbar, schauen viele Augen mit viel unterschiedlichem
Wissen darüber, Sicherheitslücken aber auch allgemeiner Verbesserungsbedarf
fallen schnell auf.</p>
<p>Während Hinweise von Externen auf Verbesserungsbedarf an proprietärem Code nicht
selten mit rechtlichen Konsequenzen zulasten des Finders einhergehen, was
offensichtlich der Fehlersuche entgegenwirkt, wird durch Offenlegung des Codes
die Verbesserung des Programms gefördert.</p>
<p>Open Source betont über die Einsehbarkeit hinaus auch die Veränderbarkeit des
Codes durch jederman, im Gegensatz zu nur Code-available-Programmen.
Selbstverständlich folgt aus der Einsehbarkeit und Veränderbarkeit des Codes
jedoch nicht, dass jemand ohne Genehmigung Veränderungen in den Ursprungscode
einpflegen kann, lediglich eine eigene Version, ein Fork, ist möglich.
Der Vorteil für den ursprünglichen Entwickler liegt darin, dass er die durch
andere Personen vorgenommenen Optimierungen bei entsprechender Lizensierung auch
wieder in den Ursprungscode übernehmen kann.</p>
<p>Free Software wiederum rückt die Freiheit der Anwender in den Mittelpunkt, für
welche freie Software notwendig ist.
Ein Entwickler von freier Software hat nicht vordergründig die technischen oder
wirtschaftlichen Vorteile eines offenen Quellcodes im Blick, sondern möchte aktiv
die Gesellschaftsordnung hin zu mehr Nutzungsfreiheit für Individuen gestalten.
Für das letztlich entstehende Programm macht dies jedoch kaum einen Unterschied.</p>
<p>Kurz gesagt fasst man unter Open Source die Beschreibung eines Programms,
nämlich mit einsehbarem und abwandelbarem Code, und unter Free Software
eine ethische Idee, die dahinter stehen kann - jedoch nicht muss.
Als gemeinsamen Begriff kann <tt class="docutils literal">FOSS</tt>, was für <tt class="docutils literal">Free and Open Source Software</tt>
steht, sowie <tt class="docutils literal">FLOSS</tt>, welches noch <tt class="docutils literal">Libre</tt> hinzufügt, verwendet werden.
Für den Verwender von FOSS-Programmen machen diese Unterschiede in den
Definitionen jedoch de facto keinen Unterschied.</p>
<p>Damit eine FOSS-Lizenz jedoch gültig ist, muss sie von dem Rechteinhaber
ausgestellt worden sein.
Ein unter Verletzung der proprietären Lizenz veröffentlichtes Programm wird nicht
durch die bloße Veröffentlichung zu einem FOSS-Programm und mithin für die
Allgemeinheit nutzbar, und eine durch die illegal veröffentlichende Person
angefügte Lizenz ist auch nicht bindend, sodass das Programm allgemein verwendbar
wäre.
So wie eine proprietäre Lizenz natürlich auch Bestand hat, selbst wenn das
Programm unerlaubt veröffentlicht wird, bleibt auch eine FOSS-Lizenz bestehen,
auch wenn beispielsweise die Betreuung des Programms beendet wird.
Eine Lizenzänderung ist zwar möglich, macht die bisher lizenzkonforme Verwendung
jedoch nicht nachträglich rechtswidrig und betrifft daher nur zukünftige
Verwendungen.</p>
</div>
<div class="section" id="embedded-linux">
<h3>Embedded Linux</h3>
<p>Bei Embedded Linux handelt es sich um Embedded Betriebssysteme, welche auf dem
Linux-Kernel basieren.
Grundsätzlich lassen sich drei Ebenen unterscheiden:</p>
<ul class="simple">
<li>die Hardware,</li>
<li>der Kernel sowie das grundlegende Betriebssystem,</li>
<li>die individuelle Anwendungssoftware.</li>
</ul>
<p>Der Linux-Kernel ist Open Source (GPL-v2) und daher einsehbar, veränderbar,
weiterverbreitbar.
FOSS-Embedded-Systeme bieten den großen Vorteil, dass sie aufgrund ihrer
Flexibilität sehr genau auf die konkreten Bedürfnisse zugeschnitten werden können,
dadurch effizienter sind sowie auf eine Vielzahl von intellektuellen Ressourcen
zurückgegriffen werden kann.
Bei regelmäßigen Updates lässt sich sagen, dass ein FOSS-System grundsätzlich
sicherer ist als ein vergleichbares System mit größtenteils proprietärer Software.</p>
<p>Gerade im gewerblichen Umfeld ist ebenfalls relevant, dass bei Verwendung von
FOSS-Systemen kein Vendor-Lock-In entsteht, also nicht dauerhaft auf einen
bestimmten Dienstleister zurückgegriffen werden muss, und mit der Zeit sogar
genügend Know-How zusammengetragen worden sein kann, sodass Inhouse-Betreuung
möglich ist.
Nichtsdestotrotz ist die Betreuung und vor allem die initiale Entwicklung
aufwendig, weshalb es sich empfiehlt, einen spezialisierten Dienstleister zu
beauftragen.
Ganz so, wie zwar jeder ein Fahrrad zusammenbauen könnte, jedoch nur der
Fachmann auch weiß, welche Bauteile für welchen Zweck sinnvoll sind und wie man
sie nicht nur so zusammensetzt, dass nichts auseinanderfällt, sondern so, dass
das Fahrrad auch den Bedürfnissen entsprechend gut benutzbar ist.</p>
</div>
<div class="section" id="lizenzmanagement">
<h3>Lizenzmanagement</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="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>Darstellung von Lizenzarten von alle Rechte gewährend bis alle Rechte bewahrend</p>
</figcaption>
</figure>
</div><p>Mit einsehbarem Quellcode einher geht jedoch eine weitere Besonderheit: diverse
Lizenzen, die jeweils beachtet werden müssen.
Während auch proprietäre Software Lizenzen beinhaltet, muss man sich über die
Erfüllung selten Gedanken machen, da mit Anschaffung der Software für gewöhnlich
bereits klar ist, dass die Software für den angedachten Zweck auch die Rechte
bereitstellt (obwohl die meisten Lizenzverletzungen wohl gerade im proprietären
Bereich auftreten, da kein Bewusstsein für Lizenzen besteht).</p>
<p>Im Falle von Open-Source-Code liegt erst einmal alles, völlig unabhängig von den
Lizenzbedingungen, offen und kann theoretisch verwendet werden.
Ob man ein Programm jedoch verwenden darf, steht auf einen anderen Blatt -
nämlich den Lizenzbedingungen.</p>
<p>Es gibt eine handvoll weit verbreiteter Lizenzen, deren Bedingungen nach einiger
Zeit der Verwendung von FOSS-Programmen im Schlaf bekannt sind.</p>
<p>Hierunter fallen die GPL-v2 und GPL-v3, die LGPL, BSD-Lizenz und noch weitere.
Jedoch kann der Rechteinhaber selbstverständlich Bedingungen ganz nach Belieben
festlegen.
Daher ist es immer möglich, dass Code keine der bekannten Lizenzen verwendet,
sondern individuelle Bedingungen aufstellt.
Auch in diesem Fall sind die Bedingungen natürlich zu erfüllen, wenn man das
Programm nutzen möchte.</p>
<p>Unerlässlich ist somit, bei allem verwendeten Code die Lizenz-Dateien (auch:
Copying-Dateien) oder, bei anderer Herangehensweise der Entwickler, den
Lizenz-Header auszulesen und mindestens bei unbekannten Lizenzen genau auf die
Bedingungen hin zu prüfen.
Eine Lizenzverletzung ist eine Rechtsverletzung, denn um ein Programm zu nutzen,
muss man dessen Bedingungen akzeptieren, da ohne die Bedingungen das Programm
allein dem Rechteinhaber zusteht.
Lizenzpflege ist mithin notwendig und muss in Form eines fortlaufenden
Lizenzmanagements geschehen.
Wenn ehrliches Bemühen um Lizenzpflege erkennbar ist, fallen Reaktionen auf
kleinere Ungenauigkeiten jedoch zumeist milder aus.
Daher sollte, wie immer, gut dokumentiert werden, um stets zu wissen, an welchen
Stellen man noch nacharbeiten muss.
Durch eine gute Dokumentation kann man das eigene Bemühen nachweisen und
erleichtert außerdem den Nachfolgern die Fortsetzung der Lizenzpflege.</p>
<p>Es gibt viele Einzelpersonen wie Unternehmen, die bereits seit vielen Jahren
Übung im Lizenzmanagement haben und hilfreiche Werkzeuge bereitstellen.
Um beispielsweise den Verwendern von PTXdist das Leben möglichst leicht zu machen,
wirft der <a class="reference external" href="https://www.pengutronix.de/de/blog/2020-02-25-ptxdist_license-report.html">Befehl</a>
<tt class="docutils literal">ptxdist make <span class="pre">license-report</span></tt> eine Datei der für die jeweils im BSP verwendeten
Programme geltenden Lizenzen in Kurzform und unter Umständen auch in Langform,
sowie den Pfad zur Lizenzdatei in Langform aus.</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="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 im Verzeichnis des BSP</p>
</figcaption>
</figure>
</div><p>Hat man sich den Lizenz-Report generiert und befolgt die gefundenen
Lizenzbedingungen, ist man auf der sicheren Seite.
Wird eine Lizenz nur mit ihrem Namen benannt oder bestehen Fragen bzgl. der
Kompatibilität von Programmen mit jeweils unterschiedlichen Lizenzen, so ist
<a class="reference external" href="https://spdx.org/">SPDX</a> (Software Package Data Exchange) hilfreich, wo alle
gängigen Lizenzen mit ihrem Lizenztext gelistet sind.</p>
<p>Da viele Entwickler Skripte verwenden, welche Lizenztexte vergleichen, ist es
sinnvoll, für gleichen Inhalt auch stets den gleichen Wortlaut zu verwenden.
Es gibt bereits für so ziemlich jeden Anwendungsfall eine Lizenz, zum Beispiel
gelistet bei <a class="reference external" href="https://choosealicense.com/">choosealicence</a>.
Wann immer möglich, sollte eine bereits existierende Lizenz verwendet werden.
Wenn eine individuelle Lizenz absolut notwendig ist, ist das Entwerfen des
Lizenztextes jedenfalls der falsche Zeitpunkt, um mit einem originellen Wortlaut
zu glänzen.</p>
</div>
<div class="section" id="und-was-sind-die-folgen">
<h3>Und was sind die Folgen?</h3>
<p>FOSS-Programme und all die daraus entstehenden Vorteile gibt es nur mit Lizenzen.
Dies liegt schlicht an unserer Rechtsordnung, die für jede intellektuelle
Leistung alle Rechte beim Urheber sieht.
Es ist somit Sache des Urhebers, wenn er seine Leistung für andere verwertbar
machen möchte, diese Rechte an einzelne Personen oder die Allgemeinheit durch
eine Lizenz abzugeben.
Gibt es zu einer Leistung keine Lizenzbedingungen, hat demnach allein der Urheber
die Rechte daran - sie ist für niemanden sonst nutzbar.</p>
<p>Andererseits gibt es Lizenzen, die darüber hinausgehen und durch bestimmte, auf
den ersten Blick beschränkende, Bedingungen zusätzliche Voraussetzungen der
Verwendung schaffen.
Verbreitet ist die Pflicht, ein den Code verwendendes Programm unter den gleichen
(oder vorbestimmten vergleichbaren) Bedingungen zu veröffentlichen.
Hervorzuheben hierbei sind die sogenannten Copyleft-Lizenzen, welche an die
Verwendung des unter Copyleft lizenzierten Codes ein ebenfalls unter Copyleft
lizenziertes Endprodukt knüpfen.
Sie verpflichten also insbesondere dazu, den Quellcode des Endprodukts (und auch
den Quellcode eines möglicherweise darauf beruhenden weiteren Endprodukts) der
Allgemeinheit zugänglich zu machen.
Ob dies die kommerzielle Weitergabe des Endprodukts einschließt oder nicht, ist
den jeweiligen Lizenzbedingungen zu entnehmen.</p>
<p>In gewisser Weise trickst Copyleft das Copyright aus: Mit den Möglichkeiten des
Copyright, mit dem eine Leistung eigentlich vor dem Zugang der Allgemeinheit
geschützt werden soll, wird gerade die Zugangsmöglichkeit festgesetzt.
So wie wir unter Hacking den kreativen Umgang mit Technik verstehen, so ist
Copyleft kreativer Umgang mit dem Recht: die vorhandenen Möglichkeiten des
Urheberrechts werden vollends und rechtlich einwandfrei genutzt, um einen durch
den Gesetzgeber nicht beabsichtigten Zweck zu verfolgen.</p>
<p>Der Vorteil dieser Lizenzarten ist die stetige Weiterverbreitung von Open Source
Code, sodass jeder auf eine stetig wachsende Basis von Programmen zurückgreifen
kann.
Der offensichtliche Nachteil ist, dass unter den gleichen Lizenzbedingungen
veröffentlicht werden muss und Entwickler, welche proprietären Code entwickeln
möchten, bewusst benachteiligt werden.
Dies wird auch Copyleft-Effekt genannt und ist bei der Verwendung von FOSS-Code,
welcher unter Umständen unter einer Copyleft-Lizenz lizenziert ist, unbedingt zu
beachten.</p>
<table border="1" class="docutils">
<colgroup>
<col width="17%"/>
<col width="23%"/>
<col width="12%"/>
<col width="17%"/>
<col width="16%"/>
<col width="15%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head"> </th>
<th class="head">Public-Domain-ähnlich</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>Beschreibung</td>
<td>Nichtbestehen von Immaterialgüterrechten,
sei es durch Verzicht, Zeitablauf oder
genereller Unlizensierbarkeit</td>
<td>gewährt alle
Nutzungsrechte
(auch kommerziell;
auch Verwendung
anderer Lizenz für
abgeleitete Werke)</td>
<td>gewährt alle Nutzungsrechte,
trifft jedoch Bestimmungen zur
Lizensierung von abgeleiteten
Werken</td>
<td>nur Nutzungsrechte für
nicht-kommerzielle
Verwendung;
kann mit Copyleft
kombiniert werden</td>
<td>es wird die Ausführung
erlaubt, ggf. gegen
Geldzahlung, jedoch
nicht die weitere
Nutzung</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>traditionelles Copyright</td>
</tr>
<tr><td>andere kreative Werke</td>
<td>Public Domain, Gemeinfreiheit, CC0</td>
<td>CC-B, andere</td>
<td>CC-BY-SA, andere</td>
<td>CC-BY-NC/CC-BY-NC-SA, andere</td>
<td>traditionelles Copyright</td>
</tr>
</tbody>
</table>
<p>Die obige Auflistung der Lizenzen soll als unvollständiges Beispiel verstanden werden.</p>
<p>Selbstverständlich kann man für Software Creative-Commons-Lizenzen oder für
sonstige kreative Werke eine eher für Software typische Lizenz verwenden.
Da es sich um vorgefertigte Lizenzen handelt, wären in dem Fall jedoch
gegebenenfalls nicht alle typischen Problematiken abgedeckt und an anderer Stelle
würden ausführlich Themen behandelt, die typischerweise gar nicht vorliegen.</p>
<p>Copyleft-Programme ergeben jedoch auch mit Verwendung von proprietärem Code keine
Probleme, soweit nicht ein gemeinsamer Prozess erzeugt wird, denn lediglich bei
der Vermischung mit fremdem Code liegt überhaupt ein bearbeitetes Werk
(derivative work) im Sinne des Urheberrechts vor, über welches der ursprüngliche
Rechteinhaber entscheiden darf.
Technisch eigenständige Programme werden durch Copyleft-Lizenzen also nicht
beeinflusst, selbst wenn sie gleichzeitig (aber unabhängig) und auf demselben
System laufen.
Gleiches gilt für sonstige zueinander inkompatible Lizenzen.
Wichtig ist für Embedded-Systeme mit Open-Source-Komponenten also insbesondere,
dass die proprietäre Software auf dem obersten Layer läuft, welches bei der
die Lizenzverpflichtungen erfüllenden Veröffentlichung weggelassen wird, und das
System somit auch ohne den proprietären Teil einwandfrei funktioniert.
Sowohl PTXdist als auch Yocto beinhalten standardmäßig diese Layeroption.
Entwickler sollten sicherstellen, dass das Layering entsprechend eingehalten wird.
Keinesfalls darf auf die Veröffentlichung der Open-Source-Komponenten und daraus
abgeleiteter Software verzichtet werden, um die proprietären Komponenten zu
schützen.
Dies stellt eine Rechtsverletzung dar und ist zudem leicht zu vermeiden.</p>
<p>Während Lizenzen zwar in der FOSS-Welt sehr präsent sind, sind sie bei weitem
keine Eigenheit von Freier und Open-Source-Software.
Lizenzen und das daraus folgenden Lizenzmanagement sind also stets notwendig,
um überhaupt von fremdem Code zu profitieren.
Dies muss die Sicherstellung der Kompatibilität von verwendeten Lizenzen
untereinander und zu der beabsichtigten Endlizenz beinhalten.
Aber letztlich ist all das kein Hexenwerk und ist mit den vorhandenen Werkzeugen
gut umsetzbar.</p>
</div>
</div>
<p>Computerprogramme und Code sind urheberrechtlich geschützt, in Deutschland lässt
sich dieser Schutz nicht umgehen oder ausschalten.
Das Urheberrecht gewährt grundsätzlich nur demjenigen, der das Werk geschaffen
hat ("Urheber"), die Rechte an dem Werk.
Mithin dürfte nur der Entwickler den von ihm geschriebenen Code verwenden,
verändern und verbreiten.</p>
2020-02-25T00:00:00+01:00tag:www.pengutronix.de,2020-02-24:/2020-02-24-blog-license.htmlJetzt als Creative Commons!2020-02-24T00:00:00+01:00Felicitas Jung<div class="section" id="jetzt-als-creative-commons">
<p>Vielleicht hast du es schon bemerkt: Wir haben jetzt einen Footer, welcher nur im
Blog auftaucht.
Hintergrund ist, dass wir unsere Blogposts bisher ohne Angabe einer Lizenz
veröffentlicht haben, sodass weder die Texte noch die sonstigen Informationen
frei nutzbar waren.</p>
<p>Das ist als Open-Source-Unternehmen natürlich nicht unsere Absicht gewesen!
Daher sind nun alle Blogposts, auch rückwirkend, unter <a class="reference external" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">CC-BY-SA Version 4.0</a> lizenziert.
Für verwendete Codeschnipsel gilt weiterhin die <a class="reference external" href="https://spdx.org/licenses/0BSD.html#licenseText">0BSD-Lizenz</a>.</p>
<p>Du kannst also gerne alle Texte, Grafiken und Fotos aus unserem Blog nutzen und
verändern, solange du die Namensnennung und den Copyleft-Effekt beachtest.
Ausnahmen werden deutlich gemacht.</p>
<p>Hab Spaß und fröhliches Hacken!</p>
</div>
<p>Vielleicht hast du es schon bemerkt: Wir haben jetzt einen Footer, welcher nur im
Blog auftaucht.
Hintergrund ist, dass wir unsere Blogposts bisher ohne Angabe einer Lizenz
veröffentlicht haben, sodass weder die Texte noch die sonstigen Informationen
frei nutzbar waren.</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>Morgen startet die Embedded Linux Conference Europe in Lyon/Frankreich,
und wie in jedem Jahr nutzt das Pengutronix Team die Gelegenheit zur
Präsentation unserer aktuellen Open Source Aktivitäten und zur
Vernetzung mit anderen Entwicklern in der Open Source Community.
Folgende Tasks wird es in den nächsten Tagen geben:</p>
<div class="section" id="vortrage-auf-der-embedded-linux-conference-europe">
<h3>Vorträge auf der Embedded Linux Conference Europe</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 berichten über unsere aktuellen
Aktivitäten, dem Linux Kernel das J1939 Protokoll zur Kommunikation
in Traktoren und Baumaschinen beizubringen
(Dienstag, 29. Oktober 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 erklärt die Designentscheidungen hinter RAUC und
unsere aktuellen Aktivitäten rund um robuste Field-Updates von
Embedded Linux Systemen
(Dienstag, 29. Oktober 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>
Unter Linux gibt es viele Möglichkeiten, Daten und Code auf
den dahinterliegenden Speicher-Devices zu verschlüseln. Jan
Lübbe diskutiert die verschiedenen Varianten für die diversen
Embedded Usecases
(Mittwoch, 30. Oktober 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>
Am Dienstag abend gibt es den Technical Showcase: wir zeigen
die aktuellen Entwicklungen bei RAUC (robustes Feld-Update)
und Etnaviv (Open Source 3D-Grafik auf i.MX8M).</li>
</ul>
</div>
<div class="section" id="vortrage-auf-dem-automated-testing-summit">
<h3>Vorträge auf dem Automated Testing Summit</h3>
<ul class="simple">
<li><strong>Labgrid: Real World Examples:</strong>
Rouven Czervinski und Jan Lübbe zeigen, wie wir im Pengutronix
Testlabor Boards mit Hilfe von Labgrid im Testbetrieb steuern
(Donnerstag, 31. Oktober 2019, 11:00, Rhone 3AB)</li>
<li><strong>New Ways out of the struggle of testing embedded devices:</strong>
Chris Fiege berichtet über die Möglichkeiten zur Hardware-Fernsteuerung
von Geräten im Testlabor und diskutiert Erfahrungen mit verschiedenen
Varianten
(Donnerstag, 31. Oktober 2019, 11:50, Rhone 3AB)</li>
</ul>
</div>
</div>
<p>Morgen startet die Embedded Linux Conference Europe in Lyon/Frankreich,
und wie in jedem Jahr nutzt das Pengutronix Team die Gelegenheit zur
Präsentation unserer aktuellen Open Source Aktivitäten und zur
Vernetzung mit anderen Entwicklern in der Open Source Community.
Folgende Tasks wird es in den nächsten Tagen geben:</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.htmlStatische Dateisysteme2019-07-09T00:00:00+01:00Jürgen Borleis<div class="section" id="statische-dateisysteme">
<div class="ps-gallery single-image right" itemscope="" itemtype="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>Wann immer es erforderlich ist, ein embedded Gerät einfach so ohne Vorbereitung
ausschalten zu können, kommt das Thema Dateisystem-Konsistenz
auf. Werden Daten geschrieben und haben vor dem Ausschalten ihren Weg auf das
Speichermedium noch nicht vollständig gefunden, droht deren Verlust.</p>
<p>Beim nächsten Systemstart kann das Dateisystem an sich in den meisten Fällen wieder
in einen konsistenten Zustand gebracht werden. Die beim letzten Lauf geänderten
Daten sind aber praktisch immer verloren. Und manchmal passiert es eben auch,
dass nicht nur die Daten im Dateisystem inkonsistent sind, sondern mitunter auch
seine Verwaltungsstrukturen. Dann ist das gesamte Dateisystem unbrauchbar und
in dessen Folge das gesamte System nicht mehr benutzbar.
Diverse Dateisysteme verfügen über Mechanismen, die die Konsistenz unter allen
Umständen sicherstellen sollen. Aber auch hier sehen wir immer wieder Ausfälle
im Feld, wo diese Mechanismen aus den verschiedensten Gründen doch versagen.</p>
<p>Eine Lösung für dieses Dilemma ist, ein Dateisystem im reinen Lesebetrieb zu
verwenden ("read-only"). Das Dateisystem wird beim Bauen vollständig definiert
und braucht zur Laufzeit keine Änderung mehr - ist also vollständig statisch.</p>
<p>Allerdings funktionieren dann nicht mehr alle Applikationen und Werkzeuge, da
sie an bestimmten Stellen in der Dateisystemhierarchie schreibenden Zugriff
erfordern, und sei es nur, um ihre Logausgaben zu sichern. In den allermeisten
Fällen betrifft das die Dateisystemhierarchie unter <cite>/var</cite>.</p>
<p>Bisher hat PTXdist den Ansatz verfolgt, in <cite>/var/lock</cite>, <cite>/var/log</cite> und <cite>/var/tmp</cite>
drei RAM-Disks zu platzieren, die somit in genau diesen drei Unterverzeichnissen
das Schreiben ermöglichen. Auch wenn dieser Ansatz einfach und auch sehr
optimistisch ist, hat er bisher erstaunlich gut funktioniert.</p>
<p>Eine wesentliche Annahme bei diesem Ansatz ist, dass die geschriebenen Daten
einen Systemneustart nicht "überleben", also nicht dauerhaft gespeichert werden
müssen.</p>
<p>Aber mehr und mehr Applikationen und Werkzeuge haben neue Anforderungen an die
Dateisystemhierarchie unter <cite>/var</cite>, und somit ist der bisherige Ansatz zu
unflexibel geworden und funktioniert daher häufig nicht mehr.</p>
<p>Aus diesem Grund gibt es nun mit dem PTXdist-Juli-Release einen weiteren
(konfigurierbaren) Ansatz, die Dateisystemhierarchie unter <cite>/var</cite> beschreibbar
zu machen: "Overlay Filesystem". Dieses vom Linux-Kernel unterstützte
Dateisystem ermöglicht es, ein statisches Dateisystem durch ein änderbares
Dateisystem zu überlagern.</p>
<p>Im einfachsten Fall ist das änderbare Dateisystem eine RAM-Disk
und beim Systemstart zunächst leer. Dann liefern lesende Zugriffe zunächst den
Inhalt des darunterliegenden statischen Dateisystems.
Somit gilt also nach einem Systemstart immer ein initialer Zustand.
Werden Daten geschrieben, werden sie nur im änderbaren
Dateisystem gespeichert. Ein wiederholter lesender Zugriff auf diese Daten wird
danach aus dem änderbaren Dateisystem bedient, nicht mehr aus dem darunter
liegenden statischen Dateisystem.</p>
<p>Die Nutzung dieses neuen Ansatzes in PTXdist ist denkbar einfach. Voraussetzung
ist, dass der eingesetzte Linux-Kernel das "Overlay Filesystem" (Symbol
CONFIG_OVERLAY_FS=y) unterstützt. Weiterhin muss im PTXdist-Konfigurationsmenü
"overlay <cite>/var</cite> with RAM disk" aktiviert werden (Symbol ROOTFS_VAR_OVERLAYFS=y).
Danach reicht es, das Root-Dateisystem neu erstellen zu lassen und zu benutzen.</p>
<p>Zur Laufzeit kann mittels "mount"-Kommando geprüft werden, ob die neue
Konfiguration wirksam ist:</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>Das Root-Dateisystem ist "ro" ("read-only") eingehängt und das
"overlay filesystem" auf <cite>/var</cite>.</p>
<p>Kommandos wie "mkdir" oder "touch" können nun gewohnt auf alle Bereiche in <cite>/var</cite>
angewendet werden.</p>
<p>Detail: Die dabei verwendete RAM-Disk ist in der Ausgabe des "mount"-Kommandos
übrigens nicht sichtbar. Sie wird nach dem Einhängen des "overlay filesystem"
wieder "offiziell" ausgehängt. Da sie aber benutzt wird, bleibt sie unsichtbar
bestehen. Sobald das sie nutzende "overlay filesystem" ausgehängt wird, wird
sie ebenfalls ausgehängt und die von ihr belegten Speicherressourcen frei gegeben.</p>
</div>
<p>Wann immer es erforderlich ist, ein embedded Gerät einfach so ohne Vorbereitung
ausschalten zu können, kommt das Thema Dateisystem-Konsistenz
auf. Werden Daten geschrieben und haben vor dem Ausschalten ihren Weg auf das
Speichermedium noch nicht vollständig gefunden, droht deren Verlust.</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.htmlPengutronix Techweek 20192019-06-11T00:00:00+01:00Chris FiegeMarie Mann<div class="section" id="pengutronix-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>Morgenstimmung über der Technologiewoche</p>
</figcaption>
</figure>
</div><p>An einem weit entfernten Ort, fernab vom Tagesgeschäft, haben sich die
Mitarbeiter von Pengutronix zur jährlichen Technologiewoche getroffen.</p>
<p>Die Technologiewoche ist eine Woche, in der wir, unterbrochen von vielen
leckeren Mahlzeiten, die Möglichkeit haben, in Ruhe zu hacken und über den
Alltag hinaus zu diskutieren und neue Ideen zu entwickeln - und nicht zuletzt
uns zu überlegen, wie wir die "Linux-World-Domination" vorantreiben.</p>
<p>Hier ein kleiner Eindruck über die Themen, die während der Zeit angefasst wurden:</p>
<ul class="simple">
<li>Die Veröffentlichung von <a class="reference external" href="https://www.pengutronix.de/de/blog/2019-06-05-RAUC-1.1.html">RAUC v1.1</a>, über die bereits berichtet wurde.</li>
<li>Einer unserer Kollegen hat barebox für Arch Linux ARM paketiert,</li>
<li>einige andere Kollegen haben an Debug-Optionen mit OpenOCD gearbeitet,</li>
<li>unser Grafikteam hat eine Testsuite für ihre Zwecke und Fälle zu entwickeln begonnen,</li>
<li>und die Barebox Entwickler haben eine Möglichkeit ersonnen, das Aufsetzen einer neuen
Maschine mit Firmware um einiges zu vereinfachen.</li>
</ul>
<p>Aber dies soll nur ein kleiner Vorgeschmack auf weitere Informationen und
"tolle neue Features" sein...</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>Darf es noch etwas Kuchen sein?</p>
</figcaption>
</figure>
</div><p>Neben der Entwicklung neuer Technologien und Zeit, an
spannenden Projekten zu hacken, ist die Technologiewoche auch immer eine gute
Möglichkeit, die Kollegen kennenzulernen.
Natürlich soll auch der Spaß nicht zu kurz kommen.
Eine Gelegenheit dafür bietet die traditionelle Exkursion.</p>
<div class="section" id="amateurfunkpeilen-fuchsjagd">
<h3>Amateurfunkpeilen "Fuchsjagd"</h3>
<p>In diesem Jahr haben wir uns in der Spaß-Variante vom <a class="reference external" href="https://de.wikipedia.org/wiki/Amateurfunkpeilen">Amateurfunkpeilen</a> versucht.
Bei dem Amateurfunkpeilen, das auch als "Fuchsjagd" bezeichnet wird,
geht es darum, mittels eines Peilers einen Transmitter zu finden.</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>Sender mit Regenschutz.
Die Antenne ist nicht Teil des Bildes, ragt aber etwa 5 Meter in die Höhe.</p>
</figcaption>
</figure>
</div><p>Nach dem Mittagessen brachen zwei Amateurfunker
auf, um zwei Sender mit Rundstrahlenantennen in der Gegend zu verstecken.</p>
<p>Die Sender arbeiten im 3.1MHz-Band und senden den Morsecode "-- ---" ("MO").
Da es für die meisten Kollegen eine neue Erfahrung war, haben wir die Spaß-Variante
gewählt, in der die Transmitter ihr Rufzeichen dauerhaft auf
unterschiedlichen Frequenzen gesendet haben.
In der sportlichen Variante der Fuchsjagd senden die Transmitter ihr
Rufzeichen nur alle paar Minuten; dafür aber auf derselben Frequenz.</p>
<p>Nach einer kurzen Einführung in die Funktionsweise und die bevorstehende
Aufgabe wurden sechs Gruppen ausgelost, die mit einem Peiler ausgerüstet
auf die Jagd gehen durften.</p>
<p>Die Peiler sind tragbare Empfänger, die sowohl über die elektrische als
auch die magnetische Komponente des Feldes Signale empfangen.
Durch Beobachtung der Lautstärke des Signals kann die Richtung, aus der dieses
kommt, ermittelt werden.</p>
<p>Damit die ganze Gruppe in der Lage war, den Morsecode zu hören, wurden anstelle
der üblichen Kopfhörer kleine Lautsprecher an die Peiler angeschlossen.</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>Der erste Sender wurde in der Nähe eines leicht zu erreichenden Parkplatzes
platziert und war zum Warmwerden gedacht.
Der zweite hingegen führte zu einem "Lost Place", dem <a class="reference external" href="http://www.koenigsberg-sanatorium.de/">Königsberg Sanatorium</a>, das vor einigen Jahren
niedergebrannt ist. Der Weg bot uns zudem einen tollen Blick auf die nahegelegene
<a class="reference external" href="https://de.wikipedia.org/wiki/Granetalsperre">Granetalsperre</a>.</p>
</div>
<div class="section" id="infrastruktur-review">
<h3>Infrastruktur 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>Unser "Arbeitsraum"</p>
</figcaption>
</figure>
</div><p>Es erfordert besondere Maßnahmen, 28 Hacker auch unterwegs arbeitsfähig und
glücklich zu machen. Dies beinhaltet vor allem eine ausreichend
bandbreitenstarke Internetverbindung.
Für die Embedded-Entwicklung sind darüber hinaus lokale TFTP- und NFS-Server
notwendig.
Das bedeutet, dass wir alles in allem weit über 100 IP-Adressen,
viele Ethernet-Ports und WiFi-Konnektivität benötigen.</p>
<p>Für die Bereitstellung der Infrastruktur hatten wir Unterstützung durch die
<a class="reference external" href="https://freifunk-bs.de">Freifunk-Initiative aus Braunschweig</a>.
Praktischerweise gibt es personelle Überschneidungen, so dass uns die
Kollegen dieses Jahr mit einem dreifach-redundanten Uplink ins Internet
versorgt haben und gleichzeitig eine gute Gelegenheit hatten, ihr Equipment
und die dazugehörige Software unter extremen Bedingungen zu testen.</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>Ein zufälliger Switch vom Freifunk Braunschweig.</p>
</figcaption>
</figure>
</div><p>Der redundante Uplink besteht aus drei einzelnen Wireguard-Tunneln,
die auf einem externen Server enden.
Mittels OSPF wird der tatsächliche Verkehr ins Internet geleitet, so dass
ein Plug-and-Play neuer Uplinks problemlos möglich ist.</p>
<p>Für die Verbindung haben wir zwei LTE-Uplinks (von unterschiedlichen Providern)
und die DSL-Anbindung des Tagungshauses genutzt.
Bereits nach einigen Stunden haben wir uns entschieden, den DSL-Uplink wieder zu
kappen: 6000 kBit/s DSL sind heute einfach nicht mehr ausreichend.</p>
<p>Insgesamt haben wir während der Woche 170 GB Daten durch das LTE geschoben.
Dabei sollte man bedenken, dass der Standard-Mobilfunkvertrag deutscher
Telekommunikationsunternehmen weniger als 10 GB Datenvolumen pro Monat zur
Verfügung stellt.</p>
</div>
</div>
<p>An einem weit entfernten Ort, fernab vom Tagesgeschäft, haben sich die
Mitarbeiter von Pengutronix zur jährlichen Technologiewoche getroffen.</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.htmlTagebuch: Chemnitzer Linux Tage 20192019-03-16T00:00:00+01:00Chris FiegeRobert Schwebel<div class="section" id="tagebuch-chemnitzer-linux-tage-2019">
<p>In diesem Artikel schreiben wir unser Tagebuch von den Chemnitzer Linux Tagen
2019. Wir laden euch herzlich ein, uns an unserem Stand zu besuchen.
In diesem Jahr haben wir bei uns ausserdem das
<a class="reference external" href="https://www.osadl.org/">OSADL</a> zu Gast.</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="managementwerkzeuge-aus-der-open-source-entwicklung">
<h3>Managementwerkzeuge aus der Open-Source-Entwicklung</h3>
<p>Für uns beginnen die CLT 2019 Samstag früh um 10:00 Uhr mit dem
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/180">Vortrag von Marie</a>.
Marie berichtet dabei darüber, wie wir unser Prozesshandbuch von einer
Wiki-basierten Lösung auf eine Hacker-freundliche Lösung umgestellt haben.</p>
<p>Marie stellt anschließend die Anforderungen vor, die wir uns im Vorfeld
an das neue Prozesshandbuch gestellt haben:</p>
<ul class="simple">
<li>Benutzbarkeit</li>
<li>Teilhabe der Mitarbeit</li>
<li>Freigabe durch die Geschäftsführung</li>
<li>Aktualität der Prozesse</li>
<li>Mögliche ISO 9001 Zertifizierung</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>Als Linux-Dienstleister sind bei uns <cite>Hacker-Tools</cite> bei vielen Mitarbeitern
gut etabliert. Daher möchten wir diese Werkzeuge auch für das Prozesshandbuch
einsetzen. Das bedeutet:</p>
<ul class="simple">
<li>Prozesse werden als <cite>Restructured Text</cite> erstellt.</li>
<li>Metadaten der Prozesse sind Teil der Textdateien.</li>
<li>Zur Verwaltung der Plaintext-Dateien kommt git zum Einsatz.</li>
<li>Durch den Einsatz von Sphinx können die Prozesse in eine Webseite überführt
werden und sind damit auch für die Mitarbeiter lesbar, für die Textdateien
und git nicht das <cite>täglich Brot</cite> sind.</li>
</ul>
<p>Im Vortrag geht es anschließend darum, wie unser Git-Workflow für die Bearbeitung
des Prozesshandbuches aussieht:</p>
<ul class="simple">
<li>Es gibt einen <cite>Master-Branch</cite>, auf den nur die Geschäftsführung schreiben
darf.</li>
<li>Mitarbeiter dürfen daneben eigene <cite>Topic-Branches</cite> haben, in denen sie
bestehende Prozesse verbessern oder neue Prozesse entwerfen dürfen.</li>
<li>Die Geschäftsführung reviewt die Prozesse, bevor diese in den Master-Branch
übernommen werden.</li>
</ul>
<p>Im nächten Abschnitt von Maries Vortrag geht es darum, wie wir mit
<cite>Continuous Integration</cite> die Text-Dateien ständig bei Änderungen neu bauen
und intern veröffentlichen.
Dafür setzen wir Jenkins ein, um den Master Branch zu überwachen, bei
Änderungen neu zu bauen und im Intranet neu zu veröffentlichen.</p>
<p>Am Ende bleibt zusammenfassend zu sagen:
Wichtig ist, dass das Prozessmanagement zu den Mitarbeitern passt, die es
später auch benutzen sollen.
Für Pengutronix sind das git, Sphinx und Jenkins.
Marie möchte aber die Entscheider motivieren, sich die Workflows und
Werkzeuge der Mitarbeiter anzusehen - und auch den Mut zu haben, die für die
eigenen Mitarbeiter passenden Werkzeuge zu wählen.</p>
</div>
<div class="section" id="container-kram">
<h3>Container Kram</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>Weiter geht es um 12:00 Uhr mit
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/314">Martin Neitzel</a>.
Im Programm wurde sein Vortrag noch als <cite>Linux-Container Grundlagen</cite> angekündigt;
aber nachdem seine einzelne Folie mit <cite>Container Kram</cite> überschrieben war
und die ersten Gummibärchen als Belohnung ins Publikum geworfen wurden, war klar:
dieser Vortrag wird unterhaltsam.</p>
<p>Martins Ansatz ist nicht einfach nur, eine fertige Lösung wie Docker oder LXC
zu verwenden.
Vielmehr hat er sich die Low-Level APIs angesehen.
Und so startet der Vortrag auch mit Details zu <cite>unshare</cite> und <cite>setns</cite>.</p>
<p>Im zweiten Teil zeigt Martin, wie sich mit <cite>systemd-nspawn</cite>
einfach Container auf einem System starten lassen.</p>
</div>
<div class="section" id="vortragsaufzeichnung-bei-den-clt-mit-ki">
<h3>Vortragsaufzeichnung bei den CLT mit KI</h3>
<p>Den Abschluss des Tages hat
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/343">Daniel Schreiber</a>
mit seinem Vortrag über Vortragsaufzeichnung bei den CLT.</p>
<p>Bisher wurden bei den Vorträgen nur die Folien via HDMI-Grabber und
der Ton von der Anlage im Raum aufgezeichnet.
Allerdings gab es keine Videoaufzeichnung der Vortragenden.
Das liegt hauptsächlich daran, dass die CLT nicht das Personal haben,
jeden Raum mit einem Helfer an der Kamera auszustatten.</p>
<p>Im letzten Jahr hat Daniel daher, um eine Datenbasis für automatisierte
Verarbeitung zu schaffen, einen Raum mitfilmen wollen.
Natürlich hatte er dabei einige Probleme mit der Aufzeichnung.
Am Ende hatte er aber eine Datenbasis, auf der er Software entwickeln konnte.</p>
<p>Zum Verarbeiten der Videodaten setzt er <a class="reference external" href="https://opencv.org/">OpenCV</a> ein.
Als ersten Ansatz hat Daniel versucht, das Gesicht der Vortragenden in den
Videos zu erkennen.
Die Ergebnisse waren dabei allerdings mäßig.
Im nächsten Schritt hat Daniel versucht, den Vortragenden zu <cite>tracken</cite>.
Die Ergebnisse waren allerdings wieder mäßig - der Tracker ließ sich zu
leicht ablenken.</p>
<p>Daniel hat sich daher dem Hype der neuronalen Netze hingegeben.
Natürlich hat sich daraus ein ganzes Bündel neuer Probleme ergeben:
Anders geordnete Farbkanäle, unterschiedliche Wertebereiche, fehlende
Rechenleistung, sinnvolle Vorverarbeitung und viele mehr...</p>
<p>Letztlich kann er aber mit viel Rechenleistung und Interpolation
(über Bereiche hinweg, in denen die Netze kein Ergebnis geliefert haben)
den Speaker verfolgen und das Video des Speakers herausschneiden.</p>
<p>Daniel setzt die neue Technik dieses Jahr bereits ein:
Es gibt neue Aufzeichnungsracks mit zwei HDMI-Grabbern,
beide Grabber zeichnen den Raumton auf (sodass der auf jeden Fall lippensynchron
ist), und 4k-Kameras in allen Räumen.
Wir können uns daher für dieses Jahr
auf automatisch nachgeführte Bildausschnitte der Vortragenden der
Chemnitzer Linux Tage freuen.</p>
</div>
<div class="section" id="ansible-module-schreiben">
<h3>Ansible-Module schreiben</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>Am Sonntag beginnen die Vorträge für mich erst um 11:00 Uhr.
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/290">Martin Schütte</a>
gibt eine
<a class="reference external" href="https://noti.st/mschuett/WEGXSS/writing-ansible-modules">Einführung</a>
in das Schreiben von
<a class="reference external" href="https://docs.ansible.com/ansible/latest/modules/modules_by_category.html">Ansible-Modulen</a>.
Sein Poll am Anfang des Vortrags zeigt: Das Publikum besteht zur Hälfte
aus Systemadministratoren und zur Hälfte aus Softwareentwicklern.</p>
<p>Martin beginnt seinen Vortrag mit dem Hinweis, dass man sich gut überlegen
sollte, ob man wirklich selber Code schreiben muss oder ob man
das Ziel nicht auch mit Ansible-Boardmitteln erreichen kann.
Er gibt anhand von Code-Beispielen einen Überblick
über den Aufbau eines Ansible-Moduls.
Anschließend gibt er Entwurfsmuster, sowie <cite>dos</cite> und <cite>dont's</cite> für die
Entwicklung von Ansible-Modulen.</p>
</div>
<div class="section" id="licht-ins-dunkel-bringen">
<h3>Licht ins Dunkel bringen</h3>
<p>Ab 12:00 Uhr ging es mit
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/242">Alexander Schreiber</a>
und seinem Vortrag <cite>Licht ins Dunkel bringen – Prometheus & Grafana</cite> weiter.
Alexander beginnt seinen Vortrag mit einer Menge an Dingen, die Monitoring
für ihn herausfinden können soll.
Dazu gehören verschiedene Metriken, die
überwacht werden können, sowie ein sinnvolles <cite>Alerting</cite>
("Damit erfährt man davon, bevor der Chef anruft.").</p>
<p>Anschließend stellt er die Geschichte und die Architektur von
<a class="reference external" href="https://prometheus.io/">Prometheus</a> vor.</p>
</div>
<div class="section" id="gdb-mit-python-scripten">
<h3>GDB mit Python Scripten</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 aus unserem Grafikteam zeigt ebenfalls um 12:00 Uhr, wie
er die Herausforderungen beim Debuggen komplexer
GStreamer-Videopipelines meistert. Leider sind diese Pipelines sehr
komplex und gleichzeitig dynamisch, so dass ständig neue Threads
entstehen, Dinge tun und wieder verschwinden. Bleibt dann beim
Processing etwas hängen oder verhält sich unerwartet, schaut man mit GDB
oft nur auf sehr kompliziert zusammenhängende Datenstrukturen. Das
führte in der Vergangenheit oft dazu, dass das Debugging sehr aufwändig
war.</p>
<p>Inzwischen bietet GDB eine Schnittstelle, mit der es sich mittels
kleiner Python-Module erweitern lässt. Michael zeigt in seinem Vortrag,
wie man eigene <cite>pretty printer</cite> schreibt und aus komplexen
Datenstrukturen übersichtliche Informationen erzeugt; da der Python Code
Zugriff auf alle verketteten Strukturen hat, kann man auch Beziehungen
zwischen den Komponenten ermitteln und die 'richtigen' Elemente
herausfischen und visualisieren. Weitere Hilfsmittel sind
selbstgeschriebene Kommandos und Funktionen.</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>In bewährter Weise moderiert Wolfram Sang das Kernel-Panel, bei dem auch
unser Kollege Lucas Stach aus dem Grafikteam, Maintainer des Etnaviv
3D-Grafiktreibers im Mainline Kernel, mit auf dem Podium sitzt. Die
Runde beantwortet spannende Fragen aus dem Publikum. Aus unserer Sicht
eine spannende Beobachtung: inzwischen ist es offenbar für Embedded
Nutzer einfacher, aktuelle Mainline-Kernel einzusetzen als für die
etablierten Enterprise-Distributionen: Der sehr stark eingeschränkte
Usecase auf eingebetteten Geräten macht es möglich, Systeme relativ vollständig zu
testen und schnell mit neuem Kernel auszurollen; diesen Luxus haben die
Distributoren nicht, da sie in der Regel nicht wissen, was ihre Partner
und die Kunden letztlich mit dem System machen - so sammeln sich dann
auch bis zu unglaubliche 40.000 Patche auf den Enterprise-Kerneln, was
wiederum ganz neue Qualitätsfragen aufwirft. Weitere Themen sind der
zunehmende Trend zu mehr teils proprietärer Firmware in modernen
Prozessoren und der aktuelle Stand zu Spectre und Meltdown.</p>
</div>
<div class="section" id="der-rest-von-sonntag">
<h3>Der Rest von Sonntag</h3>
<p>Den Rest des Tages haben wir mit spannenden Diskussionen an unserem und
anderen Ständen verbracht und die <cite>Chemnitzer Catering Tage</cite> genossen.
Wir möchten uns hier noch einmal bei allen Organisatoren, Helfern, Vortragenden,
Ausstellenden und Besuchern bedanken.
Wir wissen aus eigener Erfahrung, was für eine harte Arbeit es ist, so eine
Veranstaltung auf die Beine zu stellen.
Um so mehr sind wir begeistert, wie reibungslos und gut organisiert alles
abgelaufen ist.
Es hat uns wieder viel Spaß gemacht, bei den CLT zu sein, Bekannte zu treffen und
neue Bekanntschaften zu machen.
Wenn es irgendwie in den Zeitplan passt, sind wir nächstes Jahr gern wieder dabei.</p>
</div>
<div class="section" id="weitere-eindrucke-von-den-clt-2019">
<h3>Weitere Eindrücke von den CLT 2019</h3>
<p>Hier folgen einge weitere Eindrücke von heute, die leider zu keiner Überschrift
gepasst haben, aber es dennoch wert sind, geteilt zu werden:</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 diesem Artikel schreiben wir unser Tagebuch von den Chemnitzer Linux Tagen
2019. Wir laden euch herzlich ein, uns an unserem Stand zu besuchen.
In diesem Jahr haben wir bei uns ausserdem das
<a class="reference external" href="https://www.osadl.org/">OSADL</a> zu Gast.</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.htmlChemnitzer Linux Tage 20192019-03-04T00:00:00+01:00Chris Fiege<div class="section" id="chemnitzer-linux-tage-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>In bewährter Manier unterstützen wir auch in diesem Jahr die
<a class="reference external" href="https://chemnitzer.linux-tage.de/">Chemnitzer Linux Tage</a>
wieder sowohl als Sponsor als auch durch unsere zahlreiche
Anwesenheit.</p>
<p>Wir werden mit einem Team von 15 Mitarbeitern vor Ort sein, um den vielen
spannenden
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm">Vorträgen</a>
zu lauschen und angenehme Gespräche in der lockeren Atmosphäre der Chemnitzer
Linux Tage zu führen.</p>
<p>Auch in diesem Jahr sind wir mit einem
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/programm/beitrag/135">Stand</a>
vertreten, um mit Euch über die aktuellen interessanten Themen unserer Arbeit an
diversen Open Source Projekten aus dem Bereich <em>Embedded Linux</em> zu diskutieren.</p>
<p>Wie immer haben wir auch ein paar spannende Demos dabei; in diesem Jahr zeigen
wir:</p>
<ul class="simple">
<li>Ausfallsichere Over-The-Air Updates von Geräten mit unserem <a class="reference external" href="https://rauc.io">RAUC</a>-Demonstrator.</li>
<li>Automatisiertes Unit-Testen in Python auf Hardware mit dem neuen <a class="reference external" href="https://labgrid.org">labgrid</a>-Demonstrator.</li>
</ul>
<p>Natürlich haben wir auch wieder unsere beliebten Pengutronix-Bleistifte und
Pinguin-Aufkleber sowie Informationen und Aufkleber zu unseren Projekten,
<cite>barebox</cite>, <cite>labgrid</cite>, <cite>PTXdist</cite> und <cite>RAUC</cite> dabei.</p>
<p>Wir freuen uns, dass zwei unserer Kollegen in diesem Jahr mit einem Vortrag
auf den CLT vertreten sind:</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">Unsere Vorträge bei den CLT 2019</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Wann</td>
<td>Raum V4</td>
<td>Raum 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>So,
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>Wir freuen uns, Euch auf den Chemnitzer Linux-Tagen zu treffen!</p>
<p>PS:
Eine persönliche Anmerkung von mir:
Allen, die sich das Programm lieber auf dem Handy ansehen, empfehle ich
die Android-App <a class="reference external" href="https://f-droid.org/de/packages/net.gaast.giggity/">Giggity</a>.
Die App kann den gesamten Plan als
<a class="reference external" href="https://chemnitzer.linux-tage.de/2019/de/api/ical/programm">iCal</a>
importieren und anzeigen.
Um den Link zum Programm einfach in die App zu bekommen, kann man folgenden
QR-Code direkt aus Giggity scannen:</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>In bewährter Manier unterstützen wir auch in diesem Jahr die
<a class="reference external" href="https://chemnitzer.linux-tage.de/">Chemnitzer Linux Tage</a>
wieder sowohl als Sponsor als auch durch unsere zahlreiche
Anwesenheit.</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/de/blog/2018-10-22-elce-2018-day-one.html">ELCE</a>,
<a href="https://www.pengutronix.de/de/blog/2018-08-28-froscon.html">FroSCon</a>,
<a href="https://www.pengutronix.de/de/blog/2018-11-19-xdc-2018.html">XDC</a>,
<a href="https://www.pengutronix.de/de/blog/2018-03-06-clt-2018.html">CLT</a>,
<a href="https://www.pengutronix.de/de/blog/2018-02-12-fosdem-2018.html">FOSDEM</a> or
<a href="https://www.pengutronix.de/de/blog/2018-05-18-ripe76.html">RIPE</a>
and developed new ideas and strategies at
<a href="https://www.pengutronix.de/de/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 auf der FOSDEM 20182018-02-12T00:00:00+01:00Enrico Jörns<div class="section" id="pengutronix-auf-der-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>Wie auch in den vergangenen Jahren ist auch dieses Jahr wieder eine Horde
Pengutronix-Entwickler zur alljährlichen Open-Source-Konferenz FOSDEM nach
Brüssel gefahren, um sich dort über die aktuellen Entwicklungen in den Bereichen
Embedded Linux, Graphik und Multimedia, Elektronik und anderen interessanten
Bereichen zu informieren.</p>
<p>Mit seinem Vortrag <a class="reference external" href="https://fosdem.org/2018/schedule/event/updating_complex_systems/">Facing the Challenges of Updating Complex Systems</a>
warf Pengutronix-Entwickler Enrico Jörns einen Blick auf die Update-Thematik
fernab der grundlegenden Überlegungen über Redundanz, Atomizität, einfache
Verifikation und klassische A/B-Setups, die glücklicherweise von den heutigen
Open-Source-Update-Frameworks wie <a class="reference external" href="https://rauc.io">RAUC</a> größtenteils
gelöst sind.</p>
<p>Stattdessen hat er herausgestellt, dass das Design eines robusten
Update-Systems nicht durch das Zusammenstecken loser Komponenten gelöst werden
kann, sondern einer abgestimmten Konfiguration der einzelnen
Systemkomponenten vom Bootloader bis hin zur Deployment-Software bedarf, damit
diese reibungslos miteinander interagieren.</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>Während das reine Updaten heute durch Standard-Frameworks gelöst ist,
besteht die Bootquellenauswahl im Bootloader oftmals immer noch aus
fehleranfälligen Skripten.
Mit <a class="reference external" href="https://barebox.org/doc/latest/user/bootchooser.html">bootchooser</a>
hat Pengutronix dafür ein Framework in den Barebox-Bootloader gebracht, was
Barebox zu einem idealen Kandidaten für das Design redundanter Systeme macht.
Dazu bemerkte Enrico auch, dass mit UEFI Bootvariablen-Handling auf x86 ein
ähnlicher Standard-Mechanismus zur Verfügung steht.</p>
<p>Eines der weiteren interessanten Themen, die er in seinem Vortrag angesprochen
hat, ist der potentielle Vorteil der Benutzung des Content-Chunking-Tools
<a class="reference external" href="https://github.com/systemd/casync">casync</a> für das Updaten eingebetteter
Systeme über limitierte Datenverbindungen.
Damit lassen sich Chunks der Updates, die zwischen altem und neuem System
identisch sind, lokal wiederverwenden und nur solche, die sich unterscheiden,
müssen über die Netzwerkverbindung geholt werden.
Casync wird zukünftig auch
<a class="reference external" href="https://github.com/rauc/rauc/pull/217">in RAUC unterstützt</a> werden.</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>Dank des FOSDEM-Teams von
<a class="reference external" href="https://www.openembedded.org/wiki/Main_Page">OpenEmbedded</a> konnten wir
unseren Demonstrator für Over-The-Air-Updates mitbringen und ihren Stand damit
bereichern.
Für uns war das eine großartige Gelegenheit, mit Hackern aller Interessensfelder
über Themen wie reproduzierbare Builds von Embedded-Systemen und die eng damit
verbundene Notwendigkeit sicherer und robuster Update-Strategien im Kontext
einer immer größeren Verbreitung von eingebetteten und IoT-Systemen sprechen.</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>Neben unseren altbekannten und kultigen schwarzen Bleistiften haben sich auch
unsere neuen Pengutronix Pinguin-Sticker sowie Projekt- und Job-Visitenkarten,
die gerade rechtzeitig zur FOSDEM fertig geworden sind, großer Beliebtheit erfreut.</p>
<p>Vielen Dank an das gesamte FOSDEM-Team für Organisation, Unterstützung und
Video-Aufnahmen!</p>
</div>
<p>Wie auch in den vergangenen Jahren ist auch dieses Jahr wieder eine Horde
Pengutronix-Entwickler zur alljährlichen Open-Source-Konferenz FOSDEM nach
Brüssel gefahren, um sich dort über die aktuellen Entwicklungen in den Bereichen
Embedded Linux, Graphik und Multimedia, Elektronik und anderen interessanten
Bereichen zu informieren.</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 Release2017-11-09T15:00:00+01:00Enrico Jörns<div class="section" id="rauc-v0-2-release">
<div class="ptx-sidebar">
<div class="title">
Download
<div class="corner"></div>
</div>
<div class="body">
<p>Download RAUC Version <a class="reference external" href="http://rauc.io/pages/download.html">v0.2</a></p>
</div>
</div>
<p>Eine neue Version des RAUC Update Frameworks steht bereit.</p>
<p>Seit Version v0.1.1 wurden 171 Änderungen eingebracht; die bearbeiteten
Themen betreffen ebenso eine verbesserte Usability und Stabilität wie
auch neue Features und neue Usecases.</p>
<p>Die folgende Liste gibt einen Überblick über die wichtigsten Änderungen
in diesem Release:</p>
<ul>
<li><p class="first">Für Benutzer des Kommandozeileninterfaces stellt das Tool nun eine
Fortschrittsanzeige zur Verfügung; weiterhin wurde das Error-Reporting
verbessert, was eine einfachere Fehlersuche ermöglicht.</p>
</li>
<li><p class="first">Der Installationsvorgang wurde nun von der Aktivierung eines Updates
getrennt. Damit wird es auch möglich, zunächst ein Update auf alle
Devices auszurollen und dieses zu einem späteren Zeitpunkt
synchronisiert zu aktivieren.</p>
<p>Für diesen Mechanismus stehen nun die System-Konfigurationsoption
<tt class="docutils literal"><span class="pre">activate-installed</span></tt> und die neue D-Bus Methode <tt class="docutils literal">mark</tt> sowie das
neue Kommando <tt class="docutils literal">rauc status <span class="pre">mark-active</span></tt> bereit.</p>
<p>Mit diesen Änderungen ist es weiterhin möglich, mittels der RAUC
Bootloader Abstraktion zu Testzwecken das zu bootende Target zu
ändern.</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>Anzeige von Zertifikaten mittels <tt class="docutils literal">rauc info</tt></p>
</figcaption>
</figure>
</div><ul>
<li><p class="first">Beim Handling von Zertifikaten war in der Vergangenheit nicht direkt
ersichtlich, ob Updates korrekt signiert waren.</p>
<p>Das RAUC Commandline Tool stellt nun neue Möglichkeiten für den Umgang
mit Zertifikaten zur Verfügung:</p>
<ul>
<li><p class="first">Das neue <tt class="docutils literal"><span class="pre">--keyring</span></tt> Argument erlaubt die direkte Definition eines
Keyrings zu Testzwecken, ohne dass die system.conf geändert werden
müsste. Damit können insbesondere Bundles auf dem Build Host
untersucht werden.</p>
</li>
<li><p class="first">In der Ausgabe von <tt class="docutils literal">rauc info</tt> wird nun die Trustchain (mit subject,
issuer und berechneter
<a class="reference external" href="https://tools.ietf.org/html/rfc7469#section-2.4">SPKI (SubjectPublicKeyInfo)</a> hash)
angezeigt, mit der das untersuchte Bundle erfolgreich verifiziert
wurde.</p>
<p>Mittels des ebenfalls neuen <tt class="docutils literal"><span class="pre">--dump-cert</span></tt> Arguments wird das
vollständige Signer-Zertifikat des Bundles angezeigt.</p>
</li>
</ul>
</li>
<li><p class="first">Neben diesen verbesserten Debug-Möglichkeiten gibt es eine weitere
Verbesserung im Zusammenhang mit Zertifikaten: das neue <tt class="docutils literal">rauc
resign</tt> Kommando, mit dessen Hilfe Bundles neu signiert werden
können.</p>
<p>Dieses Werkzeug ist hilfreich, wenn ein im Test befindliches Bundle
nach einem erfolgreich absolvierten Test für den Produnktionseinsatz
neu signiert werden soll, ohne dass sich dessen Inhalt ändert.</p>
<p>Mittels RAUC resign ist es möglich, Bundles auf dem Build Host zu
verifizieren, dann die Signatur zu entfernen und eine Signatur, die
mit einem komplett anderen Key erzeugt wurde, hinzuzufügen.</p>
</li>
<li><p class="first">Nicht zuletzt wurde die Dokumentation stark verbessert, hierzu siehe
auch <a class="reference external" href="https://www.pengutronix.de/de/blog/2017-10-10-rauc_documentation_update.html">diesen Blog Post</a>.</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>Die neuen RAUC Karten und Aufkleber von der ELC-E</p>
</figcaption>
</figure>
</div><p>Eine ausführliche Liste der Änderungen (speziell auch der Bugfixes), die
im v0.2 Release enthalten sind, kann dem <a class="reference external" href="https://github.com/rauc/rauc/blob/master/CHANGES">CHANGES</a> File entnommen
werden.</p>
<p>Für das nächste Release gibt es bereits eine Liste mit neu geplanten
Features, unter anderem ein umfangreiches Status-File für
Slot-Checksummen und Metadaten, Support für Intermediate Certificates in
Bundles sowie <a class="reference external" href="https://github.com/systemd/casync">casync</a> basiertes
Streaming.</p>
</div>
<p>Eine neue Version des RAUC Update Frameworks steht bereit.</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 - Tag 32017-10-25T12:01:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-tag-3">
<p>Tag 3 der Embedded Linux Conference Europe 2017 in Prag ist vorbei, wir
haben alle unsere Vorträge erfolgreich hinter uns gebracht, neue
Community-Kontakte geknüpft und alte erneuert. Hier ist mein Bericht.</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>Am dritten Tag der ELC-E hatte mein Kollege Marc Kleine-Budde die zweite
Gelegenheit, über OP-TEE und die sichere Speicherung in der Trustzone zu
berichten. Auch diesmal war der Saal gut gefüllt, so dass sich die
Wiederholung des Vortrags gelohnt hat.</p>
<p>Das "Trusted Execution Environment" (TEE) ist eine kleine, isolierte
Umgebung für sensitiven Code+Daten. Dabei soll im TEE nur wenig Code
laufen, die Hauptfunktionalität des Systems übernimmt weiterhin das
"normale" Linux. Auf ARM kann ein TEE mit Hilfe der Trustzone realisiert
werden, d.h. der Code läuft zwar auf dem gleichen Prozessor, aber in
einer hardwareseitig abgesicherten Betriebsart, der "Secure World". Der
einzige Weg von der Normal World in die Secure World geht über den
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>Die Hardware stellt dabei sicher, dass z.B. auf bestimmten Speicher nur
in der Secure World zugegriffen werden kann. Ebenso kann auf bestimmte
Register nur in der Secure World zugegriffen werden. Auf ARMv7 wird der
Secure Monitor in OP-TEE implementiert, bei ARMv8 ist er Teil der
Trusted Firmware. Beim Booten geht das System zunächst in den Secure
State.</p>
<p>OP-TEE wurde zunächst proprietär implementiert und in 2015 unter der BSD
Lizenz freigegeben. Seit 4.12 ist die Kernel-Seite, die Global Platform
API, in Mainline, zur Zeit existieren ca. 20 Portierungen. Das OP-TEE
Mini-Betriebssystem selbst besteht aus dem TEE Core, einer internen API
und den 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>Auf i.MX6 wird der Bootvorgang mittels HABv4 abgesichert, OP-TEE wird in
den Bootloader (in unserem Fall barebox) integriert und im Bootablauf
ausgeführt. Barebox prüft dann die Signatur des Kernels
(FIT-Image) und startet den Rest des Systems. Der OP-TEE Code läuft dann
während der Lebensdauer des Systems weiter und wird im Fall eines
Secure Monitor Calls angesprungen. Die bisherigen Erkenntnisse wurden
im Rahmen eines Prototyps auf der Pengutronix TechWeek 2017 gewonnen;
für die Zukunft wäre es hilfreich, wenn OP-TEE an die Key Storage API in
Linux angebunden würde, damit man die Trustzone zum sicheren Speichern
von Keys nutzen kann.</p>
<p>In der Diskussion wurde auf verschiedene Sicherheitsprobleme
hingewiesen; es stellt sich heraus, dass Security komplex ist und es
keine Garantien gibt. Allgemein wird begrüßt, wenn mehr Leute OP-TEE
benutzen und die Codebase damit mehr Testing, Fuzzing usw. bekommt.</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>Nach der Mittagspause berichtete mein Kollege Lucas Stach über
Maßnahmen, die ABI Stabilität von Open Firmware Devicetrees
sicherzustellen. Eine Motivation für das Thema ist, dass wir bei
Pengutronix Embedded Linux Systeme basierend auf dem Mainline Kernel
entwickeln und dabei eine offensive Upstream-Strategie verfolgen; das
bedeutet, dass produktive Systeme über lange Zeit mit neuen Kerneln
ausgestattet werden.</p>
<p>Während der Kernel schon lange seine Initialisierung aus dem Devicetree
vornimmt, greifen zunehmend auch Bootloader (barebox, U-Boot) oder
Secure World Firmware auf die Informationen aus dem Devicetree zu.
Einige Devicetree Properties sind gut eingeführt (z.B. Memory Nodes),
aber es gibt diverse Peripheriegeräte, für die sich die Bindings über
die Zeit ändern müssen. Insofern ist es kein gangbarer Weg, davon
auszugehen, dass sich die Definition des Devicetrees über lange
Zeiträume überhaupt nicht ändert.</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>Die Erkenntnisse, die vorgestellt wurden, stammen aus der Maintenance
der i.MX Plattform und basieren auf den Erfahrungen, die dort in den
letzten Jahren gemacht wurden. Der erste Schritt zur Definition eines
stabilen Bindings ist der Blick ins Datenblatt einer Komponente: Alle
Hardware-Eigenschaften müssen im Binding beschrieben werden - speziell
nicht nur die, die im eigenen Design benutzt werden. Dann ist es
wichtig, dass die verpflichtenden Compatibles von Tag eins an stabil
gehalten werden müssen - man kann sie später nicht mehr ändern. Wenn man
mit neuen Hardware-Blocks zu tun hat, sollte man neue Compatibles
nutzen: Beispielsweise hat der SPI Core auf dem MX6 ULL das Compatible
"fsl,imx6ul-ecspi, fsl,imx51-ecspi". Der Treiber schaut nur auf den
letzten Teil, kann aber im Fall von Abweichungen anhand des ersten
herausfinden, dass es sich um neuere Hardware handelt. Sollten
tatsächlich Modifikationen notwendig werden, sollte man diese im Kernel
und nicht im Devicetree vornehmen.</p>
<p>Als Fazit hat sich herausgestellt, dass eigentlich nur relativ wenige
Regeln zu befolgen sind, um eine stabile Devicetree ABI zu realisieren.
Die Diskussion war engagiert und zeigte, dass das das Thema komplex ist.</p>
</div>
<div class="section" id="swupdate">
<h3>swupdate</h3>
<p>Stefano Babic berichtete in meinem nächsten Vortrag über das swupdate
Projekt; ich fand es interessant, zu sehen, wie andere Entwickler die
Herausforderungen angehen, die wir bei Pengutronix mit RAUC umsetzen.</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>Zu Beginn folgte eine Einführung zu Update-Usecases, vom USB Stick bis
zu Netzwerk-basierten Updates. swupdate kann ebenso wie RAUC hawkBit als
Updateserver benutzen. Ebenfalls möglich ist es, ein sicheres Fallback
auf ein immer vorhandenes System zu machen. Auch andere Anforderungen
wie Atomarität oder das ausschließliche Ausrollen von getesteten
Firmwaren sind letztlich für jedes Update-System gleich.</p>
<p>swupdate gibt es seit 2014, es steht unter der GPLv2/LGPLv2 Lizenz und
hat inzwischen etliche Entwickler gefunden. Das System hat ein lokales
Interface, kann als Bibliothek in Applikationen eingebunden werden und
setzt eine Reihe von OTA Update Varianten um. Es gibt Yocto- und
Buildroot-Integration, Support für U-Boot und Grub sowie ein CPIO
basiertes Format für die Updates. Für verschiedene Backend-Store Devices
gibt es jeweils Handler, und swupdate lässt sich in LUA scripten.
Boot-Counter sind im Zusammenhang mit U-Boot realisiert. Auf der Agenda
stehen noch Bootloader Fallback, File Updater, ein Progress-Interface
und Streaming-Updates.</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>Im letzten Vortrag aus unserem Team stellten Michael Tretter und Philipp
Zabel ihre Erfahrungen rund um bandbreitenschonendes Videostreaming vor.
Generell geht es darum, mit einem SoC Video vom Sensor zu übernehmen, zu
prozessieren, über einen Kommunikationsweg zu übertragen, zu empfangen
und anzuzeigen. Dabei gilt es, die hohen Verarbeitungsanforderungen mit
stromsparenden Embedded Prozessoren zu verbinden.</p>
<p>Viele Einheiten auf den SoCs brauchen die Daten in speziellen
Farbformaten: Kameras liefern für gewöhnlich Bayer-Pattern, die
Encoder/Decoder benötigen ein YUV-Format, wohingegen 3D-Einheiten
getiledte Formate benötigen. Dazwischen gilt es zu vermitteln, ohne
jedoch unnötige Kopien der Daten anzufertigen und damit Bus-Bandbreite zu
verschwenden.</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>Für die 3D Einheiten, die für geometrische Korrekturen (z.B.
Linsenentzerrung) verwendet werden, wird das Etnaviv Projekt eingesetzt;
die Patche dafür sind inzwischen in MESA und Linux Mainline enthalten.
Die Ausgabe-Seite wird mit dem imx-drm Treiber bedient, die
Encoder/Decoder Treiber (coda) sind ebenfalls im Kernel enthalten.</p>
<p>Der Schlüssel zum Weiterreichen von Puffern zwischen den
Hardware-Geräten ist "dmabuf": Mit diesem Mechanismus ist es möglich,
vom Userspace aus ein Handle auf einen Puffer zwischen verschiedenen
Kernel-Treibern weiterzureichen, ohne die Daten kopieren zu müssen. Da
der Userspace nur den Handle hat, muss man damit keine Adressen mehr in
den Userspace exponieren; weiterhin behält der Kernel die Lebensdauer
der Puffer vollständig unter Kontrolle.</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>Nachdem einige v4l2- und EGL-Beispiele gezeigt wurden (die durchaus
<em>nicht</em> einfach aussehen), zeigten die Referenten den Einsatz von
GStreamer. Damit sind die Beispiele zwar immer noch nicht einfach, man
sieht aber nicht mehr so viel davon, wenn man lediglich Applikationen
schreibt. Für komplexere Szenarien, in denen auf der Ausgabeseite
Compositing zwischen Video und z.B. graphischen Oberflächen benötigt
wird, kommt Wayland ins Spiel. Die resultierenden GStreamer-Pipelines
sehen nun endlich in der Tat einfach aus.</p>
<p>Leider ist eine Kamera-Input-Pipeline weiterhin komplex und muss über
media-ctl konfiguriert werden; hier wird zur Zeit noch Arbeit
investiert, um sinnvolle Defaults zu ermitteln. Auf der Weston-Seite
gibt es schon Patche für atomares Mode-Settings, die noch nicht in
Mainline gelandet sind.</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>Tag 3 der Embedded Linux Conference Europe 2017 in Prag ist vorbei, wir
haben alle unsere Vorträge erfolgreich hinter uns gebracht, neue
Community-Kontakte geknüpft und alte erneuert. Hier ist mein Bericht.</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 - Tag 22017-10-24T11:00:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-tag-2">
<p>Der zweite Tag der Embedded Linux Conference Europe ist vorbei, und hier
ist mein Bericht.</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 berichtete im ersten Vortrag, den ich am Dienstag
Vormittag gehört habe, über den aktuellen Stand des OSADL SIL2LinuxMP
Projekts. Dabei geht es um die Frage, ob sich ein Linux-basiertes System
für den Einsatz in sicherheitskritischen Systemen, wie sie für das
autonome Fahren benötigt werden, eignet. Letztlich geht es um die Frage,
im Sinne der IEC61501 "unakzeptable Risiken" in einem System
auszuschließen.</p>
<p>Um die Anforderungen von SIL2 zu erfüllen, gibt es mehrere
Architektur-Möglichkeiten:</p>
<ul class="simple">
<li>Check des Outputs eines Systems mit einer kleinen Safety Hardware</li>
<li>Safety Hypervisor</li>
<li>Benutzung des Linux Kernels zur Isolierung von kritischem und nicht
kritischem Teil</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>Im dritten Ansatz muss ein Teil des Linux-Kernels zertifiziert werden;
dies ist die Variante, die im Projekt untersucht wird. Die
Herausforderungen sind groß: So gilt es, einen Prozess zu finden, um
einen Kernel mit 23 Millionen Lines of Code und einem
Community-Entwicklungsprozess zu qualifizieren. Der Referent berichtete,
dass, wenn er diesen Vortrag in der Sicherheitscommunity hält, die
Hälfte des Publikums den Saal verlässt...</p>
<p>Eines der größten konzeptionellen Probleme ist, dass Safety-Software
üblicherweise vor dem Hintergrund eines Safety-Prozesses entwickelt
wird. Da dies für Linux nicht der Fall ist, werden die Prozesse mit den
von den Normen vorgegebenen Prozessen verglichen und mögliche Lücken
durch eigene Maßnahmen geschlossen. Dabei werden z.B. für Syscalls wie
open() alle möglichen Varianten im System auf ihre Safety-Auswirkungen
untersucht ("Hazard Driven Decomposition, Design & Development").
Weiterhin wird ein eigenes, nach dieser Methode designtes
Init-Replacement entwickelt.</p>
<p>Neben den architekturellen Fragen werden git Commits auf bestimmte
Faktoren untersucht. Der "patch impact tester" untersucht, auf welche
Konfigurationen ein Patch Einfluss hat. Weiterhin wird ein minimales
Kernel-Subset untersucht. Eine (durchaus fragwürdige) Annahme ist, dass
bei einem Longterm-Kernel die Anzahl der gefundenen Fehler über die Zeit
zurückgeht (es bleibt die Frage, ob dies nicht auch dadurch kommen
kann, dass sich einfach niemand in der Community mehr für alte Kernel
interessiert); das Safety-Projekt setzt somit bevorzugt besonders späte
Longterm Kernel ein. Auf der positiven Seite wird ein Satz an
Analyse-Tools entwickelt, die auch für die allgemeine Verbesserung der
Kernel-Qualität benutzt werden können.</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>Der zweite Vortrag behandelte die "Civil Infrastructure Platform" (CIP).
Die CIP ist als Basis-Betriebssystem-Infrastruktur für Komponenten wie
Züge, Ticketingsysteme, Energieverteilung, Industriesteuerungen,
Gebäudeautomatisierung und Medizintechnik gedacht. Allen diesen Systemen
ist gemein, dass sie sehr lange im Markt gepflegt und mit
Sicherheitsupdates ausgestattet werden müssen; beispielsweise gibt es
Zug-Beeinflussungssysteme, die 50 Jahre alt sind. Solche Systeme
brauchen typischerweise allein mehrere Jahre, bis sie alle Entwicklungs-
und Zertifizierungsschritte hinter sich gelassen haben. Die Idee ist,
einen Super-Longterm-Kernel (4.4) und andere Komponenten wie ein Debian
für mehr als 10 Jahre zu pflegen.</p>
<p>Der Vortrag hat meine Bedenken darüber, dass das CIP einen grundlegend
falschen Weg verfolgt, nicht zerstreut. Einer der Vorteile von Linux
ist, dass (halbwegs) moderne Kernel viel Testabdeckung und
Community-Feedback und damit auch Bugfixing bekommen, während es für so
alte Kernel, wie sie CIP nutzen möchte, nahezu niemanden mehr gibt, der
sie testet und nachpflegt. Zudem bedeuten Kundenanforderungen in
Industrie-Projekten oft, dass neue Features benötigt werden, die in so
einem Setup mit viel Aufwand backgeportet werden müssen, was nach kurzer
Zeit nicht mehr handhabbar ist. Der einzig praktikable Weg, solche
Systeme über lange Zeit zu pflegen, ist, mittels Update-Systemen die
Devices pflegbar zu halten und konstant mit soliden, noch vom Upstream
gepflegten Kerneln zu versehen (siehe dazu Jan Lübbe's Vortrag <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> von der 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>Nach der Mittagspause berichtete Ben Dooks darüber, wie er mit Hilfe von
Open Source herausgefunden hat, was die 1,2 kg Masse in seinem Kopf tut.
Während viele Methoden der Visualisierung des Gehirns weiterhin aus
Kostengründen nicht in Reichweite von Amateuren sind, gibt es in letzter
Zeit z.B. Datenbanken mit anonymisierten Messdaten, die unter einer
Creative Commons Lizenz stehen.</p>
<p>Eine weitere Möglichkeit der Informationsgewinnung ist, die elektrische
Kommunikation zwischen Neuronen mittels EEG (Elektroenzephalographie) zu
messen. Die interessanten Spannungen liegen im Bereich weniger µVolt,
die Meßfrequenzen bei 1-100 Hz, und das Verfahren birgt keine bekannten
gefährlichen Nebeneffekte. Es gibt einen Kickstarter-finanzierten Open
Source Sensor (<a class="reference external" href="https://openbci.com">OpenBCI</a>) mit 16 Kanälen, der mittels
eines 3D Druckers hergestellt oder gekauft werden kann. Mit dem Setup
können Gehirnwellen aufgezeichnet und Regionen im Gehirn zugeordnet
werden. Daneben stehen andere Devices im Open Source Kontext bereit
(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>Eine andere Metode, die Magnetoenzephalographie (MEG), nutzt
Magnetfelder im 10 fT Bereich zur Messung. Die Methode kann bessere
Bilder erzeugen, ist allerdings sehr rauschanfällig. Ben hat an einem
Gerät mitgearbeitet, das dieses Messverfahren nutzt. Das
Steuerungssystem besteht aus mehreren Knoten, die die Daten mit bis zu
600 Kanälen bei 24 Bit Auflösung erfassen, speichern und in Echtzeit
anzeigen. Das System basiert auf Debian, die Daten werden im HDF5 Format
gespeichert und mit OpenGL und Python (NumPY, Arrow, HSPy) verarbeitet,
während die Synchronisation der Messungen im FPGA stattfindet. Auch auf
der FPGA-Seite wurde versucht, möglichst offene IP-Cores zu verwenden.
Leider sind auf der FPGA-Seite weiterhin kaum offene Tools zu bekommen,
zumindest nicht für die eingesetzte Hardware.</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 berichtete über Sicherheitsfeatures auf NAND Chips,
ein Thema, was uns ebenfalls immer wieder umtreibt. Nach einer kurzen
Einführung der verfügbaren Verschlüsselungsverfahren in Linux wurden
diese darauf hin untersucht, welche sich für den Betrieb auf "nackten"
NAND Flashes eignen.</p>
<p>Eine interessante Option ist fscrypt, ein Nachfolger von eCryptFS.
Verschlüsselung ist direkt im Filesystem implementiert (in fs/crypto).
Für jeden Knoten kann im Dateisystem eine Policy für den
darunterliegenden Tree festgelegt werden; Die Keys werden dabei mittels
des In-Kernel Keystores verwaltet. Dateien, für die der Benutzer keinen
gültigen Schlüssel hat, werden im Directory mit einem Base 64 String
angezeigt. Die Tools sind noch in Bearbeitung, werden aber in Kürze zur
Verfügung stehen. Der Versuch, fscrypt auf UBIFS zu portieren, stellte
sich als eine größere Herausforderung heraus. Inzwischen ist das Feature
unter dem Konfig-Symbol CONFIG_UBIFS_FS_ENCRYPTION im Kernel verfügbar.</p>
<p>Neben Verschlüsselung ist ein zweites interessantes Feature, die
Integrität des Dateisystems sicherzustellen. Hierfür gibt es die
Integrity Measurement Architecture, IMA. Zur Zeit ist dieser Part
allerdings noch nicht implementiert; die Frage, wie die beste Variante
für eine Implementierung ausehen könnte, wird derzeit diskutiert. Eine
Idee könnte sein, dass die Keys aus fscrypt wiederverwertet werden und
nur der Index-Tree mit einer eigenen HMAC Summe gesichert wird. Hier
sind aber noch weitere Untersuchungen nötig.</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>Im letzten Dienstags-Track berichtete Sebastian Siewior über den Stand
des RT Preempt Patches. Das Linux Foundation Collaborative Project läuft
nun seit Oktober 2015, und die Patch-Kurven zeigen, dass zu Zeiten von
3.10-rt mehr oder weniger eine konstante Anzahl Patche vorhanden waren
und kaum Fortschritte erzielt werden konnten. In 3.14-rt und 3.18-rt
zeigen die Kurven ebenfalls nur sehr wenig Bewegung in der
Patch-Statistik. Erst ab 4.4-rt zeigen die Kurven eine deutliche
Bewegung, in dem Maße, in dem mehr und mehr Features angefasst wurden.
Insofern zeigt offenbar die Tatsache, dass zunächst von OSADL und nun im
Rahmen der Linux-Foundation die Arbeit an RT finanziert wird und nicht
mehr nur ein Hobby-Projekt ist, Wirkung.</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>Seit 4.9 wurde intensiv an CPU Hotplug gearbeitet, dann wurde mit 4.11
das Timer Wheel überarbeitet. Aktuelle Baustellen wurden kurz skizziert,
aber nicht weiter vertieft. Zur Zeit veröffentlichen die Entwickler
einen RT-Patch für jeden zweiten Kernel und versuchen dabei, die LTS
Kernel zu treffen.</p>
<p>Der Fortschritt beim RT-Projekt ist für mich weiterhin schwer
einzuschätzen. Ein kurzer Blick in den aktuellen Patch zeigt viele
Backports aus Upstream und weiterhin viele kleine alte Patche, bei denen
von außen nicht wirklich erkennbar ist, warum sie nicht längst
gemainlinet wurden. Viele andere Patche sind eher im Bereich "Tooling"
angesiedelt und gehören nicht zur Kernfunktionalität. Während der Status
der Patches früher noch im series File vermerkt war, fehlt diese
Information inzwischen; allerdings bin ich der Entwicklung in letzter
Zeit auch nicht mehr intensiv gefolgt, so dass sie anderswo zu finden
sein mag.</p>
</div>
<div class="section" id="showcase">
<h3>Showcase</h3>
<p>Im Showcase hat unser Team diesmal drei Open Source Projekte gezeigt,
die zur Zeit eine große Rolle in unserer Arbeit spielen:</p>
<ul class="simple">
<li>Etnaviv (Open Source GPU Treiber für i.MX6)</li>
<li>Labgrid (Testautomatisierung)</li>
<li>RAUC (Field Upgrading)</li>
</ul>
<p>Hierzu gab es viele interessante Gespräche.</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 und Enrico Jörns zeigen labgrid und 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>Besucheransturm</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 von Embedded Linux Updates mit RAUC und 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 ist jetzt in Mainline von Kernel, MESA und
Wayland/Weston</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 mit 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 Diskussionen</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 Diskussionen</p>
</figcaption>
</figure>
</div><div style="clear: both"></div></div>
</div>
<p>Der zweite Tag der Embedded Linux Conference Europe ist vorbei, und hier
ist mein Bericht.</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 - Tag 12017-10-23T15:08:00+01:00Robert Schwebel<div class="section" id="rsc-s-diary-elc-e-2017-tag-1">
<p>Hier ist mein Bericht vom ersten Tag der Embedded Linux Conference
Europe (ELC-E) 2017 in Prag.</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>Im ersten Vortragsslot um 09:00 Uhr hatte ich eigentlich vor, den
Vortrag "OP-TEE - Using Trust Zone to Protect Our Own Secrets" meines
Kollegen Marc Kleine-Budde anzuhören, aber der Vortrag war so restlos
überlaufen, dass kein Platz mehr zu bekommen war. Somit startete der Tag
mit einer ausführlicheren Kaffeepause... Offenbar waren noch mehr
Teilnehmer enttäuscht, den Vortrag verpasst zu haben, so dass es am
Mittwoch einen weiteren Zeitslot geben wird.</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>Im zweiten Vortrag berichtete Satish Chetty über "Linux Powered
Autonomous Arctic Buoys".</p>
<p>Der Referent betreibt einen Satz dieser von
ihm selbstgebauten Sensorträger in Alaska und berichtete über die
Erfahrungen, die man so macht, wenn man eine Embedded Linux / ARM
basierte Plattform bei Temperaturen von bis zu -40 °C betreibt. Die
Geräte werden genutzt, um die Vorgänge beim Abschmelzen des Eises im
Sommer zu untersuchen.</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>Eines der wichtigsten Themen war, mit dem Mess-System so viel Strom wie
möglich zu sparen; so wird immer jeweils ein Mess-Zyklus gefahren, dann
wird das Device ausgeschaltet und von einem Microcontroller Stunden
später für den Beginn des nächsten Zyklusses wieder aufgeweckt.</p>
<p>Als Batterien haben sich überraschenderweise normale Handy-Akkupacks als
vorteilhaft erwiesen, da diese auch von ungeschultem Personal leicht in
der Forschungsstation aufgeladen und selbst unter widrigen Bedingungen
hinreichend gut getauscht werden können. Andere Probleme jedoch, wie
Kabelbiss durch Polarfüchse oder Eisbären, die sich auf den Sensorträger
setzen, sind weiterhin ungelöst.</p>
</div>
<div class="section" id="agl">
<h3>AGL</h3>
<p>Der nächste Vortrag von Walt Miner gab einen Einblick in das Automotive
Grade Linux Projekt der Linux-Foundation. Der Vortrag war allerdings
sehr high-level gehalten und ging nicht auf technische Details ein, so
dass als Message vor allem hängengeblieben ist, dass der Referent die in
der Automotive-Industrie mit Linux befassten Entwickler zur
Zusammenarbeit aufruft.</p>
</div>
<div class="section" id="r4d">
<h3>r4d</h3>
<p>Im letzten Slot vor der Mittagspause gaben Anna-Maria Gleixner und
Manuel Traut einen Einblick in ihre Erfahrungen, Jenkins und libvirt zu
nutzen, um ihr Testlabor für das Testen der Preempt-RT Kernel zu nutzen.
Viele der Anforderungen, die im Vortrag angesprochen wurden, sind sehr
ähnlich zu denen, die uns bei unseren eigenen Aktivitäten zu labgrid
geleitet haben.</p>
<p>Leider scheinen wir uns auch im Bereich Testautomatisierung wieder in
einer Phase zu befinden, wo viele Protagonisten gleichzeitig versuchen,
sehr ähnliche Lösungen zu finden und ihre eigenen Projekte starten.</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>Dieser Eindruck verfestigte sich auch in der BoF Session "Farming
Together" von Andrew Murray nach der Mittagspause: Viele der Anwesenden
im Raum betreiben Testfarmen, aber kaum jemand benutzt die gleiche
Technik. Im oberen Bereich des Stacks scheinen sich Jenkins und LAVA
durchgesetzt zu haben (was sich mit unseren eigenen Erfahrungen deckt -
Pengutronix nutzt ebenfalls Jenkins für das automatische Bauen und LAVA
als Infrastruktur für unser kernelci.org Testlabor).</p>
<p>Tim Bird regte an, dass die Teilnehmer eine Mailingliste und eine
Wiki-Seite einrichten; letzere wurde noch in der BoF Session auf
<a class="reference external" href="https://elinux.org/Board_Farm">elinux.org</a> angelegt; dort werden
weiterhin Kontaktdaten von Interessenten gesammelt.</p>
</div>
<div class="section" id="kernel-process">
<h3>Kernel Process</h3>
<p>Die "Bash the Kernel Maintainers" BoF von Laurent Pinchart griff das
altbekannte Thema auf, dass es manchmal schwierig sein kann,
Kernel-Maintainer dazu zu bekommen, gewisse Patche zu akzeptieren. Ein
Problem ist, dass man manchmal selbst für kleine Patche einfach keine
Rückmeldung bekommt und dies erst Monate später mitbekommt, wenn der
Patch eben nicht aufgenommen wurde ("Black Hole Problem"). Vor allem
kleinere Consulter stehen vor dem Problem, dass sie während eines
Projekts Patche einschicken, später dann aber längst mit einem anderen
Thema befasst sind, wenn das Feedback eintrifft, und manchmal nicht mal
mehr Zugriff auf die Hardware haben. Hans Verkuil machte den Vorschlag,
dass man solche Infos gern auf den Mailinglisten ansprechen soll, damit
die Maintainer Bescheid wissen.</p>
<p>Fazit: "politely pinging" und immer wieder den Kontakt Suchen sind die
Schlüssel dazu, dass diese Probleme gelöst werden können.</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>Ein weiteres Highlight für das Pengutronix-Team war der Vortrag
"Automation beyond Testing and Embedded System Validation" von Jan
Lübbe. Der Hintergrund der Testaktivitäten ist, dass Pengutronix für
Kundenprojekte ständig eine größere Menge Open Source Komponenten
integriert, die sich ständig ändern. Da das Updaten und Ausrollen von
Updates nicht ohne intensives Testen funktioniert, ist es Zeit für mehr
Automatisierung in diesem Bereich. Dabei war wichtig, dass die gleiche
Fernsteuertechnik sowohl für automatische Tests wie auch für das
interaktive Arbeiten an den Boards (die als Prototypen oft nur in
wenigen Stückzahlen existieren) genutzt werden kann.</p>
<p>Weitere Features, die mit existierenden Frameworks nicht abgedeckt
werden konnten, sind das Testen von Updates (inkl. Booten der Devices
während des Tests) oder das gleichzeitige Fernsteuern mehrerer Geräte
(Video-Streaming Box + Empfänger). Jan gab einen kurzen Überblick über
die zur Zeit verfügbaren Testframeworks und erklärte, warum diese leider
nicht die Anforderungen erfüllen, die sich in unseren Projekten zeigen.</p>
<p>labgrid bietet eine Python-basierte Infrastruktur, in der
Fernsteuer-Geräte wie Powerschalter und USB-Seriell-Wandler mittels
Treibern abstrahiert werden. Ein wichtiges Feature sind die sogenannten
"strategies": Mit diesen kann man ein System anweisen, in einen
bestimmten State zu gehen (z.B. auf die Linux-Konsole); wenn nötig, wird
das System dabei hinter den Kulissen auch mittels der Fernsteuertechnik
gebootet oder mit Software versehen. Die eigentlichen Tests werden in
pytest geschrieben, der Output wird als JUnit XML erzeugt und kann z.B.
von Jenkins direkt angezeigt werden.</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>Für ein Lab, das verteilt an mehreren Rechnern angeschlossen ist,
übernimmt der labgrid Concentrator die Koordination der verfügbaren
Ressourcen.</p>
<p>Neben dem eigentlichen Testen kann labgrid auch bei der Produktion von
Embedded Systemen helfen und am Bandende die komplette Firmware auf das
Device schreiben und das Ergebnis testen.</p>
<p>Zum Schluss des Vortrags zeigte eine Demo, wie man mit labgrid das
Updaten eines Systems mittels RAUC mit einem simulierten System im QEmu
testen kann.</p>
</div>
</div>
<p>Hier ist mein Bericht vom ersten Tag der Embedded Linux Conference
Europe (ELC-E) 2017 in Prag.</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>Auf der <a class="reference external" href="https://all-systems-go.io">All Systems Go</a> Konferenz in
Berlin berichtete Michael Olbrich am 22.10.2017 über die Erfahrungen
unseres Integration Teams, unter dem Titel "Updating Embedded Systems -
Putting it all together".</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">Vortragsvideo bei media.ccc.de</a></p>
</figcaption>
</figure>
</div><p>Während noch vor ein paar Jahren Embedded Geräte fast nie geupdatet
wurden, sorgen die vielen IoT Security Vorfälle in letzter Zeit dafür,
dass das Thema Updating zunehmend auf der Agenda der Hersteller
erscheint. Viele Embedded Linux Systeme folgen dabei einem "A/B" Schema,
d.h. ein System-Slot ist aktuell gebootet, während ein zweiter geupdatet
wird; mit diesem Mechanismus kann ein Update "atomar" durchgeführt
werden, d.h. selbst eine Fehlfunktion führt nicht dazu, dass das System
nicht mehr bootfähig ist.</p>
<p>Wie funktioniert der Update-Vorgang? Neben dem eigentlichen
Schreibvorgang des Images, der mehr oder weniger generisch ablaufen
kann, muss die Integrität des Images auf mögliche Fehler geprüft werden.
Bei interaktiven Geräten kann z.B. der Benutzer (lokal oder remote
hinter einem Rollout-Server) informiert werden, dass im Fehlerfall auf
eine alte Version zurückgeschaltet wird. Schwieriger wird es bei nicht
interaktiven Geräten: hier kann z.B. der Watchdog genutzt werden, um den
Startvorgang zu überwachen; dabei wird im Userspace systemd als
Watchdog-Handler genutzt. Allerdings müssen im Gegensatz zum
Desktop-Usecase Maßnahmen ergriffen werden, damit <a class="reference external" href="https://www.freedesktop.org/wiki/Software/systemd/">systemd</a> den erfolgreichen
Start des Systems inklusive seiner Applikationen korrekt überwachen
kann:</p>
<ul class="simple">
<li>Das System kann im Fehlerfall versuchen, neu zu booten. Dabei können
die Reboot-Vorgänge vom Bootloader (meist <a class="reference external" href="http://www.barebox.org">barebox</a>) mitgezählt werden und es kann bei
Überschreiten einer Anzahl von Versuchen ein Fallback auf das alte
System vorgenommen werden.</li>
<li>Bei transienten Fehlern kann dieser Vorgang in einer Loop durchgeführt
werden.</li>
<li>Bei kritischeren Systemen kann das System im Fehlerfall aus
Sicherheitsgründen heruntergefahren werden.</li>
</ul>
<p>Welche Variante bei einem konkreten Gerät umgesetzt wird, ist oft
projektspezifisch.</p>
<p>Für das Schreiben der Updates und die Verwaltung der Slots ist <a class="reference external" href="http://www.rauc.io">RAUC</a> ein mächtiges Werkzeug, das neben der Prüfung
von Signaturen auch die Synchronisation (z.B. mittels <a class="reference external" href="https://github.com/systemd/casync">casync</a>) vornehmen kann.</p>
</div>
<p>Auf der <a class="reference external" href="https://all-systems-go.io">All Systems Go</a> Konferenz in
Berlin berichtete Michael Olbrich am 22.10.2017 über die Erfahrungen
unseres Integration Teams, unter dem Titel "Updating Embedded Systems -
Putting it all together".</p>2017-10-22T00:00:00+01:00tag:www.pengutronix.de,2017-10-21:/2017-10-21-all_systems_go.htmlVortragsankündigung zur All Systems Go 20172017-10-21T00:00:00+01:00Robert Schwebel<div class="section" id="vortragsankundigung-zur-all-systems-go-2017">
<p>Noch vor der ELC-E Konferenz in Prag findet an diesem Wochenende die
<a class="reference external" href="https://all-systems-go.io">All Systems Go</a>, Nachfolger der systemd
conference, in Berlin statt. Das Thema "Embedded Systeme sicher und
zuverlässig updaten" spielt gerade vor dem Hintergrund stetig mehr
werdender IT Sicherheitsvorfälle eine große Rolle; der Vortrag gibt
einen Überblick über die Herausforderungen und Lösungsmöglichkeiten für
einen robusten Update-Prozess.</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>Übliche System-Update-Mechanismen aus der IT Welt lassen sich schwer auf
Embedded- und IoT Geräte übertragen, da es dort für gewöhnlich keinen
Administrator gibt. Somit müssen die Embedded Systeme erheblich mehr
Mechanismen mitbringen, die sicherstellen, dass Updates niemals
fehlschlagen können.</p>
<p>Unsere aktuellen Update-Konzepte nutzen viele Teile des Linux
Systembaukastens, z.B. <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> und <a class="reference external" href="https://github.com/systemd/casync">casync</a>.</p>
<p>Mehr zum Vortrag findet sich im <a class="reference external" href="https://cfp.all-systems-go.io/en/ASG2017/public/events/133">Konferenz-Programm</a>,
erfahrungsgemäß gibt es Livestreams auf <a class="reference external" href="https://media.ccc.de/b/conferences">media.ccc.de</a>.</p>
</div>
<p>Noch vor der ELC-E Konferenz in Prag findet an diesem Wochenende die
<a class="reference external" href="https://all-systems-go.io">All Systems Go</a>, Nachfolger der systemd
conference, in Berlin statt. Das Thema "Embedded Systeme sicher und
zuverlässig updaten" spielt gerade vor dem Hintergrund stetig mehr
werdender IT Sicherheitsvorfälle eine große Rolle; der Vortrag gibt
einen Überblick über die Herausforderungen und Lösungsmöglichkeiten für
einen robusten Update-Prozess.</p>2017-10-21T00:00:00+01:00tag:www.pengutronix.de,2017-10-20:/2017-10-20-elce_talks.htmlPengutronix Vorträge auf der ELC-E Prag2017-10-20T00:00:00+01:00Robert Schwebel<div class="section" id="pengutronix-vortrage-auf-der-elc-e-prag">
<p>Das Embedded Linux Konferenz-Highlight im Herbst ist die Embedded Linux
Conference Europe (ELC-E), die in diesem Jahr vom 23.-25.10.2017 in Prag
stattfindet. Das Pengutronix Team ist mit vier Vorträgen und zwei
Demo-Points/Showcases zu aktuellen Open Source Projekten (RAUC, labgrid,
etnaviv) vertreten.</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>Die ersten beiden Vorträge finden am Montag, den 23.10.2017 statt:</p>
<ul class="simple">
<li><strong>OP-TEE: Using Trust Zone to Protect Your Own Secrets:</strong> Um 09:00
berichtet Marc Kleine-Budde über OP-TEE: seit Linux 4.12 wurde die
Infrastruktur in den Kernel aufgenommen, mit der man das Trusted
Execution Environment auf modernen ARM-Prozessoren mit Open Source
Komponenten zum (möglicherweise) sicheren Speichern geheimer
Informationen verwenden kann.</li>
<li><strong>Automation Beyond Testing and Embedded Systems Validation:</strong> Um
17:10 trägt Jan Lübbe über die Fortschritte bei der Automatisierung
von Continuous Testing Szenarien und über das labgrid
Testautomatisierungs-Werkzeug vor.</li>
</ul>
<p>Weitere zwei Vorträge finden am Mittwoch, dem 25.10.2017 statt:</p>
<ul class="simple">
<li><strong>Stable Device Tree ABI: It's Possible:</strong> Um 14:15 berichtet Lucas
Stach darüber, wie die ABI Stabilität von Devicetrees über lange Zeit
stabil gehalten werden kann.</li>
<li><strong>Zerocopy Video Streaming the Easy Way:</strong> Um 16:15 schließlich zeigen
Philipp Zabel und Michael Tretter, wie mittels Zerocopy Mechanismen
die Bandbreite von modernen ARM Prozessoren beim Video-Streamen
geschont werden kann.</li>
</ul>
<p>Am Dienstag, dem 24.10.2017 zeigen wir im Rahmen des Technical Showcase
verschiedene Open Source Projekte, die bei unseren Aktivitäten eine
Rolle spielen:</p>
<ul class="simple">
<li>Etnaviv, die Open Source Treiber für die 3D Grafikhardware auf i.MX6</li>
<li>RAUC: Robust Auto Upgrade Controller</li>
<li>labgrid: Testautomatisierung für Continuous Testing von Embedded Linux
Systemen</li>
</ul>
</div>
<p>Das Embedded Linux Konferenz-Highlight im Herbst ist die Embedded Linux
Conference Europe (ELC-E), die in diesem Jahr vom 23.-25.10.2017 in Prag
stattfindet. Das Pengutronix Team ist mit vier Vorträgen und zwei
Demo-Points/Showcases zu aktuellen Open Source Projekten (RAUC, labgrid,
etnaviv) vertreten.</p>2017-10-20T00:00:00+01:00tag:www.pengutronix.de,2017-10-10:/2017-10-10-rauc_documentation_update.htmlUmfassendes RAUC Dokumentations-Update2017-10-10T00:00:00+01:00Enrico Jörns<div class="section" id="umfassendes-rauc-dokumentations-update">
<p>Wie in vielen Projekten, ist auch bei RAUC an vielen Stellen nach massiver
Entwicklung meist nicht mehr ausreichend Zeit geblieben, die Änderungen, neuen
Features und grundlegenden Konzepte angemessen aufbereitet in der Dokumentation
unterzubringen und zu erklären.</p>
<div class="ptx-sidebar">
<div class="title">
Statistik
<div class="corner"></div>
</div>
<div class="body">
<table border="1" class="docutils">
<colgroup>
<col width="35%"/>
<col width="31%"/>
<col width="35%"/>
</colgroup>
<thead valign="bottom">
<tr><th class="head"> </th>
<th class="head">Vorher</th>
<th class="head">Nachher</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>Zeilen</td>
<td>2135</td>
<td>3522</td>
</tr>
<tr><td>Wörter</td>
<td>9275</td>
<td>16805</td>
</tr>
<tr><td>Zeichen</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>Damit fallen nicht nur nützliche und sinnvolle Features unter den Tisch,
sondern es häufen sich auch Nachfragen und Missverständnisse, die mit einer
guten Dokumentation von vornherein hätten ausgeräumt werden können.</p>
<p>Daher hat Pengutronix eine gesamte Woche lang
den virtuellen Zettel und Stift in die Hand genommen, um die
<a class="reference external" href="https://rauc.readthedocs.io/en/latest/">Dokumentation</a>
von RAUC an vielen Stellen grundlegend umzukrempeln und zu erweitern.</p>
<p>Das Ergebnis kann sich durchaus sehen lassen, wenn man allein auf die
quantitative Auswirkung schaut.
Nach Anzahl Zeichen hat sich der Umfang der Dokumentation um knapp 80%
vergrößert.</p>
<p>Die Struktur und der Inhalt der einleitenden Kapitel, welche grundlegende
Konzepte und Ideen hinter RAUC für den Benutzer in einer Übersicht darstellen sollen,
wurden komplett überarbeitet und um viele Aspekte ergänzt.
Darüber hinaus wurden einige Themenkomplexe mit anschaulichen Grafiken
untermalt.</p>
<p>Mit dem neu geschaffenen Kapitel
<a class="reference external" href="http://rauc.readthedocs.io/en/latest/scenarios.html">Scenarios</a>
wird auf einige der am häufigsten verwendeten Redundanz-Setups eingegangen
und an Konfigurations-Beispielen gezeigt, wie sie in RAUC realisiert werden
können.</p>
<p>Technisch deutlich detaillierter wurden auch die wichtigen Kapitel zur
Integration von Barebox und U-Boot ausgeführt.</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>Komplett neu hinzugekommen sind auch eine ganze Reihe weiterführender Themen
wie Umgang mit Sicherheit, Erzeugung und Behandlung von Zertifikaten,
Applikationsdaten-Behandlung und -Migration, Bootloader-Updates oder Software
Deployment.</p>
<p>Auch wenn es robuste Frameworks wie RAUC gibt, zur Entwicklung eines
individuell passenden und soliden Update-Konzeptes gehören viel Know-How und
Sorgfalt bei der Zusammenstellung und Konfiguration des Gesamtsystems.
Von der Auswahl des Bootloaders über das Aufsetzen und die Behandlung des
Watchdogs bis hin zur Detektierung eines erfolgreich gebooteten Userspace
müssen diverse Komponenten eng ineinandergreifen.</p>
<p>Mit der neu eingeführten
<a class="reference external" href="http://rauc.readthedocs.io/en/latest/checklist.html">Design Checklist</a>
haben wir daher einen grundlegenden Laufzettel erarbeitet, der (ohne Anspruch
auf Vollständigkeit) vielen generellen Fallstricken beim Design und bei der
Realisierung von Update-Konzepten zuvorkommen soll.</p>
</div>
<p>Wie in vielen Projekten, ist auch bei RAUC an vielen Stellen nach massiver
Entwicklung meist nicht mehr ausreichend Zeit geblieben, die Änderungen, neuen
Features und grundlegenden Konzepte angemessen aufbereitet in der Dokumentation
unterzubringen und zu erklären.</p>2017-10-10T00:00:00+01:00tag:www.pengutronix.de,2017-09-29:/2017-09-29-ptx_ypp.htmlPengutronix wird Yocto Project Participant2017-09-29T00:00:00+01:00Enrico Jörns<div class="section" id="pengutronix-wird-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>Nicht zuletzt da das Yocto Projekt aus der Embedded-Welt schon seit
längerem nicht mehr weg zu denken ist,
setzt auch Pengutronix bereits seit einigen Jahren neben PTXdist in diversen
Projekten auch OpenEmbedded erfolgreich als Distributions-Buildtool ein.</p>
<p>Dabei stehen wir seither in möglichst enger Verbindung zu der mittlerweile
breit gestreuten Community.
Sei es durch Teilnahme an Konferenzen wie der OEDEM,
diversen BoFs bei der Embedded Linux Conference Europe oder durch Diskussion
und Contributions auf den diversen Mailinglisten.</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>Mit <a class="reference external" href="https://github.com/rauc/meta-rauc">meta-rauc</a>,
dem Yocto Layer für das OpenSource Update Framework <a class="reference external" href="http://rauc.io/">RAUC</a>,
pflegt Pengutronix seit längerer Zeit in enger Zusamenarbeit mit der Community
eine der Schlüsselstellen für moderne und sichere Embedded-Systeme.</p>
<p>Wir freuen uns, dass nun mit der offiziellen Listung als
<a class="reference external" href="https://www.yoctoproject.org/organization/pengutronix">Yocto-Project Participant</a>
unsere Beiträge zur Yocto- und Embedded-Community sichtbar gewürdigt werden und
nehmen dies als weiteren Ansporn auch in Zukunft die Reproduzierbarkeit,
Stabilität und Sicherheit in der Enwicklung von Embedded-System durch robuste
Build Tools wie PTXdist oder OpenEmbedded mit voran zu bringen.</p>
</div>
<p>Nicht zuletzt da das Yocto Projekt aus der Embedded-Welt schon seit
längerem nicht mehr weg zu denken ist,
setzt auch Pengutronix bereits seit einigen Jahren neben PTXdist in diversen
Projekten auch OpenEmbedded erfolgreich als Distributions-Buildtool ein.</p>2017-09-29T00:00:00+01:00tag:www.pengutronix.de,2017-09-28:/2017-09-28-etnaviv.htmlEtnaviv-Unterstützung in Wayland Mainline2017-09-28T00:00:00+01:00Lucas Stach<div class="section" id="etnaviv-unterstutzung-in-wayland-mainline">
<p>Wenn man der Entwicklung des Linux Grafikstacks folgt, konnte man in den
letzten Wochen die Releases von MESA 17.2 und Weston 3.0 beobachten.
Neben den üblichen Verbesserungen und Bugfixes für diverse
Grafik-Hardware stellen diese aber auch einen wichtigen Meilenstein für
das Etnaviv Projekt dar: mit diesen Releases gibt es vollständigen
Support für Vivante-Grafikchips in Wayland!</p>
<div class="embed-responsive embed-responsive-16by9">
<iframe class="embed-responsive-item" src="https://www.youtube-nocookie.com/embed/dq6AXAMreos"></iframe>
</div>
<p>Für Etnaviv als ein Hardware Treiber in MESA standen Standard-Features
wie GBM und die Wayland EGL Plattform ohne weiteres seit der Aufnahme in
MESA zur Verfügung; allerdings konnten normale Wayland-Applikationen
zunächst noch nicht fehlerfrei genutzt werden: zwar starteten sie,
zeigten jedoch noch kein sinnvolles Bild an. Der Grund für dieses
Verhalten war das Tiled Memory Layout, das die GPU für Texturing und
Rendering verwendet. <a class="reference external" href="https://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-swizzling/">Im hier verlinkten Artikel befindet sich eine
schöne Erklärung der Details</a>.</p>
<p>Da dieses Verhalten ein gängiges Szenario beim 3D Rendern auf allen
modernen GPUs ist, stellte sich die Frage, warum der Mechanismus auf
Etnaviv zunächst nicht funktionierte. Es stellte sich heraus, dass die
alten Protokolle zum Sharen von Grafik-Puffern zwischen einer
Applikation und dem Compositor/Server, etwa DRI2 und wl_dru, einen
Mechanismus besaßen, um Metadaten wie das verwendete Tiling Layout mit
dem Buffer zu übertragen. Alle existierende Treiber wie Radeon, Noveau
und Intel benutzten hingegen Side-Channels, um die Informationen
zwischen den verschiedenen Prozessen auszutauschen. Diese Treiber hängen
die Metadaten an die kernelseitigen Grafikpuffer, was so lange gut
funktioniert, wie es ein direktes 1:1 Verhältnis zwischen Userspace- und
Kernelseite gibt. Allerdings entwickeln sich moderne Grafiksysteme wie
Vulcan zunehmend in eine Richtung, bei der der Inhalt eines
kernelseitigen Puffers mehreren Userspace-Puffern zugeordnet ist. Für
diese Vorgehensweise funktioniert die Zuordnung der Metadaten auf die
bislang gewählte Weise nicht mehr.</p>
<p>Daneben ergäbe sich aus dem alten Konzept eine breitere API zwischen der
Kernelseite von Etnaviv und dem Userspace Treiber, die aus
Kompatibilitätsgründen für alle Zeiten von Linux unterstützt werden
müsste. Deshalb wurde entschieden, diesen Weg mit Etnaviv nicht zu
beschreiten und das bereits von Intel und Collabora begonnene Verfahren
zu implementieren, bei dem die Tiling-Informationen vollständig im
Userspace geshared werden. Dabei werden sogenannte "modifiers"
verwendet, bei denen es sich um 64 Bit Enums handelt. Der Kernel
verwaltet diese Modifier, so dass diese nicht nur im 3D Stack, sondern
auch auf der Grafik-Ausgabeseite verwendet werden. Für die Details des
Verfahrens sei der <a class="reference external" href="https://www.x.org/wiki/Events/XDC2017/Program/#ben_widawsky">Vortrag über End-to-End Kompression im Intel
Grafikstack auf der XDC</a> von vor
ein paar Tagen empfohlen.</p>
<p>Was ändert sich nun mit Weston 3.0 und MESA 17.2?</p>
<p>Weston implementiert nun das zwp_linux_dmabuf Protokoll zusätzlich zum
bereits bestehenden wl_drm Protokoll. Damit ist es nun möglich, Puffer
zwischen der Wayland-Applikation und dem Compositor mit Hilfe von
dma-buf Deskriptoren auszutauschen und dabei beliebige Metadaten zur
Beschreibung des Puffer-Inhalts über das Wayland-Protokoll
auszutauschen. Findet MESA dieses Protokoll vor, wird es für die
Implementierung des Buffer-Sharings in der Wayland EGL Plattform
genutzt.</p>
<p>Ein Großteil der Arbeit, die für diese Funktionalität im generischen
Weston und MESA Code notwendig war, wurde von Daniel Stone (Collabora)
umgesetzt. Varad Gautam, ebenfalls Collabora, hat Support für die
Modifier auf dem Gallium Interface Level implementiert. Im Rahmen meiner
Aufgaben bei Pengutronix wurden die Gallium-Patches gereviewt und alle
nötigen Mechanismen im Etnaviv-Treiber implementiert. Damit ist Etnaviv
der erste Gallium-Treiber, der den neuen Mechanismus zum Sharen von
Puffer-Metadaten über das Wayland-Protokoll nutzt.</p>
<p>Aus der Kombination der Änderungen, die in die neuen Revisionen
eingeflossen sind, ergibt sich nun ein vollständig funktionierender
Wayland-Stack auf den Plattformen, die von Etnaviv unterstützt sind.
Und ein weiterer Vorteil ergibt sich aus diesem Konzept: mit diesem
Stack ist es <a class="reference external" href="https://www.collabora.com/news-and-blog/blog/2017/06/05/android-nxp-imx6-buffer-modifier-support/">ohne Änderungen auf Treiberebene möglich, den Android
Grafikstack mit Etnaviv zu nutzen!</a>.</p>
</div>
<p>Wenn man der Entwicklung des Linux Grafikstacks folgt, konnte man in den
letzten Wochen die Releases von MESA 17.2 und Weston 3.0 beobachten.
Neben den üblichen Verbesserungen und Bugfixes für diverse
Grafik-Hardware stellen diese aber auch einen wichtigen Meilenstein für
das Etnaviv Projekt dar: mit diesen Releases gibt es vollständigen
Support für Vivante-Grafikchips in Wayland!</p>2017-09-28T00:00:00+01:00tag:www.pengutronix.de,2017-09-25:/2017-09-25-embedded_recipes.htmlVortrag: Long Term Maintenance (Embedded Recipes)2017-09-25T00:00:00+01:00Robert Schwebel<div class="section" id="vortrag-long-term-maintenance-embedded-recipes">
<div class="ps-gallery single-image right" itemscope="" itemtype="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>Während die technische Seite der Erstellung von Embedded Linux Systemen
ein weitgehend gelöstes Problem ist, wohnen dem Betrieb solcher Systeme
mit Verbindung zum Internet über lange Zeiträume gewisse
Herausforderungen inne.</p>
<p>Marc Kleine-Budde berichtet am 26.09.2017 auf der
<a class="reference external" href="https://embedded-recipes.org/2017/">Embedded Recipes Konferenz</a>
in Paris über die Entwicklung eines nachhaltingen Workflows für diesen
Usecase.</p>
<div class="section" id="fotostrecke">
<h3>Fotostrecke</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>Während die technische Seite der Erstellung von Embedded Linux Systemen
ein weitgehend gelöstes Problem ist, wohnen dem Betrieb solcher Systeme
mit Verbindung zum Internet über lange Zeiträume gewisse
Herausforderungen inne.</p>2017-09-25T00:00:00+01:00tag:www.pengutronix.de,2017-09-04:/2017-09-04-ptxdist_did_you_know.htmlPTXdist: Schon gewusst? Heute: Mal eben neu booten2017-09-04T00:00:00+01:00Jürgen Borleis<div class="section" id="ptxdist-schon-gewusst-heute-mal-eben-neu-booten">
<p>Wer während der Entwicklung an einem embedded System selbiges immer wieder mal
komplett neu starten muss, wird es zu schätzen wissen, wenn so wenig wie möglich
getan werden muss, um bei veränderten Daten das System im konsistenten
Zustand zu halten.</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 entspannt</p>
</figcaption>
</figure>
</div><p>Die Einleitung war schon ganz schön kompliziert. Vorallem ist es kontraproduktiv,
so lange Sätze zu schreiben. Aber das ist wie eine Tür: Da müssen wir durch.</p>
<p>Konkret geht es darum, dass ich bei meinem embedded System während der Entwicklung
niemals Diskjockey spielen will: Es dauert einfach zu lange beispielsweise eine
SD-Karte neu zu bespielen, nur um eine inhaltliche Änderung am Root-Dateisystem
auf dem embedded System auszuprobieren.</p>
<p>Ich will also mein embedded System komplett über Netzwerk betreiben. Und "komplett"
meint hier, dass es auch den Kernel und ggf. dessen Devicetree beinhalten soll.
Gehen wir davon aus, dass der Bootlader des embedded Systems das NFS-Protokoll
und darüber hinaus auch noch die
<a class="reference external" href="https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/">BootLoaderSpec</a>
beherrscht (wer wie ich den Bootlader <a class="reference external" href="http://www.barebox.org">barebox</a> einsetzt
ist jetzt fein raus). Beide Eigenschaften plus ein NFS-Dienst bieten zusammen die
Möglichkeit, das embedded System komplett und konsistent über Netzwerk zu
betreiben. Die Möglichkeiten eines NFS-Dienst habe ich bereits
<a class="reference external" href="https://www.pengutronix.de/de/blog/2017-08-21-ptxdist_did_you_know.html">hier</a> besprochen.</p>
<p>Ich benutze auf allen meinen embedded Systemen den Bootloader <em>barebox</em>, so dass
ich diesen auch hier im Beispiel voraussetze.</p>
<p>Der NFS-Dienst muss das BSP-Unterverzeichnis <tt class="docutils literal"><span class="pre">platform-<name>/root</span></tt>
exportieren. Das ist das Root-Dateisystem für das embedded System und es muss
aus seiner Sicht einen Pfad auf dieses BSP-Unterverzeichnis verwenden. Das
BSP-Unterverzeichnis entsteht, wenn <tt class="docutils literal">ptxdist go</tt> durchgelaufen ist.</p>
<p>Zunächst muss im Bootloader <em>barebox</em> die verwendete Netzwerk-Schnittstelle
geeignet konfiguriert werden. Das kann mittels statischer Konfiguration oder auch
per DHCP erfolgen.</p>
<p>Um den Linux-Kernel und seinen Devicetree über Netzwerk zu laden, definiere
ich im <em>barebox</em>-Environment einen weiteren sog. <em>automount</em>-Eintrag. Ich verwende
auf meinem embedded System die Schnittstelle <tt class="docutils literal">eth0</tt> und somit sieht mein
<em>automount</em>-Eintrag wie folgt aus:</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>Die hier mit <tt class="docutils literal"><path></tt> markierte Stelle ist bei mir durch den aktuellen Pfad
zu meinem per NFS exportierten Root-Dateisystem ersetzt.</p>
<p>Jetzt macht bereits der Bootloader <em>barebox</em> Gebrauch vom Netzwerk, aber der
Linux-Kernel benötigt noch eine entsprechende Parametrisierung, um ebenfalls
für sein Root-Dateisystem Netzwerk zu verwenden. Auch das ergänzt der Bootloader
<em>barebox</em> für mich, wenn in der Konfigurationsdatei der <em>BootLoaderSpec</em> der
Eintrag <tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt> enthalten ist. Dazu gleich mehr. Soweit zur
Vorbereitung des embedded Systems.</p>
<p>Auf PTXdist-Seite (meinem Enwicklungsrechner) genügt es nun in der Plattform im Untermenü
<tt class="docutils literal">bootloader spec entries</tt> den Menüpunkt <tt class="docutils literal">default bootloader spec entry</tt> zu
aktivieren. Da PTXdist die oben zitierte Zeile <tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt> nicht
selbst einfügt, muss ich das selber tun. Dazu kopiere ich mir die Vorlage dieser
<em>BootLoaderSpec</em>-Konfigurationsdatei in mein BSP, also die Datei
<tt class="docutils literal">default.conf</tt> aus dem Pfad <tt class="docutils literal">projectroot/loader/entries</tt> im
PTXdist-Installationsverzeichnis in mein BSP-lokales
<tt class="docutils literal">projectroot/loader/entries</tt>-Verzeichnis und ergänze darin eine Zeile mit dem
gewünschen <tt class="docutils literal"><span class="pre">linux-appendroot</span> true</tt>-Inhalt. Im Ergebnis sollte das dann in
etwa so aussehen:</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>Nun lasse ich mittels <tt class="docutils literal">ptxdist go</tt> das Root-Dateisystem-Verzeichnis auf meiner
lokalen Festplatte bauen, starte den NFS-Dienst (falls ich das noch nicht getan
haben sollte) und schalte mein embedded System ein. Es genügt nun das ich
folgendes, einfaches Boot-Kommando anwende:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox:/ boot /mnt/nfs
</pre></div>
</div><p>Bei mir sieht das dann etwa so aus:</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>Mein embedded System wurde per DHCP konfiguriert und damit wird diese Methode
von <em>barebox</em> auch an den Kernel übergeben (<tt class="docutils literal">ip=dhcp</tt>). Auch hier taucht die
<path>-Komponente wieder auf. <em>barebox</em> hat diese direkt aus der
<em>automount</em>-Einheit übernommen und für den Kernel entsprechend aufbereitet.</p>
<p>Um das oben dargestellte Boot-Kommando nicht bei jedem Start erneut eingeben
zu müssen, kann ich auch das automatisieren:</p>
<div class="code-block">
<div class="highlight"><pre><span></span>barebox:/ nv boot.default=/mnt/nfs
barebox:/ saveenv
</pre></div>
</div><p>Ich für meinen Teil bin nun bereits entspannt beim Arbeiten und nutze den
hohen Druck lieber in meiner Kaffee-Maschine...</p>
</div><p>Wer während der Entwicklung an einem embedded System selbiges immer wieder mal
komplett neu starten muss, wird es zu schätzen wissen, wenn so wenig wie möglich
getan werden muss, um bei veränderten Daten das System im konsistenten
Zustand zu halten.</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: Schon gewusst? Heute: Das Entwicklerleben verschönern2017-08-21T00:00:00+01:00Jürgen Borleis<div class="section" id="ptxdist-schon-gewusst-heute-das-entwicklerleben-verschonern">
<p>Es gibt Dinge, die machen das Leben als Entwickler einfacher - und schöner.
Hier dazu ein Beispiel.</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>Kaffee verändert Dein Leben</p>
</figcaption>
</figure>
</div><p><a class="reference external" href="http://www.ptxdist.org">PTXdist</a> erzeugt während des Bauens des
Projekts ein komplettes Unterverzeichnis welches das vollständige
Root-Dateisystem exportierbar via NFS enthält.</p>
<p>Dieses Unterverzeichnis kann anschl. mittels des regulären und Kernel-basierten
NFS-Dienstes exportiert werden oder auch durch den in PTXdist eingebauten
Userland-basierten NFS-Dienst.</p>
<p>Der Userland-basierte NFS-Dienst in PTXdist sei hiermit empfohlen, weil er
die von PTXdist erzeugte Liste der für das Zielsystem vorgesehenen Benutzer- und
Rechteinformation für alle Dateien im Root-Dateisystem verwendet. Diese
Möglichkeit besitzt der Kernel-basierte NFS-Dienst nicht.</p>
<p>Sollte es also bereits während der Entwicklung relevant sein, dass bei der
Verwendung von NFS-Root auch Benutzer und Rechte auf dem Zielsystem korrekt
vorliegen, muss zwingend der Userland-basierte NFS-Dienst von PTXdist verwendet
werden. Andernfalls stolpern wir Entwickler erst bei der Verwendung des echten
durch PTXdist erstellten Root-Dateisystems auf einem lokalen Speicher des
Zielsystems über mögliches Fehlverhalten im Zusammenhang mit den Benutzern und
Rechten im Dateisystem.</p>
<p>Egal für welche Variante des NFS-Dienst wir uns entscheiden, wir erleben durch
die Verwendung von NFS-Root auf dem Zielsystem eine enorme Arbeitserleichterung
während wir noch gleichzeitig daran entwickeln.</p>
<p>Sobald wir eine Software-Komponente im System vermissen, genügt es jetzt, diese nachträglich
im PTXdist Menü zu aktivieren, PTXdist sie hinzubauen lassen und sofort steht
sie auf dem Zielsystem zur Verfügung. Es müssen dazu keine Dateien zum Zielsystem
übertragen werden oder gar ganze Root-Dateisystem-Abbilder ausgetauscht werden.
Und meist muss das Zielsystem nichteinmal neu gestartet werden.</p>
<p>Ausnahmen wie der Linux-Kernel bestätigen diese Regel. Aber auch im Falle des
Linux-Kernels und beispielsweise der Entwicklung eines Kernel-Treibers ist es
mitunter möglich an einem Treiber-Modul zu arbeiten, welches sich zur Laufzeit
des Zielsystems entladen und in einer überarbeiteten Version wieder laden läßt.
Die überarbeite Version wird auf dem Entwicklungsrechner regulär mit PTXdist
erstellt und ebenfalls wie jede andere Datei via NFS-Dienst bereitgestellt.</p>
<p>Und wer schon einmal mühsam während der Entwicklung direkt auf dem Zielsystem mit
einem "vi" Konfigurationsdateien bearbeitet hat, für den gibt es auch eine
gute Nachricht: Dank NFS-Dienst geht das nun mit dem persönlichen Lieblingseditor
direkt und lokal auf dem Entwicklungsrechner. Die Änderung ist anschl. instantan
auf dem Zielsystem verfügbar.</p>
<p>So ist das Entwicklerleben schön und den Kaffee trinke ich nicht aus
Verzweiflung, sondern mit Genuß.</p>
</div>
<p>Es gibt Dinge, die machen das Leben als Entwickler einfacher - und schöner.
Hier dazu ein Beispiel.</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.htmlFrei verfügbares Linux BSP für Emulierte ARM/x86 Plattformen2014-07-11T10:00:00+01:00Robert Schwebel<div class="section" id="frei-verfugbares-linux-bsp-fur-emulierte-arm-x86-plattformen">
<p>Hildesheim, Germany - Pengutronix veröffentlicht eine aktualisierte
Version ihres <em>Board Support Package</em> für generische und emulierbare
ARM/x86 Plattformen. Dieses <em>Board Support Package</em> bringt alle für die
Simulation benötigten Software-Komponenten mit. Es richtet sich
hauptsächlich an Neulinge in der embedded Programmierung, kann aber auch
dem erfahrenen Anwender als Ausgangspunkt für ein eigenes Projekt mit
ARM oder x86 basierten Systemen dienen.</p>
<p>Komponenten-Liste:</p>
<ul class="simple">
<li>PTXdist basierendes /Buildsystem/ für eine einfache Konfiguration und
anschl. Bauen aller Software-Komponenten</li>
<li>Aktuelle GCC basierte Toolchain (GCC 4.8.2, libc 2.18)</li>
<li>Betriebssystem: 3.0/3.7.1-Linux</li>
<li>QEMU: Aktuelle 2.0 Version</li>
<li>Umfangreiche Dokumentation über alle notwendigen Schritte, die Emulation
mittels QEMU in Betrieb zu nehmen und mit Software auszustatten. Weiterhin
enthält die Dokumentation das PTXdist-Referenz Handbuch.</li>
</ul>
</div>
<p>Hildesheim, Germany - Pengutronix veröffentlicht eine aktualisierte
Version ihres <em>Board Support Package</em> für generische und emulierbare
ARM/x86 Plattformen. Dieses <em>Board Support Package</em> bringt alle für die
Simulation benötigten Software-Komponenten mit. Es richtet sich
hauptsächlich an Neulinge in der embedded Programmierung, kann aber auch
dem erfahrenen Anwender als Ausgangspunkt für ein eigenes Projekt mit
ARM oder x86 basierten Systemen dienen.</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>In der Kalenderwoche 25/2014 ist das Pengutronix Team nicht regulär im
Büro in Hildesheim erreichbar; in dieser Zeit findet die jährliche
Pengutronix TechWeek statt.</p>
<p>Kunden wenden sich bitte an ihre Projektmailingliste. In allen anderen
Fällen können Sie unser Team über <a class="reference external" href="mailto:info@pengutronix.de">info@pengutronix.de</a> erreichen.</p>
<p>Die TechWeek ist die jährliche Pengutronix-interne
Technologie-Konferenz, bei der das Team für eine Woche an Zukunftsthemen
arbeitet. Mehr über Inhalte der Aktivitäten finden Sie auf Google+.</p>
</div>
<p>In der Kalenderwoche 25/2014 ist das Pengutronix Team nicht regulär im
Büro in Hildesheim erreichbar; in dieser Zeit findet die jährliche
Pengutronix TechWeek statt.</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>Das Barebox Projekt hat Version 2014.03.0 des Bootloaders
veröffentlicht.</p>
<p>Neue und geupdatete Features sind:</p>
<ul class="simple">
<li>Die i.MX25 und i.MX27 Prozessoren haben nun Support für die
Initialisierung aus dem Devicetree. Bei anderen i.MX Boards
wurden die Devicestrees geupdatet.</li>
<li>Initialer Support für die MIPS Loongson Architektur wurde aufgenommen.</li>
<li>Die UBIFS Implementierung ist nun in der Lage, mit Links umzugehen.</li>
<li>Es können nun automatisch aufgrund von Informationen aus dem
Devicetree die passenden console= Angaben an den Kernel übergeben
werden.</li>
<li>Diverse Bugs wurden gefixt, z.B. fuktioniert nun die SoC Type
Detection beim Booten von eMMC auf i.MX6. Das PFD Clock Gating
wurde gefixt, die ASIX AX88772B USB Netzwerkchips wurden
bereinigt und es wurden diverse Bugs im NAND- und SD-Card Handling
gefixt.</li>
<li>Ein neuer Treiber für National Semiconductor DP83865 Phys wurde
aufgenommen. Das Freescale MCIMX53-START-R Board ist nun unterstützt,
und der Support für Tegra20 wurde verbessert.</li>
<li>Das Sandbox Environment wurde geupdatet.</li>
</ul>
<p>Der Barebox Bootloader macht weiterhin gute Fortschritte, die Anzahl der
Contributions aus der Community wächst beständig.</p>
</div>
<p>Das Barebox Projekt hat Version 2014.03.0 des Bootloaders
veröffentlicht.</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>Die Version 2014.02.0 des Barebox Bootloaders wurde veröffentlicht:</p>
<p>Neue oder geupdatete Features sind:</p>
<ul class="simple">
<li>Viele Bugfixes und Verbesserungen</li>
<li>Support für die OpenCores 10/100 Mbps Ethernet MACs</li>
<li>Die IPU Framebuffer Treiber (i.MX35) wurden verbessert und supporten
nun die Bereichnung der Clocks mit verringertem Jitter. Damit ist es
nun möglich, externe LVDS Displays zu betreiben.</li>
<li>Das Memory Management wurde geändert und Barebox findet nun
automatisch Speicherstellen, um ATAGs für die Kernel-Parameter zu
übergeben. Alle Plattformen wurden auf das neue Verfahren umgestellt,
so dass der Plattform-Code weniger Platz einnimmt.</li>
</ul>
</div>
<p>Die Version 2014.02.0 des Barebox Bootloaders wurde veröffentlicht:</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