https://wiki.dave.eu/api.php?action=feedcontributions&user=U0002&feedformat=atomDAVE Developer's Wiki - User contributions [en]2024-03-28T22:09:39ZUser contributionsMediaWiki 1.31.3https://wiki.dave.eu/index.php?title=MVM_FAQs&diff=20232MVM FAQs2024-02-16T12:02:20Z<p>U0002: /* Q: OE Sanity check failed with Fetcher failure for URL: 'https://eula-downloads.yoctoproject.org/index.php' */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies_To_MVM}}<br />
{{InfoBoxBottom}}<br />
<br />
==Configuration==<br />
===Q: VirtualBox manager reports the "The shared folder 'xyz' could not be set up" when starting the MVM. How to fix it?===<br />
This kind of error is due to an incorrect path of the folder(s) shared between the host and the guest machines. The following image shows an example of such an error.<br />
<br />
<br />
[[File:MVM_shared_folders_error1.png|thumb|center|600px]]<br />
<br />
<br />
To fix it, just remove the erroneous shared folders as depicted in the following image.<br />
<br />
<br />
[[File:MVM_shared_folders_error2.png|thumb|center|600px]]<br />
===Q: How to configure the network interface of the MVM?===<br />
Please refer to [[VirtualBox_Network_Configuration|this page]].<br />
=== Q: How to change the keyboard layout of Lightweight X11 Desktop Environment (LXDE)? ===<br />
<br />
To change the keyboard layout, open a terminal (<code>CTRL+ALT+T</code>) and run the following command:<br />
<br />
<shell><br />
sudo dpkg-reconfigure keyboard-configuration<br />
</shell><br />
<br />
Follow the on-screen instruction to select the desired keyboard layout<br />
<br />
===Q: How to use the USB devices connected to the host machine?===<br />
By default, the USB controller of the MVM (guest machine) is not enabled. To enable it, in the VM VirtualBox Manager right click on the selected MVM end open the <code>Settings</code> item. Them, select the <code>USB</code> item and configure it as shown in the following image.<br />
[[File:MVM-add-USB-controller.png|thumb|center|600px]]<br />
<br />
The USB devices which are physically connected to the host machine can be connected to the guest machine with the <code>Devices->USB</code> menu, as shown in the following image.<br />
[[File:MVM-USB-host-devices.png|thumb|center|600px]]<br />
===Q: I can't start <code>make menuconfig</code>. How to fix it?===<br />
If the following error is encountered when trying to configure the Linux kernel via <code>menuconfig</code><br />
<pre><br />
dvdk@vagrant-ubuntu-trusty-64:~/lynx/linux$ make O=../linux-build/ menuconfig<br />
GEN /home/dvdk/lynx/linux-build/Makefile<br />
*** Unable to find the ncurses libraries or the<br />
*** required header files.<br />
*** 'make menuconfig' requires the ncurses libraries.<br />
*** <br />
*** Install ncurses (ncurses-devel) and try again.<br />
*** <br />
make[2]: *** [scripts/kconfig/dochecklxdialog] Error 1<br />
make[1]: *** [menuconfig] Error 2<br />
make: *** [sub-make] Error 2<br />
</pre><br />
, required libraries are missing.<br />
<br />
Please install the following packages:<br />
*<code>libncurses5-dev</code><br />
*<code>libncursesw5-dev</code>.<br />
===Q: Is it possible to resize the virtual disk?===<br />
Yes, but you need to convert the image to VDI format first. For example, see [https://www.jamescoyle.net/how-to/2000-convert-virtual-disk-image-vmware-vmdk-to-virtualbox-vdi this page].<br />
<br />
Once you have the VDI file, follow the procedure described [https://www.howtogeek.com/124622/how-to-enlarge-a-virtual-machines-disk-in-virtualbox-or-vmware/ here].<br />
<br />
=== Q: I get an OpenSSL error when accessing resources over TLS, e.g. download using wget on https. How to fix this? ===<br />
This errors is caused when an old version of OpenSSL, e.g. like the one present on an non-updated Ubuntu 12.04, is used to access resources using TLS, e.g.:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 22:59:47-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.3, 140.82.118.4<br />
Connecting to github.com (github.com)|140.82.118.3|:443... connected.<br />
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version<br />
Unable to establish SSL connection.<br />
<br />
</syntaxhighlight>To fix this user just have to updates OpenSSL and related libraries, using the following commands:<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install libssl-dev curl wget openssl<br />
</syntaxhighlight>This is the result:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 23:02:38-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.4, 140.82.118.3<br />
Connecting to github.com (github.com)|140.82.118.4|:443... connected.<br />
HTTP request sent, awaiting response... 302 Found<br />
Location: https://codeload.github.com/openssl/openssl/zip/master [following]<br />
--2018-11-15 23:02:39-- https://codeload.github.com/openssl/openssl/zip/master<br />
Resolving codeload.github.com (codeload.github.com)... 192.30.253.120, 192.30.253.121<br />
Connecting to codeload.github.com (codeload.github.com)|192.30.253.120|:443... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: unspecified [application/zip]<br />
Saving to: `master.zip'<br />
<br />
[ <=> ] 652.482 694K/s<br />
</syntaxhighlight><br />
<br />
=== Q: Buffer I/O Error when accessing USB devices ===<br />
When trying to write a large file on a USB device (e.g. micro SD, connected to the MVM through an adapter) user may experience some ''Buffer I/O errors'' (followed by additional kernel errors, depending on the specific operation that caused the error) like the following (use <code>dmesg</code> on a terminal to see the kernel log buffer) <pre class="mw-collapsible mw-collapsed"><br />
[ 358.392710] sdb: sdb1 sdb2<br />
[ 880.588382] EXT4-fs (sdb2): mounting ext3 file system using the ext4 subsystem<br />
[ 881.046203] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)<br />
[ 1008.759054] usb 1-1: USB disconnect, device number 2<br />
[ 1008.778105] blk_update_request: I/O error, dev sdb, sector 19338752 op 0x1:(WRITE) flags 0x4000 phys_seg 14 prio class 0<br />
[ 1008.778116] blk_update_request: I/O error, dev sdb, sector 19091736 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778119] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386468)<br />
[ 1008.778121] Buffer I/O error on device sdb2, logical block 289315<br />
[ 1008.778128] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386469)<br />
[ 1008.778128] Buffer I/O error on device sdb2, logical block 289316<br />
[ 1008.778130] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386470)<br />
[ 1008.778130] Buffer I/O error on device sdb2, logical block 289317<br />
[ 1008.778132] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386471)<br />
[ 1008.778133] Buffer I/O error on device sdb2, logical block 289318<br />
[ 1008.778135] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386472)<br />
[ 1008.778136] Buffer I/O error on device sdb2, logical block 289319<br />
[ 1008.778138] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386473)<br />
[ 1008.778138] Buffer I/O error on device sdb2, logical block 289320<br />
[ 1008.778140] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386474)<br />
[ 1008.778140] Buffer I/O error on device sdb2, logical block 289321<br />
[ 1008.778141] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386475)<br />
[ 1008.778142] Buffer I/O error on device sdb2, logical block 289322<br />
[ 1008.778144] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386476)<br />
[ 1008.778144] Buffer I/O error on device sdb2, logical block 289323<br />
[ 1008.778146] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386477)<br />
[ 1008.778146] Buffer I/O error on device sdb2, logical block 289324<br />
[ 1008.778208] blk_update_request: I/O error, dev sdb, sector 19338992 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0<br />
[ 1008.778222] blk_update_request: I/O error, dev sdb, sector 19358224 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0<br />
[ 1008.778262] blk_update_request: I/O error, dev sdb, sector 19091976 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778282] blk_update_request: I/O error, dev sdb, sector 19092216 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778317] blk_update_request: I/O error, dev sdb, sector 44090904 op 0x1:(WRITE) flags 0x0 phys_seg 10 prio class 0<br />
[ 1008.778325] blk_update_request: I/O error, dev sdb, sector 19092456 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778356] blk_update_request: I/O error, dev sdb, sector 19339136 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0<br />
[ 1008.778364] blk_update_request: I/O error, dev sdb, sector 19358464 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0<br />
[ 1008.778423] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 13, block_bitmap = 425984<br />
[ 1008.778456] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778458] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778558] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 14, block_bitmap = 458752<br />
[ 1008.778615] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778617] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778626] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 15, block_bitmap = 491520<br />
[ 1008.778677] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778678] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778686] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 16, block_bitmap = 524288<br />
[ 1008.778735] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778737] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778744] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 17, block_bitmap = 557056<br />
[ 1008.778826] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778828] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.839764] Buffer I/O error on dev sdb2, logical block 131072, lost async page write<br />
[ 1008.839769] Buffer I/O error on dev sdb2, logical block 164865, lost async page write<br />
[ 1008.839776] Buffer I/O error on dev sdb2, logical block 196608, lost async page write<br />
[ 1008.839778] Buffer I/O error on dev sdb2, logical block 230401, lost async page write<br />
[ 1008.839795] Buffer I/O error on dev sdb2, logical block 2818048, lost async page write<br />
[ 1008.841976] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.842006] Aborting journal on device sdb2-8.<br />
[ 1008.842011] JBD2: Error -5 detected when updating journal superblock for sdb2-8.<br />
[ 1008.842130] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.851777] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.851780] EXT4-fs error (device sdb2): ext4_journal_check_start:61: Detected aborted journal<br />
[ 1008.851780] EXT4-fs (sdb2): Remounting filesystem read-only<br />
[ 1008.921620] JBD2: Error while async write back metadata bh 131072.<br />
[ 1008.921621] JBD2: Error while async write back metadata bh 164865.<br />
[ 1008.921624] JBD2: Error while async write back metadata bh 196608.<br />
[ 1008.921649] JBD2: Error while async write back metadata bh 230401.<br />
[ 1008.921864] JBD2: Error while async write back metadata bh 2818048.<br />
[ 1008.922181] JBD2: Error while async write back metadata bh 2818637.<br />
...<br />
[ 1008.924465] JBD2: Error while async write back metadata bh 3408720.<br />
[ 1008.924467] JBD2: Error while async write back metadata bh 3408721.<br />
[ 1009.027187] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027191] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027193] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027194] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027200] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 18, block_bitmap = 589824<br />
[ 1014.162995] EXT4-fs error: 30 callbacks suppressed<br />
[ 1014.162997] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163016] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163160] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163163] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163178] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163181] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163192] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163194] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163204] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163207] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736540] EXT4-fs error: 4649 callbacks suppressed<br />
[ 1020.736541] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736679] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736707] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736733] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736741] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736909] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736917] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736946] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736955] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.737113] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1022.476182] EXT4-fs warning: 33909 callbacks suppressed<br />
[ 1022.476184] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476187] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476189] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476192] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476193] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476196] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476198] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476200] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476202] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476204] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
</pre><br />
<br />
The root cause of the problem may vary (e.g. Windows host OS device drivers, host hardware issue, Virtual Box incompatibility with host OS and so on) but, in our experience, this is caused by poor USB device or SD card reader.<br />
<br />
For this reason, as first action we suggest to change SD card adapter with a more robust one<br />
<br />
E.g. we've found that simple adapters like the one in the following picture, most of the time shows this kind of error during the creation of bootable SD card (like the one described in [[DESK-MX8M-L/Development/How to create a bootable microSD card|this article]])<br />
<br />
[[File:Generic-card-reader.jpg|none|thumb]]<br />
<br />
=== Q: OE Sanity check failed with <code>Fetcher failure for URL: '<nowiki>https://eula-downloads.yoctoproject.org/index.php'</nowiki></code> ===<br />
This usually happens from 1st October 2023 on Ubuntu 14.04 and Ubuntu 16.04 based MVM and the root cause is the DST Root CA X3 certificate expiration (see for example [https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60 this superuser thread])<br />
<br />
Without involving bitbake and Yocto, this can be easily reproduced with a <code>curl</code> command, here showed with it's error output:<syntaxhighlight lang="text"><br />
bash# curl https://eula-downloads.yoctoproject.org/index.php<br />
<br />
curl: (60) SSL certificate problem: certificate has expired<br />
More details here: http://curl.haxx.se/docs/sslcerts.html<br />
<br />
curl performs SSL certificate verification by default, using a "bundle"<br />
of Certificate Authority (CA) public keys (CA certs). If the default<br />
bundle file isn't adequate, you can specify an alternate file<br />
using the --cacert option.<br />
If this HTTPS server uses a certificate signed by a CA represented in<br />
the bundle, the certificate verification probably failed due to a<br />
problem with the certificate (it might be expired, or the name might<br />
not match the domain name in the URL).<br />
If you'd like to turn off curl's verification of the certificate, use<br />
the -k (or --insecure) option.<br />
</syntaxhighlight><br />
<br />
The easy way to fix this is to disable the expired certificate the the following command (please note that it must be run with <code>sudo</code>)<syntaxhighlight lang="bash"><br />
sudo sed -i '/^mozilla\/DST_Root_CA_X3.crt$/ s/^/!/' /etc/ca-certificates.conf && sudo update-ca-certificates<br />
</syntaxhighlight><br />
<br />
This is a persistent change on the MVM, so you'll need to perform it only once<br />
<br />
After applying the fix, the <code>curl</code> command now succeed<syntaxhighlight lang="text"><br />
bash# curl https://eula-downloads.yoctoproject.org/index.php<br />
<html><br />
<head><title>301 Moved Permanently</title></head><br />
<body bgcolor="white"><br />
<center><h1>301 Moved Permanently</h1></center><br />
<hr><center>nginx/1.14.2</center><br />
</body><br />
</html><br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=DESK-MX8M-L/General/Release_Notes&diff=20231DESK-MX8M-L/General/Release Notes2024-02-15T14:23:25Z<p>U0002: /* Downloadable binary images */</p>
<hr />
<div><section begin="History" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|16132| 2022/02/17}}<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK-MX8M-L-2.0.0-rc2 release<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|17078| 2022/06/01}}<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Updated MVM information<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|17625| 2023/02/27}}<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK-MX8M-L-2.0.0 release<br />
|-<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#ededed; padding:5px; color:#000000" |2023/08/22<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#ededed; padding:5px; color:#000000" |DESK-MX8M-L-4.0.0 release<br />
|-<br />
|}<br />
<br />
<section end="History" /><br />
<section begin="Body" /><br />
<br />
__TOC__<br />
<br />
==Release Notes==<br />
<br />
'''DAVE Embedded Systems''' adds to the latest Linux BSP from NXP the customization required to support the SOC platform. For this reason, most of the documentation provided by NXP remains valid for the DESK development kit. <br />
<br />
However, some customization is required, in particular at bootloader and linux kernel levels.<br />
<br />
The following table reports the DESK releases information.<br />
{| class="wikitable" <br />
!<br />
! width="300pt" |DESK version<br />
|-<br />
|Release number<br />
|4.0.0<br />
|-<br />
|Release type<br />
|Major<br />
|-<br />
|Status<br />
|Released<br />
|-<br />
|Release date<br />
|Aug 2023<br />
|-<br />
|'''Release notes'''<br />
| [[#DESK-MX8M-L_4.0.0 | Ver 4.0.0]]<br />
|-<br />
|Product support<br />
|[[ORCA SOM | ORCA]], [[MITO 8M Mini SOM |MITO 8M Mini]]<br />
|-<br />
|MVM (distro version)<br />
|Ubuntu 20.04<br />
|-<br />
|U-Boot version<br />
|2022.04-desk-mx8-l-4.0.0<br />
|-<br />
|Linux version<br />
|5.15.71-desk-mx8-l-4.0.0<br />
|-<br />
|Drivers<br />
| <br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
Audio<br>Ethernet<br>HDMI<br>LVDS<br>MIPI<br>SD<br />
</div><br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
UART<br>USB-C<br>USB1 OTG<br>USB2 OTG<br>PCIe<br>GPIOs<br>[[ConfigID_and_UniqueID | ConfigID]]<br />
</div><br />
|-<br />
|Manufacturer BSP version<br />
|rel_imx_5.15.71_2.2.0<br />
|-<br />
|Graphic libraries<br />
|Qt 6.3.2<br />
|-<br />
|Build System<br />
|Yocto Kirkstone (4.0)<br />
|-<br />
|}<br />
<br />
=== DESK-MX8M-L 4.0.0 ===<br />
<br />
{{ImportantMessage|text=New MVM must be installed for using <code>DESK-MX-L-4.0.0</code>. The VM is available for download on DAVE's XELK Reserved Area for registered users.}}<br />
<br />
Release notes:<br />
<br />
* Stable release based on NXP BSP 5.15.71<br />
<br />
==== Known Limitations ====<br />
<br />
The following table reports the known limitations of this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Issue<br />
!Description<br />
|-<br />
|USB-C 1 limitations<br />
|Some USB 3.2 Gen1 peripherals connected to USB-C 1 are not working on ORCA SBC<br />
|-<br />
|Suspend mode<br />
|Waken up from suspend mode is not properly working correctly when the [[DWS_ADD-ON | DWS]] add-on module is inserted<br />
|-<br />
|mipi2lvds and lvds2hdmi not working on MITO 8M Mini<br />
|Display connected to mipi2lvds and lvds2hdmi is not working on MITO 8M Mini Evaluation kit<br />
|-<br />
|zstd package missing on MVM<br />
|zstd package is needed to build Yocto BSP on MVM, to install it run <code>apt install zstd</code><br />
|-<br />
|Audio subsystem not working correctly<br />
|Audio subsystem is not configured correctly and sound is not played with the right frequency<br />
|}<br />
<br />
====Downloadable binary images====<br />
<br />
All binary images for [[DESK-MX8M-L]] are hosted on [http://mirror.dave.eu/desk-mx-l/ DAVE Embedded System mirror server]. There you can find a subdirectory for each version of this development kit.<br />
<br />
U-Boot performs a container image providing a single file: <code>flash.bin</code>. The binary file must be stored into SD card using <code>dd</code> command.<br />
<br />
A summary of images with a brief description can be found into the table below:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Image <br />
! colspan="2" | DESK version 4.0.0<br />
|-<br />
| Platform <br />
| style="text-align: center" | ORCA SBC <br />
| style="text-align: center" | SBCX MITO 8M Mini<br />
|-<br />
| Carrier Board [[ConfigID_and_UniqueID | ConfigID]] <br />
| style="text-align: center" | 1008<br />
| style="text-align: center" | 100A<br />
|-<br />
| LCD panel <br />
| style="text-align: center" | HDMI<br />
| style="text-align: center" | Not Avaible<br />
|-<br />
| Touchscreen <br />
| style="text-align: center" | capacitive<br />
| style="text-align: center" | Not Avaible<br />
|-<br />
| flash.bin<br> (SD or eMMC)<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-mx8m-l-4.0.0_imx8mp_flash.bin|desk-mx8m-l-4.0.0_imx8mp_flash.bin]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-mx8m-l-4.0.0_imx8mm_flash.bin|desk-mx8m-l-4.0.0_imx8mm_flash.bin]] <br />
|-<br />
| Linux kernel <br />
| colspan="2" style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-mx8m-l-4.0.0_Image|Image]]<br />
|-<br />
| Device tree<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-mx8m-l-4.0.0_imx8mp-mito8mplus-cb1008.dtb|imx8mp-mito8mplus-cb1008.dtb]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-mx8m-l-4.0.0_imx8mm-mito8mmini-cb100a.dtb|imx8mm-mito8mmini-cb100a.dtb]]<br />
|-<br />
| root file system<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/desk-image-qt6-desk-mx8mp.tar.bz2 | desk-image-qt6-desk-mx8mp]]<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-4.0.0/dave-image-devel-desk-mx8mm.tar.bz2 | dave-image-devel-desk-mx8mm]]<br />
|}<br />
<br />
=== DESK-MX8M-L 2.0.0 ===<br />
<br />
{{ImportantMessage|text=The <code>DESK-MX8M-L-2.0.0</code> BSP and SDK can be installed starting from [https://wiki.dave.eu/index.php?title=DESK-MX6-L/General/DVDK_Virtual_Machine&oldid=14296 DESK-MX6-L 1.0.0] MVM. See the [[DESK-MX8M-L/General/DVDK_Virtual_Machine#DVDK_for_release_2.0.0 | DVDK for release 2.0.0]] installation how to for more information.<br>The [https://wiki.dave.eu/index.php?title=DESK-MX6-L/General/DVDK_Virtual_Machine&oldid=14296 <code>DESK-MX6-L 1.0.0</code>] MVM is available for download on DAVE's DESK-MX Reserved Area for registered users.}}<br />
<br />
Release notes:<br />
<br />
* Stable release based on NXP BSP 5.4.70<br />
<br />
==== Known Limitations ====<br />
<br />
The following table reports the known limitations of this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Issue<br />
!Description<br />
|-<br />
|USB-C 1 not working in U-Boot<br />
|USB-C 1 not working in ORCA SBC<br />
|-<br />
|USB1, USB2 not working in U-Boot<br />
|USB1, USB2 not working in U-Boot for MITO 8M Mini<br />
|}<br />
<br />
====Downloadable binary images====<br />
<br />
All binary images for [[DESK-MX8M-L]] are hosted on [http://mirror.dave.eu/desk-mx-l/desk-mx8m-l-2.0.0/ DAVE Embedded System mirror server]. There you can find a subdirectory for each version of this development kit.<br />
<br />
U-boot performs a container image providing a single file: <code>flash.bin</code>. The binary file must be stored into SD card using <code>dd</code> command.<br />
<br />
A summary of images with a brief description can be found into the table below:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Image <br />
! colspan="2" | DESK version 2.0.0<br />
|-<br />
| Platform <br />
| style="text-align: center" | ORCA SBC <br />
| style="text-align: center" | SBCX MITO 8M Mini<br />
|-<br />
| Carrier Board [[ConfigID_and_UniqueID | ConfigID]] <br />
| style="text-align: center" | 1008<br />
| style="text-align: center" | 100A<br />
|-<br />
| LCD panel <br />
| style="text-align: center" | HDMI<br />
| style="text-align: center" | Not Avaible<br />
|-<br />
| Touchscreen <br />
| style="text-align: center" | capacitive<br />
| style="text-align: center" | Not Avaible<br />
|-<br />
| bootscript <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mp_boot.scr|boot.scr]]<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mm_boot.scr|boot.scr]]<br />
|-<br />
| flash.bin<br> (SD or eMMC)<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mp_flash.bin|flash.bin]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mm_flash.bin|flash.bin]] <br />
|-<br />
| Linux kernel <br />
| colspan="2" style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_Image|Image]]<br />
|-<br />
| Device tree<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mp-mito8mplus-cb1008.dtb|imx8mp-mito8mplus-cb1008.dtb]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/desk-mx8m-l-2.0.0_imx8mm-mito8mmini.dtb|imx8mm-mito8mmini.dtb]]<br />
|-<br />
| root file system<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/dave-image-qt5-desk-mx8mp.tar.bz2 | desk-image-qt5-desk-mx8mp]]<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0/dave-image-devel-desk-mx8mm.tar.bz2 | dave-image-devel-desk-mx8mm]]<br />
|}<br />
<br />
=== DESK-MX8M-L 2.0.0-rc2 ===<br />
<br />
{{ImportantMessage|text=The <code>DESK-MX8M-L-2.0.0</code> BSP and SDK can be installed starting from [https://wiki.dave.eu/index.php?title=DESK-MX6-L/General/DVDK_Virtual_Machine&oldid=14296 DESK-MX6-L 1.0.0] MVM. See the [[DESK-MX8M-L/General/DVDK_Virtual_Machine#DVDK_for_release_2.0.0 | DVDK for release 2.0.0]] installation how to for more information.<br>The [https://wiki.dave.eu/index.php?title=DESK-MX6-L/General/DVDK_Virtual_Machine&oldid=14296 <code>DESK-MX6-L 1.0.0</code>] MVM is available for download on DAVE's DESK-MX Reserved Area for registered users.}}<br />
<br />
Release notes:<br />
<br />
* First release based on NXP BSP 5.4.70<br />
<br />
==== Known Limitations ====<br />
<br />
The following table reports the known limitations of this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Issue<br />
!Description<br />
|-<br />
|HDMI not working<br />
|HDMI is not working on ORCA SBC. Device tree fixing is required<br />
|}<br />
<br />
=== Release types ===<br />
<br />
DESK release type can be:<br />
* '''Major''', when substantial changes are applied to the BSP (eg: major kernel version upgrades) or to the development kit (eg: new features, build system updates, ..). This usually means that a new DVDK is created for the DESK release<br />
* '''Maintenance''', when minor updates and bug fixes are introduced. This usually means that the DVDK remains the same provided with the previous major version, and only an update of the source tree repositories (and the tftp binaries) is required<br />
<br />
As an example, DESK 2.1.0 is a maintenance release, so it provides the DVDK released with the 2.0.0 major release; customers can easily upgrade to the 1.1.0 release by updating the software components as described in [[DESK-MX8M-L/Development/Synchronizing_git_repositories|Synchronizing git repositories]].<br />
<br />
=== Supported platforms ===<br />
<br />
The following table reports the supported platforms in this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Platform<br />
!Description<br />
|-<br />
|[[ORCA SBC | SBC ORCA]]<br />
|Single Board Computer using ORCA SOM as [[ORCA SOM/ORCA Evaluation_Kit | Evaluation Kit]]<br />
|-<br />
|[[SBC_Axel_SBC | SBC AXEL]]<br />
|Single Board Computer using MITO 8M Mini SOM as [[MITO 8M Mini SOM/MITO 8M Mini Evaluation_Kit | Evaluation Kit]]<br />
|-<br />
|}<br />
<br />
----<br />
<br />
[[Category:ORCA]] <br />
[[Category:MITO 8M Mini]]</div>U0002https://wiki.dave.eu/index.php?title=Sandbox&diff=19854Sandbox2024-01-20T13:51:26Z<p>U0002: /* CAD drawings */</p>
<hr />
<div>= Main Page=<br />
<br />
{|width="100%" style="border-collapse:collapse; font-size:12px"<br />
!colspan="3" style="width:60%; border-left:solid 2px #ededed; border-right:solid 0px #ededed; border-top:solid 2px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:14px; color:#000000; text-align:center" | ORCA System On Module<br />
!colspan="2" style="width:40%; border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7; border-top:solid 2px #73B2C7;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:14px; color:#000000; text-align:center" | ORCA SOM Evaluation Kit<br />
|-<br />
|style="width:20%; border-left:solid 2px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; text-align:center; background-color:#ffffff"| <br />[[File:ORCA-SOM-TOP-render.png|thumb|200px|center|ORCA SOM TOP view]]<br>[[File:ORCA-SOM-BOTTOM.png|thumb|200px|center|ORCA SOM BOTTOM view]]<br />
|style="width:20%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; text-align:center; background-color:#ffffff"|<br /> [[File:ORCA-SOM-BD.png|thumb|300px|center|ORCA SOM Block diagram]]<br />
|rowspan="2" style="width:40%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:center; background-color:#ffffff"|<fusion365 height="300" width="640">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion365><br />
|rowspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-right:solid 2px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 2px #73B2C7; text-align:left; background-color:#ffffff"| <br/>[[File:SBC8MU-1.0.0.png|thumb|300px|center|ORCA SOM Evaluation Kit|link=ORCA SOM/ORCA Evaluation Kit ]] <br />
<br/><br />
{{EvaluationKitDocumentation|nome-som=ORCA }}<br />
|-<br />
|-<br />
|style="width:20%; border-left:solid 2px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:left; padding:13px; background-color:#ffffff"|<br />
* [http://mirror.dave.eu/marketing/ORCA%20SOM/ORCA%20SOM-leaflet.pdf ORCA SOM Brochure PDF ]<br />
* [[/Part number composition| ORCA SOM P/N composition]]<br />
* [[Dave_Developer%27s_Wiki_Conventions#RSS_Feeds| RSS feeding]]<br />
* [[Dave_Developer's_Wiki:General_disclaimer|Disclaimer about this documentation]]<br />
| style="width:20%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:left; padding:13px; background-color:#ffffff"|<br />
* {{RFQ|product-name=ORCA SOM}}<br />
* {{CustomerService}}<br />
* {{ServiceMaintenance}}<br />
|style="width:20%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:left; padding:13px; background-color:#ffffff"|<br />
|-<br />
|}<br />
<br />
=Mech specs=<br />
<br />
<section begin="History" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Version<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |1.0.0<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Feb 2021<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |First release<br />
|-<br />
|-<br />
|}<br />
<section end="History" /><br />
<section begin="Body" /><br />
<br />
== Mechanical specifications ==<br />
<br />
This chapter describes the mechanical characteristics of the ORCA module.<br />
<br />
=== Board Layout ===<br />
<br />
The following figure shows the physical dimensions of the ORCA module:<br />
<br />
{| style="color:#000000; border:solid 2px #73B2C7; background-color:#ededed;font-size:95%; vertical-align:middle;"<br />
|[[File:TBD.png|30px]]<br />
|'''Section not completed yet'''<br />
|<br />
|}<br />
<br />
{|<br />
!Top View<br />
!3D drawing<br />
|-<br />
|[[File:ORCA-SOM-TOP-render.png|400px|frameless|border|Top View]]<br />
|rowspan="3"|<fusion365 height="600" width="800">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion365><br />
|-<br />
!Top View<br />
|-<br />
|[[File:ORCA-SOM-TOP-render.png|400px|frameless|border|Top View]]<br />
|}<br />
=== Connectors ===<br />
<br />
The following figure shows the ORCA connector layout:<br />
<br />
[[File:ORCA-connector-view.png|800px|frameless|border]]<br />
<br />
=== CAD drawings ===<br />
<br />
* DXF (2D): [https://mirror.dave.eu/mito/ORCA/mechanicals/CS054420.dxf.zip CS054420.dxf]<br />
* STEP (3D): [https://mirror.dave.eu/mito/ORCA/mechanicals/CS054420.zip CS054420]<br />
<br />
----<br />
<br />
<br />
<br />
<br />
<fusion360 height="600" width="800">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion360><br />
<br />
<fusion360 height="480" width="640">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion360><br />
<br />
<fusion360 height="300" width="400">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion360><br />
<br />
<fusion360 height="240" width="320">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion360></div>U0002https://wiki.dave.eu/index.php?title=MVM_FAQs&diff=18977MVM FAQs2023-11-21T16:30:26Z<p>U0002: /* Q: Buffer I/O Error when accessing USB devices */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies_To_MVM}}<br />
{{InfoBoxBottom}}<br />
<br />
==Configuration==<br />
===Q: VirtualBox manager reports the "The shared folder 'xyz' could not be set up" when starting the MVM. How to fix it?===<br />
This kind of error is due to an incorrect path of the folder(s) shared between the host and the guest machines. The following image shows an example of such an error.<br />
<br />
<br />
[[File:MVM_shared_folders_error1.png|thumb|center|600px]]<br />
<br />
<br />
To fix it, just remove the erroneous shared folders as depicted in the following image.<br />
<br />
<br />
[[File:MVM_shared_folders_error2.png|thumb|center|600px]]<br />
===Q: How to configure the network interface of the MVM?===<br />
Please refer to [[VirtualBox_Network_Configuration|this page]].<br />
=== Q: How to change the keyboard layout of Lightweight X11 Desktop Environment (LXDE)? ===<br />
<br />
To change the keyboard layout, open a terminal (<code>CTRL+ALT+T</code>) and run the following command:<br />
<br />
<shell><br />
sudo dpkg-reconfigure keyboard-configuration<br />
</shell><br />
<br />
Follow the on-screen instruction to select the desired keyboard layout<br />
<br />
===Q: How to use the USB devices connected to the host machine?===<br />
By default, the USB controller of the MVM (guest machine) is not enabled. To enable it, in the VM VirtualBox Manager right click on the selected MVM end open the <code>Settings</code> item. Them, select the <code>USB</code> item and configure it as shown in the following image.<br />
[[File:MVM-add-USB-controller.png|thumb|center|600px]]<br />
<br />
The USB devices which are physically connected to the host machine can be connected to the guest machine with the <code>Devices->USB</code> menu, as shown in the following image.<br />
[[File:MVM-USB-host-devices.png|thumb|center|600px]]<br />
===Q: I can't start <code>make menuconfig</code>. How to fix it?===<br />
If the following error is encountered when trying to configure the Linux kernel via <code>menuconfig</code><br />
<pre><br />
dvdk@vagrant-ubuntu-trusty-64:~/lynx/linux$ make O=../linux-build/ menuconfig<br />
GEN /home/dvdk/lynx/linux-build/Makefile<br />
*** Unable to find the ncurses libraries or the<br />
*** required header files.<br />
*** 'make menuconfig' requires the ncurses libraries.<br />
*** <br />
*** Install ncurses (ncurses-devel) and try again.<br />
*** <br />
make[2]: *** [scripts/kconfig/dochecklxdialog] Error 1<br />
make[1]: *** [menuconfig] Error 2<br />
make: *** [sub-make] Error 2<br />
</pre><br />
, required libraries are missing.<br />
<br />
Please install the following packages:<br />
*<code>libncurses5-dev</code><br />
*<code>libncursesw5-dev</code>.<br />
===Q: Is it possible to resize the virtual disk?===<br />
Yes, but you need to convert the image to VDI format first. For example, see [https://www.jamescoyle.net/how-to/2000-convert-virtual-disk-image-vmware-vmdk-to-virtualbox-vdi this page].<br />
<br />
Once you have the VDI file, follow the procedure described [https://www.howtogeek.com/124622/how-to-enlarge-a-virtual-machines-disk-in-virtualbox-or-vmware/ here].<br />
<br />
=== Q: I get an OpenSSL error when accessing resources over TLS, e.g. download using wget on https. How to fix this? ===<br />
This errors is caused when an old version of OpenSSL, e.g. like the one present on an non-updated Ubuntu 12.04, is used to access resources using TLS, e.g.:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 22:59:47-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.3, 140.82.118.4<br />
Connecting to github.com (github.com)|140.82.118.3|:443... connected.<br />
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version<br />
Unable to establish SSL connection.<br />
<br />
</syntaxhighlight>To fix this user just have to updates OpenSSL and related libraries, using the following commands:<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install libssl-dev curl wget openssl<br />
</syntaxhighlight>This is the result:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 23:02:38-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.4, 140.82.118.3<br />
Connecting to github.com (github.com)|140.82.118.4|:443... connected.<br />
HTTP request sent, awaiting response... 302 Found<br />
Location: https://codeload.github.com/openssl/openssl/zip/master [following]<br />
--2018-11-15 23:02:39-- https://codeload.github.com/openssl/openssl/zip/master<br />
Resolving codeload.github.com (codeload.github.com)... 192.30.253.120, 192.30.253.121<br />
Connecting to codeload.github.com (codeload.github.com)|192.30.253.120|:443... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: unspecified [application/zip]<br />
Saving to: `master.zip'<br />
<br />
[ <=> ] 652.482 694K/s<br />
</syntaxhighlight><br />
<br />
=== Q: Buffer I/O Error when accessing USB devices ===<br />
When trying to write a large file on a USB device (e.g. micro SD, connected to the MVM through an adapter) user may experience some ''Buffer I/O errors'' (followed by additional kernel errors, depending on the specific operation that caused the error) like the following (use <code>dmesg</code> on a terminal to see the kernel log buffer) <pre class="mw-collapsible mw-collapsed"><br />
[ 358.392710] sdb: sdb1 sdb2<br />
[ 880.588382] EXT4-fs (sdb2): mounting ext3 file system using the ext4 subsystem<br />
[ 881.046203] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)<br />
[ 1008.759054] usb 1-1: USB disconnect, device number 2<br />
[ 1008.778105] blk_update_request: I/O error, dev sdb, sector 19338752 op 0x1:(WRITE) flags 0x4000 phys_seg 14 prio class 0<br />
[ 1008.778116] blk_update_request: I/O error, dev sdb, sector 19091736 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778119] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386468)<br />
[ 1008.778121] Buffer I/O error on device sdb2, logical block 289315<br />
[ 1008.778128] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386469)<br />
[ 1008.778128] Buffer I/O error on device sdb2, logical block 289316<br />
[ 1008.778130] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386470)<br />
[ 1008.778130] Buffer I/O error on device sdb2, logical block 289317<br />
[ 1008.778132] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386471)<br />
[ 1008.778133] Buffer I/O error on device sdb2, logical block 289318<br />
[ 1008.778135] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386472)<br />
[ 1008.778136] Buffer I/O error on device sdb2, logical block 289319<br />
[ 1008.778138] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386473)<br />
[ 1008.778138] Buffer I/O error on device sdb2, logical block 289320<br />
[ 1008.778140] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386474)<br />
[ 1008.778140] Buffer I/O error on device sdb2, logical block 289321<br />
[ 1008.778141] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386475)<br />
[ 1008.778142] Buffer I/O error on device sdb2, logical block 289322<br />
[ 1008.778144] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386476)<br />
[ 1008.778144] Buffer I/O error on device sdb2, logical block 289323<br />
[ 1008.778146] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386477)<br />
[ 1008.778146] Buffer I/O error on device sdb2, logical block 289324<br />
[ 1008.778208] blk_update_request: I/O error, dev sdb, sector 19338992 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0<br />
[ 1008.778222] blk_update_request: I/O error, dev sdb, sector 19358224 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0<br />
[ 1008.778262] blk_update_request: I/O error, dev sdb, sector 19091976 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778282] blk_update_request: I/O error, dev sdb, sector 19092216 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778317] blk_update_request: I/O error, dev sdb, sector 44090904 op 0x1:(WRITE) flags 0x0 phys_seg 10 prio class 0<br />
[ 1008.778325] blk_update_request: I/O error, dev sdb, sector 19092456 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778356] blk_update_request: I/O error, dev sdb, sector 19339136 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0<br />
[ 1008.778364] blk_update_request: I/O error, dev sdb, sector 19358464 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0<br />
[ 1008.778423] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 13, block_bitmap = 425984<br />
[ 1008.778456] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778458] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778558] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 14, block_bitmap = 458752<br />
[ 1008.778615] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778617] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778626] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 15, block_bitmap = 491520<br />
[ 1008.778677] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778678] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778686] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 16, block_bitmap = 524288<br />
[ 1008.778735] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778737] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778744] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 17, block_bitmap = 557056<br />
[ 1008.778826] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778828] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.839764] Buffer I/O error on dev sdb2, logical block 131072, lost async page write<br />
[ 1008.839769] Buffer I/O error on dev sdb2, logical block 164865, lost async page write<br />
[ 1008.839776] Buffer I/O error on dev sdb2, logical block 196608, lost async page write<br />
[ 1008.839778] Buffer I/O error on dev sdb2, logical block 230401, lost async page write<br />
[ 1008.839795] Buffer I/O error on dev sdb2, logical block 2818048, lost async page write<br />
[ 1008.841976] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.842006] Aborting journal on device sdb2-8.<br />
[ 1008.842011] JBD2: Error -5 detected when updating journal superblock for sdb2-8.<br />
[ 1008.842130] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.851777] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.851780] EXT4-fs error (device sdb2): ext4_journal_check_start:61: Detected aborted journal<br />
[ 1008.851780] EXT4-fs (sdb2): Remounting filesystem read-only<br />
[ 1008.921620] JBD2: Error while async write back metadata bh 131072.<br />
[ 1008.921621] JBD2: Error while async write back metadata bh 164865.<br />
[ 1008.921624] JBD2: Error while async write back metadata bh 196608.<br />
[ 1008.921649] JBD2: Error while async write back metadata bh 230401.<br />
[ 1008.921864] JBD2: Error while async write back metadata bh 2818048.<br />
[ 1008.922181] JBD2: Error while async write back metadata bh 2818637.<br />
...<br />
[ 1008.924465] JBD2: Error while async write back metadata bh 3408720.<br />
[ 1008.924467] JBD2: Error while async write back metadata bh 3408721.<br />
[ 1009.027187] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027191] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027193] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027194] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027200] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 18, block_bitmap = 589824<br />
[ 1014.162995] EXT4-fs error: 30 callbacks suppressed<br />
[ 1014.162997] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163016] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163160] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163163] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163178] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163181] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163192] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163194] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163204] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163207] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736540] EXT4-fs error: 4649 callbacks suppressed<br />
[ 1020.736541] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736679] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736707] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736733] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736741] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736909] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736917] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736946] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736955] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.737113] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1022.476182] EXT4-fs warning: 33909 callbacks suppressed<br />
[ 1022.476184] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476187] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476189] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476192] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476193] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476196] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476198] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476200] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476202] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476204] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
</pre><br />
<br />
The root cause of the problem may vary (e.g. Windows host OS device drivers, host hardware issue, Virtual Box incompatibility with host OS and so on) but, in our experience, this is caused by poor USB device or SD card reader.<br />
<br />
For this reason, as first action we suggest to change SD card adapter with a more robust one<br />
<br />
E.g. we've found that simple adapters like the one in the following picture, most of the time shows this kind of error during the creation of bootable SD card (like the one described in [[DESK-MX8M-L/Development/How to create a bootable microSD card|this article]])<br />
<br />
[[File:Generic-card-reader.jpg|none|thumb]]<br />
<br />
=== Q: OE Sanity check failed with <code>Fetcher failure for URL: '<nowiki>https://eula-downloads.yoctoproject.org/index.php'</nowiki></code> ===<br />
This usually happens from 1st October 2023 on Ubuntu 14.04 based MVM and the root cause is the DST Root CA X3 certificate expiration (see for example [https://superuser.com/questions/1679204/curl-on-ubuntu-14-all-lets-encrypt-certificates-are-expired-error-60 this superuser thread])<br />
<br />
Without involving bitbake and Yocto, this can be easily reproduced with a <code>curl</code> command, here showed with it's error output:<syntaxhighlight lang="text"><br />
bash# curl https://eula-downloads.yoctoproject.org/index.php<br />
<br />
curl: (60) SSL certificate problem: certificate has expired<br />
More details here: http://curl.haxx.se/docs/sslcerts.html<br />
<br />
curl performs SSL certificate verification by default, using a "bundle"<br />
of Certificate Authority (CA) public keys (CA certs). If the default<br />
bundle file isn't adequate, you can specify an alternate file<br />
using the --cacert option.<br />
If this HTTPS server uses a certificate signed by a CA represented in<br />
the bundle, the certificate verification probably failed due to a<br />
problem with the certificate (it might be expired, or the name might<br />
not match the domain name in the URL).<br />
If you'd like to turn off curl's verification of the certificate, use<br />
the -k (or --insecure) option.<br />
</syntaxhighlight><br />
<br />
The easy way to fix this is to disable the expired certificate the the following command (please note that it must be run with <code>sudo</code>)<syntaxhighlight lang="bash"><br />
sudo sed -i '/^mozilla\/DST_Root_CA_X3.crt$/ s/^/!/' /etc/ca-certificates.conf && sudo update-ca-certificates<br />
</syntaxhighlight><br />
<br />
This is a persistent change on the MVM, so you'll need to perform it only once<br />
<br />
After applying the fix, the <code>curl</code> command now succeed<syntaxhighlight lang="text"><br />
bash# curl https://eula-downloads.yoctoproject.org/index.php<br />
<html><br />
<head><title>301 Moved Permanently</title></head><br />
<body bgcolor="white"><br />
<center><h1>301 Moved Permanently</h1></center><br />
<hr><center>nginx/1.14.2</center><br />
</body><br />
</html><br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=XUELK-WP-001:_Secure_boot_on_iMX6UL&diff=18798XUELK-WP-001: Secure boot on iMX6UL2023-10-03T07:30:31Z<p>U0002: /* Conclusions */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToSBCLynx}}<br />
{{AppliesToAXELULite}}<br />
{{AppliesToAXEL ULite WP}}<br />
{{AppliesTo SBC Lynx WP}}<br />
{{AppliesToIoT}}<br />
{{AppliesTo IoT WP}}<br />
{{InfoBoxBottom}}<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|February 2018<br />
|First public release<br />
|}<br />
<br />
==Introduction==<br />
Nowdays, thanks to embedded systems diffusion and explosive growth anyone is aware about security. One of the key factors is to grant that on a specific hardware devices should be executed only authorized SW. <br />
This is extremely important in devices which can be upgraded Over The Air (OTA). <br />
<br />
As we said before, security on Embedded Device is getting important in the embedded world. In particular, one of the most important targets, discussed in this article is the software authentication: it is particularly important to guarantee that the embedded processor '''executes '''<b>only</b> authenticated software code which should be originally certified (i.e. u-boot, kernel,..).<br />
<br />
In this article, it is described the process applied on DAVE Embedded Systems' devices in order to:<br />
<br />
(1) demonstrate the capability of the authentication mechanisms and <br />
<br />
(2) give an idea about the effort required for implementing the process on the in-house production. <br />
<br />
<br />
It is important to highlight that this is '''not''' just a SW procedure but also a company arrangement design because of security pass through company procedure and good practice (any alarm system doesn't work properly if you live the keys on the door...).<br />
<br />
What described in the following, starts from the HAB Security mechanism provided on iMX6/iMX6UL processor family by NXP. This mechanism permits only that authentic/original software is executed. Then is described how an HAB enabled system, via bootrom proper configuration, guarantees that software loaded from external memory devices, like NOR, NAND flash memories or SD card, will be executed only if has been authenticated.<br />
<br />
References:<br />
[1] See for example [https://www.nxp.com/docs/en/application-note/AN4581.pdf Secure Boot on i.MX 6 using HABv4].<br />
<br />
[2] See starting from pag.19 the follwoing document [https://www.nxp.com/docs/en/supporting-information/DWF13_AMF_IND_T0291.pdf i.MX High Assurance Boot - Enablement & Tools]<br />
<br />
[3] See ''[https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-6-processors/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL NXP i.MX6UL: i.MX 6UltraLite Processor]''.<br />
<br />
==Code Signing theory==<br />
The following image shows a generic code signing flow and the different actors involved. As stated above, secure an embedded devices means not only to define a SW update procedure; it requires to define a secure manufacturing procedure where it is important to ensure that security is applied to the information access. In particular an embedded systems is secure if the Super Root Keys are well protected and if the code signing keys are protected. Nowdays, very often, in the manufacturing process, some third parties are involved. This means that secure those keys is fundamental as well as define properly formal agreements with those suppliers in order to define well the responsability and calculate the '''"security risk"'''.<br />
<br />
[[File:Generic_Code-signing.png_Participants.png|thumb|center|600px|Code signing participants]]<br />
<br />
<br />
In this image it clear the process foo generate keys and certificates. Now these concepts should be applied to the embedded context. In the following it is described how this can be implemented in a real case scenario.<br />
==Implementation==<br />
The following image shows a simplified block diagram of the implemented solution. Basically this image describes how to apply the generic concepts in a real case scenario. In particular it is clear that any piece of SW should be signed and then authenticated before execution in order to grant security. This process is called Secure Boot and it is the essential tool for making possible the chain of authentication in an embedded device. In detail, Secure Boot is the mechanism used for verify (authenticate) the signature of any piece of SW. In the following sections it is described and listed the implementation procedure for make this possible in a DAVE EMbedded Systems' device called [http://www.dave.eu/products/sbc/freescale/i.mx6-ul-lynx SBC Lynx based on NXP i.MX6 UL platform].<br />
<br />
The main steps involved on Secure Boot usage are the following:<br />
* create the Public Keys starting from the Super Root Keys. The Public Keys are then used by the bootrom RSA algorithm to authenticate the binaries to be executed.<br />
* properly configures the iMX6UL eFuse for the bootrom to authenticate the signed binaries versus the Public/Private keys<br />
* signing the binaries images to be validated (u-boot, bootscript, dtb and kernel, ramdisk, etc..)<br />
* create a <b>chain of trust</b> avoiding any external possibility to interrupt the authenticatin process flow (i.e. only if a binary is validated it will be executed)<br />
<br />
Is this case the role of the ''father'' is to authenticates the ''children'' before passing the software control to it.[[File:Chain-of-trust.png|thumb|center|600px|Chain of trust example ]]<br />
<br />
== Security process and flow ==<br />
Going deep in the description, in this section it is described in detail the process with some shots on console log in order to give the precise idea about the entire procedure.<br />
*download Code Signing Tool (CST) NXP for CSF generation and digital signatures: the tool, once installed on a Linux environment, allows to:<br />
** create the PKI tree (Public Key Infrastructure): using the <code>hab4_pki_tree.sh</code> from NXP it is possible to create the Public Keys<br />
<pre class="board-terminal"><br />
dvdk@vagrant-ubuntu-trusty-64:~/lynx/hab/cst-2.3.3/keys$ ./hab4_pki_tree.sh<br />
<br />
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br />
This script is a part of the Code signing tools for Freescale's<br />
High Assurance Boot. It generates a basic PKI tree. The PKI<br />
tree consists of one or more Super Root Keys (SRK), with each<br />
SRK having two subordinate keys: <br />
+ a Command Sequence File (CSF) key <br />
+ Image key. <br />
Additional keys can be added to the PKI tree but a separate <br />
script is available for this. This this script assumes openssl<br />
is installed on your system and is included in your search <br />
path. Finally, the private keys generated are password <br />
protectedwith the password provided by the file key_pass.txt.<br />
The format of the file is the password repeated twice:<br />
my_password<br />
my_password<br />
All private keys in the PKI tree are in PKCS #8 format will be<br />
protected by the same password.<br />
<br />
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br />
Do you want to use an existing CA key (y/n)?: n<br />
Do you want to use Elliptic Curve Cryptography (y/n)?: n<br />
Enter key length in bits for PKI tree: 3072<br />
Enter PKI tree duration (years): 10<br />
How many Super Root Keys should be generated? 4<br />
Do you want the SRK certificates to have the CA flag set? (y/n)?: y<br />
<br />
+++++++++++++++++++++++++++++++++++++<br />
+ Generating CA key and certificate +<br />
+++++++++++++++++++++++++++++++++++++<br />
<br />
Generating a 3072 bit RSA private key<br />
.........++<br />
........................................................................................++<br />
writing new private key to 'temp_ca.pem'<br />
-----<br />
<br />
++++++++++++++++++++++++++++++++++++++++<br />
+ Generating SRK key and certificate 1 +<br />
++++++++++++++++++++++++++++++++++++++++<br />
<br />
Generating RSA private key, 3072 bit long modulus<br />
..............................++<br />
..................................++<br />
<br />
...<br />
...<br />
...<br />
<br />
++++++++++++++++++++++++++++++++++++++++<br />
+ Generating IMG key and certificate 4 +<br />
++++++++++++++++++++++++++++++++++++++++<br />
<br />
Generating RSA private key, 3072 bit long modulus<br />
................................................................................................................................................++<br />
.....................++<br />
e is 65537 (0x10001)<br />
Using configuration from ../ca/openssl.cnf<br />
Check that the request matches the signature<br />
Signature ok<br />
The Subject's Distinguished Name is as follows<br />
commonName :ASN.1 12:'IMG4_1_sha256_3072_65537_v3_usr'<br />
Certificate is to be certified until Jan 9 16:35:07 2028 GMT (3650 days)<br />
<br />
Write out database with 1 new entries<br />
Data Base Updated<br />
dvdk@vagrant-ubuntu-trusty-64:~/lynx/hab/cst-2.3.3/keys$ <br />
</pre><br />
* create the SRK table and SRK fuse table: using the <code>srktool</code> from NXP is it possible to generate the value to be programmed on eFuse OTP This process should be kept secret as much as possible. The ability to maintain secret the private keys (Super Root Keys) is the crucial factor which security depends. Once the processor is secured there is no way to load unsecured code. This because of the verification values are stored in eFuse OTP(One Time programming) which cannot be modified once programed. This means also that it is fundamental that the bootloader process is properly tested and prepared before deploying on the field the Secure Boot process.<br />
*program the eFuse values using the ''fuse'' command on u-boot. Once the eFuses are programmed it is not possible to modify them. <br />
<pre class="board-terminal"><br />
=> fuse prog -y 3 0 0x56D3468C<br />
Programming bank 3 word 0x00000000 to 0x56d3468c...<br />
=> fuse prog -y 3 1 0x2313CE16<br />
Programming bank 3 word 0x00000001 to 0x2313ce16...<br />
=> fuse prog -y 3 2 0xF374DA2D<br />
Programming bank 3 word 0x00000002 to 0xf374da2d...<br />
=> fuse prog -y 3 3 0xB0843A55<br />
Programming bank 3 word 0x00000003 to 0xb0843a55...<br />
=> fuse prog -y 3 4 0x74F39B9<br />
Programming bank 3 word 0x00000004 to 0x074f39b9...<br />
=> fuse prog -y 3 5 0xEF12FBA6<br />
Programming bank 3 word 0x00000005 to 0xef12fba6...<br />
=> fuse prog -y 3 6 0x2555E044<br />
Programming bank 3 word 0x00000006 to 0x2555e044...<br />
=> fuse prog -y 3 7 0x242C46B8<br />
Programming bank 3 word 0x00000007 to 0x242c46b8...<br />
</pre><br />
*digital signature of binaries to be loaded <br />
**CSF (Command Sequence File)<br />
**u-boot signature using the <code>cst</code> tool from NXP and the ''CSF'' configuration file<br />
**bootscript, kernel and dtb digital signature This process should be kept secret as much as possible. The signature of SW is directly linked to the private key generation so kepting this process secured is fundamental. Hacking a systems should happen at any system level. For this reason any SW layer should be signed. Only with this approach it is possbile to ensure a complete Secure Boot. This principle is calles also chain of trust.<br />
*chain of trust. In this section it is possible to see how the chain of trust works. Any piece of SW is authenticated before execution. Who is in charge of this check? The piece of code authenticated before... This means that Secure Boot will check with bootrom the u-boot and then any following piece of SW should be designed integrating the authentication check of the next stage. This is the chain of trust principle.<br />
**the bootrom <b>authenticates</b> u-boot<br />
**u-boot, using HAB's API (<code>hab_status</code> and <code>hab_auth_img</code>) <b>autenthicates</b> the boot.scr<br />
**boot.scr, using HAB's API (<code>hab_status</code> and <code>hab_auth_img</code>) <b>autenthicates</b> kernel, dtb e ramdisk<br />
<br />
=== Examples of authentication process on u-boot ===<br />
* u-boot not signed with status ''open'' <br />
<pre class="board-terminal"><br />
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 17:18:25 +0100)<br />
<br />
CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)<br />
CPU: Industrial temperature grade (-40C to 105C) at 44C<br />
Reset cause: POR<br />
Environment: MMC<br />
I2C: ready<br />
DRAM: 512 MiB<br />
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90<br />
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11<br />
NAND: 2048 MiB<br />
MMC: FSL_SDHC: 0<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
switch to partitions #0, OK<br />
mmc0 is current device<br />
SOM ConfigID#: 00000013<br />
SOM UniqueID#: ea9c2afe:3b0899d4<br />
CB ConfigID#: 0000002f<br />
CB UniqueID#: 00000000:00000000<br />
Board: MX6UL SBC Lynx<br />
Net: FEC0<br />
Normal Boot<br />
Hit any key to stop autoboot: 0<br />
=> hab_status<br />
<br />
Secure boot disabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
<br />
--------- HAB Event 1 -----------------<br />
event data:<br />
0xdb 0x00 0x14 0x42 0x33 0x28 0x33 0x00<br />
0x00 0x00 0x00 0x0f 0x87 0x7f 0xbb 0xd4<br />
0x00 0x09 0x00 0x00<br />
<br />
STS = HAB_FAILURE (0x33)<br />
RSN = HAB_INV_CALL (0x28)<br />
CTX = HAB_CTX_TARGET (0x33)<br />
ENG = HAB_ENG_ANY (0x00)<br />
<br />
...<br />
...<br />
</pre><br />
<br />
* u-boot signed with ''valid'' signature<br />
<pre class="board-terminal"><br />
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 18:30:36 +0100)<br />
<br />
CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)<br />
CPU: Industrial temperature grade (-40C to 105C) at 45C<br />
Reset cause: POR<br />
Environment: MMC<br />
I2C: ready<br />
DRAM: 512 MiB<br />
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90<br />
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11<br />
NAND: 2048 MiB<br />
MMC: FSL_SDHC: 0<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
switch to partitions #0, OK<br />
mmc0 is current device<br />
SOM ConfigID#: 00000013<br />
SOM UniqueID#: ea9c2afe:3b0899d4<br />
CB ConfigID#: 0000002f<br />
CB UniqueID#: 00000000:00000000<br />
Board: MX6UL SBC Lynx<br />
Net: FEC0<br />
Normal Boot<br />
Hit any key to stop autoboot: 0<br />
=> hab_status<br />
<br />
Secure boot disabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
No HAB Events Found!<br />
<br />
=><br />
</pre><br />
<br />
* bootscript, kernel and dtb with ''valid'' signature<br />
<pre class="board-terminal"><br />
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 18:30:36 +0100)<br />
<br />
CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)<br />
CPU: Industrial temperature grade (-40C to 105C) at 45C<br />
Reset cause: POR<br />
Environment: MMC<br />
I2C: ready<br />
DRAM: 512 MiB<br />
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90<br />
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11<br />
NAND: 2048 MiB<br />
MMC: FSL_SDHC: 0<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
switch to partitions #0, OK<br />
mmc0 is current device<br />
SOM ConfigID#: 00000013<br />
SOM UniqueID#: ea9c2afe:3b0899d4<br />
CB ConfigID#: 0000002f<br />
CB UniqueID#: 00000000:00000000<br />
Board: MX6UL SBC Lynx<br />
Net: FEC0<br />
Normal Boot<br />
Hit any key to stop autoboot: 0<br />
reading boot.scr<br />
20512 bytes read in 19 ms (1 MiB/s)<br />
<br />
Authenticate image from DDR location 0x80700000...<br />
<br />
Secure boot enabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
No HAB Events Found!<br />
<br />
bootscript AUTHENTICATED<br />
## Executing script at 80700000<br />
reading xuelk-2.0.1-signed_uImage<br />
7106592 bytes read in 323 ms (21 MiB/s)<br />
<br />
Authenticate image from DDR location 0x80800000...<br />
<br />
Secure boot enabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
No HAB Events Found!<br />
<br />
kernel AUTHENTICATED<br />
reading xuelk-2.0.1-signed_imx6ul-lynx-som0013-cb002f.dtb<br />
53280 bytes read in 24 ms (2.1 MiB/s)<br />
<br />
Authenticate image from DDR location 0x83000000...<br />
<br />
Secure boot enabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
No HAB Events Found!<br />
<br />
fdt AUTHENTICATED<br />
<br />
Authenticate image from DDR location 0x80800000...<br />
<br />
Secure boot enabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
No HAB Events Found!<br />
<br />
## Booting kernel from Legacy Image at 80800000 ...<br />
Image Name: Linux-4.1.15-xuelk-2.0.1<br />
Image Type: ARM Linux Kernel Image (uncompressed)<br />
Data Size: 7090064 Bytes = 6.8 MiB<br />
Load Address: 80008000<br />
Entry Point: 80008000<br />
Verifying Checksum ... OK<br />
## Flattened Device Tree blob at 83000000<br />
Booting using the fdt blob at 0x83000000<br />
Loading Kernel Image ... OK<br />
Using Device Tree in place at 83000000, end 8300b21d<br />
Modify /soc/aips-bus@02000000/bee@02044000:status disabled<br />
ft_system_setup for mx6<br />
<br />
Starting kernel ...<br />
<br />
[ 0.000000] Booting Linux on physical CPU 0x0<br />
[ 0.000000] Linux version 4.1.15-xuelk-2.0.1 (jenkins@linuxserver2) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Tue Oct 3 16:18:51 CEST 2017<br />
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d<br />
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache<br />
[ 0.000000] Machine model: Freescale i.MX6 UltraLite LYNX Board<br />
[ 0.000000] cma: Reserved 64 MiB at 0x9c000000<br />
[ 0.000000] Memory policy: Data cache writealloc<br />
[ 0.000000] PERCPU: Embedded 12 pages/cpu @9bbb2000 s17420 r8192 d23540 u49152<br />
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048<br />
[ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait rw ip=192.168.0.99:192.168.0.23::255.255.255.0:xelk:eth0:off panic=1 console=ttymxc0,115200 vmalloc=400M <br />
...<br />
...<br />
</pre><br />
<br />
=== HAB Warnings ===<br />
Not everything that is notified by <code>hab_status</code> command as <code>HAB Event</code> is a critical error (in other words: invalid signature)<br />
<br />
On some cases (in our experience depending on silicon revision, part to part differences and bootloader software releases) there might be some HAB events that are just warning, e.g. the following is a warning on an issue RNG initialization (please note the difference in <code>STS</code> field, from <code>HAB_FAILURE</code> to <code>HAB_WARNING</code>)<syntaxhighlight lang="text"><br />
=> hab_status<br />
<br />
Secure boot disabled<br />
<br />
HAB Configuration: 0xf0, HAB State: 0x66<br />
<br />
--------- HAB Event 1 -----------------<br />
event data:<br />
0xdb 0x00 0x24 0x42 0x69 0x30 0xe1 0x1d<br />
0x00 0x08 0x00 0x02 0x40 0x00 0x36 0x06<br />
0x55 0x55 0x00 0x03 0x00 0x00 0x00 0x00<br />
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00<br />
0x00 0x00 0x00 0x01<br />
<br />
STS = HAB_WARNING (0x69)<br />
RSN = HAB_ENG_FAIL (0x30)<br />
CTX = HAB_CTX_ENTRY (0xE1)<br />
ENG = HAB_ENG_CAAM (0x1D)<br />
<br />
</syntaxhighlight><br />
<br />
Warnings like this don't prevent booting even if secure boot is enabled<br />
<br />
== Conclusions ==<br />
The complete authentication process based on Secure Boot was described in this White Paper. There are many details around how to deploy this process in a manufacturing line. DAVE Embedded Systems' has successfully completed several projects with or without external manufacturing suppliers. In any case it is important to keep in mind:<br />
# Make the process secure and controlled<br />
# Chech and verify the code carefully before deplying<br />
# Authenticate all SW pieces<br />
# Evaluate carefully the Security level needed. On top of the authentication process there is also the possibility to have encryption mechanisms but not all application should require other security mechanisms expecially because of the high level of impact in the manufacturing process and in the resources required in the embedded systems</div>U0002https://wiki.dave.eu/index.php?title=DESK-MP1-L&diff=18399DESK-MP1-L2023-08-24T09:41:00Z<p>U0002: </p>
<hr />
<div><br />
{| style="border-collapse:collapse; " width="100%"<br />
! colspan="2" style="width:100%; border-left:solid 2px #ededed; border-right:solid 2px #ededed; border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ededed; font-size:14px; text-align:left;color:#000000" | ETRA Embedded Sofware Kit - DESK-MP1-L<br />
|-<br />
| style="width:50%; border-left:solid 2px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:left; padding:13px; background-color:#ffffff" | <br />
'''D'''AVE '''E'''mbedded '''S'''oftware '''K'''it '''L'''inux (DESK-''MP1''-L in short - [[DESK naming|read more info about the naming]]) - provides all the necessary components required to set up the developing environment to:<br />
* build the bootloader (ATF and U-Boot)<br />
* build the Linux operating system<br />
* build Linux applications that will run on the target<br />
* build the Yocto BSP<br />
<br />
The Embedded Software kit is composed by:<br />
* A [[DESK-MP1-L/General/Managed Virtual Machine (MVM)|Linux virtual machine]] (called MVM) containing<br />
** Yocto build system (toolchain and SDK)<br />
** Prebuilt images for supported targets (microSD card partitioned images, U-Boot images, etc.)<br />
* [[DESK-MP1-L/Development/Synchronizing git repositories|git repositories]]:<br />
** ARM Trusted Firmware (ATF)<br />
** U-Boot<br />
** desk-mp1-boot-image<br />
** Linux kernel<br />
** desk-mp1-l-bsp<br />
** [[DESK-MP1-L/Development/Using the STM32CubeMX Configuration file (.ioc)|STM32CubeMX Configuration file (<code>.ioc</code>)]]<br />
* [[DESK-MP1-L/Development/How to create a bootable microSD card|Bootable SD card images]] (U-Boot, Linux kernel, and root file systems binaries already configured)<br />
* A [[DESK-MP1-L/Development/Management of prebuilt packages|repository]] containing all of the prebuilt packages available in the Yocto distribution<br />
<br />
To populate the MVM with the source files of interest, please refer to [[DESK-MP1-L/Development/Synchronizing git repositories|this page]].<br />
<br />
It also is worth remembering that '''DESK-MP1-L is compatible with the use of STM32Cube tools provided by ST Microelectronics'''. When applicable, they are mentioned in the documentation to show how they can be used in tandem with the DESK tools. For instance, see [[DESK-MP1-L/Development/Using the STM32CubeMX Configuration file (.ioc)|this page]].<br />
| style="width:50%; border-left:solid 0px #ededed;border-right:solid 2px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ededed; text-align:left; vertical-align:top; padding:13px; background-color:#ffffff" |<br />
<section begin="Software-History-Linux" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |DESK-MP1-L History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Version<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Refers to<br />
|-<br />
| rowspan="2" style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |1.0.0<br />
| rowspan="2" style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Aug 2023<br />
| rowspan="2" style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK-MP1-L-1.0.0 release<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 0px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |[[File:ETRA_SOM_-_top.png|100px|link=ETRA SOM]][[ETRA SOM|ETRA SOM]]<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 0px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |[[File:ETRA-EVK.png|100px|link=ETRA SBC]][[ETRA SBC|ETRA SBC]]<br />
|-<br />
|}<br />
<section end="Software-History-Linux" /><br />
{{ImportantMessage|text='''Customers are strongly recommended to register their kits'''. Registration grants access to reserved material such as source code and additional documentation.<br />
<br />
To register the kit, please send an email to [mailto:helpdesk@dave.eu helpdesk@dave.eu], [[Development_Kits_Identification_Codes|providing the kit P/N and S/N]].}}<br />
{{PDFManual|nome-som=ETRA|link=https://www.dave.eu/links/p/HQVMw4FUzUBfZlCv|Descrizione= DESK-MP1-L Manual}}<br />
|-<br />
|}<br />
<br />
<br><br />
<br />
{| style="border-collapse:collapse; font-size:12px" width="100%"<br />
|-<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ededed; text-align:left; font-size:14px; color:#000000" |'''General'''<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 2px #ffffff;border-bottom:solid 0px #ededed; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ededed; text-align:left; font-size:14px; color:#000000" |'''Development'''<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 2px #ffffff;border-bottom:solid 0px #ededed; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ededed; text-align:left; font-size:14px; color:#000000" |'''Deployment'''<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 2px #ffffff;border-bottom:solid 0px #ededed; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ededed; text-align:left; font-size:14px; color:#000000" |'''Peripherals'''<br />
|-<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ffffff; vertical-align:top" |<br />
* [[/General/Release Notes | Release Notes]]<br />
* [[DESK-MP1-L/General/Managed Virtual Machine (MVM)|Managed Virtual Machine (MVM)]]<br />
* [[/General/ConfigID_and_UniqueID | ConfigID and UniqueID]]<br />
* [[/General/ConfigID | ConfigID]]<br />
* [[/General/Booting_from_NFS | Booting from nfs]]<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ffffff; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ffffff; vertical-align:top" |<br />
* [[/Development/Synchronizing_git_repositories | Synchronizing the git repositories]]<br />
* [[DESK-MP1-L/Development/Using the STM32CubeMX Configuration file (.ioc)|Using the ''STM32CubeMX'' Configuration file (.ioc)]]<br />
* [[/Development/Building_Boot_image | Building Boot images with <i>desk-boot-image repo</i>]]<br />
* [[/Development/Building_Linux_kernel | Building Linux with <i>make</i>]]<br />
* [[/Development/Building_the_Yocto_BSP | Building overall BSP with Yocto]]<br />
* [[/Development/How_to_create_a_bootable_microSD_card | How to create a bootable SD card]]<br />
* [[/Development/Hello_World_example | Hello World example]]<br />
* [[/Development/Asymmetric Multiprocessing (AMP) with OpenAMP| Asymmetric Multiprocessing (AMP) with OpenAMP]]<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ffffff; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ffffff; vertical-align:top" |<br />
* [[/Deployment/Customizing_the_splash_screen| Customizing u-boot splash screen]]<br />
* [[/Deployment/How_to_configure_the_network_interfaces | Configuring the network interfaces]]<br />
* [[/Deployment/MAC_Address_programming | MAC Address programming]]<br />
* [[DESK-MP1-L/Development/Management of prebuilt packages | Management of prebuilt packages]]<br />
| style="width:1%; border-left:solid 0px #ededed;border-right:solid 0px #ededed;border-top:solid 0px #ededed;border-bottom:solid 2px #ffffff; background-color:#ffffff" |<br />
| style="width:20%; border-left:solid 2px #ededed;border-right:solid 2px #ededed;border-top:solid 2px #ededed;border-bottom:solid 2px #ededed; background-color:#ffffff; vertical-align:top" |<br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
* [[/Pheripherals/Ethernet | Ethernet]]<br />
* [[/Pheripherals/LCD | LCD]]<br />
* [[/Pheripherals/Touchscreen | Touchscreen]]<br />
* [[/Pheripherals/micro SD | micro SD]]<br />
* [[/Pheripherals/UARTs | UARTs]]<br />
</div><br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
* [[/Pheripherals/USB_Host | USB Host]]<br />
* [[/Pheripherals/USB_OTG | USB OTG]]<br />
* [[/Pheripherals/RTC | RTC]]<br />
* [[/Pheripherals/DWS | DWS]]<br />
* [[/Pheripherals/GPIOs | GPIOs]]<br />
</div><br />
|-<br />
|}<br />
<br />
[[Category:ETRA]] <br />
[[Category:ETRA_SBC]]</div>U0002https://wiki.dave.eu/index.php?title=DESK-MX8M-AN-0001:_Package_Management_with_apt-get&diff=18311DESK-MX8M-AN-0001: Package Management with apt-get2023-08-11T12:57:55Z<p>U0002: cleanup</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesTo ORCA AN}}<br />
{{AppliesTo MITO 8M Mini AN}}<br />
{{InfoBoxBottom}}<br />
<br />
{{ImportantMessage|text=This application note has been validated using the '''kit version''' in the History table.}}<br />
==History==<br />
<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Development Kit version<br />
|-<br />
| 1.0.0<br />
| Apr 2022<br />
|[[DESK-MX8M-L/General/Release_Notes#DESK-MX8M-L_2.0.0-rc2|DESK-MX8M-L 2.0.0-rc2]]<br />
|-<br />
| 2.0.0<br />
| Aug 2023<br />
|[[DESK-MX8M-L/General/Release_Notes#DESK-MX8M-L_4.0.0|DESK-MX8M-L 4.0.0]]<br />
|-<br />
|}<br />
<br />
==Introduction==<br />
<br />
Since NXP BSP 5.15.71 Yocto release, [https://debian-handbook.info/browse/stable/sect.apt-get.html apt-get] has been added as a package manager for installing packages in the DUT (target machine). <br />
<br />
As reported by NXP official documentation:<br />
<br />
The default package management with Yocto Project is <code>rpm</code>. The i.MX distro now enables '''debian''' as the package management. This can be easily turned off by add <code>PACKAGE_CLASSES_*</code> set to <code>package_rpm</code> to the <code>local.conf</code> (or creating a custom distro without the debian package feed <code>PACKAGE_CLASSES = "package_rpm"</code>.<br />
With the addition of the debian package feed, a sources.list can be added ''/etc/apt'' that links in Debian's package feed. This allows users to install packages not provided in the image without having to add them to a yocto image. Because this package feed is not generated by the i.MX Yocto build process, there is no guarantee each package will work with the right dependencies but it allows simpler tools to be provided. Software that is complex and has more dependencies on specific versions might have issues with an external package feed.<br />
<br />
'''apt-get''' performs runtime package management of <code>.deb</code> packages. In order to use '''apt-get''' for runtime package management, you must perform an initial setup on the target machine for cases where the <code>PACKAGE_FEED_*</code> variables were not set as part of the image that is running on the target. <br />
<br />
In principle, the adoption of the Debian package management should allow to use prebuilt package archives available for [http://ftp.debian.org/debian/README.html Debian distributions]. However, close attention should be paid when mixing packages of different distributions. For instance, Debian packages installed on a Yocto file system could not work. Even worse, '''they could interfere with existing packages and make these unusable'''. <br />
<br />
This Application Note (AN) describes a way to apply the approach illustrated here to a Yocto distribution that makes use of Debian packetization. In other words, a local archive of Yocto-generated, prebuilt <code>.deb</code> packages is used in combination with the well known <code>apt-get</code> utility. <br />
<br />
== apt-get ==<br />
The following instructions detail how to use apt-get for installing packages with Yocto repositories created by DAVE's build system for DESK-MX8M-L.<br />
<br />
===Configuring <code>apt</code> for SBC-ORCA===<br />
Edit the file <code>/etc/apt/apt.conf</code> like this:<br />
<pre><br />
root@desk-mx8mp:~# cat /etc/apt/apt.conf<br />
APT::Architecture "arm64";<br />
APT::Get::AllowUnauthenticated "true";<br />
Acquire::Languages "none";<br />
</pre><br />
<br />
Edit the file <code>/etc/apt/sources.list.d/debian-10.list</code> like this:<br />
<pre class="board-terminal"><br />
root@desk-mx8mp:~# cat /etc/apt/sources.list.d/debian-10.list<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ all/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ armv8a-mx8mp/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ desk_mx8mp/<br />
</pre><br />
<br />
Execute the following commands in order to re-create the ''apt'' cache based on the new server's list:<br />
<br />
<pre><br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
apt-get update<br />
</pre><br />
<br />
<pre class="board-terminal"><br />
root@desk-mx8mp:~# rm -rf /var/lib/apt/lists/*<br />
root@desk-mx8mp:~# apt-get clean<br />
root@desk-mx8mp:~# apt-get update<br />
Ign:1 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ InRelease<br />
Ign:2 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ InRelease<br />
Ign:3 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mp/ InRelease<br />
Get:4 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release [1215 B]<br />
Get:5 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ Release [1224 B]<br />
Get:6 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mp/ Release [1222 B]<br />
Ign:7 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release.gpg<br />
Ign:8 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ Release.gpg<br />
Ign:9 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mp/ Release.gpg<br />
Get:10 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Packages [174 kB]<br />
Get:11 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ Packages [308 kB]<br />
Get:12 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mp/ Packages [263 kB]<br />
Fetched 749 kB in 1s (866 kB/s)<br />
Reading package lists... Done<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release (expected all/ but got )<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ Release (expected armv8a-mx8mp/ but got )<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mp/ Release (expected desk_mx8mp/ but got )<br />
</pre><br />
<br />
Then, modify the cached package list due to the proper DAVE's server configuration:<br />
<br />
<pre><br />
root@desk-mx8mp:~# sed -i 's/\.\//armv8a-mx8mp\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_armv8a-mx8mp_Packages<br />
root@desk-mx8mp:~# sed -i 's/\.\//all\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_all_Packages<br />
root@desk-mx8mp:~# sed -i 's/\.\//desk%5fmx8mp\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_desk%5fmx8mp_Packages<br />
</pre><br />
<br />
===Configuring <code>apt</code> for SBCX-Mito8MMini===<br />
Edit the file <code>/etc/apt/apt.conf</code> like this:<br />
<pre><br />
root@desk-mx8mm:~# cat /etc/apt/apt.conf<br />
APT::Architecture "arm64";<br />
APT::Get::AllowUnauthenticated "true";<br />
Acquire::Languages "none";<br />
</pre><br />
<br />
Edit the file <code>/etc/apt/sources.list.d/debian-10.list</code> like this:<br />
<pre class="board-terminal"><br />
root@desk-mx8mm:~# cat /etc/apt/sources.list.d/debian-10.list<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ all/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ armv8a-mx8mm/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ desk_mx8mm/<br />
</pre><br />
<br />
Execute the following commands in order to re-create the ''apt'' cache based on the new server's list:<br />
<br />
<pre><br />
rm -rf /var/lib/apt/lists/*<br />
apt-get clean<br />
apt-get update<br />
</pre><br />
<br />
<pre class="board-terminal"><br />
root@desk-mx8mm:~# rm -rf /var/lib/apt/lists/*<br />
root@desk-mx8mm:~# apt-get clean<br />
root@desk-mx8mm:~# apt-get update<br />
Ign:1 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ InRelease<br />
Ign:2 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mm/ InRelease<br />
Ign:3 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mm/ InRelease<br />
Get:4 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release [1215 B]<br />
Get:5 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mm/ Release [1224 B]<br />
Get:6 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mm/ Release [1222 B]<br />
Ign:7 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release.gpg<br />
Ign:8 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mm/ Release.gpg<br />
Ign:9 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mm/ Release.gpg<br />
Get:10 http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Packages [174 kB]<br />
Get:11 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mm/ Packages [304 kB]<br />
Get:12 http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mm/ Packages [259 kB]<br />
Fetched 740 kB in 1s (714 kB/s)<br />
Reading package lists... Done<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 all/ Release (expected all/ but got )<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mm/ Release (expected armv8a-mx8mm/ but got )<br />
W: Conflicting distribution: http://yocto.dave.eu/desk-mx8m-l-4.0.0 desk_mx8mm/ Release (expected desk_mx8mm/ but got )<br />
</pre><br />
<br />
Then, modify the cached package list due to the proper DAVE's server configuration:<br />
<br />
<pre><br />
root@desk-mx8mm:~# sed -i 's/\.\//armv8a-mx8mm\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_armv8a-mx8mm_Packages<br />
root@desk-mx8mm:~# sed -i 's/\.\//desk%5fmx8mm\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_desk%5fmx8mm_Packages<br />
root@desk-mx8mm:~# sed -i 's/\.\//all\//g' /var/lib/apt/lists/yocto.dave.eu_desk-mx8m-l-4.0.0_all_Packages<br />
</pre><br />
<br />
== Installing packages on target ==<br />
<br />
We assume that network interface has been already configured for Internet access. In any case, a simple network configuration can be done according to the [[DESK-MX8M-L/Deployment/How_to_configure_the_network_interfaces#Static_IP_address | How to configure the network interfaces]] wiki page.<br />
<br />
<br />
The target is finally ready to install new packages. The following example shows for instance the installation of <code>graphviz</code>:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx8mp:~# apt-get install graphviz<br />
Reading package lists... Done<br />
Building dependency tree... Done<br />
The following NEW packages will be installed:<br />
graphviz<br />
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.<br />
Need to get 2094 kB of archives.<br />
After this operation, 0 B of additional disk space will be used.<br />
Get:1 http://yocto.dave.eu/desk-mx8m-l-4.0.0 armv8a-mx8mp/ graphviz 2.50.0-r0 [2094 kB]<br />
Fetched 2094 kB in 1s (1913 kB/s)<br />
Selecting previously unselected package graphviz.<br />
(Reading database ... 81414 files and directories currently installed.)<br />
Preparing to unpack .../graphviz_2.50.0-r0_arm64.deb ...<br />
Unpacking graphviz (2.50.0-r0) ...<br />
Setting up graphviz (2.50.0-r0) ...<br />
</pre><br />
<br />
== Other useful apt commands ==<br />
<br />
=== List of configured software repositories ===<br />
As shown before, the target is configured for accessing the Yocto repositories as listed in the <code>/etc/apt/sources.list.d</code> apt configuration directory:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx8mp:~# cat /etc/apt/sources.list.d/debian-10.list<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ all/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ armv8a-mx8mp/<br />
deb [trusted=yes] http://yocto.dave.eu/desk-mx8m-l-4.0.0/ desk_mx8mp/<br />
</pre><br />
<br />
=== Search for packages ===<br />
<br />
To search for an available package into the current configured channels use <code>apt-cache search</code><br />
<br />
Please note that this will show all packages, it's usually more useful to grep for a pattern, e.g.:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx8mp:~# apt-cache search vim<br />
vim - Vi IMproved - enhanced vi editor<br />
vim-common - Vi IMproved - enhanced vi editor<br />
vim-help - Vi IMproved - enhanced vi editor<br />
vim-syntax - Vi IMproved - enhanced vi editor<br />
vim-tutor - Vi IMproved - enhanced vi editor<br />
vim-vimrc - Vi IMproved - enhanced vi editor<br />
</pre><br />
<br />
=== List of installed packages ===<br />
<br />
User can see the list of installed packages with <code>dpkg --get-selections | sed 's:install$::'</code> (sed removes the ''install'' string from the output list)<br />
<br />
<pre><br />
acl<br />
acl-dev<br />
adwaita-icon-theme-symbolic<br />
alsa-conf<br />
alsa-state<br />
alsa-states<br />
alsa-tools<br />
alsa-utils<br />
alsa-utils-aconnect<br />
alsa-utils-alsactl<br />
alsa-utils-alsaloop<br />
alsa-utils-alsamixer<br />
alsa-utils-alsatplg<br />
...<br />
[snip]<br />
...<br />
volatile-binds-dev<br />
wayland<br />
wayland-dev<br />
which<br />
which-dev<br />
wireless-regdb-static<br />
wireless-tools<br />
wpa-supplicant<br />
wpa-supplicant-cli<br />
wpa-supplicant-passphrase<br />
xinetd<br />
xz<br />
xz-dev<br />
</pre></div>U0002https://wiki.dave.eu/index.php?title=DESK-MP1-L/Development/Synchronizing_git_repositories&diff=18280DESK-MP1-L/Development/Synchronizing git repositories2023-08-09T13:27:04Z<p>U0002: /* Synchronizing the git repositories */</p>
<hr />
<div><section begin="History" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |19/07/2023<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK-MP1-L-1.0.0 release<br />
|-<br />
|}<br />
<section end="History" /><br />
__FORCETOC__<br />
<section begin="Body" /><br />
<br />
== Synchronizing the git repositories ==<br />
<br />
In [[DESK-MP1-L | DESK-MP1-L]] the following source trees are clones of the correspondent '''DAVE Embedded Systems''' git repositories:<br />
<br />
{| class="wikitable"<br />
|-<br />
!| Component<br />
!GIT Remote<br />
|-<br />
|ATF<br />
|<code>git@git.dave.eu:desk-mp1-l/arm-trusted-firmware.git</code><br />
|-<br />
|U-Boot<br />
|<code>git@git.dave.eu:desk-mp1-l/u-boot.git</code><br />
|-<br />
|Linux kernel<br />
|<code>git@git.dave.eu:desk-mp1-l/linux.git</code><br />
|-<br />
|Boot Image<br />
|<code>git@git.dave.eu:desk-mp1-l/desk-mp1-boot-image.git</code><br />
|-<br />
|Yocto BSP<br />
|<code>git@git.dave.eu:desk-mp1-l/desk-mp1-l-bsp.git</code><br />
|-<br />
|Yocto meta DESK<br />
|<code>git@git.dave.eu:desk-mp1-l/meta-desk-mp1.git</code><br />
|-<br />
|CubeMX project<br />
|<code>git@git.dave.eu:desk-mp1-l/stm32cubemx.git</code><br />
|-<br />
|}<br />
<br />
For more information about the access to these repositories, please refer to [[DESK-MP1-L/Development/Building_the_Yocto_BSP|this link]].<br />
<br />
Access to DAVE Embedded Systems' git repositories is granted to development kit's owners only. Please refer to [[Accessing_DAVE_Embedded_Systems_restricted_git_repositories|this page]] for detailed instructions on how to get access.<br />
<br />
=== Instructions ===<br />
<br />
The components listed in the table above can be kept in sync and up to date with DAVE Embedded Systems' repositories.<br />
<br />
Once the git account has been enabled, the developer can:<br />
<br />
*clone the repository with the <code>git clone <git_remote_repository></code> command <br />
*synchronize a source tree entering the repository directory and launching the <code>git fetch origin</code> command.<br />
<br />
Please note that git fetch doesn't merge the commits on the current branch. To do that, the developer should run the <code>git merge</code> command or replace the ''fetch-merge'' process with a single <code>git pull</code> command. Please note that the recommended method is the ''fetch-merge'' process. For further information on Git, please refer to the official [http://git-scm.com Git Documentation]<br />
<br />
----<br />
<br />
[[Category:ETRA]] <br />
[[Category:ETRA_SBC]]</div>U0002https://wiki.dave.eu/index.php?title=Template:InfoMessage&diff=18266Template:InfoMessage2023-08-07T09:52:46Z<p>U0002: Created page with "{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;" | style="padding:1em;width: 4..."</p>
<hr />
<div>{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"<br />
| style="padding:1em;width: 40px" | [[Image:Info-icon.png]]<br />
| {{{text|Put here instructions or notes use as <code><nowiki>{{InfoMessage|test=my test to put into box}}</nowiki></code>}}}<br />
| style="padding:1em;width: 40px" | [[Image:Info-icon.png]]<br />
|}<br />
<noinclude><br />
<templatedata><br />
{<br />
"params": {<br />
"text": {<br />
"label": "Text to show",<br />
"default": "Put here instructions or notes",<br />
"example": "Put here instructions or notes",<br />
"type": "string",<br />
"required": true,<br />
"suggested": true<br />
}<br />
}<br />
}<br />
</templatedata><br />
</noinclude></div>U0002https://wiki.dave.eu/index.php?title=DESK-MX6UL-L/Development/Building_U-Boot&diff=18065DESK-MX6UL-L/Development/Building U-Boot2023-07-27T07:02:31Z<p>U0002: fix tag vs branch naming</p>
<hr />
<div><section begin="History" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Version<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|14309|1.0.1}}<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Apr 2021<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |First DESK release<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |2.0.0<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Mar 2022<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK 3.0.0 release<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |3.0.0<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Apr 2023<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK 4.0.0 release<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |3.0.1<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Apr 2023<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |DESK 4.0.1 release<br />
|-<br />
|}<br />
<section end="History" /><br />
__FORCETOC__<br />
<section begin="Body" /><br />
<br />
==Building U-Boot==<br />
<br />
===Quick reference===<br />
{| class="wikitable" border="1"<br />
|+Repository Information<br />
|-<br />
! URL<br />
| git@git.dave.eu:desk-mx-l/u-boot-imx.git<br />
|-<br />
! stable branch<br />
| desk-mx6ul-l-4.x.x<br />
|-<br />
! stable tag<br />
| desk-mx6ul-l-4.0.0<br />
|}<br />
<br />
<span id="u-boot_defconfigs"><br />
<br />
{| class="wikitable" border="1"<br />
|+U-Boot defconfigs<br />
|-<br />
! Platform<br />
! SOM ConfigID<br />
! CB ConfigID<br />
! defconfig<br />
|-<br />
| SDV04<br />
| -<br />
| 0x0000003a<br />
| mx6uldesk_axelulite_defconfig<br />
|-<br />
| SBC Lynx<br />
| 0x00000013<br />
| 0x0000002f<br />
| mx6uldesk_lynx_defconfig<br />
|}<br />
</span><br />
<br />
=== Instructions ===<br />
<br />
It is assumed that the development environment has been set up properly as described [[DESK-MX6UL-L#Quick_start_guide|here]].<br />
* start the Linux development VM and login into the system<br />
* open a terminal window and ''cd'' into U-Boot source code<br />
<br />
<pre class="workstation-terminal"><br />
cd ~/desk-mx-l/u-boot<br />
</pre><br />
<br />
* in case of needs you can update your local repository with the following git command<br />
<br />
<pre class="workstation-terminal"><br />
git pull<br />
</pre><br />
<br />
* configure the build environment<br />
<br />
<pre class="workstation-terminal"><br />
source ~/desk-mx-l/desk-mx6ul-l-4.0.1_env.sh<br />
</pre><br />
<br />
*enter the source tree directory and run the following commands:<br />
<br />
for the [[AXEL_ULite_SOM/AXEL_ULite_Evaluation_Kit | AXEL Ulite EVK]]<br />
<br />
<pre class="workstation-terminal"><br />
make mx6uldesk_axelulite_defconfig<br />
make<br />
</pre><br />
<br />
for the [[SBC Lynx SBC | SBC]] platform:<br />
<br />
<pre class="workstation-terminal"><br />
make mx6uldesk_lynx_defconfig<br />
make<br />
</pre><br />
<br />
NOTE: this is the default configuration suitable for latest <SOM> target.<br />
<br />
:The former command selects the default DESK-MX6UL-L configuration suitable for latest <SOM> targets (for additional defconfig please refer to the [[#u-boot_defconfigs|U-Boot defconfigs table above]]), while the latter builds the U-Boot binary image files (<code>SPL</code> and <code>u-boot.img</code>).<br />
<br />
Binary files can be copied to the tftp root directory <code>/tftpboot/desk-mx-l/</code> with the following command:<br />
<br />
<pre class="workstation-terminal"><br />
cp SPL u-boot.img /tftpboot/desk-mx-l/<br />
</pre><br />
<br />
Please refer to [[DESK-MX6UL-L/Deployment/Standalone_boot|this page]] for more information on how to update the bootloader on your board.<br />
<br />
<br />
----<br />
<br />
[[Category:AXEL ULite]]</div>U0002https://wiki.dave.eu/index.php?title=MVM_FAQs&diff=17853MVM FAQs2023-04-28T13:20:50Z<p>U0002: /* Q: Buffer IO Error for uSD */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies_To_MVM}}<br />
{{InfoBoxBottom}}<br />
<br />
==Configuration==<br />
===Q: VirtualBox manager reports the "The shared folder 'xyz' could not be set up" when starting the MVM. How to fix it?===<br />
This kind of error is due to an incorrect path of the folder(s) shared between the host and the guest machines. The following image shows an example of such an error.<br />
<br />
<br />
[[File:MVM_shared_folders_error1.png|thumb|center|600px]]<br />
<br />
<br />
To fix it, just remove the erroneous shared folders as depicted in the following image.<br />
<br />
<br />
[[File:MVM_shared_folders_error2.png|thumb|center|600px]]<br />
===Q: How to configure the network interface of the MVM?===<br />
Please refer to [[VirtualBox_Network_Configuration|this page]].<br />
=== Q: How to change the keyboard layout of Lightweight X11 Desktop Environment (LXDE)? ===<br />
<br />
To change the keyboard layout, open a terminal (<code>CTRL+ALT+T</code>) and run the following command:<br />
<br />
<shell><br />
sudo dpkg-reconfigure keyboard-configuration<br />
</shell><br />
<br />
Follow the on-screen instruction to select the desired keyboard layout<br />
<br />
===Q: How to use the USB devices connected to the host machine?===<br />
By default, the USB controller of the MVM (guest machine) is not enabled. To enable it, in the VM VirtualBox Manager right click on the selected MVM end open the <code>Settings</code> item. Them, select the <code>USB</code> item and configure it as shown in the following image.<br />
[[File:MVM-add-USB-controller.png|thumb|center|600px]]<br />
<br />
The USB devices which are physically connected to the host machine can be connected to the guest machine with the <code>Devices->USB</code> menu, as shown in the following image.<br />
[[File:MVM-USB-host-devices.png|thumb|center|600px]]<br />
===Q: I can't start <code>make menuconfig</code>. How to fix it?===<br />
If the following error is encountered when trying to configure the Linux kernel via <code>menuconfig</code><br />
<pre><br />
dvdk@vagrant-ubuntu-trusty-64:~/lynx/linux$ make O=../linux-build/ menuconfig<br />
GEN /home/dvdk/lynx/linux-build/Makefile<br />
*** Unable to find the ncurses libraries or the<br />
*** required header files.<br />
*** 'make menuconfig' requires the ncurses libraries.<br />
*** <br />
*** Install ncurses (ncurses-devel) and try again.<br />
*** <br />
make[2]: *** [scripts/kconfig/dochecklxdialog] Error 1<br />
make[1]: *** [menuconfig] Error 2<br />
make: *** [sub-make] Error 2<br />
</pre><br />
, required libraries are missing.<br />
<br />
Please install the following packages:<br />
*<code>libncurses5-dev</code><br />
*<code>libncursesw5-dev</code>.<br />
===Q: Is it possible to resize the virtual disk?===<br />
Yes, but you need to convert the image to VDI format first. For example, see [https://www.jamescoyle.net/how-to/2000-convert-virtual-disk-image-vmware-vmdk-to-virtualbox-vdi this page].<br />
<br />
Once you have the VDI file, follow the procedure described [https://www.howtogeek.com/124622/how-to-enlarge-a-virtual-machines-disk-in-virtualbox-or-vmware/ here].<br />
<br />
=== Q: I get an OpenSSL error when accessing resources over TLS, e.g. download using wget on https. How to fix this? ===<br />
This errors is caused when an old version of OpenSSL, e.g. like the one present on an non-updated Ubuntu 12.04, is used to access resources using TLS, e.g.:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 22:59:47-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.3, 140.82.118.4<br />
Connecting to github.com (github.com)|140.82.118.3|:443... connected.<br />
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version<br />
Unable to establish SSL connection.<br />
<br />
</syntaxhighlight>To fix this user just have to updates OpenSSL and related libraries, using the following commands:<syntaxhighlight lang="bash"><br />
sudo apt-get update<br />
sudo apt-get install libssl-dev curl wget openssl<br />
</syntaxhighlight>This is the result:<syntaxhighlight lang="bash"><br />
dvdk@dvdkVM:~$ wget https://github.com/openssl/openssl/archive/master.zip<br />
--2018-11-15 23:02:38-- https://github.com/openssl/openssl/archive/master.zip<br />
Resolving github.com (github.com)... 140.82.118.4, 140.82.118.3<br />
Connecting to github.com (github.com)|140.82.118.4|:443... connected.<br />
HTTP request sent, awaiting response... 302 Found<br />
Location: https://codeload.github.com/openssl/openssl/zip/master [following]<br />
--2018-11-15 23:02:39-- https://codeload.github.com/openssl/openssl/zip/master<br />
Resolving codeload.github.com (codeload.github.com)... 192.30.253.120, 192.30.253.121<br />
Connecting to codeload.github.com (codeload.github.com)|192.30.253.120|:443... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: unspecified [application/zip]<br />
Saving to: `master.zip'<br />
<br />
[ <=> ] 652.482 694K/s<br />
</syntaxhighlight><br />
<br />
=== Q: Buffer I/O Error when accessing USB devices ===<br />
When trying to write a large file on a USB device (e.g. micro SD, connected to the MVM through an adapter) user may experience some ''Buffer I/O errors'' (followed by additional kernel errors, depending on the specific operation that caused the error) like the following (use <code>dmesg</code> on a terminal to see the kernel log buffer) <pre class="mw-collapsible mw-collapsed"><br />
[ 358.392710] sdb: sdb1 sdb2<br />
[ 880.588382] EXT4-fs (sdb2): mounting ext3 file system using the ext4 subsystem<br />
[ 881.046203] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)<br />
[ 1008.759054] usb 1-1: USB disconnect, device number 2<br />
[ 1008.778105] blk_update_request: I/O error, dev sdb, sector 19338752 op 0x1:(WRITE) flags 0x4000 phys_seg 14 prio class 0<br />
[ 1008.778116] blk_update_request: I/O error, dev sdb, sector 19091736 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778119] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386468)<br />
[ 1008.778121] Buffer I/O error on device sdb2, logical block 289315<br />
[ 1008.778128] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386469)<br />
[ 1008.778128] Buffer I/O error on device sdb2, logical block 289316<br />
[ 1008.778130] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386470)<br />
[ 1008.778130] Buffer I/O error on device sdb2, logical block 289317<br />
[ 1008.778132] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386471)<br />
[ 1008.778133] Buffer I/O error on device sdb2, logical block 289318<br />
[ 1008.778135] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386472)<br />
[ 1008.778136] Buffer I/O error on device sdb2, logical block 289319<br />
[ 1008.778138] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386473)<br />
[ 1008.778138] Buffer I/O error on device sdb2, logical block 289320<br />
[ 1008.778140] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386474)<br />
[ 1008.778140] Buffer I/O error on device sdb2, logical block 289321<br />
[ 1008.778141] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386475)<br />
[ 1008.778142] Buffer I/O error on device sdb2, logical block 289322<br />
[ 1008.778144] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386476)<br />
[ 1008.778144] Buffer I/O error on device sdb2, logical block 289323<br />
[ 1008.778146] EXT4-fs warning (device sdb2): ext4_end_bio:311: I/O error 10 writing to inode 853990 (offset 0 size 0 starting block 2386477)<br />
[ 1008.778146] Buffer I/O error on device sdb2, logical block 289324<br />
[ 1008.778208] blk_update_request: I/O error, dev sdb, sector 19338992 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0<br />
[ 1008.778222] blk_update_request: I/O error, dev sdb, sector 19358224 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0<br />
[ 1008.778262] blk_update_request: I/O error, dev sdb, sector 19091976 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778282] blk_update_request: I/O error, dev sdb, sector 19092216 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778317] blk_update_request: I/O error, dev sdb, sector 44090904 op 0x1:(WRITE) flags 0x0 phys_seg 10 prio class 0<br />
[ 1008.778325] blk_update_request: I/O error, dev sdb, sector 19092456 op 0x1:(WRITE) flags 0x4800 phys_seg 30 prio class 0<br />
[ 1008.778356] blk_update_request: I/O error, dev sdb, sector 19339136 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0<br />
[ 1008.778364] blk_update_request: I/O error, dev sdb, sector 19358464 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0<br />
[ 1008.778423] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 13, block_bitmap = 425984<br />
[ 1008.778456] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778458] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778558] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 14, block_bitmap = 458752<br />
[ 1008.778615] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778617] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778626] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 15, block_bitmap = 491520<br />
[ 1008.778677] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778678] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778686] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 16, block_bitmap = 524288<br />
[ 1008.778735] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778737] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.778744] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 17, block_bitmap = 557056<br />
[ 1008.778826] Buffer I/O error on dev sdb2, logical block 0, lost sync page write<br />
[ 1008.778828] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.839764] Buffer I/O error on dev sdb2, logical block 131072, lost async page write<br />
[ 1008.839769] Buffer I/O error on dev sdb2, logical block 164865, lost async page write<br />
[ 1008.839776] Buffer I/O error on dev sdb2, logical block 196608, lost async page write<br />
[ 1008.839778] Buffer I/O error on dev sdb2, logical block 230401, lost async page write<br />
[ 1008.839795] Buffer I/O error on dev sdb2, logical block 2818048, lost async page write<br />
[ 1008.841976] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.842006] Aborting journal on device sdb2-8.<br />
[ 1008.842011] JBD2: Error -5 detected when updating journal superblock for sdb2-8.<br />
[ 1008.842130] JBD2: Detected IO errors while flushing file data on sdb2-8<br />
[ 1008.851777] EXT4-fs (sdb2): I/O error while writing superblock<br />
[ 1008.851780] EXT4-fs error (device sdb2): ext4_journal_check_start:61: Detected aborted journal<br />
[ 1008.851780] EXT4-fs (sdb2): Remounting filesystem read-only<br />
[ 1008.921620] JBD2: Error while async write back metadata bh 131072.<br />
[ 1008.921621] JBD2: Error while async write back metadata bh 164865.<br />
[ 1008.921624] JBD2: Error while async write back metadata bh 196608.<br />
[ 1008.921649] JBD2: Error while async write back metadata bh 230401.<br />
[ 1008.921864] JBD2: Error while async write back metadata bh 2818048.<br />
[ 1008.922181] JBD2: Error while async write back metadata bh 2818637.<br />
...<br />
[ 1008.924465] JBD2: Error while async write back metadata bh 3408720.<br />
[ 1008.924467] JBD2: Error while async write back metadata bh 3408721.<br />
[ 1009.027187] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027191] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027193] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 12, block_bitmap = 393216<br />
[ 1009.027194] EXT4-fs error (device sdb2): ext4_discard_preallocations:4113: comm tar: Error -5 reading block bitmap for 12<br />
[ 1009.027200] EXT4-fs error (device sdb2): ext4_wait_block_bitmap:519: comm tar: Cannot read block bitmap - block_group = 18, block_bitmap = 589824<br />
[ 1014.162995] EXT4-fs error: 30 callbacks suppressed<br />
[ 1014.162997] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163016] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163160] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163163] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163178] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163181] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163192] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163194] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163204] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1014.163207] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736540] EXT4-fs error: 4649 callbacks suppressed<br />
[ 1020.736541] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736679] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736707] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736733] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736741] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736909] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736917] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736946] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.736955] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1020.737113] EXT4-fs error (device sdb2): __ext4_find_entry:1577: inode #819201: comm tar: reading directory lblock 0<br />
[ 1022.476182] EXT4-fs warning: 33909 callbacks suppressed<br />
[ 1022.476184] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476187] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476189] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476192] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476193] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476196] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476198] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476200] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476202] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
[ 1022.476204] EXT4-fs warning (device sdb2): dx_probe:786: inode #851989: lblock 0: comm tar: error -5 reading directory block<br />
</pre><br />
<br />
The root cause of the problem may vary (e.g. Windows host OS device drivers, host hardware issue, Virtual Box incompatibility with host OS and so on) but, in our experience, this is caused by poor USB device or SD card reader.<br />
<br />
For this reason, as first action we suggest to change SD card adapter with a more robust one<br />
<br />
E.g. we've found that simple adapters like the one in the following picture, most of the time shows this kind of error during the creation of bootable SD card (like the one described in [[DESK-MX8M-L/Development/How to create a bootable microSD card|this article]])<br />
<br />
[[File:Generic-card-reader.jpg|none|thumb]]</div>U0002https://wiki.dave.eu/index.php?title=Accessing_DAVE_Embedded_Systems_restricted_git_repositories&diff=17130Accessing DAVE Embedded Systems restricted git repositories2022-11-14T14:11:41Z<p>U0002: fix mediawiki category typo</p>
<hr />
<div><br />
[[Category:Software]]<br />
<br />
{{InfoBoxTop}}<br />
{{Applies_To_DVDK}}<br />
{{Applies_To_MVM}}<br />
{{InfoBoxBottom}}<br />
__FORCETOC__<br />
<br />
==Introduction==<br />
<br />
Generally speaking, source code maintained by DAVE Embedded Systems is delivered to customers via restricted-access [https://git-scm.com git] repositories. To access these repositories a public key is required, as described in the following section.<br />
<br />
On explicit request, DAVE Embedded Systems also provide https access to its repositories. Please see the https section below for more information.<br />
<br />
== Public key access ==<br />
<br />
Public key is the default authorization system for our git repositories. User needs to generate a RSA key pair and send the ''public'' key to the support team, which will grant access to the specific repository.<br />
<br />
=== RSA key generation ===<br />
<br />
Please follow this procedure to generate the RSA ssh key. It is assumed that the host machine is Linux-based (such as [[:Category:DVDK|DVDKs]] and [[Managed_Virtual_Machine_(MVM)|MVMs]]).<br />
<br />
* pick you main corporate e-mail and use it instead of <code>myname@mycompany.com</code> in the examples below<br />
* start the host machine and log in into it<br />
* start a shell session (usually with CTRL-ALT-T)<br />
* enter the <code>.ssh</code> subdirectory into your home directory: <code>cd ~/.ssh/</code><br />
* launch the following command:<br />
<br />
<pre>ssh-keygen -t rsa -C "myname@mycompany.com" -f myname@mycompany.com</pre><br />
<br />
* this command creates the files <code>~/.ssh/myname@mycompany.com</code> ('''private key''') and <code>~/.ssh/myname@mycompany.com.pub</code> ('''public key''')<br />
* edit your <code>~/.ssh/config</code> by adding the following lines:<br />
<br />
<pre><br />
Host git.dave.eu<br />
User git<br />
Hostname git.dave.eu<br />
PreferredAuthentications publickey<br />
IdentityFile ~/.ssh/myname@mycompany.com<br />
</pre><br />
<br />
<br />
{{ImportantMessage|text=Please make sure that <code>~/.ssh/config</code> has the right ownership/access right<br />
<br />
<pre><br />
chmod 600 ~/.ssh/config<br />
chown $USER ~/.ssh/config<br />
</pre><br />
<br />
Please refer to [https://linux.die.net/man/5/ssh_config ssh_config man page]<br />
}}<br />
<br />
<br />
* Send the request for the creation of a new public git account associated to your username, to the following support email address: [mailto:helpdesk@dave.eu helpdesk@dave.eu]. Please indicate in the subject the name of the product and/or the development kit. The technical support team will enable the account and send you a confirmation as soon as possible.<br />
<br />
* Once you have the confirm that your account has been enabled, the easier way to check that everything is configured correctly is to run the following command on you development workstation<br />
<br />
<pre><br />
ssh git@git.dave.eu<br />
</pre><br />
<br />
The output will show you not only that you have successfully login into DAVE Embedded Systems' git server but also which repository you can access and with what access rights. In the following example the user have access all [[AXEL ULite and SBC Lynx Embedded Linux Kit (XUELK)|XUELK]] repository in read-only mode:<br />
<br />
<pre><br />
bash# ssh git@git.dave.eu<br />
PTY allocation request failed on channel 0<br />
hello YOURNAME, this is gitolite 2.2-1 (Debian) running on git 1.7.9.5<br />
the gitolite config gives you the following access:<br />
R lynx/..*<br />
Connection to git.dave.eu closed.<br />
</pre><br />
<br />
=== Troubleshooting ===<br />
<br />
In case of trouble use ssh verbose mode by using <code>-vvv</code> command line switch (<code>ssh -vvv git@git.dave.eu</code>) and send its output text to [mailto:support@dave.eu DAVE Embedded Systems' support team].<br />
<br />
=== Server fingerprint ===<br />
<br />
When establishing the fist ssh connection, the default behavior of Linux ssh clients is to ask about ECDSA fingerprint confirmation, which will look like the following:<br />
<br />
<pre><br />
bash# ssh git@git.dave.eu<br />
The authenticity of host 'git.dave.eu (46.252.156.152)' can't be established.<br />
ECDSA key fingerprint is ff:1b:14:0e:f8:89:af:40:52:18:6e:9f:6f:1f:a7:d4.<br />
Are you sure you want to continue connecting (yes/no)? <br />
</pre><br />
<br />
or:<br />
<br />
<pre><br />
bash# ssh git@git.dave.eu<br />
The authenticity of host 'git.dave.eu (46.252.156.152)' can't be established.<br />
ECDSA key fingerprint is SHA256:P3RfK2M6ICVfvzKAozujgMopvos7Ls897qG/FqInr54.<br />
Are you sure you want to continue connecting (yes/no)? <br />
</pre><br />
<br />
Current git.dave.eu ECDSA fingerprint are listed below:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Hash !! Fingerprint<br />
|-<br />
| SHA256 || <code>P3RfK2M6ICVfvzKAozujgMopvos7Ls897qG/FqInr54</code><br />
|-<br />
| MD5 || <code>ff:1b:14:0e:f8:89:af:40:52:18:6e:9f:6f:1f:a7:d4</code><br />
|}<br />
<br />
In case of server move (e.g. to improve it's performance), serve side RSA keys, and this its signatures, will get updated too. In this case standard ssh clients will refuse to connect showing a warning like the following:<br />
<br />
<pre><br />
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br />
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @<br />
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br />
The ECDSA host key for git.dave.eu has changed,<br />
and the key for the corresponding IP address xxx.xxx.xxx.xxx<br />
is unchanged. This could either mean that<br />
DNS SPOOFING is happening or the IP address for the host<br />
and its host key have changed at the same time.<br />
Offending key for IP in /home/user/.ssh/known_hosts:24<br />
remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R xxx.xxx.xxx.xxx<br />
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br />
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @<br />
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@<br />
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!<br />
Someone could be eavesdropping on you right now (man-in-the-middle attack)!<br />
It is also possible that a host key has just been changed.<br />
The fingerprint for the ECDSA key sent by the remote host is<br />
ff:1b:14:0e:f8:89:af:40:52:18:6e:9f:6f:1f:a7:d4.<br />
Please contact your system administrator.<br />
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.<br />
Offending ECDSA key in /home/user/.ssh/known_hosts:31<br />
remove with: ssh-keygen -f "/home/user/.ssh/known_hosts" -R git.dave.eu<br />
ECDSA host key for git.dave.eu has changed and you have requested strict checking.<br />
Host key verification failed.<br />
</pre><br />
<br />
In this case:<br />
* take a look on this page to check the ECDSA signature<br />
* if the signature corresponds, use the following command to clear the obsolete local cached signature<br />
<br />
<pre><br />
ssh-keygen -f ~/.ssh/known_hosts -R git.dave.eu<br />
</pre><br />
<br />
Upon next connection, ssh client will prompt the user to confirm ECDSA signature like it was the first time connecting to the server.<br />
<br />
=== Your Identity ===<br />
<br />
The first thing you should do when you install git is to set your user name and email address. <br />
This is important because every git commit uses this information, and they are written into your commits:<br />
<br />
<pre><br />
git config --global user.name "Name Surname"<br />
git config --global user.email myname@mycompany.com<br />
</pre><br />
<br />
Please find documentation [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup here] and [https://www.kernel.org/pub/software/scm/git/docs/git-config.html here] for more information.<br />
<br />
== HTTPS access ==<br />
<br />
Some organization filter all outgoing Internet communication apart the one using standard HTTP/HTTPS well known ports (TCP 80 and 443). This will prevent also SSH connection (TCP 22) and, thus, will not allow to access DAVE Embedded Systems' git repositories using the public key authentication method.<br />
<br />
To let those organization access git server, we also provide HTTPS connection, using a standard username/password pair.<br />
<br />
=== Access credential ===<br />
<br />
Access credential are generated on-demand by DAVE Embedded Systems support team. If you need https access, write an email to [mailto:support@dave.eu us] and we'll generate the credential for you.<br />
<br />
Please note that username and password cannot be reset neither recovery without contacting the [mailto:support@dave.eu support team via email]<br />
<br />
=== Git URI mapping ===<br />
<br />
The default access to our git repositories is via public key and, thus SSH. For this reason all the GIT URI on our documentation (in all forms) are the ssh one. However there's a simple rule to map SSH URI to HTTPS URI as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! SSH URI !! HTTPS URI<br />
|-<br />
| git@git.dave.eu:project/repository.git || <nowiki>https://git.dave.eu/git/project/repository.git</nowiki><br />
|}<br />
<br />
E.g. <code>git@git.dave.eu:lynx/linux-2.6-imx.git</code> can be accesses via https as <code><nowiki>https://git.dave.eu/git/lynx/linux-2.6-imx.git</nowiki></code><br />
<br />
=== Username/password caching ===<br />
<br />
By default, every git command executed via https on git.dave.eu will ask for the username/password couple. This might be annoying and a simple workaround is to let git cache your credential on the current shell for a given time.<br />
<br />
First of all enable credential caching, in your global git configuration, e.g.:<br />
<br />
<pre><br />
git config credential.helper cache<br />
</pre><br />
<br />
User can change the default cache drop timeout by adding <code>--timeout=secs</code> paramater. E.g. the following command set caching timeout to 5 minutes:<br />
<br />
<pre><br />
git config credential.helper 'cache --timeout=300'<br />
</pre><br />
<br />
For more information, see the [https://git-scm.com/docs/git-credential-cache official git documentation]</div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-015:_Yocto_and_git_protocol_error&diff=16443MISC-TN-015: Yocto and git protocol error2022-04-22T14:41:19Z<p>U0002: </p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAXEL Lite TN}}<br />
{{AppliesToAXEL ULite TN}}<br />
{{AppliesToBORA TN}}<br />
{{AppliesToBORA Xpress TN}}<br />
{{AppliesToBORA Lite TN}}<br />
{{Applies To Yocto}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
{{InfoBoxBottom}}<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|Apr 2022<br />
|First public release<br />
|}<br />
<br />
==Introduction==<br />
Starting from beginning of 2022, there was a policy change on most git hosting services to restrict "unsecure" git protocol for security issues.<br />
<br />
GitHub security access has been changed for accessing the git repositories via ssh: more information can be found in the following news [https://github.blog/2021-09-01-improving-git-protocol-security-github/ Improving Git protocol security on GitHub].<br />
<br />
As reported :<br />
<br />
''We’re changing which keys are supported in SSH and removing unencrypted Git protocol. Only users connecting via SSH or git:// will be affected. If your Git remotes start with https://, nothing in this post will affect you. If you’re an SSH user, read on for the details and timeline.'' <br />
<br />
<br />
This is already applied in DAVE BSPs published after March 2022 but older BSPs, published prior this change, may need to be fixed manually to use ssh instead of <code>git://</code> to access some repositories<br />
<br />
This Technical Note shows an example on how to update those older releases to solve this issue<br />
<br />
== BSP repo Manifest ==<br />
DAVE Yocto BSPs uses [https://gerrit.googlesource.com/git-repo/ repo] to track the multiple layers required to setup the BSP itself<br />
<br />
If <code>git</code> protocol is used to clone some these layers, user will encounter the above issue<br />
<br />
Here there is an example using the {{OldRevision|page=DESK-MX6-L/Development/Building the Yocto BSP|revision=14300|text=DESK-MX6-L-1.0.0}}page instructions for building the overall BSP while fixing the manifest<br />
<br />
=== Setup with original manifest===<br />
The original file, as per <code>desk-mx6-l-1.0.1</code> tag, uses the <code>git</code> protocol to clone some layers:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<manifest><br />
<br />
<default sync-j="2"/><br />
<br />
<remote fetch="git://git.yoctoproject.org" name="yocto"/><br />
<remote fetch="git://github.com/Freescale" name="freescale"/><br />
<remote fetch="git://git.openembedded.org" name="oe"/><br />
<remote fetch="git://github.com/OSSystems" name="OSSystems"/><br />
<remote fetch="git://github.com/meta-qt5" name="QT5"/><br />
<remote fetch="git://github.com/meta-rust" name="rust"/><br />
<remote fetch="https://source.codeaurora.org/external/imx" name="CAF" /><br />
<remote fetch="ssh://git@git.dave.eu/" name="DAVE"/><br />
...<br />
...<br />
</pre><br />
in this case, multiple access error will be prompted while running <code>repo sync</code>:<br />
<br />
dvdk@vagrant:~/yocto$ ./repo sync<br />
% Total % Received % Xferd Average Speed Time Time Time Current<br />
Dload Upload Total Spent Left Speed<br />
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0remote: Counting objects: 101, done. <br />
remote: Compressing objects: 100% (99/99), done. <br />
remote: Total 101 (delta 27), reused 0 (delta 0) <br />
Receiving objects: 100% (101/101), 15.88 KiB | 7.94 MiB/s, done.<br />
Resolving deltas: 100% (27/27), done.<br />
From ssh://git.dave.eu/desk-mx-l/desk-mx-l-bsp<br />
* [new branch] hardknott -> DAVE/hardknott<br />
* [new branch] sumo -> DAVE/sumo<br />
* [new tag] desk-mx6-l-1.0.1 -> desk-mx6-l-1.0.1<br />
* [new tag] desk-mx6-l-1.0.0 -> desk-mx6-l-1.0.0<br />
* [new tag] desk-mx6-l-1.0.2 -> desk-mx6-l-1.0.2<br />
* [new tag] desk-mx6-l-3.0.0 -> desk-mx6-l-3.0.0<br />
* [new tag] desk-mx6ul-l-1.0.0 -> desk-mx6ul-l-1.0.0<br />
* [new tag] desk-mx6ul-l-1.0.1 -> desk-mx6ul-l-1.0.1<br />
* [new tag] desk-mx6ul-l-3.0.0 -> desk-mx6ul-l-3.0.0<br />
* [new tag] desk-mx8m-l-2.0.0-rc2 -> desk-mx8m-l-2.0.0-rc2<br />
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0<br />
'''fatal: remote error: '''<br />
''' The unauthenticated git protocol on port 9418 is no longer supported.'''<br />
'''Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.'''<br />
100 145 100 145 0 0 147 0 --:--:-- --:--:-- --:--:-- 147<br />
100 15.5M 100 15.5M 0 0 2051k 0 0:00:07 0:00:07 --:--:-- 2660k<br />
Receiving objects: 100% (182040/182040), 15.58 MiB | 37.81 MiB/s, done.<br />
Resolving deltas: 100% (126131/126131), done.<br />
From /home/dvdk/yocto/.repo/projects/sources/meta-fsl-bsp-release.git/clone.bundle<br />
* [new branch] warrior-4.19.35-1.1.0 -> CAF/warrior-4.19.35-1.1.0<br />
* [new branch] thud-4.19.35-1.0.0 -> CAF/thud-4.19.35-1.0.0<br />
* [new branch] sumo-4.14.98-2.3.0 -> CAF/sumo-4.14.98-2.3.0<br />
...<br />
...<br />
<br />
=== Fixing repo manifest===<br />
<code>repo</code> stores the current manifest in <code>.repo/manifest.xml</code>: this is the file that needs to be patched to solve this issue locally<br />
<br />
After <code>repo init</code> and prior <code>repo sync</code>, user need to edit <code>.repo/manifest.xml</code> to change all occurrence of <code>git://</code> protocol specifier to <code>https://</code><br />
<br />
This can be also applied with a simple <code>sed</code> command:<syntaxhighlight lang="bash"><br />
sed -i 's/git:\/\//https:\/\//g' .repo/manifest.xml<br />
</syntaxhighlight><br />
Please note that, for <code>DESK-MX6-L-1.x.x</code>, this is already fixed in <code>desk-mx6-l-1.0.2</code> release:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<manifest><br />
<br />
<default sync-j="2"/><br />
<br />
<remote fetch="https://git.yoctoproject.org" name="yocto"/><br />
<remote fetch="https://github.com/Freescale" name="freescale"/><br />
<remote fetch="https://git.openembedded.org" name="oe"/><br />
<remote fetch="https://github.com/OSSystems" name="OSSystems"/><br />
<remote fetch="https://github.com/meta-qt5" name="QT5"/><br />
<remote fetch="https://github.com/meta-rust" name="rust"/><br />
<remote fetch="https://source.codeaurora.org/external/imx" name="CAF" /><br />
<remote fetch="ssh://git@git.dave.eu/" name="DAVE"/><br />
...<br />
...<br />
</pre><br />
<br />
To be precise the <code>diff</code> between the two releases is:<syntaxhighlight lang="diff"><br />
diff --git a/default.xml b/default.xml<br />
index f4d7443..1a4d7fb 100644<br />
--- a/default.xml<br />
+++ b/default.xml<br />
@@ -3,12 +3,12 @@<br />
<br />
<default sync-j="2"/><br />
<br />
- <remote fetch="git://git.yoctoproject.org" name="yocto"/><br />
- <remote fetch="git://github.com/Freescale" name="freescale"/><br />
- <remote fetch="git://git.openembedded.org" name="oe"/><br />
- <remote fetch="git://github.com/OSSystems" name="OSSystems"/><br />
- <remote fetch="git://github.com/meta-qt5" name="QT5"/><br />
- <remote fetch="git://github.com/meta-rust" name="rust"/><br />
+ <remote fetch="https://git.yoctoproject.org" name="yocto"/><br />
+ <remote fetch="https://github.com/Freescale" name="freescale"/><br />
+ <remote fetch="https://git.openembedded.org" name="oe"/><br />
+ <remote fetch="https://github.com/OSSystems" name="OSSystems"/><br />
+ <remote fetch="https://github.com/meta-qt5" name="QT5"/><br />
+ <remote fetch="https://github.com/meta-rust" name="rust"/><br />
<remote fetch="https://source.codeaurora.org/external/imx" name="CAF" /><br />
<remote fetch="ssh://git@git.dave.eu/" name="DAVE"/><br />
<br />
</syntaxhighlight><br />
<br />
== Layer recipes ==<br />
While most of Yocto recipes used tar (or similar) archive to get source code, some of them download source code using git.<br />
<br />
Usually <code>https</code> protocol is used for this, but in some cases <code>SRC_URI</code> may need to be updated if plain <code>git</code> protocol is used (and if the git server implements GitHub like security policies)</div>U0002https://wiki.dave.eu/index.php?title=Template:OldRevision&diff=16442Template:OldRevision2022-04-22T14:23:24Z<p>U0002: </p>
<hr />
<div><span class="plainlinks">[{{fullurl:{{{page}}}|oldid={{{revision}}}}} {{{text}}}]</span><br />
<noinclude><br />
<templatedata><br />
{<br />
"params": {<br />
"page": {},<br />
"revision": {},<br />
"text": {}<br />
}<br />
}<br />
</templatedata><br />
</noinclude></div>U0002https://wiki.dave.eu/index.php?title=DESK-MX8M-L/General/Release_Notes&diff=16387DESK-MX8M-L/General/Release Notes2022-04-11T10:24:55Z<p>U0002: /* Downloadable binary images */</p>
<hr />
<div><section begin="History" /><br />
{| style="border-collapse:collapse; "<br />
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History<br />
|- <br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Version<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date<br />
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes<br />
|-<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |1.0.0<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Feb 2022<br />
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |First DESK-MX8M-L version<br />
|-<br />
|}<br />
<section end="History" /><br />
<section begin="Body" /><br />
<br />
__TOC__<br />
<br />
==Release Notes==<br />
<br />
'''DAVE Embedded Systems''' adds to the latest Linux BSP from NXP the customization required to support the SOC platform. For this reason, most of the documentation provided by NXP remains valid for the DESK development kit. <br />
<br />
However, some customization is required, in particular at bootloader and linux kernel levels.<br />
<br />
The following table reports the DESK releases information.<br />
{| class="wikitable" <br />
!<br />
! width="300pt" |DESK version<br />
|-<br />
|Release number<br />
|2.0.0-rc2<br />
|-<br />
|Release type<br />
|Major<br />
|-<br />
|Status<br />
|In progress<br />
|-<br />
|Release date<br />
|Feb 2022<br />
|-<br />
|'''Release notes'''<br />
| [[#DESK_2.0.0 | Ver 2.0.0]]<br />
|-<br />
|Product support<br />
|[[MITO 8M Mini SOM |MITO 8M Mini]], [[ORCA SOM | ORCA]]<br />
|-<br />
|MVM (distro version)<br />
|Ubuntu 16.04<br />
|-<br />
|U-Boot version<br />
|2020.04-desk-mx8-l-2.0.0-rc2 <br />
|-<br />
|Linux version<br />
|5.4.70-desk-mx8-l-2.0.0-rc2 <br />
|-<br />
|Drivers<br />
| <br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
UART debug (2-wire)<br>USB Host<br>USB OTG<br>SD/MMC1<br>Touch screen <br>Ethernet<br />
</div><br />
<div style="width:100%;"><br />
<div style="width:50%; float: left;"><br />
LVDS<br>RTC<br>I2C<br>SPI<br>PCIe<br>[[ConfigID_and_UniqueID | ConfigID]]<br />
</div><br />
|-<br />
|Manufacturer BSP version<br />
|rel_imx_5.4.70_2.3.0<br />
|-<br />
|Graphic libraries<br />
|Qt 5.13.2<br />
|-<br />
|Build System<br />
|Yocto zeus<br />
|-<br />
|}<br />
<br />
=== DESK-MX8M-L 2.0.0-rc2 ===<br />
<br />
{{ImportantMessage|text=New MVM must be installed for using <code>DESK-MX8M-L-2.0.0</code>. The VM is available for download on DAVE's MITO Reserved Area for registered users.}}<br />
<br />
Release notes:<br />
<br />
* First release based on NXP BSP 5.4.70<br />
<br />
==== Known Limitations ====<br />
<br />
The following table reports the known limitations of this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Issue<br />
!Description<br />
|-<br />
|HDMI not working<br />
|HDMI is not working on ORCA SBC. Device tree fixing is required<br />
|-<br />
|}<br />
<br />
====Downloadable binary images====<br />
<br />
All binary images for [[DESK-MX8M-L]] are hosted on [http://mirror.dave.eu/desk-mx-l/desk-mx8m-l-2.0.0-rc2/ DAVE Embedded System mirror server]. There you can find a subdirectory for each version of this development kit.<br />
<br />
U-boot performs a container image providing a single file: <code>flash.bin</code>. The binary file must be stored into SD card using <code>dd</code> command.<br />
<br />
A summary of images with a brief description can be found into the table below:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Image <br />
! colspan="2" | DESK version 2.0.0-rc2<br />
|-<br />
| Platform <br />
| style="text-align: center" | ORCA SBC <br />
| style="text-align: center" | SBCX<br />
|-<br />
| Carrier Board [[ConfigID_and_UniqueID | ConfigID]] <br />
| style="text-align: center" | 1001 <br />
| style="text-align: center" | 1003<br />
|-<br />
| LCD panel <br />
| style="text-align: center" | HDMI<br />
| style="text-align: center" | Ampire 1280 x 800 10.1" LVDS<br />
|-<br />
| Touchscreen <br />
| style="text-align: center" | capacitive<br />
| style="text-align: center" | capacitive<br />
|-<br />
| bootscript <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mp_boot.scr|boot.scr]]<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mm_boot.scr|boot.scr]]<br />
|-<br />
| flash.bin<br> (SD or eMMC)<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mp_flash.bin|flash.bin]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mm_flash.bin|flash.bin]] <br />
|-<br />
| Linux kernel <br />
| colspan="2" style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_Image|Image]]<br />
|-<br />
| Device tree<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mp-mito8mplus-cb1001.dtb|imx8mp-mito8mplus-cb1001.dtb]] <br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/desk-mx8m-l-2.0.0-rc2_imx8mm-mito8mmini.dtb|imx8mm-mito8mmini.dtb]]<br />
|-<br />
| root file system<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/dave-image-devel-desk-mx8mp.tar.bz2 | dave-image-devel-desk-mx8mp]]<br />
| style="text-align: center" | [[mirror:desk-mx-l/desk-mx8m-l-2.0.0-rc2/dave-image-devel-desk-mx8mm.tar.bz2 | dave-image-devel-desk-mx8mm]]<br />
|}<br />
<br />
=== Release types ===<br />
<br />
DESK release type can be:<br />
* '''Major''', when substantial changes are applied to the BSP (eg: major kernel version upgrades) or to the development kit (eg: new features, build system updates, ..). This usually means that a new DVDK is created for the DESK release<br />
* '''Maintenance''', when minor updates and bug fixes are introduced. This usually means that the DVDK remains the same provided with the previous major version, and only an update of the source tree repositories (and the tftp binaries) is required<br />
<br />
As an example, DESK 2.1.0 is a maintenance release, so it provides the DVDK released with the 2.0.0 major release; customers can easily upgrade to the 1.1.0 release by updating the software components as described in [[DESK-MX8M-L/Development/Synchronizing_git_repositories|Synchronizing git repositories]].<br />
<br />
=== Supported platforms ===<br />
<br />
The following table reports the supported platforms in this DESK release:<br />
<br />
{| class="wikitable" <br />
|-<br />
!Platform<br />
!Description<br />
|-<br />
|[[ORCA SBC | SBC ORCA]]<br />
|Single Board Computer using ORCA SOM as [[ORCA SOM/ORCA Evaluation_Kit | Evaluation Kit]]<br />
|-<br />
|[[SBC_Axel_SBC | SBC AXEL]]<br />
|Single Board Computer using MITO 8M Mini SOM as [[MITO 8M Mini SOM/MITO 8M Mini Evaluation_Kit | Evaluation Kit]]<br />
|-<br />
|}<br />
<br />
----<br />
<br />
[[Category:ORCA]] <br />
[[Category:MITO 8M Mini]]</div>U0002https://wiki.dave.eu/index.php?title=Sandbox&diff=14281Sandbox2021-07-20T21:49:38Z<p>U0002: </p>
<hr />
<div>Test<br />
<br />
Test nr2<br />
<br />
<fusion365 height="600" width="800">SH56a43QTfd62c1cd9686f9424187e3f8f2c</fusion365></div>U0002https://wiki.dave.eu/index.php?title=MediaWiki:Sidebar&diff=14054MediaWiki:Sidebar2021-07-15T20:28:02Z<p>U0002: </p>
<hr />
<div><br />
* navigation<br />
* Quick Links<br />
** mainpage|Wiki Main Page<br />
** Machine Learning Services|ML/AI Services<br />
** IoT Services|IoT Services<br />
** Embedded Design Services|Embedded Design Services<br />
** Main Page#System On Module|SOMs<br />
** Main Page#Single Board Computers|SBCs<br />
* Contact us<br />
** https://www.dave.eu|DAVE Embedded Systems' Website<br />
** https://www.dave.eu/helpdesk|Helpdesk support<br />
** https://www.dave.eu/get-a-quote|Sales support<br />
** https://www.dave.eu/service_RMA_request|RMA - Return Material Authorization Form<br />
* Advanced Search<br />
** Special:Search|Search<br />
** Special:WhatLinksHere/{{FULLPAGENAME}}|What links here<br />
* SEARCH</div>U0002https://wiki.dave.eu/index.php?title=MediaWiki:Sidebar&diff=14053MediaWiki:Sidebar2021-07-15T20:26:57Z<p>U0002: </p>
<hr />
<div><br />
* navigation<br />
* Quick Links<br />
** mainpage|Wiki Main Page<br />
** Machine Learning Services|ML/AI Services<br />
** IoT Services|IoT Services<br />
** Embedded Design Services|Embedded Design Services<br />
** Main Page#System On Module|SOMs<br />
** Main Page#Single Board Computers|SBCs<br />
* Contact us<br />
** https://www.dave.eu|DAVE Embedded Systems' Website<br />
** https://www.dave.eu/helpdesk|Helpdesk support<br />
** https://www.dave.eu/get-a-quote|Sales support<br />
** https://www.dave.eu/service_RMA_request|RMA - Return Material Authorization Form<br />
* Advanced Search<br />
** Special:Search|Search<br />
** Special:WhatLinksHere/{{FULLPAGENAME}}|WhatLinksHere<br />
* SEARCH<br />
* TOOLBOX<br />
* LANGUAGES</div>U0002https://wiki.dave.eu/index.php?title=DESK-MX6-L-AN-0001:_Crank_Storyboard_engine_and_application&diff=13636DESK-MX6-L-AN-0001: Crank Storyboard engine and application2021-05-11T07:12:37Z<p>U0002: </p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAXEL Lite AN}}<br />
{{InfoBoxBottom}}<br />
<br />
{{ImportantMessage|text=This application note has been validated using the '''kit version''' in the History table.}}<br />
==History==<br />
<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Development Kit version<br />
|-<br />
| 1.0.0<br />
| May 2021<br />
|[[DESK-MX6-L/General/Release_Notes#DESK-MX6-L_1.0.0|DESK-MX6-L 1.0.0]]<br />
|-<br />
|}<br />
<br />
==Introduction==<br />
<br />
[https://www.cranksoftware.com/ Crank Storyboard] is a cross-platform embedded GUI development framework, which will help the Customer to create aspirational GUI experiences. Crank Software has become the trusted embedded GUI framework across the wearables, industrial, healthcare, smart home, and appliances industries.<br />
<br />
DAVE AXEL Lite SOM is able to run Crank Storyboard engine in its bundled root file system: the following Application Note shows how to integrate the <code>sbengine</code> runtime and then executing the Storyboard application in the targte platform.<br />
<br />
==Installing Crank Storyboard==<br />
First of all, watch and follow the [https://www.cranksoftware.com/learn/video-library/getting-started-with-storyboard Getting started with Storyboard] page for learning how to install and learn the Crank Software Storyboard.<br />
<br />
==Installing sbengine in the root file system==<br />
For installing the right [[DESK-MX6-L/General | DESK-MX6-L]] BSP version, create a proper [[AXEL_Lite_SOM/DESK-MX6-L/Development/How_to_create_a_bootable_microSD_card | SD card]] or download the already built version present into our [https://mirror.dave.eu/desk-mx-l/desk-mx6-l-1.0.0/ mirror cloud] services.<br />
<br />
=== SD card===<br />
The proper SD card image should be selected, i.e.: <code>desk-image-qt5-desk-mx6.sdcard.gz</code> and then create the SD card using - for example - Linux or Windows [https://www.balena.io/etcher/ balenaEtcher] tool.<br />
<br />
=== runtime installation ===<br />
From the Storyboard Engine directory of your Storyboard installation extract and copy the runtime directory<br />
<br />
linux-imx6yocto-armle-opengles_2.0-obj<br />
<br />
in the target root file system.<br />
<br />
For example, if the runtime has been copied in the SD card first partition, copy it in the <code>/usr/share/crank/runtimes</code> directory<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank<br />
root@desk-mx6:~# mkdir /usr/share/crank/runtimes<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/linux-imx6yocto-armle-opengles_2.0-obj/ /usr/share/crank/runtimes<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
Then, copy a Storyboard example in another directory, e.g.:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank/apps<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/Launcher2016_FullScreen /usr/share/crank/apps<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
=== touchscreen ===<br />
Storyboard ''sbengine'' uses <code>mtdev</code> for accessing the touchscreen device. The mtdev library is then required. <br />
<br />
For adding the mtdev package it is enough to build it with Yocto following the [[DESK-MX6-L/Development/Building_the_Yocto_BSP#Building_additional_packages | Building_additional_packages]] instructions<br />
<br />
Once the package has been built, just install it with <code>rpm</code><br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# rpm -i mtdev-1.1.5-r0.cortexa9hf_neon.rpm<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
thus enabling the touchscreen device.<br />
<br />
You can find the package built [https://mirror.dave.eu/desk-mx-l/packages here] for your convenience.<br />
<br />
== Script for automatic application startup==<br />
A simple shell script can be used for starting the <code>sbengine</code> runtime and the selected application<br />
<br />
* <code>storyboard_launcher.sh</code><br />
<br />
<syntaxhighlight lang="bash"><br />
set -e<br />
<br />
echo "Starting Storyboard Application..."<br />
echo -e '\033[9;0]' >> /dev/tty1<br />
echo 0 >> /sys/class/graphics/fb0/blank<br />
<br />
export FB_MULTI_BUFFER=3<br />
<br />
export SB_APP=/usr/share/crank/apps/Launcher2016_FullScreen/Launcher2016_FullScreen_NoCircles.gapp<br />
<br />
export ENGINE=/usr/share/crank/runtimes/linux-imx6yocto-armle-opengles_2.0-obj<br />
export SB_PLUGINS=$ENGINE/plugins<br />
export LD_LIBRARY_PATH=$ENGINE/lib<br />
<br />
$ENGINE/bin/gstreamer-backend &<br />
$ENGINE/bin/sbengine -omtdev,device=/dev/input/event0,points=1 -orender_mgr,multisample=0,scale=aspect $SB_APP<br />
</syntaxhighlight><br />
<br />
=== systemd service ===<br />
A '''systemd''' service has to be created for starting the script, for example:<br />
<br />
/etc/systemd/system/storyboard.service<br />
<br />
and the service contains the initialization parameters:<br />
<br />
<pre><br />
[Unit]<br />
Description=Storyboard service<br />
After=network.target<br />
StartLimitIntervalSec=0<br />
<br />
[Service]<br />
Type=simple<br />
Restart=0<br />
RestartSec=1<br />
User=root<br />
ExecStart=/etc/init.d/storyboard_launcher.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</pre><br />
<br />
and then start/enable the service:<br />
<br />
systemctl enable storyboard.service<br />
<br />
== Results ==<br />
At the next reboot, the ''service'' will start <code>sbengine</code> with the selected application:<br />
<br />
<pre class="board-terminal"><br />
...<br />
...<br />
[ OK ] Started Terminate Psplash Boot Screen.<br />
[ OK ] Started Storyboard Service.<br />
[ OK ] Started Getty on tty1.<br />
[ OK ] Started Serial Getty on ttymxc2.<br />
[ OK ] Reached target Sound Card.<br />
[ OK ] Started Hostname Service.<br />
<br />
NXP i.MX Release Distro 4.14-sumo desk-mx6 ttymxc2<br />
<br />
desk-mx6 login:<br />
</pre><br />
<br />
[[File:Crank.jpg |thumb|center|700px | Crank Software Storyboard Launcher demo]]</div>U0002https://wiki.dave.eu/index.php?title=DESK-MX6-L-AN-0001:_Crank_Storyboard_engine_and_application&diff=13635DESK-MX6-L-AN-0001: Crank Storyboard engine and application2021-05-11T07:11:02Z<p>U0002: /* History */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAXEL Lite AN}}<br />
{{InfoBoxBottom}}<br />
<br />
{{ImportantMessage|text=This application note has been validated using the '''kit version''' in the History table.}}<br />
==History==<br />
<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Development Kit version<br />
|-<br />
| 1.0.0<br />
| May 2021<br />
|[[DESK-MX6-L/General/Release_Notes#DESK-MX6-L_1.0.0|DESK-MX6-L 1.0.0]]<br />
|-<br />
|}<br />
<br />
==Introduction==<br />
<br />
[https://www.cranksoftware.com/ Crank Storyboard] is a cross-platform embedded GUI development framework, which will help the Customer to create aspirational GUI experiences. Crank Software has become the trusted embedded GUI framework across the wearables, industrial, healthcare, smart home, and appliances industries.<br />
<br />
DAVE AXEL Lite SOM is able to run Crank Storyboard engine in its bundled root file system: the following Application Note shows how to integrate the <code>sbengine</code> runtime and then executing the Storyboard application in the targte platform.<br />
<br />
==Installing Crank Storyboard==<br />
First of all, watch and follow the [https://www.cranksoftware.com/learn/video-library/getting-started-with-storyboard Getting started with Storyboard] page for learning how to install and learn the Crank Software Storyboard.<br />
<br />
==Installing sbengine in the root file system==<br />
For installing the right [[DESK-MX6-L/General | DESK-MX6-L]] BSP version, create a proper [[AXEL_Lite_SOM/DESK-MX6-L/Development/How_to_create_a_bootable_microSD_card | SD card]] or download the already built version present into our [https://mirror.dave.eu/desk-mx-l/desk-mx6-l-1.0.0/ mirror cloud] services.<br />
<br />
=== SD card===<br />
The proper SD card image should be selected, i.e.: <code>desk-image-qt5-desk-mx6.sdcard.gz</code> and then create the SD card using - for example - Linux or Windows [https://www.balena.io/etcher/ balenaEtcher] tool.<br />
<br />
=== runtime installation ===<br />
From the Storyboard Engine directory of your Storyboard installation extract and copy the runtime directory<br />
<br />
linux-imx6yocto-armle-opengles_2.0-obj<br />
<br />
in the target root file system.<br />
<br />
For example, if the runtime has been copied in the SD card first partition, copy it in the <code>/usr/share/crank/runtimes</code> directory<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank<br />
root@desk-mx6:~# mkdir /usr/share/crank/runtimes<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/linux-imx6yocto-armle-opengles_2.0-obj/ /usr/share/crank/runtimes<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
Then, copy a Storyboard exmaple in another directory, for example:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank/apps<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/Launcher2016_FullScreen /usr/share/crank/apps<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
=== touchscreen ===<br />
Storyboard ''sbengine'' uses <code>mtdev</code> for accessing the touchscreen device. The mtdev library is then required. <br />
<br />
For adding the mtdev package it is enough to build it with Yocto following the [[DESK-MX6-L/Development/Building_the_Yocto_BSP#Building_additional_packages | Building_additional_packages]] instructions<br />
<br />
Once the package has been built, just install it with <code>rpm</code><br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# rpm -i mtdev-1.1.5-r0.cortexa9hf_neon.rpm<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
thus enabling the touchscreen device.<br />
<br />
You can find the package built [https://mirror.dave.eu/desk-mx-l/packages here] for your convenience.<br />
<br />
== Script for automatic application startup==<br />
A simple shell script can be used for starting the <code>sbengine</code> runtime and the selected application<br />
<br />
* <code>storyboard_launcher.sh</code><br />
<br />
<syntaxhighlight lang="bash"><br />
set -e<br />
<br />
echo "Starting Storyboard Application..."<br />
echo -e '\033[9;0]' >> /dev/tty1<br />
echo 0 >> /sys/class/graphics/fb0/blank<br />
<br />
export FB_MULTI_BUFFER=3<br />
<br />
export SB_APP=/usr/share/crank/apps/Launcher2016_FullScreen/Launcher2016_FullScreen_NoCircles.gapp<br />
<br />
export ENGINE=/usr/share/crank/runtimes/linux-imx6yocto-armle-opengles_2.0-obj<br />
export SB_PLUGINS=$ENGINE/plugins<br />
export LD_LIBRARY_PATH=$ENGINE/lib<br />
<br />
$ENGINE/bin/gstreamer-backend &<br />
$ENGINE/bin/sbengine -omtdev,device=/dev/input/event0,points=1 -orender_mgr,multisample=0,scale=aspect $SB_APP<br />
</syntaxhighlight><br />
<br />
=== systemd service ===<br />
A '''systemd''' service has to be created for starting the script, for example:<br />
<br />
/etc/systemd/system/storyboard.service<br />
<br />
and the service contains the initialization parameters:<br />
<br />
<pre><br />
[Unit]<br />
Description=Storyboard service<br />
After=network.target<br />
StartLimitIntervalSec=0<br />
<br />
[Service]<br />
Type=simple<br />
Restart=0<br />
RestartSec=1<br />
User=root<br />
ExecStart=/etc/init.d/storyboard_launcher.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</pre><br />
<br />
and then start/enable the service:<br />
<br />
systemctl enable storyboard.service<br />
<br />
== Results ==<br />
At the next reboot, the ''service'' will start <code>sbengine</code> with the selected application:<br />
<br />
<br />
<pre class="board-terminal"><br />
...<br />
...<br />
[ OK ] Started Terminate Psplash Boot Screen.<br />
[ OK ] Started Storyboard Service.<br />
[ OK ] Started Getty on tty1.<br />
[ OK ] Started Serial Getty on ttymxc2.<br />
[ OK ] Reached target Sound Card.<br />
[ OK ] Started Hostname Service.<br />
<br />
NXP i.MX Release Distro 4.14-sumo desk-mx6 ttymxc2<br />
<br />
desk-mx6 login:<br />
</pre><br />
<br />
[[File:Crank.jpg |thumb|center|700px | Crank Software Storyboard Launcher demo]]</div>U0002https://wiki.dave.eu/index.php?title=DESK-MX6-L-AN-0001:_Crank_Storyboard_engine_and_application&diff=13634DESK-MX6-L-AN-0001: Crank Storyboard engine and application2021-05-11T07:10:39Z<p>U0002: /* Script for automatic application startup */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAXEL Lite AN}}<br />
{{InfoBoxBottom}}<br />
<br />
{{ImportantMessage|text=This application note has been validated using the '''kit version''' in the History table.}}<br />
==History==<br />
<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Development Kit version<br />
|-<br />
| 1.0.0<br />
| May 2021<br />
|[[DESK-MX6-L/General/Release_Notes#DESK-MX6-L_1.0.0|DESK 1.0.0]]<br />
|-<br />
|}<br />
<br />
==Introduction==<br />
<br />
[https://www.cranksoftware.com/ Crank Storyboard] is a cross-platform embedded GUI development framework, which will help the Customer to create aspirational GUI experiences. Crank Software has become the trusted embedded GUI framework across the wearables, industrial, healthcare, smart home, and appliances industries.<br />
<br />
DAVE AXEL Lite SOM is able to run Crank Storyboard engine in its bundled root file system: the following Application Note shows how to integrate the <code>sbengine</code> runtime and then executing the Storyboard application in the targte platform.<br />
<br />
==Installing Crank Storyboard==<br />
First of all, watch and follow the [https://www.cranksoftware.com/learn/video-library/getting-started-with-storyboard Getting started with Storyboard] page for learning how to install and learn the Crank Software Storyboard.<br />
<br />
==Installing sbengine in the root file system==<br />
For installing the right [[DESK-MX6-L/General | DESK-MX6-L]] BSP version, create a proper [[AXEL_Lite_SOM/DESK-MX6-L/Development/How_to_create_a_bootable_microSD_card | SD card]] or download the already built version present into our [https://mirror.dave.eu/desk-mx-l/desk-mx6-l-1.0.0/ mirror cloud] services.<br />
<br />
=== SD card===<br />
The proper SD card image should be selected, i.e.: <code>desk-image-qt5-desk-mx6.sdcard.gz</code> and then create the SD card using - for example - Linux or Windows [https://www.balena.io/etcher/ balenaEtcher] tool.<br />
<br />
=== runtime installation ===<br />
From the Storyboard Engine directory of your Storyboard installation extract and copy the runtime directory<br />
<br />
linux-imx6yocto-armle-opengles_2.0-obj<br />
<br />
in the target root file system.<br />
<br />
For example, if the runtime has been copied in the SD card first partition, copy it in the <code>/usr/share/crank/runtimes</code> directory<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank<br />
root@desk-mx6:~# mkdir /usr/share/crank/runtimes<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/linux-imx6yocto-armle-opengles_2.0-obj/ /usr/share/crank/runtimes<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
Then, copy a Storyboard exmaple in another directory, for example:<br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# mkdir /usr/share/crank/apps<br />
root@desk-mx6:~# cp -aR /run/media/mmcblk0p1/Launcher2016_FullScreen /usr/share/crank/apps<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
=== touchscreen ===<br />
Storyboard ''sbengine'' uses <code>mtdev</code> for accessing the touchscreen device. The mtdev library is then required. <br />
<br />
For adding the mtdev package it is enough to build it with Yocto following the [[DESK-MX6-L/Development/Building_the_Yocto_BSP#Building_additional_packages | Building_additional_packages]] instructions<br />
<br />
Once the package has been built, just install it with <code>rpm</code><br />
<br />
<pre class="board-terminal"><br />
root@desk-mx6:~# rpm -i mtdev-1.1.5-r0.cortexa9hf_neon.rpm<br />
root@desk-mx6:~#<br />
</pre><br />
<br />
thus enabling the touchscreen device.<br />
<br />
You can find the package built [https://mirror.dave.eu/desk-mx-l/packages here] for your convenience.<br />
<br />
== Script for automatic application startup==<br />
A simple shell script can be used for starting the <code>sbengine</code> runtime and the selected application<br />
<br />
* <code>storyboard_launcher.sh</code><br />
<br />
<syntaxhighlight lang="bash"><br />
set -e<br />
<br />
echo "Starting Storyboard Application..."<br />
echo -e '\033[9;0]' >> /dev/tty1<br />
echo 0 >> /sys/class/graphics/fb0/blank<br />
<br />
export FB_MULTI_BUFFER=3<br />
<br />
export SB_APP=/usr/share/crank/apps/Launcher2016_FullScreen/Launcher2016_FullScreen_NoCircles.gapp<br />
<br />
export ENGINE=/usr/share/crank/runtimes/linux-imx6yocto-armle-opengles_2.0-obj<br />
export SB_PLUGINS=$ENGINE/plugins<br />
export LD_LIBRARY_PATH=$ENGINE/lib<br />
<br />
$ENGINE/bin/gstreamer-backend &<br />
$ENGINE/bin/sbengine -omtdev,device=/dev/input/event0,points=1 -orender_mgr,multisample=0,scale=aspect $SB_APP<br />
</syntaxhighlight><br />
<br />
=== systemd service ===<br />
A '''systemd''' service has to be created for starting the script, for example:<br />
<br />
/etc/systemd/system/storyboard.service<br />
<br />
and the service contains the initialization parameters:<br />
<br />
<pre><br />
[Unit]<br />
Description=Storyboard service<br />
After=network.target<br />
StartLimitIntervalSec=0<br />
<br />
[Service]<br />
Type=simple<br />
Restart=0<br />
RestartSec=1<br />
User=root<br />
ExecStart=/etc/init.d/storyboard_launcher.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</pre><br />
<br />
and then start/enable the service:<br />
<br />
systemctl enable storyboard.service<br />
<br />
== Results ==<br />
At the next reboot, the ''service'' will start <code>sbengine</code> with the selected application:<br />
<br />
<br />
<pre class="board-terminal"><br />
...<br />
...<br />
[ OK ] Started Terminate Psplash Boot Screen.<br />
[ OK ] Started Storyboard Service.<br />
[ OK ] Started Getty on tty1.<br />
[ OK ] Started Serial Getty on ttymxc2.<br />
[ OK ] Reached target Sound Card.<br />
[ OK ] Started Hostname Service.<br />
<br />
NXP i.MX Release Distro 4.14-sumo desk-mx6 ttymxc2<br />
<br />
desk-mx6 login:<br />
</pre><br />
<br />
[[File:Crank.jpg |thumb|center|700px | Crank Software Storyboard Launcher demo]]</div>U0002https://wiki.dave.eu/index.php?title=Main_Page&diff=13408Main Page2021-04-06T08:00:49Z<p>U0002: fix SDV03/SDV04 internal wiki links</p>
<hr />
<div>__NOTOC__<br />
<br />
==System On Modules==<br />
{|width="100%" style="border-collapse:collapse; font-size:10px" <br />
!style="width:16%; border-left:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | <br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:NXP logo.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:Logo xilinx.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:St-logo.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:Texas Instruments.png|150px|none]]<br />
|-<br />
|rowspan="5" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ffffff"| '''CORTEX-A53'''<br />
|- <br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[ORCA SOM|'''ORCA SOM<br />NXP i.MX8 M Plus''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:ORCA-SOM-TOP-render.png | 100x100px |link=ORCA SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [https://www.dave.eu/products/som/xilinx/zynq-ultrascale_mpsoc_onda '''ONDA<br />Xilinx ZYNQ US+ MPSoC'''] <p style="color:red">PREVIEW ONLY</p><br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:ONDA-preliminary.png | 100x100px |link=https://www.dave.eu/products/som/xilinx/zynq-ultrascale_mpsoc_onda | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[MITO 8M SOM| '''MITO 8M<br />NXP i.MX8M''']] <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:DMI-Mito-top.png | 100x100px |link=MITO 8M SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[MITO 8M Mini SOM|'''MITO 8M Mini<br />NXP i.MX8M Mini''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:Mito8M_Mini-top.png | 100x100px |link=MITO 8M Mini SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[MITO 8M Nano SOM |'''MITO 8M Nano<br />NXP i.MX8M Nano''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:Mito8M_Mini-top.png | 100x100px |link=MITO 8M Nano SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|rowspan="4" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ededed"| '''CORTEX-A9'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[SMARX SOM | '''SMARX - SMARC<br />NXP i.MX6 S/D/Q''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:SmarX-top-big.png | 100x100px |link=SMARX SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[:Category:BoraX|'''BORA Xpress<br />Xilinx Zynq XC7Z015/030''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:BORA_Xpress.png | 110x110px |link=:Category:BoraX | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[AXEL_Lite_SOM|'''AXEL LITE<br />NXP i.MX6''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:Axel-lite_02.png | 100x100px |link=:AXEL_Lite_SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[:Category:Bora|'''BORA<br />Xilinx Zynq XC7Z010/020''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:Bora5-small.jpg | 120x120px |link=:Category:Bora | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[BORA Lite SOM|'''BORA Lite<br />Xilinx Zynq XC7Z007S/012S/014S or Xilinx Zynq XC7Z010/020''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:BORALite-TOP.png | 100x100px |link=BORA Lite SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|-<br />
|rowspan="2" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ffffff"| '''CORTEX-A7'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[AXEL ULite SOM |'''AXEL ULite<br />NXP i.MX6UL''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:AXEL ULite-top.png | 100x100px |link=AXEL ULite SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[ETRA_SOM| '''ETRA SOM<br />ST STM32MP1''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:ETRA_SOM-2.jpg | 100x100px |link=https://wiki.dave.eu/index.php/ETRA_SOM | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|rowspan="4" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; border-bottom:solid 0px #73B2C7; font-size:12px; background-color:#ededed"| '''CORTEX-A8'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[:Category:Diva|'''DIVA<br />Texas Instruments AM335xx''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:Diva-am335x-overview.png | 100x100px |link=:Category:Diva | Details]]<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[:Category:Dido|'''DIDO<br />Texas Instruments DM8148''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:Dido-main.png | 100x100px |link=:Category:Dido | Details]]<br />
|-<br />
|}<br />
<br />
==Single Board Computers==<br />
{|width="100%" style="border-collapse:collapse; font-size:10px"<br />
!style="width:16%; border-left:solid 0px #73B2C7; background-color:#ededed; font-size:12px; color:#000000" | <br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:NXP logo.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:Logo xilinx.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:St-logo.png|150px|none]]<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; font-size:12px; color:#000000" | [[File:Texas Instruments.png|150px|none]]<br />
|-<br />
|rowspan="2" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ffffff"| '''DIN BAR profile 4 modules'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[SBC Lynx SBC|'''SBC LYNX<br />CPU: based on NXP i.MX6UL''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:SBC_Lynx-top.png | 100x100px |link=SBC Lynx SBC | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[ETRA SBC | '''SBC ETRA<br />CPU: based on ST STM32MP1''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:ETRA_SBC.png | 100x100px |link=ETRA SBC | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|rowspan="2" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ededed"| '''DIN BAR profile 6 modules'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[ORCA SBC|'''SBC ORCA<br />CPU: based on NXP i.MX8M Plus''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:SBC8MU-1.0.0.png | 80x80px |link=ORCA SBC | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| <br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|-<br />
|rowspan="3" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ffffff"| '''DIN BAR profile 10 modules'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[SBC Axel SBC|'''SBC AXEL<br />CPU: based on NXP i.MX6''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:AXEL_Lite-EVK-kit-SBC.png | 100x100px |link=:SBC Axel SBC | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[:Category:SBC-DIVA|'''SBC DIVA<br />CPU: based on Texas Instruments "Sitara" AM335x Cortex-A8''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:SBC-DIVA.png | 100x100px |link=:Category:SBC-DIVA | Details]]<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ffffff"| [[SDV04| '''SDV04<br />CPU: based on NXP i.MX6 and i.MX6UL SOM''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:SDV04-Carrier-C1R.jpg | 100x100px |link=https://wiki.dave.eu/index.php/SDV04 | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|-<br />
|rowspan="2" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; text-align:left; background-color:#ededed"| '''Custom size profile'''<br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; padding:10px; background-color:#ededed"| [[SDV03| '''SDV03<br />CPU: based on NXP i.MX6 S/D/Q''']]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"| [[File:SDV03.png | 100x100px |link=https://wiki.dave.eu/index.php/SDV03 | Details]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ededed"|<br />
|-<br />
|}<br />
<br />
===Single Board Computers' ADD-ONs===<br />
{|width="100%" style="border-collapse:collapse; font-size:10px"<br />
!style="width:16%; border-left:solid 0px #73B2C7; background-color:#ededed; font-size:12px; color:#000000" | <br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; padding:10px; font-size:12px; color:#000000" | [[File:Wifi-icon.png|50px]] WIFI/Bluetooth Modules<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; padding:10px; font-size:12px; color:#000000" | [[File:Mobile-Nfc-Checkpoint-icon.png|50px]] Cellular Modules<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; padding:10px; font-size:12px; color:#000000" | [[File:Electronic-circuit.png|50px]] Expansion boards<br />
!colspan="2" style="width:20%; border-left:solid 2px #73B2C7;border-top:solid 0px #ededed;border-bottom:solid 0px #ededed; background-color:#ededed; padding:10px; font-size:12px; color:#000000" | [[File:Monitor.png|50px]] [[File:Videocamera.png|50px]] Camera/Display boards<br />
|-<br />
|rowspan="2" style="width:16%; text-align:left; padding:10px; border-left:solid 0px #73B2C7; font-size:12px; background-color:#ffffff"| <br />
|-<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:left; background-color:#ffffff"| [[DWM ADD-ON|DWM DAVE Wifi Bluetooth Module]]<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"| [[File:Dwm_01.png|50px|none|link=DWM SOM]]<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 2px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|style="width:10%; border-left:solid 0px #73B2C7;border-right:solid 0px #73B2C7;border-top:solid 0px #73B2C7;border-bottom:solid 0px #73B2C7; text-align:center; background-color:#ffffff"|<br />
|-<br />
|}</div>U0002https://wiki.dave.eu/index.php?title=Tikiwiki_replaced&diff=13356Tikiwiki replaced2021-03-21T21:33:39Z<p>U0002: better have text before image</p>
<hr />
<div>Our, tikiwiki based, documentation website <code>project.dave.eu</code> has been '''replaced''' with a brand new mediawiki-based documentation service<br />
<br />
Please contact our [mailto:helpdesk@dave.eu] for more information[[File:Website moved.jpg|center|frameless|469x469px]]</div>U0002https://wiki.dave.eu/index.php?title=Tikiwiki_replaced&diff=13355Tikiwiki replaced2021-03-21T21:26:59Z<p>U0002: </p>
<hr />
<div>[[File:Website moved.jpg|center|frameless|469x469px]]<br />
<br />
Our, tikiwiki based, documentation website <code>project.dave.eu</code> has been replaced with a brand new mediawiki-based documentation service<br />
<br />
Please contact our [mailto:helpdesk@dave.eu] for more information</div>U0002https://wiki.dave.eu/index.php?title=File:Website_moved.jpg&diff=13354File:Website moved.jpg2021-03-21T21:25:07Z<p>U0002: </p>
<hr />
<div>website moved</div>U0002https://wiki.dave.eu/index.php?title=Tikiwiki_replaced&diff=13353Tikiwiki replaced2021-03-21T21:24:01Z<p>U0002: Created page with " Our website <code>project.dave.eu</code> has beed replaced with a brand new mediawiki-based documentation service Please contact our [mailto:helpdesk@dave.eu] for more infor..."</p>
<hr />
<div><br />
Our website <code>project.dave.eu</code> has beed replaced with a brand new mediawiki-based documentation service<br />
<br />
Please contact our [mailto:helpdesk@dave.eu] for more information</div>U0002https://wiki.dave.eu/index.php?title=MediaWiki:Badaccess-groups&diff=14449MediaWiki:Badaccess-groups2021-03-19T21:47:03Z<p>U0002: </p>
<hr />
<div><!--The action you have requested is limited to users in {{PLURAL:$2|the group|one of the groups}}: $1.--><br />
<br />
<br />
<br />
<span style="font-size:200%"><br />
Access to this wiki is restricted: please go to the [[Special:UserLogin|login page]] or contact our [mailto:helpdesk@dave.eu helpdesk] to get your credential<br />
</span></div>U0002https://wiki.dave.eu/index.php?title=File:Twitter.jpg&diff=13271File:Twitter.jpg2021-03-05T14:33:28Z<p>U0002: U0002 uploaded a new version of File:Twitter.jpg</p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:Emailbanner.png&diff=13240File:Emailbanner.png2021-03-04T20:35:23Z<p>U0002: Changed protection level for "File:Emailbanner.png" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite) [Upload=Allow only administrators] (indefinite))</p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:Emailbanner.png&diff=13239File:Emailbanner.png2021-03-04T20:35:07Z<p>U0002: Protected "File:Emailbanner.png" ([Edit=Allow only administrators] (indefinite))</p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:Wiki.jpg&diff=13238File:Wiki.jpg2021-03-02T08:14:50Z<p>U0002: </p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:In.jpg&diff=13237File:In.jpg2021-03-02T08:14:42Z<p>U0002: </p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:Twitter.jpg&diff=13236File:Twitter.jpg2021-03-02T08:14:32Z<p>U0002: </p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=File:Emailbanner.png&diff=13235File:Emailbanner.png2021-03-02T08:14:06Z<p>U0002: </p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12641MISC-TN-017: Persistent storage and read-write file systems2021-01-21T09:13:37Z<p>U0002: U0002 moved page MISC-TN-017: Persistent storage and read/write file systems to MISC-TN-017: Persistent storage and read-write file systems without leaving a redirect: remove / from title (which is used in mediawiki for subpages</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, [https://www.micron.com/products/nand-flash/choosing-the-right-nand raw NAND flashes], eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories providing some real-world examples as well.<br />
<br />
=== Embedded Linux systems with NOR flashes or raw NAND flashes ===<br />
Some of the following examples refer to embedded Linux systems making use of NOR flashes or raw NAND flashes. Such systems are commonly managed by [http://www.linux-mtd.infradead.org/doc/general.html MTD]/[http://www.linux-mtd.infradead.org/doc/ubi.html UBI] subsystems and, on top of them, [http://www.linux-mtd.infradead.org/doc/ubifs.html UBIFS] to manage files.<br />
<br />
Therefore, before diving into these examples, we suggest to take a look at our [[Memory Tecnology Device (MTD)]] article where these subsystems are explained in more detail.<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet:<br />
* erase block size is 128KiB<br />
* the number of P/E cycles is 100000<br />
* the capacity is 1 GiByte (8 Gibit).<br />
For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GiByte * 100000) / 5 = 20000 GiByte ~ 19.5 TiByte <br />
<br />
Assuming that the user-space software writes 650 GiB every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
The main indicator of ''how much data has been written'' for NAND devices is ''how many blocks has been erased'', assuming that a block has been erased only if:<br />
* has already being written (even if not completely)<br />
* needs to be written again (this is not completely true, because UBI has a background tasks that erases dirty LEB while the system is idle).<br />
Assuming that <code>TEC</code> is the ''sum of PEB Erase Counter'' and <code>DAYS</code> is the number of days the test has been run, the ''estimated amount of written data per year'' can be computed as:<br />
<br />
D = (TEC * PEBsize) * (365 / DAYS)<br />
This already includes WAF and, thus, we can estimate life-time, in year, as:<syntaxhighlight lang="text"><br />
LF = [capacity * P/E cycles] / D<br />
</syntaxhighlight>In the same case above, if we have 30000 TEC/day we have<syntaxhighlight lang="text"><br />
LF = (1GiB * 100k) / ((30k * 128KiB) * (365 / 1)) ~ 74 years<br />
</syntaxhighlight><br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system over UBI partition ===<br />
Even though both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply, and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.<br />
<br />
E.g.:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file zero-file length corruption]<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole trailing zeros on files]<br />
Additional failures like [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_sudden_ro UBIFS mounted as read-only] at boot time usually do not depend only on power-cut but are symptom of major failures (buggy MTD device driver, storage device hardware failure, device wear-out, major EMI and so on).<br />
<br />
When designing application to be as safe as possible w.r.t. power-cuts, please also take care of:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change information of how to change a file atomically]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback notes about UBIFS write-writeback support]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer UBIFS write-buffer].<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter.<br />
We will focus on the latter because it is easy to extract and give a good lifetime expectation of the device.<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). By Comparing the sum of the EC of all PEB's with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package, but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it is also provided by default on most of DAVE Linux Embedded development kit).<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = ((MaxEC * nr_blocks) - sum(EC)) / (MaxEC * nr_blocks)) * 100<br />
</syntaxhighlight>Where:<br />
* <code>MaxEC</code> is the maximum erase count supported by raw NAND<br />
* <code>nr_blocks</code> is the count of PEB that are contained on this partition<br />
E.g. in case of a "standard" SLC NAND, which usually has 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code>:<syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* sum of EC (in this <code>/dev/ubi0</code> partition)<br />
* total number of erase/program cycle allowed by this partition<br />
* expected lifetime left to be used (in percentage).<br />
<br />
Running on a (nearly) 1GiB partition on a brand new SLC NAND flash gives:<syntaxhighlight lang="text"><br />
root@axel:~# ubinfo /dev/ubi0<br />
ubi0<br />
Volumes count: 3<br />
Logical eraseblock size: 126976 bytes, 124.0 KiB<br />
Total amount of logical eraseblocks: 8112 (1030029312 bytes, 982.3 MiB)<br />
Amount of available logical eraseblocks: 0 (0 bytes)<br />
Maximum count of volumes 128<br />
Count of bad physical eraseblocks: 0<br />
Count of reserved physical eraseblocks: 160<br />
Current maximum erase counter value: 2<br />
Minimum input/output unit size: 2048 bytes<br />
Character device major/minor: 248:0<br />
Present volumes: 0, 1, 2<br />
<br />
root@axel:~# ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
8161 811200000 99.999<br />
</syntaxhighlight><br />
*<br />
As a confirmirmation of this data, the maximum EC of a given UBI partition can be read directly from <code>sysfs</code>:<syntaxhighlight lang="text"><br />
root@axel:~# cat /sys/class/ubi/ubi0/max_ec <br />
2<br />
<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12639MISC-TN-017: Persistent storage and read-write file systems2021-01-20T16:30:25Z<p>U0002: /* Experimental measurement of the actual written data */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, raw NAND flashes, eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
On embedded Linux system, raw NAND are commonly managed by MTD/UBI subsystems and, on top of them, UBIFS to manage files<br />
<br />
We suggest to take a look at our [[Memory Tecnology Device (MTD)]] article where these subsystems are explained in more details, prior taking a look at this examples<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet:<br />
* erase block size is 128KiB<br />
* the number of P/E cycles is 100000<br />
* the capacity is 1 GiByte (8 Gibit)<br />
For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GiByte * 100000) / 5 = 20000 GiByte ~ 19.5 TiByte <br />
<br />
Assuming that the user-space software writes 650 GiB every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
The main indicator of ''how much data has been written'' for NAND devices is ''how many blocks has been erased'', assuming that a block has been erased only if:<br />
* has already being written (even if not completely)<br />
* needs to be written again (this is not completely true, because UBI has a background tasks that erases dirty LEB while the system is idle)<br />
Assuming that <code>TEC</code> is the ''sum of PEB Erase Counter'' and <code>DAYS</code> is the number of days the test has been run, the ''estimated amount of written data per year'' can be written as:<br />
<br />
D = (TEC * PEBsize) * (365 / DAYS)<br />
This already includes WAF and, thus, we can estimate life-time, in year, as:<syntaxhighlight lang="text"><br />
LF = [capacity * P/E cycles] / D<br />
</syntaxhighlight>In the same case above, if we have 30000 TEC at day we have<syntaxhighlight lang="text"><br />
LF = (1GiB * 100k) / ((30k * 128KiB) * (365 / 1)) ~ 74 years<br />
</syntaxhighlight><br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
That being said, TBD<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system over UBI partition ===<br />
Even if both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.<br />
<br />
E.g.:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file zero-file length corruption]<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole trailing zeros on files]<br />
Additional failure like [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_sudden_ro UBIFS mounted as read-only] at boot time usually do not depend only on power-cut but are symptom of major failure (buggy MTD device driver, storage device hardware failure, device wear-out, major EMI and so on)<br />
<br />
When designing application to be as safer as possible w.r.t. power-cut, please also take care of:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change information of how to change a file atomically]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback notes about UBIFS write-writeback support]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer UBIFS write-buffer]<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter<br />
We'll focus on the latter because it's easy to extract and give a good lifetime expectation of the device<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). Comparing the sum of the EC of all PEB with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it's also provided by default on most of DAVE Linux Embedded development kit)<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = ((MaxEC * nr_blocks) - sum(EC)) / (MaxEC * nr_blocks)) * 100<br />
</syntaxhighlight>Where:<br />
* <code>MaxEC</code> is the maximum erase count supported by raw NAND<br />
* <code>nr_blocks</code> is the count of PEB that are contained on this partition<br />
E.g. in case of a "standard" SLC NAND, which usually have 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code><syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* sum of EC (in this <code>/dev/ubi0</code> partition)<br />
* total number of erase/program cycle allowed by this partition<br />
* expected lifetime left to be used (in percentage)<br />
<br />
Running on a (nearly) 1GiB partition on a brand new SLC NAND flash gives<syntaxhighlight lang="text"><br />
root@axel:~# ubinfo /dev/ubi0<br />
ubi0<br />
Volumes count: 3<br />
Logical eraseblock size: 126976 bytes, 124.0 KiB<br />
Total amount of logical eraseblocks: 8112 (1030029312 bytes, 982.3 MiB)<br />
Amount of available logical eraseblocks: 0 (0 bytes)<br />
Maximum count of volumes 128<br />
Count of bad physical eraseblocks: 0<br />
Count of reserved physical eraseblocks: 160<br />
Current maximum erase counter value: 2<br />
Minimum input/output unit size: 2048 bytes<br />
Character device major/minor: 248:0<br />
Present volumes: 0, 1, 2<br />
<br />
root@axel:~# ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
8161 811200000 99.999<br />
</syntaxhighlight><br />
*<br />
As confirm of this data, the maximum EC of a given UBI partition can be read directly from <code>sysfs</code><syntaxhighlight lang="text"><br />
root@axel:~# cat /sys/class/ubi/ubi0/max_ec <br />
2<br />
<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12638MISC-TN-017: Persistent storage and read-write file systems2021-01-20T15:49:57Z<p>U0002: /* Power failures */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, raw NAND flashes, eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories.<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet, the number of P/E cycles is 100000. The capacity is 1 GByte (8 Gbit). For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GByte * 100000) / 5 = 20000 GByte ~ 19.5 TByte <br />
<br />
Assuming that the user-space software writes 650 gigabytes every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
TBD<br />
<br />
Thus, the expected lifetime is<br />
<br />
LT = = x years<br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
That being said, TBD<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system over UBI partition ===<br />
Even if both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.<br />
<br />
E.g.:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file zero-file length corruption]<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole trailing zeros on files]<br />
Additional failure like [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_sudden_ro UBIFS mounted as read-only] at boot time usually do not depend only on power-cut but are symptom of major failure (buggy MTD device driver, storage device hardware failure, device wear-out, major EMI and so on)<br />
<br />
When designing application to be as safer as possible w.r.t. power-cut, please also take care of:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change information of how to change a file atomically]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback notes about UBIFS write-writeback support]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer UBIFS write-buffer]<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
On embedded Linux system, raw NAND are commonly managed by MTD/UBI subsystems and, on top of them, UBIFS to manage files<br />
<br />
These subsystems are explained in more details in [[Memory Tecnology Device (MTD)]] article, here we'll focus on health monitoring<br />
<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter<br />
We'll focus on the latter because it's easy to extract and give a good lifetime expectation of the device<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). Comparing the sum of the EC of all PEB with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it's also provided by default on most of DAVE Linux Embedded development kit)<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = ((MaxEC * nr_blocks) - sum(EC)) / (MaxEC * nr_blocks)) * 100<br />
</syntaxhighlight>Where:<br />
* <code>MaxEC</code> is the maximum erase count supported by raw NAND<br />
* <code>nr_blocks</code> is the count of PEB that are contained on this partition<br />
E.g. in case of a "standard" SLC NAND, which usually have 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code><syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* sum of EC (in this <code>/dev/ubi0</code> partition)<br />
* total number of erase/program cycle allowed by this partition<br />
* expected lifetime left to be used (in percentage)<br />
<br />
Running on a (nearly) 1GiB partition on a brand new SLC NAND flash gives<syntaxhighlight lang="text"><br />
root@axel:~# ubinfo /dev/ubi0<br />
ubi0<br />
Volumes count: 3<br />
Logical eraseblock size: 126976 bytes, 124.0 KiB<br />
Total amount of logical eraseblocks: 8112 (1030029312 bytes, 982.3 MiB)<br />
Amount of available logical eraseblocks: 0 (0 bytes)<br />
Maximum count of volumes 128<br />
Count of bad physical eraseblocks: 0<br />
Count of reserved physical eraseblocks: 160<br />
Current maximum erase counter value: 2<br />
Minimum input/output unit size: 2048 bytes<br />
Character device major/minor: 248:0<br />
Present volumes: 0, 1, 2<br />
<br />
root@axel:~# ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
8161 811200000 99.999<br />
</syntaxhighlight><br />
*<br />
As confirm of this data, the maximum EC of a given UBI partition can be read directly from <code>sysfs</code><syntaxhighlight lang="text"><br />
root@axel:~# cat /sys/class/ubi/ubi0/max_ec <br />
2<br />
<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12614MISC-TN-017: Persistent storage and read-write file systems2021-01-20T14:25:13Z<p>U0002: /* Power failures */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, raw NAND flashes, eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories.<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet, the number of P/E cycles is 100000. The capacity is 1 GByte (8 Gbit). For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GByte * 100000) / 5 = 20000 GByte ~ 19.5 TByte <br />
<br />
Assuming that the user-space software writes 650 gigabytes every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
TBD<br />
<br />
Thus, the expected lifetime is<br />
<br />
LT = = x years<br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
That being said, TBD<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system over UBI partition ===<br />
Even if both UBI and UBIFS [http://www.linux-mtd.infradead.org/doc/ubi.html#L_powercut are designed with power-cut tolerance in mind] without having support from additional hardware (e.g. supercap, battery power supply and so on) some data might be lost and some ''weird'' effect happens when not performing a clean shutdown of the system.<br />
<br />
E.g.:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file zero-file length corruption]<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_end_hole trailing zeros on files]<br />
Additional failure like [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_sudden_ro UBIFS mounted as read-only] at boot time usually do not depend only on power-cut but are symptom of major failure (buggy MTD device driver, storage device hardware failure, device wear-out, major EMI and so on)<br />
<br />
When designing application to be as safer as possible w.r.t. power-cut, please also take care of:<br />
* [http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atomic_change information of how to change a file atomically]<br />
* [http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writeback notes about UBIFS write-writeback support]<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
On embedded Linux system, raw NAND are commonly managed by MTD/UBI subsystems and, on top of them, UBIFS to manage files<br />
<br />
These subsystems are explained in more details in [[Memory Tecnology Device (MTD)]] article, here we'll focus on health monitoring<br />
<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter<br />
We'll focus on the latter because it's easy to extract and give a good lifetime expectation of the device<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). Comparing the sum of the EC of all PEB with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it's also provided by default on most of DAVE Linux Embedded development kit)<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = ((MaxEC * nr_blocks) - sum(EC)) / (MaxEC * nr_blocks)) * 100<br />
</syntaxhighlight>Where:<br />
* <code>MaxEC</code> is the maximum erase count supported by raw NAND<br />
* <code>nr_blocks</code> is the count of PEB that are contained on this partition<br />
E.g. in case of a "standard" SLC NAND, which usually have 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code><syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* sum of EC (in this <code>/dev/ubi0</code> partition)<br />
* total number of erase/program cycle allowed by this partition<br />
* expected lifetime left to be used (in percentage)<br />
<br />
Running on a (nearly) 1GiB partition on a brand new SLC NAND flash gives<syntaxhighlight lang="text"><br />
root@axel:~# ubinfo /dev/ubi0<br />
ubi0<br />
Volumes count: 3<br />
Logical eraseblock size: 126976 bytes, 124.0 KiB<br />
Total amount of logical eraseblocks: 8112 (1030029312 bytes, 982.3 MiB)<br />
Amount of available logical eraseblocks: 0 (0 bytes)<br />
Maximum count of volumes 128<br />
Count of bad physical eraseblocks: 0<br />
Count of reserved physical eraseblocks: 160<br />
Current maximum erase counter value: 2<br />
Minimum input/output unit size: 2048 bytes<br />
Character device major/minor: 248:0<br />
Present volumes: 0, 1, 2<br />
<br />
root@axel:~# ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
8161 811200000 99.999<br />
</syntaxhighlight><br />
*<br />
As confirm of this data, the maximum EC of a given UBI partition can be read directly from <code>sysfs</code><syntaxhighlight lang="text"><br />
root@axel:~# cat /sys/class/ubi/ubi0/max_ec <br />
2<br />
<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12613MISC-TN-017: Persistent storage and read-write file systems2021-01-20T13:53:17Z<p>U0002: /* Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, raw NAND flashes, eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories.<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet, the number of P/E cycles is 100000. The capacity is 1 GByte (8 Gbit). For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GByte * 100000) / 5 = 20000 GByte ~ 19.5 TByte <br />
<br />
Assuming that the user-space software writes 650 gigabytes every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
TBD<br />
<br />
Thus, the expected lifetime is<br />
<br />
LT = = x years<br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
That being said, TBD<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
On embedded Linux system, raw NAND are commonly managed by MTD/UBI subsystems and, on top of them, UBIFS to manage files<br />
<br />
These subsystems are explained in more details in [[Memory Tecnology Device (MTD)]] article, here we'll focus on health monitoring<br />
<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter<br />
We'll focus on the latter because it's easy to extract and give a good lifetime expectation of the device<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). Comparing the sum of the EC of all PEB with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it's also provided by default on most of DAVE Linux Embedded development kit)<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = ((MaxEC * nr_blocks) - sum(EC)) / (MaxEC * nr_blocks)) * 100<br />
</syntaxhighlight>Where:<br />
* <code>MaxEC</code> is the maximum erase count supported by raw NAND<br />
* <code>nr_blocks</code> is the count of PEB that are contained on this partition<br />
E.g. in case of a "standard" SLC NAND, which usually have 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code><syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* sum of EC (in this <code>/dev/ubi0</code> partition)<br />
* total number of erase/program cycle allowed by this partition<br />
* expected lifetime left to be used (in percentage)<br />
<br />
Running on a (nearly) 1GiB partition on a brand new SLC NAND flash gives<syntaxhighlight lang="text"><br />
root@axel:~# ubinfo /dev/ubi0<br />
ubi0<br />
Volumes count: 3<br />
Logical eraseblock size: 126976 bytes, 124.0 KiB<br />
Total amount of logical eraseblocks: 8112 (1030029312 bytes, 982.3 MiB)<br />
Amount of available logical eraseblocks: 0 (0 bytes)<br />
Maximum count of volumes 128<br />
Count of bad physical eraseblocks: 0<br />
Count of reserved physical eraseblocks: 160<br />
Current maximum erase counter value: 2<br />
Minimum input/output unit size: 2048 bytes<br />
Character device major/minor: 248:0<br />
Present volumes: 0, 1, 2<br />
<br />
root@axel:~# ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
8161 811200000 99.999<br />
</syntaxhighlight><br />
*<br />
As confirm of this data, the maximum EC of a given UBI partition can be read directly from <code>sysfs</code><syntaxhighlight lang="text"><br />
root@axel:~# cat /sys/class/ubi/ubi0/max_ec <br />
2<br />
<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-017:_Persistent_storage_and_read-write_file_systems&diff=12612MISC-TN-017: Persistent storage and read-write file systems2021-01-20T13:45:50Z<p>U0002: /* Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{InfoBoxBottom}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|January 2021<br />
|First public release<br />
|}<br />
==Introduction==<br />
In many cases, embedded systems that are based on Application Processors such as the NXP i.MX6 make use of read/write file systems. In turn, these file systems use non-volatile flash technologies integrated into several different devices (NOR flashes, raw NAND flashes, eMMC's, etc.).<br />
<br />
By nature, these components are subject to several issues that need to be handled properly. If not, this can affect negatively their performance in terms of reliability and/or lifetime.<br />
<br />
This Technical Note deals with the use of read/write file systems in combination with such memories.<br />
<br />
==Wear-out==<br />
One of the most important factors to take into account is wear-out. Simply put, this is a degradation of the memory device due to repeated erasing/writing cycles — aka P/E cycles — resulting in a limited lifetime.<br />
<br />
In order to mitigate this phenomenon, erasing and writing operations have to be distributed uniformly all over the memory. Please note that this process, known as wear leveling, can be either implemented in the host (in the case of a raw NAND memory, for example) or in the memory device itself (for instance, in the case of eMMC's).<br />
<br />
Even though wear-out is properly managed, it is unavoidable when writing operations are performed. That being said, how to estimate the lifetime of such a device in practice? Manufacturers provide the number of guaranteed P/E cycles. For more details about this number, please refer to the specifications of your device, which detail the test conditions this number refers to. Once the guaranteed P/E cycles are known and '''assuming a proper wear-leveling algorithm is in place''', the expected lifetime can be determined as follows.<br />
<br />
First of all, the ''Total Bytes Written (TBW)'' has to be calculated:<br />
<br />
TBW = [capacity * P/E cycles] / WAF<br />
<br />
where WAF is the ''Write Amplification Factor''. WAF takes into account the '''actual''' amount of data written to the memory when performing write operations. This is due to the fact that non-volatile flash memories are organized as an array of sectors that can be individually erased or written. Often, the size of erase sectors and write sectors are different. That is why, in the case of NAND flashes for instance, they are named differently (blocks and pages, respectively). WAF varies largely depending on the workload. If it is not known for the application under discussion, it can also be measured experimentally (see the following example for more details).<br />
<br />
Once the TBW is calculated, the expected lifetime can be estimated with this equation:<br />
<br />
LT = TBW / D<br />
<br />
where D is the amount of data written in the unit of time of interests (month, year, etc.).<br />
<br />
===Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system===<br />
This example shows how to estimate the lifetime of a raw NAND flash memory used in an embedded Linux system making use of the UBIFS file system. Specifically, the memory p/n is W29N08GVSIAA by Winbond, which is a 1-bit ECC Single-Level Cell (SLC) component. In this case, the wear leveling algorithm is implemented at the Linux kernel level.<br />
<br />
According to the datasheet, the number of P/E cycles is 100000. The capacity is 1 GByte (8 Gbit). For the sake of simplicity, it is assumed that the file system makes use of the entire memory. Otherwise, only the capacity of the partition of interest has to be taken into account. Regarding the WAF, it is assumed it is 5. This means that for each byte written by the user-space applications and daemons, five bytes are actually saved onto the memory.<br />
<br />
TBW = (1 GByte * 100000) / 5 = 20000 GByte ~ 19.5 TByte <br />
<br />
Assuming that the user-space software writes 650 gigabytes every year, the expected lifetime is<br />
<br />
LT = 20000 / 650 = 30.8 years<br />
<br />
=====Experimental measurement of the '''actual''' written data=====<br />
In many cases, WAF is unknown and can not be estimated either. As stated previously, the system integrator can determine the lifetime expectancy by adopting an experimental approach though. The following procedure describes how to determine the '''actual''' written data for the system used in this example.<br />
<br />
TBD<br />
<br />
Thus, the expected lifetime is<br />
<br />
LT = = x years<br />
<br />
==Power failures==<br />
Even though modern file systems are usually tolerant w.r.t. power failures (*), in general, sudden power cuts should be avoided. The system should always be turned off cleanly. As this is not always possible, several techniques can be put in place to mitigate the effects of a power failure. For instance, see [[Carrier_board_design_guidelines_(SOM)#Sudden_power_off_management|this section of the carrier board design guidelines]].<br />
<br />
That being said, TBD<br />
<br />
(*) Roughly speaking, this means that these file systems are able to keep their consistency across such events. They can not avoid data loss if a power failure occurs in the middle of a write operation, however. For this reason, further countermeasures, such as data redundancy and/or the use of error-detecting/correcting codes, should be implemented at the application level for particularly important data. At the hardware level, DAVE Embedded Systems products usually leverage the "write protect" feature of flash memories in order to prevent erase/program operations during power transitions.<br />
<br />
== Memory health monitoring ==<br />
Although implementing a mechanism for monitoring the health of flash memories is not required strictly speaking, it is recommended. Think about it as a sort of life insurance to cope with unpredictable events that might occur during the life of the product. As a result of a on-the-field software upgrade, for example, new features could be added leading to an increase of data rate written onto the flash memories. Consequently, the lifetime expectancy calculated when the product was designed is not valid anymore. In such a case, a properly designed monitoring system would alert the personnel devoted to the maintenance who could take measures before it is too late (see for instance the case of eMMC's used in [https://electrek.co/2020/11/09/tesla-emmc-failure-touchscreen-offers-extended-warranty/ Tesla cars]). The following section details an example of such a system.<br />
<br />
=== Example: embedded Linux system equipped with a raw NAND flash memory and UBIFS file system ===<br />
On embedded Linux system, raw NAND are commonly managed by MTD/UBI subsystems and, on top of them, UBIFS to manage files<br />
<br />
These subsystems are explained in more details in [[Memory Tecnology Device (MTD)]] article, here we'll focus on health monitoring<br />
<br />
There's two main indicator of NAND device health:<br />
* current ECC corrected errors<br />
* block erase counter<br />
We'll focus on the latter because it's easy to extract and give a good lifetime expectation of the device<br />
<br />
UBI put [http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubi_headers its header] on top of each NAND physical erase block ('''PEB''') and here, among the other fields, user can find the erase counter ('''EC'''). Comparing the sum of the EC of all PEB with the nominal expected maximum erase count, user can estimate the usage of the whole NAND device.<br />
<br />
To read EC directly from PEB at runtime, user can rely on <code>ubidumpec</code> tool: this is not yet merged in [http://git.infradead.org/mtd-utils.git mtd-utils] package but is provided as [http://lists.infradead.org/pipermail/linux-mtd/2015-May/059381.html RFC on linux-mtd mailing list] (it's also provided by default on most of DAVE Linux Embedded development kit)<br />
<br />
UBI partition expected remaining life in percentage can be calculated with a simple formula:<syntaxhighlight lang="text"><br />
RL = (MaxEC - sum(EC)) / MaxEC) * 100<br />
</syntaxhighlight>Where <code>MaxEC</code> is the maximum erase count supported by raw NAND.<br />
<br />
E.g. in case of a "standard" SLC NAND, which usually have 100k maximum erase count, this can be implemented as simple bash pipe between <code>ubidumpec</code> and <code>awk</code><syntaxhighlight lang="bash"><br />
ubidumpec /dev/ubi0 | awk -v MAXEC=100000 '{ s+=$1; n=n+1} END {print s, n*MAXEC, (((n*MAXEC)-s)/(n*MAXEC))*100 }'<br />
</syntaxhighlight>This command prints:<br />
* number of blocks (in this <code>/dev/ubi0</code> partition)<br />
*</div>U0002https://wiki.dave.eu/index.php?title=BELK-TN-010:_MAC_address_programming_on_OTP&diff=11528BELK-TN-010: MAC address programming on OTP2020-11-18T13:46:34Z<p>U0002: add reference to supported BELK/BXELK release</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies To Bora}}<br />
{{Applies To BoraX}}<br />
{{Applies To BoraLite}}<br />
{{InfoBoxBottom}}<br />
__FORCETOC__<br />
<br />
{{WarningMessage|text=This technical note was validated against specific versions of hardware and software. What is described here may not work with other versions.}}<br />
<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!BELK/BXELK version<br />
!Notes<br />
|-<br />
|1.0.0<br />
|Sep 2020<br />
|[[BELK/BXELK software components#BELK 4.1.2|4.1.2]]<br />
|First public release<br />
|}<br />
<br />
== Introduction ==<br />
Every network adapter has a Media Access Control address (usually shortened to MAC address). A MAC address is a six-byte identifying number permanently embedded in the firmware of the adapter, and is readable by the network and the operating system of the device on which the adapter is installed. <br />
<br />
The address must follow the standards set by the [https://standards.ieee.org/products-services/regauth/index.html Institute of Electrical and Electronics Engineers (IEEE)], which sets computer networking standards. <br />
<br />
The MAC address is a six-pair set of hexadecimal numbers, for example <code>a1-c2-e3-44-5f-6d</code>. The purpose of the MAC address is to uniquely identify every node; every adapter has a unique MAC address.<br />
<br />
=== Permanent storage areas ===<br />
<br />
Some SOCs provide programmable OTPs for security, MAC address, boot modes, etc. Usually, some of these are general-purpose registers and can be managed by the user. <br />
<br />
In other cases, an external permanent storage device can be used for storing permanent settings like the MAC address: for the Bora/BoraX product family, DAVE proposes to use the OTP block on NOR SPI flash for storing permanently ConfigID, UniqueID and MAC address.<br />
<br />
=== About this document ===<br />
<br />
In this Application Note, we will describe how to use the Bora/BoraX NOR SPI for programming and using the MAC address programmed on its OTP block area.<br />
<br />
== MAC address programming how-to ==<br />
<br />
=== Accessing NOR SPI and u-boot update ===<br />
Actual u-boot version <code>belk-4.1.1</code> has native macros for managing the u-boot update. Here below the messages using the boot from NOR QSPI:<br />
<br />
<pre><br />
U-Boot SPL 2017.01-belk-4.1.1 (Jan 08 2020 - 16:44:36)<br />
qspi boot<br />
Trying to boot from SPI<br />
<br />
<br />
U-Boot 2017.01-belk-4.1.1 (Jan 08 2020 - 16:44:36 +0100), Build: belk-4.1.1<br />
<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
I2C: ready<br />
DRAM: ECC disabled 1 GiB<br />
Relocating to 3ff14000, new gd at 3ead3ee8, sp at 3ead3ec0<br />
NAND: 1024 MiB<br />
MMC: Card did not respond to voltage select!<br />
Card did not respond to voltage select!<br />
sdhci@e0100000 - probe failed: -95<br />
Card did not respond to voltage select!<br />
<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
*** Warning - bad CRC, using default environment<br />
<br />
In: serial@e0001000<br />
Out: serial@e0001000<br />
Err: serial@e0001000<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
WARNING: ConfigID on block 0 is UNLOCKED<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
SOM ConfigID#: 00000006<br />
SOM UniqueID#: 3a12db08:32291263<br />
ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
CB ConfigID CRC mismatch for 0x00000000 (was 0x00000000, expected 0x2144df1c) at block 3 (offset 96): using default<br />
CB ConfigID#: ffffffff<br />
CB UniqueID#: 00000000:00000000<br />
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
Bora><br />
</pre><br />
<br />
The following macros can be used for '''u-boot''' re-programming:<br />
<pre><br />
load_spl=tftpboot ${loadaddr} bora/boot.bin<br />
update_spl=sf probe 0 0 0;sf erase ${SPL_base} +${filesize};sf write ${loadaddr} ${SPL_base} ${filesize}<br />
load=tftpboot ${loadaddr} bora/u-boot.img<br />
update=sf probe 0 0 0;sf erase ${u-boot_base} +${filesize};sf write ${loadaddr} ${u-boot_base} ${filesize}<br />
</pre><br />
with proper settings (i.e. binary filenames)<br />
<br />
==== ethaddr ====<br />
Into the u-boot source code, a default value for the ethernet MAC address is set to the DAVE's default MAC value, i.e.:<br />
<br />
Bora> pri ethaddr<br />
ethaddr='''00:50:C2:1E:AF:E0'''<br />
Bora><br />
<br />
==== random MAC address ====<br />
If the <code>ethaddr</code> variable is deleted from the environment, a random value is generated by u-boot:<br />
<br />
<pre><br />
Bora> setenv ethaddr<br />
Bora> saveenv<br />
Saving Environment to SPI Flash...<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Erasing SPI flash...Writing to SPI flash...done<br />
Valid environment: 2<br />
Bora> reset<br />
resetting ...<br />
</pre><br />
<br />
Warning: ethernet@e000b000 (eth0) using '''random MAC address''' - ae:a4:d7:3c:57:ff<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
Bora><br />
<br />
=== Accessing the NOR SPI OTP area ===<br />
<br />
For accessing the NOR OTP blocks area a special u-boot version should be used. <br />
<br />
The proper <code>defconfig</code> should be used for compiling a ''development'' binary which allows to use the writing commands on this area:<br />
<br />
For Bora SOM:<br />
<br />
make bora_mmc_devel_defconfig<br />
<br />
For BoraX SOM:<br />
<br />
make borax_mmc_devel_defconfig<br />
<br />
=== u-boot ''devel'' ===<br />
<br />
The u-boot ''devel'' version can be used for the application purposes: in this application note we used the new u-boot release with the following files:<br />
<br />
belk-4.1.2_borax_mmc_devel_boot.bin<br />
belk-4.1.2_borax_mmc_devel_u-boot.img<br />
<br />
The ''devel'' u-boot version provides a new command (hidden into standard relase) used for the MAC management:<br />
<br />
<pre><br />
Bora> macprog<br />
macprog - MAC address in SPI NOR OTP management<br />
<br />
Usage:<br />
macprog <cmd><br />
ethaddr - program ethaddr environment variable in OTP<br />
eth1addr - program eth1addr environment variable in OTP<br />
lock_ethaddr - lock OTP block where ethaddr is stored<br />
lock_eth1addr - lock OTP block where eth1addr is stored<br />
<br />
Bora><br />
</pre><br />
<br />
Simply properly copied into a FAT32 SD card with the default filename (for the bootrom readability) <code>boot.bin</code> and <code>u-boot.img</code>. <br />
<br />
<pre><br />
Bora> fatls mmc 0:1<br />
system volume information/<br />
88892 boot.bin<br />
688280 u-boot.img<br />
<br />
2 file(s), 1 dir(s)<br />
<br />
Bora><br />
</pre><br />
<br />
Once programmed, the devel u-boot version provides the command required:<br />
<br />
<pre><br />
U-Boot SPL 2017.01-belk-4.1.2 (Jun 25 2020 - 17:49:47)<br />
qspi boot<br />
Trying to boot from SPI<br />
<br />
<br />
U-Boot 2017.01-belk-4.1.2 (Jun 25 2020 - 17:49:47 +0200), Build: belk-4.1.2<br />
<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
I2C: ready<br />
DRAM: ECC disabled 1 GiB<br />
Relocating to 3ff13000, new gd at 3ead2ee8, sp at 3ead2ec0<br />
NAND: 1024 MiB<br />
MMC: sdhci@e0100000: 0 (SD)<br />
reading bora.env<br />
<br />
** Unable to read "bora.env" from mmc0:1 **<br />
Using default environment<br />
<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
In: serial@e0001000<br />
Out: serial@e0001000<br />
Err: serial@e0001000<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
WARNING: ConfigID on block 0 is UNLOCKED<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
SOM ConfigID#: 00000006<br />
SOM UniqueID#: 3a12db08:32291263ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
CB ConfigID CRC mismatch for 0x00000000 (was 0x00000000, expected 0x2144df1c) at block 3 (offset 96): using default<br />
CB ConfigID#: ffffffff<br />
CB UniqueID#: 00000000:00000000<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Warning: ethaddr not found in SPI NOR at block 8<br />
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id<br />
<br />
Warning: ethernet@e000b000 (eth0) using random MAC address - 12:32:a0:c2:77:e8<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
Bora> macprog<br />
macprog - MAC address in SPI NOR OTP management<br />
<br />
Usage:<br />
macprog <cmd><br />
ethaddr - program ethaddr environment variable in OTP<br />
eth1addr - program eth1addr environment variable in OTP<br />
lock_ethaddr - lock OTP block where ethaddr is stored<br />
lock_eth1addr - lock OTP block where eth1addr is stored<br />
<br />
Bora><br />
</pre><br />
<br />
The MAC not programmed is shown by the two debug messages:<br />
<br />
'''Warning: ethaddr not found in SPI NOR at block 8'''<br />
<br />
Warning: ethernet@e000b000 (eth0) using random MAC address - 12:32:a0:c2:77:e8<br />
<br />
==== Programming the required MAC address ====<br />
For programming the MAC address the following steps can be used:<br />
<br />
* set the <code>ethaddr</code> ethernet address value<br />
Bora> setenv ethaddr '''00:50:C2:1E:AF:EC'''<br />
Bora> printenv ethaddr<br />
ethaddr=00:50:C2:1E:AF:EC<br />
Bora> <br />
<br />
* programming the MAC and '''lock''' the OTP register<br />
<pre><br />
Bora> macprog ethaddr<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Your're about to program this MAC address: 00:50:C2:1E:AF:EC for ethaddr (block 8). Continue? (y/N)<br />
y<br />
Block 8 NOT locked. Use 'macprog lock_ethaddr' to lock it<br />
Bora> macprog lock_ethaddr<br />
You're about to lock block 8. Continue (y/N)?<br />
y<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Bora><br />
</pre><br />
<br />
==== incorrect ethaddr ====<br />
If <code>ethaddr</code> is empty the ''macprog'' command will report an error:<br />
<br />
<pre><br />
Bora> setenv ethaddr<br />
Bora> macprog ethaddr<br />
Error: "ethaddr" not defined<br />
Bora> <br />
</pre><br />
<br />
=== u-boot ===<br />
<br />
Once the MAC address has been programmed, the standard u-boot version can be used in the field. <br />
<br />
Typically, the NOR SPI is used as boot storage device, so the <code>defconfig</code> used for the binary version is:<br />
<br />
* for Bora SOM: bora_qspi_defconfig (i.e. u-boot has to compiled with <code> make bora_qspi_defconfig</code>)<br />
* for BoraX SOM: borax_qspi_defconfig (i.e. u-boot has to compiled with <code> make borax_qspi_defconfig</code>)<br />
<br />
==== Verify the programmed MAC address ====<br />
The MAC address can be checked using the ''on the field'' u-boot version:<br />
<br />
* install the u-boot ''field'' version using the u-boot binaries<br />
<br />
<pre><br />
belk-4.1.2_bora_qspi_boot.bin<br />
belk-4.1.2_bora_qspi_u-boot.img<br />
</pre><br />
<br />
and reset the board.<br />
<br />
* the configured MAC address is available in the variable <code>ethaddr</code><br />
<br />
<pre><br />
U-Boot SPL 2017.01-belk-4.1.2 (Jun 25 2020 - 17:43:07)<br />
qspi boot<br />
Trying to boot from SPI<br />
<br />
<br />
U-Boot 2017.01-belk-4.1.2 (Jun 25 2020 - 17:43:07 +0200), Build: belk-4.1.2<br />
<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
I2C: ready<br />
DRAM: ECC disabled 1 GiB<br />
Relocating to 3ff14000, new gd at 3ead3ee8, sp at 3ead3ec0<br />
NAND: 1024 MiB<br />
MMC: Card did not respond to voltage select!<br />
Card did not respond to voltage select!<br />
sdhci@e0100000 - probe failed: -95<br />
Card did not respond to voltage select!<br />
<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
In: serial@e0001000<br />
Out: serial@e0001000<br />
Err: serial@e0001000<br />
Model: Bora<br />
Board: Xilinx Zynq<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
WARNING: ConfigID on block 0 is UNLOCKED<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
SOM ConfigID#: 00000006<br />
SOM UniqueID#: 3a12db08:32291263<br />
ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
ds2431_readmem(): error in chip reset<br />
ds2431_readmem(): error in reading buffer<br />
CB ConfigID CRC mismatch for 0x00000000 (was 0x00000000, expected 0x2144df1c) at block 3 (offset 96): using default<br />
CB ConfigID#: ffffffff<br />
CB UniqueID#: 00000000:00000000<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
Bora> pri ethaddr<br />
ethaddr=00:50:c2:1e:af:ec<br />
Bora><br />
</pre><br />
<br />
It is possible to change (using an environment override) the MAC address simply assigning a new value; in this case, the reboot displays the incongruent value and uses the last one:<br />
<br />
<pre><br />
Bora> pri ethaddr<br />
ethaddr=00:50:c2:1e:af:ec<br />
Bora> setenv ethaddr 00:50:c2:1e:af:aa<br />
Bora> saveenv<br />
Saving Environment to SPI Flash...<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Erasing SPI flash...Writing to SPI flash...done<br />
Valid environment: 2<br />
Bora> reset<br />
resetting ...<br />
...<br />
...<br />
Warning: ethaddr MAC addresses don't match:<br />
Address in SROM is 00:50:c2:1e:af:ec<br />
Address in environment is 00:50:c2:1e:af:aa<br />
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
</pre><br />
<br />
For using the OTP MAC, simply delete the ''ethaddr'' and save the environment:<br />
<br />
<pre><br />
Bora> pri ethaddr<br />
ethaddr=00:50:c2:1e:af:aa<br />
Bora> setenv ethaddr<br />
Bora> saveenv<br />
Saving Environment to SPI Flash...<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Erasing SPI flash...Writing to SPI flash...done<br />
Valid environment: 1<br />
Bora> reset<br />
resetting ...<br />
...<br />
...<br />
SF: Detected s25fl128s_64k with page size 256 Bytes, erase size 64 KiB, total 32 MiB<br />
Net: ZYNQ GEM: e000b000, phyaddr 7, interface rgmii-id<br />
eth0: ethernet@e000b000<br />
Hit ENTER within 3 seconds to stop autoboot<br />
Bora> pri ethaddr<br />
ethaddr=00:50:c2:1e:af:ec<br />
Bora><br />
</pre><br />
<br />
=== Linux userspace access ===<br />
<br />
The programmed MAC value can be verified once the ethernet interface has been correctly configured by u-boot and then activated by the Linux kernel.<br />
<br />
It is enough to check it using <code>ifconfig</code> at the userspace level:<br />
<br />
<pre><br />
root@bora:~# ifconfig eth0<br />
eth0 Link encap:Ethernet HWaddr 00:50:c2:1e:af:ec<br />
inet addr:192.168.0.90 Bcast:192.168.0.255 Mask:255.255.255.0<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:11620 errors:0 dropped:4 overruns:0 frame:0<br />
TX packets:9125 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:1000<br />
RX bytes:12494336 (11.9 MiB) TX bytes:1189523 (1.1 MiB)<br />
Interrupt:148 Base address:0xb000<br />
<br />
root@bora:~# <br />
</pre><br />
<br />
== Bora git repositories ==<br />
DAVE's Bora/BoraX git repositories have been updated with the latest development release which includes the routines for accessing the NOR OTP area and storing the MAC address.<br />
<br />
The git repositories can be accessed, for DAVE's enabled Customers, at the following addresses:<br />
<br />
git@git.dave.eu:dave/bora/u-boot-xlnx.git<br />
<br />
The Bora [https://wiki.dave.eu/index.php/Building_U-Boot_(BELK/BXELK) Building_U-Boot] wiki page describes how to keep updated with DAVE's git repository and build the required u-boot version.<br />
<br />
The binaries used in this AN can be found into our [https://mirror.dave.eu/bora/belk-4.1.2/ mirror server]</div>U0002https://wiki.dave.eu/index.php?title=Template:Pinout&diff=10196Template:Pinout2020-09-23T14:56:14Z<p>U0002: Reverted edits by U0005 (talk) to last revision by U0007</p>
<hr />
<div><section begin=History/><br />
{| style="border-collapse:collapse; "<br />
!colspan="4" style="width:100%; text-align:left"; border-bottom:solid 2px #ededed"|History<br />
|- <br />
!style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white"|Version<br />
!style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white"|Issue Date<br />
!style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white"|Notes<br />
|-<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|X.Y.Z<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|Month Year<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|TBD<br />
|-<br />
|-<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|[TBD_link X.Y.Z]<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|Month Year<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|TBD<br />
|-<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|...<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|...<br />
|style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000"|...<br />
|-<br />
|}<br />
<section end=History/><br />
<section begin=Body/><br />
==Pinout Table==<br />
''TBD: modificare la tabella seguente con le caratteristiche dei pin del SOM''<br />
<br />
''TBD: modificare le due tabelle ODD e EVEN con la mappa completa dei pins''<br />
<br />
===Introduction===<br />
<br />
This chapter contains the pinout description of the {{{nome-som}}} module, grouped in two tables (odd and even pins) that report the pin mapping of the ''TBD: connector type'' {{{nome-som}}} connector.<br />
<br />
Each row in the pinout tables contains the following information:<br />
<br />
{|class="wikitable" style="width:50%;"<br />
|-<br />
|'''Pin'''<br />
| Reference to the connector pin<br />
|-<br />
|'''Pin Name''' <br />
| Pin (signal) name on the AxelLite connectors<br />
|-<br />
|'''Internal<br>connections''' <br />
| Connections to the Axel Ultra components<br />
* CPU.<x> : pin connected to CPU pad named <x><br />
* CAN.<x> : pin connected to the CAN transceiver<br />
* PMIC.<x> : pin connected to the Power Manager IC<br />
* LAN.<x> : pin connected to the LAN PHY<br />
* NOR.<x>: pin connected to the flash NOR<br />
* SV.<x>: pin connected to voltage supervisor<br />
* MTR: pin connected to voltage monitors<br />
|-<br />
|'''Ball/pin #''' <br />
| Component ball/pin number connected to signal<br />
|-<br />
|'''Voltage''' || I/O voltage levels <br />
|-<br />
|'''Type''' <br />
| Pin type:<br />
* I = Input<br />
* O = Output<br />
* D = Differential<br />
* Z = High impedance<br />
* S = Power supply voltage<br />
* G = Ground<br />
* A = Analog signal<br />
|-<br />
|'''Notes'''<br />
|Remarks on special pin characteristics<br />
|-<br />
|'''Pin MUX alternative functions'''<br />
|Muxes:<br />
* Pin ALT-0<br />
* Pin ALT-1<br />
* Pin ALT-2<br />
* Pin ALT-3<br />
* Pin ALT-4<br />
* Pin ALT-5<br />
* Pin ALT-6<br />
* Pin ALT-7<br />
* Pin ALT-8<br />
|-<br />
|}<br />
<br />
===Pinout Table ODD pins declaration ===<br />
<br />
{| class="wikitable" <br />
! latexfontsize="scriptsize"| Pin <br />
! latexfontsize="scriptsize"| Pin Name<br />
! latexfontsize="scriptsize"| Internal Connections <br />
! latexfontsize="scriptsize"| Ball/pin # <br />
! latexfontsize="scriptsize"| Voltage|domain<br />
! latexfontsize="scriptsize"| Type <br />
! latexfontsize="scriptsize"| Notes<br />
! colspan="2" latexfontsize="scriptsize"| Alternative Functions<br />
|-<br />
|rowspan="5"|J2.69<br />
|rowspan="5"|SD2_CMD<br />
|rowspan="5"|CPU.SD2_CMD<br />
|rowspan="5"|F19<br />
|rowspan="5"|AXEL_IO_3V3<br />
|rowspan="5"|IO<br />
|rowspan="5"|<br />
|Pin ALT-0<br />
|SD2_CMD<br />
|-<br />
|Pin ALT-1<br />
|ECSPI5_MOSI<br />
|-<br />
|Pin ALT-2<br />
|KEY_ROW5<br />
|-<br />
|Pin ALT-3<br />
|AUD4_RXC<br />
|-<br />
|Pin ALT-5<br />
|GPIO1_IO11<br />
|-<br />
|}<br />
<br />
===Pinout Table EVEN pins declaration ===<br />
<br />
{| class="wikitable" <br />
! latexfontsize="scriptsize"| Pin <br />
! latexfontsize="scriptsize"| Pin Name<br />
! latexfontsize="scriptsize"| Internal Connections <br />
! latexfontsize="scriptsize"| Ball/pin # <br />
! latexfontsize="scriptsize"| Voltage|domain<br />
! latexfontsize="scriptsize"| Type <br />
! latexfontsize="scriptsize"| Notes<br />
! colspan="2" latexfontsize="scriptsize"| Alternative Functions<br />
|-<br />
|rowspan="5"|J2.69<br />
|rowspan="5"|SD2_CMD<br />
|rowspan="5"|CPU.SD2_CMD<br />
|rowspan="5"|F19<br />
|rowspan="5"|AXEL_IO_3V3<br />
|rowspan="5"|IO<br />
|rowspan="5"|<br />
|Pin ALT-0<br />
|SD2_CMD<br />
|-<br />
|Pin ALT-1<br />
|ECSPI5_MOSI<br />
|-<br />
|Pin ALT-2<br />
|KEY_ROW5<br />
|-<br />
|Pin ALT-3<br />
|AUD4_RXC<br />
|-<br />
|Pin ALT-5<br />
|GPIO1_IO11<br />
|-<br />
|}<br />
<br />
----<br />
<br />
[[Category:{{{nome-som}}}]]</div>U0002https://wiki.dave.eu/index.php?title=MISC-TN-014:_Yocto_and_Debian_packetization&diff=9875MISC-TN-014: Yocto and Debian packetization2020-08-10T21:06:13Z<p>U0002: fix some internal wiki reference</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAxel}}<br />
{{AppliesToAxelEsatta}}<br />
{{AppliesToAxelLite}}<br />
{{Applies To Yocto}}<br />
[[Category:MISC-AN-TN]]<br />
[[Category:MISC-TN]]<br />
{{InfoBoxBottom}}<br />
<br />
__FORCETOC__<br />
== History ==<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!Notes<br />
|-<br />
|1.0.0<br />
|August 2020<br />
|First public release<br />
|}<br />
<br />
==Introduction==<br />
In recent years, the [https://www.yoctoproject.org/ Yocto build system] has gained popularity in the embedded world. Many silicon vendors such as NXP e Xilinx base their Board Support Packages (BSP) on this tool. Despite the fact that Yocto is very powerful and rich, it may be fairly tricky to use, however, especially during the development stage when developers generally need a lot of flexibility. In particular, the unavailability of an archive of prebuilt common packages—as opposed to most of server/desktop Linux distributions—can be really annoying. As described [[Working_with_the_Yocto_build_system|here]], Yocto is basically devised to build an entire distribution from scratch indeed.<br />
<br />
To mitigate this drawback, the technique described in [[XELK-AN-003:_Package_Management_with_Yocto|this article]] can be used. In essence, one can build all the packages supported by Yocto (<code>bitbake -k world</code>) and make them available through a <code>smart</code> channel on a local server. Developers working on the target can easily install required packages without having to build them.<br />
<br />
Interestingly, in recent BSP's, NXP indicates a little different approach, which goes even further as it is also open to interfacing to the Debian world. The following excerpt is taken from ''NXP i.MX Yocto Project User's Guide, Document Number: IMXLXYOCTOUG, Rev. L5.4.24_2.1.0, 06/2020'':<br />
<br />
<br />
''Package Management''<br />
<br />
''The default package management with Yocto Project is rpm. The i.MX distro now enables Debian as the package management. This can be easily turned off by add <code>PACKAGE_CLASSES</code> set to <code>package_rpm</code> to the <code>local.conf</code> (or creating a custom distro without the Debian package feed <code>PACKAGE_CLASSES = "package_rpm"</code>). With the addition of the Debian package feed, a <code>sources.list</code> can be added <code>/etc/apt</code> that links in Debian's package feed. This allows users to install packages not provided in the image without having to add them to a Yocto image. Because this package feed is not generated by the i.MX Yocto build process, there is no guarantee each package will work with the right dependencies but it allows simpler tools to be provided. Software that is complex and has more dependencies on specific versions might have issues with an external package feed.<br />
''<br />
<br />
<br />
In principle, the adoption of the Debian package management should allow to use prebuilt package archives available for [http://ftp.debian.org/debian/README.html Debian distributions]. However, close attention should be paid when mixing packages of different distributions. For instance, Debian packages installed on a Yocto file system could not work. Even worse, '''they could interfere with existing packages and make these unusable'''.<br />
<br />
This Technical Note (TN) describes a way to apply the approach illustrated [[XELK-AN-003: Package Management with Yocto|here]] to a Yocto distribution that makes use of Debian packetization. In other words, a local archive of Yocto-generated, prebuilt .deb packages is used in combination with the well known <code>apt-get</code> utility.<br />
<br />
==Testbed==<br />
The testbed used to verify this procedure consists of an NXP i.MX8M Plus EVK (*) combined with the Linux BSP tagged as ''L5.4.24_2.1.0''.<br />
<br />
<br />
(*) At the time of this writing, the i.MX8M Plus SoC is not released yet. DAVE Embedded Systems, however, has access to the EVK because our company is part of the related Beta program.<br />
<br />
==Configuring and testing==<br />
First of all, all the packages were built with Yocto. Then, they were copied to a server supporting the HTTPS protocol. The resulting archive is available here: https://yocto.dave.eu/imx-5.4/.<br />
<br />
On the target, the file <code>/etc/apt/sources.list.d/imx-5.4.list</code> was created in order to point to this archive:<br />
<pre class="board-terminal"><br />
root@imx8mpevk:/etc/apt/sources.list.d# cat imx-5.4.list <br />
deb https://yocto.dave.eu/imx-5.4/aarch64-mx8mp ./<br />
deb https://yocto.dave.eu/imx-5.4/aarch64 ./<br />
deb https://yocto.dave.eu/imx-5.4/all ./<br />
deb https://yocto.dave.eu/imx-5.4/imx8mpevk ./<br />
</pre><br />
<br />
Please note that two <code>.list</code> files were automatically generated by Yocto: <code>/etc/apt/sources.list.d/debian-10.list</code> and <code>/etc/apt/sources.list</code>. They were renamed to <code>debian-10.list.ignore</code> and <code>sources.list.ignore</code> respectively.<br />
<br />
<br />
The following example shows the installation of the <code>git</code> package, which is retrieved from the local archive:<br />
<pre class="board-terminal"><br />
root@imx8mpevk:~# apt-get install git<br />
Reading package lists... Done<br />
Building dependency tree <br />
Reading state information... Done<br />
The following NEW packages will be installed:<br />
git<br />
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.<br />
Need to get 0 B/3043 kB of archives.<br />
After this operation, 0 B of additional disk space will be used.<br />
WARNING: The following packages cannot be authenticated!<br />
git<br />
Install these packages without verification? [y/N] y<br />
Selecting previously unselected package git.<br />
(Reading database ... 99542 files and directories currently installed.)<br />
Preparing to unpack .../git_2.23.1-r0_arm64.deb ...<br />
Unpacking git (2.23.1-r0) ...<br />
Setting up git (2.23.1-r0) ...<br />
N: Ignoring file 'debian-10.list.ignore' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension<br />
</pre></div>U0002https://wiki.dave.eu/index.php?title=MediaWiki:Common.css&diff=9856MediaWiki:Common.css2020-08-10T12:52:18Z<p>U0002: </p>
<hr />
<div>/* CSS placed here will be applied to all skins */<br />
<br />
#mw-head {display: yes} /*rimuove la barra in alto a dx*/<br />
#mw-head-base {display: yes} /*?*/<br />
#mw-page-base {display: yes} /*fa qualcosa in alto che non capisco*/<br />
#mw-panel {display: yes} /*rimuove la sidebar e logo*/<br />
#p-namespaces {display: yes} /*?*/<br />
#footer {display: yes} /*mostra last update, footer in fondo*/<br />
#p-tb {display: none} /*mostra o meno toolbox */<br />
#mw-searchButton {display: yes} /*?*/<br />
#searchGoButton {display: yes} /*?*/<br />
<br />
body.page-Main_Page.action-view h1.firstHeading { display: none; } /*nascondo il titolo della pagina*/<br />
/*body.page-Main_Page.action-submit h1.firstHeading { display: none; } */ /*nascondo il titolo della pagina*/<br />
<br />
<br />
code.board-terminal,<br />
pre.board-terminal {<br />
font-family: monospace, "Courier New" !important;<br />
color:white;<br />
background:black;<br />
white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
word-wrap: break-word<br />
}<br />
<br />
pre.workstation-terminal {<br />
font-family: monospace, "Courier New" !important;<br />
color:lightgreen;<br />
background:black;<br />
white-space: pre-wrap; <br />
white-space: -moz-pre-wrap; <br />
word-wrap: break-word<br />
}<br />
<br />
div.reflist ol.references {<br />
list-style-type: inherit; /* Enable custom list style types */<br />
}</div>U0002https://wiki.dave.eu/index.php?title=How_to_configure_the_network_interfaces&diff=9659How to configure the network interfaces2020-03-05T10:21:16Z<p>U0002: apply network configuration at runtime with systemd</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{AppliesToAxel}}<br />
{{AppliesToAxelLite}}<br />
{{AppliesToAxelEsatta}}<br />
{{Applies To Bora}}<br />
{{Applies To BoraX}}<br />
{{Applies To BoraLite}}<br />
{{Applies To Diva}}<br />
{{InfoBoxBottom}}<br />
<br />
<br />
== Introduction ==<br />
<br />
For deploying an Embedded System, one of the most important configuration is the ''Network Interface configuration''. <br />
<br />
Once the Embedded Device is finally configured for stand-alone bootstrap, the network interface should be configured for reaching the device remotely via network connections like ssh, telnet, ftp, http, etc.<br />
<br />
This Application Note briefly describes how it is possible to simply configure the network interfaces on [https://en.wikipedia.org/wiki/UNIX_System_V SystemV] (aka ''SysV'') or [https://www.freedesktop.org/wiki/Software/systemd/ systemd]<br />
<br />
=== Resources ===<br />
<br />
For further details on network configuration, please refer - for example - to:<br />
<br />
* [https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_basic_network_configuration_with_ifupdown_legacy Debian - The basic network configuration]<br />
* [https://www.freedesktop.org/software/systemd/man/systemd.network.html systemd network configuration]<br />
<br />
== Examples==<br />
<br />
The following configuration assumptions are used in the paragraphs shown below:<br />
<br />
* IP address range of the LAN network '''192.168.1.0 - 192.168.1.255'''<br />
* IP address of the gateway '''192.168.1.254'''<br />
* IP address of the device '''192.168.1.100'''<br />
<br />
== SysV ==<br />
<br />
The configuration files for SysV can be found in pre-defined directorys as written [https://en.wikibooks.org/wiki/Linux_Networking/Where_should_I_put_the_configuration_commands%3F here]<br />
<br />
Basically, for network configuration, it should be enough to properly configure the <code>/etc/network/interfaces</code> file.<br />
<br />
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)<br />
<br />
Here below an example of configuration file:<br />
<br />
=== Static IP address ===<br />
The network interface is configured with a static IP address by creating the configuration entry in the '''/etc/network/interfaces''' file as the following:<br />
<br />
<pre><br />
auto eth0<br />
iface eth0 inet static<br />
address 192.168.1.100<br />
netmask 255.255.255.0<br />
gateway 192.168.1.254<br />
</pre><br />
<br />
=== Dynamic IP addres (DHCP) ===<br />
<br />
The network interface is configured - using a proper DHCP server on the network - by creating the configuration entry in the '''/etc/network/interfaces''' file as the following:<br />
<br />
<pre><br />
allow-hotplug eth0<br />
iface eth0 inet dhcp<br />
</pre><br />
<br />
When the Linux kernel detects the physical interface eth0, the iface causes ''ifup'' to use DHCP to configure the interface.<br />
<br />
=== DNS ===<br />
<br />
If the <code>resolvconf</code> package is not installed, the DNS configuration can be done manually by editing the '''/etc/resolv.conf''' as the following:<br />
<br />
<pre><br />
nameserver 192.168.1.1<br />
</pre><br />
<br />
For example, it can be done on the command line echoing the string in this way:<br />
<br />
root@axel-lite:~# echo "nameserver 192.168.1.1" > /etc/resolv.conf<br />
<br />
=== loopback network interface ===<br />
<br />
The following configuration entry in the '''/etc/network/interfaces''' file brings up the loopback network interface lo upon booting the system.<br />
<pre><br />
# The loopback interface<br />
auto lo<br />
iface lo inet loopback<br />
</pre><br />
<br />
This one always exists in the ''/etc/network/interfaces'' file.<br />
<br />
== systemd ==<br />
<br />
The network configuration for systemd are basically found in the <code>/etc/systemd/network/</code> directory.<br />
<br />
The most simply way for configuring the network interface is to create/edit the file '''/etc/systemd/network/eth0.network''' as per the following paragraphs.<br />
<br />
For more example and usage hints on systemd, please refer to our [[XELK-AN-008:_How_to_use_systemd_on_an_Embedded_system#Configuring_the_network_interfaces | wiki]] page.<br />
<br />
=== Static IP address ===<br />
<br />
<pre><br />
[Match]<br />
Name=eth0<br />
<br />
# Prevent the interface loading if the kernel boots from nfs<br />
KernelCommandLine=!nfsroot<br />
<br />
[Network]<br />
Address=192.168.1.100<br />
Gateway=192.168.1.254<br />
DNS=192.168.1.1<br />
</pre><br />
<br />
=== Dynamic IP addres (DHCP) ===<br />
<br />
The network interface is configured - using a proper DHCP server on the network - by using the '''DHCP''' key in the configuration file as the following:<br />
<br />
<pre><br />
[Match]<br />
Name=eth0<br />
<br />
# Prevent the interface loading if the kernel boots from nfs<br />
KernelCommandLine=!nfsroot<br />
<br />
[Network]<br />
DHCP=yes<br />
</pre><br />
<br />
When systemd network starts, it tries to use a DHCP server present in the network to configure the interface.<br />
<br />
=== DNS ===<br />
<br />
The DNS key (in the configuration file) is used only if the '''systemd-resolved service''' is enabled and the ''/etc/resolv.conf'' has a symbolic link to ''/run/systemd/resolve/stub-resolv.conf''<br />
<br />
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf<br />
<br />
=== loopback network interface ===<br />
systemd contains native implementations of various tasks that need to be executed as part of the boot process. <br />
<br />
For example, it sets the hostname or configures the loopback network device.<br />
<br />
=== Apply configuration changes ===<br />
After editing the above files, changes are applied after reboot or by restarting <code>systemd-networkd.service</code>:<syntaxhighlight lang="bash"><br />
root@imx6qdlxelk:~# systemctl restart systemd-networkd.service<br />
</syntaxhighlight></div>U0002https://wiki.dave.eu/index.php?title=Yocto_build_system_FAQs&diff=9655Yocto build system FAQs2020-02-27T14:17:07Z<p>U0002: /* FAQs */</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies To Yocto}}<br />
{{InfoBoxBottom}}<br />
==Introduction==<br />
This page provides includes a list of general FAQs related to the use of Yocto on the DAVE Embedded System's products.<br />
<br />
==FAQs==<br />
<br />
===Q: Why does smart return error: Failed acquiring release file for '<channel_name>': when used over https ?===<br />
Although smart is capable of handling https connections, this error is caused by the SSL_CERTIFICATE issue that is affecting yocto build system. For more information, you can refer to this [https://lists.yoctoproject.org/pipermail/yocto/2015-July/025774.html discussion]. <br><br />
<br />
At the moment we are still working on this issue in the attempt to find a permanent solution. Unfortunately, the SSL_CERTIFICATE problem also affects other tools for which a temporary workaround is provided.<br />
<br />
===Q:<span id="Q2"></span> Why does pip return There was a problem confirming the ssl certificate: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) - skipping ?===<br />
<br />
In order to solve this problem, a possible workaround consist of disabling the SSL CERTIFICATE checking as suggested in the following example:<br><br />
''pip install pyserial --trusted-host pypi.python.org --index-url=<nowiki>http://pypi.python.org/simple/</nowiki>'' <br><br />
Other similar solutions can be found at this [https://stackoverflow.com/questions/34615693/can-i-turn-off-python-pip-ssl-cert-validation-with-an-env-variable page ]<br />
<br />
'''Note:''' In the case that the time on your system is out of sync, please adjust the date and time and make another attempt to install the package. A wrong system date/time may cause the verification process to fail.<br />
<br />
===Q:<span id="Q3"></span> How can I turn off git SSL verification? ===<br />
<br />
Since the SSL_CERTIFICATE problem affects also 'git', it is suggested to turn off the SSL CERTIFICATE checking in the case you are trying to work with a repository over https. In order to achieve this, from the local folder export the GIT_SSL_NO_VERIFY variable, in this way: <br />
''export GIT_SSL_NO_VERIFY=1''<br />
<br />
===Q: How to graphically visualize the dependencies of an image?===<br />
<br />
During the implementation of the production root file system image, it is convenient to graphically visualize the dependencies of the packages used in the development image (see also [[Working_with_the_Yocto_build_system#Introduction|this section]]).<br />
<br />
To do that, issue the following command:<br />
<br />
<pre class="board-terminal"><br />
bitbake -g <image_name><br />
</pre><br />
<br />
This command produces a <code>recipe-depends.dot</code> file which can be visualized with the [http://www.graphviz.org/ <code>graphviz</code> tool].<br />
<br />
===Q:How to solve <code>fatal: the '--set-upstream' option is no longer supported</code> bitbake error? ===<br />
<br />
Using recent <code>git</code> versions (>2.14.1) with old Yocto releases (e.g. <code>krogoth</code> and older) lead to the following error during <code>do_unpack</code> task of packages downloading sources with git:<br />
<br />
<pre class="board-terminal"><br />
ERROR: PACKAGE do_unpack: Fetcher failure: ...;<br />
git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master failed with exit code 128, output:<br />
fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead.<br />
<br />
ERROR: PACKAGE do_unpack: Function failed: base_do_unpack<br />
</pre><br />
<br />
This is a known bitbake issue (see [https://www.yoctoproject.org/pipermail/yocto/2017-October/038472.html this Yocto mailing list message]) which has been solved in more recent bitbake releases<br />
<br />
Due the fact that DAVE cannot patch bitbake on its own BSP (unless providing a mirror of the whole poky repository with this patch included), we suggest to add the follwing patch manually, after setting up Yocto repositories (in other word, after <code>repo sync</code> command)<br />
<br />
<br />
[[File:0001-bitbake-Replace-deprecated-git-branch-parameter-set-.patch]]<br />
<br />
With the following command:<br />
<br />
<pre class="board-terminal"><br />
cd sources/poky<br />
wget https://wiki.dave.eu/images/c/cf/0001-bitbake-Replace-deprecated-git-branch-parameter-set-.patch<br />
git am 0001-bitbake-Replace-deprecated-git-branch-parameter-set-.patch<br />
</pre></div>U0002https://wiki.dave.eu/index.php?title=File:0001-bitbake-Replace-deprecated-git-branch-parameter-set-.patch&diff=9654File:0001-bitbake-Replace-deprecated-git-branch-parameter-set-.patch2020-02-27T14:13:12Z<p>U0002: </p>
<hr />
<div></div>U0002https://wiki.dave.eu/index.php?title=Mechanicals_(SDV04)&diff=9339Mechanicals (SDV04)2020-01-21T15:05:48Z<p>U0002: </p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies To SDVX}}<br />
{{InfoBoxBottom}}<br />
<br />
= Mechanical specifications =<br />
<br />
This article provides mechanical information of the SDV04.<br />
<br />
== Board Layout ==<br />
<br />
The following figure shows the physical dimensions of the SDV04:<br />
<br />
[[File:SDV04-mechanicals.png|thumb|center|700px|Mechanical dimensions]]<br />
<br />
== CAD drawings ==<br />
<br />
* DXF (2D): [[File:CS073817A.dxf.zip]]<br />
* IDF (3D): [[File:CS073817A.idf.zip]]<br />
<br />
=== STP FILE FULL VERSION ===<br />
* STEP (3D): [[File:CS073817A.step.zip | CS073817A.step.zip]]<br />
<br />
* This FULL version reports the most important configurations available for SDV04<br />
* The real position of connectors may differ from the real ones due to CAD position and render precision<br />
* for PCB precise psitioning refer to IDF file version</div>U0002https://wiki.dave.eu/index.php?title=BELK-AN-004:_Interfacing_BoraEVB/BoraXEVB_to_TFT_LCD_display&diff=9256BELK-AN-004: Interfacing BoraEVB/BoraXEVB to TFT LCD display2020-01-03T14:55:18Z<p>U0002: </p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies To Bora}}<br />
{{Applies To BoraLite}}<br />
{{Applies To BoraX}}<br />
{{InfoBoxBottom}}<br />
{{WarningMessage|text=This application note was validated against specific versions of the kit only. It may not work with other versions. Supported versions are listed in the ''History'' section.}}<br />
==History==<br />
<br />
{| class="wikitable" border="1"<br />
!Version<br />
!Date<br />
!BELK/BXELK version<br />
!Notes<br />
|-<br />
|1.0.0<br />
|15:03, 4 September 2015 (CEST)<br />
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|2.2.0]]<br />
|First release<br />
|-<br />
|2.0.0<br />
|10:21, 9 November 2015 (CET)<br />
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|2.2.0, 3.0.0]]<br />
|Added support for BoraX/BoraXEVB platform<br />
|-<br />
|{{oldid|8292|2.0.1}}<br />
|11:53, 13 March 2017 (CET)<br />
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|2.2.0, 3.0.0]]<br />
|Added info for installing Qt on rfs using <code>smart</code><br />
|-<br />
|3.0.0<br />
|TBD<br />
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|4.1.0 / 2.1.0]]<br />
|Migrated to BELK 4.1.0 / BXELK 2.1.0<br />
|-<br />
|}<br />
<br />
==Introduction==<br />
<br />
This application note describes the interfacing of [http://www.ampire.com.tw/en/index.asp Ampire AM-800480STMQW-TA1] display to [[BoraEVB |BoraEVB ]]and [[BoraXEVB|BoraXEVB]]. Main characteristics of this 7" TFT LCD panel are:<br />
* 800x480 resolution<br />
* color depth: 18 bpp<br />
* electrical interface: LVDS (3 pairs).<br />
<br />
This project is based on [[Bora_Embedded_Linux_Kit_%28BELK%29#BELK_software_components|BELK 2.2.0]] and [[Bora_Embedded_Linux_Kit_%28BELK%29#BELK_software_components|BELK 3.0.0]].<br />
<br />
==Physical interfacing==<br />
===BoraEVB===<br />
To interface the display a small adapter board is needed. It interfaces J22 connector on BoraEVB side and provides a 20-pin connector to directly attach display cable.<br />
<br />
The adapter board <br />
* is also equipped with a linear regulator generating 2.5V. This voltage is used as power supply for the VDDIO_BANK13 rail. This voltage is required to implement LVDS differential pairs that drive display.<br />
* integrates a pad (denoted as TP1) that is used to connect 5V power supply generated by MOD2 PSU of BoraEVB. This additional power rails is required by display backlight circuitry.<br />
<br />
Ampire AM-800480STMQW-TA1 part integrates resistive touch too. This is directly connected to BoraEVB's J25 connector. Resistive touch is managed by Texas Instruments TSC2003 controller (U27).<br />
<br />
Schematics of adapter board can be downloaded from this [https://www.dave.eu/system/files/area-riservata/BORA_LCD_ADAPTOR_ADBL7000C1R_1.0.0_0.pdf link].<br />
<br />
===BoraXEVB===<br />
In case of BoraXEVB, no adapter board is needed. LCD panel is directly connected to J26 connector where PL bank 13's signals implementing LVDS interface are routed (see [[BoraXEVB#Schematics|page 14]] of the schematics). I/O voltage of bank 13 is set to 2.5V by configuring [[BoraXEVB#BANK13_VDDIO_selector_-_JP25|JP25 ]] as shown in the following table.<br />
{| class="wikitable" border="1"<br />
!Pins<br />
!Setting<br />
|-<br />
|1-2<br />
|closed<br />
|-<br />
|3-4<br />
|open<br />
|-<br />
|5-6<br />
|closed<br />
|-<br />
|7-8<br />
|open<br />
|-<br />
|9-10<br />
|open<br />
|-<br />
|11-12<br />
|open<br />
|-<br />
|}<br />
<br />
==Block diagram and Vivado project==<br />
The following pictures show simplified block diagram of the design. <br />
<br />
[[File:An-belk-004-01.png|thumb|center|600px|Simplified block diagram of the design (Bora + BoraEVB)]]<br />
[[File:An-belk-004-borax-01.png|thumb|center|600px|Simplified block diagram of the design (BoraX + BoraXEVB)]]<br />
[[File:an-belk-004-boralite-01.png|thumb|center|600px|Simplified block diagram of the design (BoraLite + Adapter + BoraXEVB)]]<br />
<br />
LCD is driven by a controller implemented in PL that fetches pixel data from frame buffer and periodically refreshes physical screen.<br />
The LCD controller is composed of an AXI VDMA IP, the LCD controller itself and a parallel-to-LVDS serializer.<br />
AXI VDMA and the LCD controller provides configuration registers that are mapped in the following address range:<br />
* AXI VDMA: 0x43000000 - 0x4300FFFF<br />
* LCD Controller: 0x43C00000 - 0x43C0FFFF<br />
<br />
The following picture shows the block diagram of the Vivado project with LCD controller:<br />
<br />
<br />
[[File:An-belk-004-02.png|800px]]<br />
<br />
<br />
To implement frame buffer, a portion of main SDRAM is used. This area is allocated at runtime by linux frame buffer driver. Even if LCD is 18 bpp, each pixel is represented by 32-bit word in memory. In fact each pixel is in RGB666 format, so for each colour only the six most significant bits of the frame buffer RGB888 are used to drive the display.<br />
<br />
===Bora + BoraEVB===<br />
Here is the pinout assignment to drive the LCD:<br />
{| class="wikitable" | <br />
| align="center" style="background:#f0f0f0;"|'''LCD Signal'''<br />
| align="center" style="background:#f0f0f0;"|'''BORA SOM Signal'''<br />
|-<br />
| BackLight (*)||IO_L15P_T2_DQS_13<br />
|-<br />
| LVDS_CLK_P||IO_L22P_T3_13<br />
|-<br />
| LVDS_CLK_N||IO_L22N_T3_13<br />
|-<br />
| LVDS_D0_P||IO_L21P_T3_DQS_13<br />
|-<br />
| LVDS_D0_N||IO_L21N_T3_DQS_13<br />
|-<br />
| LVDS_D1_P||IO_L19P_T3_13<br />
|-<br />
| LVDS_D1_N||IO_L19N_T3_VREF_13<br />
|-<br />
| LVDS_D2_P||IO_L18P_T2_13<br />
|-<br />
| LVDS_D2_N||IO_L18N_T2_13<br />
|-<br />
|}<br />
<br />
The Vivado project can be downloaded from this [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-bora-xpr.zip link].<br />
<br />
(*) This signal is used to control backlight. It is usually driven by a PWM signal whose duty cycle is proportional to backlight intensity. For the sake of simplicity, in this project this signal is driven by a GPIO, thus only two intensity levels are supported (0% and 100%).<br />
<br />
===BoraLite + Adapter + BoraXEVB===<br />
Here is the pinout assignment to drive the LCD:<br />
{| class="wikitable" | <br />
| align="center" style="background:#f0f0f0;"|'''LCD Signal'''<br />
| align="center" style="background:#f0f0f0;"|'''BORA SOM Signal'''<br />
|-<br />
| BackLight (*)||IO_L6N_T0_VREF_13 (**)<br />
|-<br />
| LVDS_CLK_P||IO_L13P_T2_MRCC_13 (**)<br />
|-<br />
| LVDS_CLK_N||IO_L13N_T2_MRCC_13 (**)<br />
|-<br />
| LVDS_D0_P||IO_L12P_T1_MRCC_13 (**)<br />
|-<br />
| LVDS_D0_N||IO_L12N_T1_MRCC_13 (**)<br />
|-<br />
| LVDS_D1_P||IO_L15P_T2_DQS_13 (**)<br />
|-<br />
| LVDS_D1_N||IO_L15N_T2_DQS_13 (**)<br />
|-<br />
| LVDS_D2_P||IO_L11P_T1_SRCC_13 (**)<br />
|-<br />
| LVDS_D2_N||IO_L11N_T1_SRCC_13 (**)<br />
|-<br />
|}<br />
<br />
The Vivado project can be downloaded from this [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-Interfacing-to-LCD-display_0.zip link] '''TODO''': update link<br />
<br />
(*) This signal is used to control backlight. It is usually driven by a PWM signal whose duty cycle is proportional to backlight intensity. For the sake of simplicity, in this project this signal is driven by a GPIO, thus only two intensity levels are supported (0% and 100%). This is a CMOS 2.5V level signal. Make sure that voltage levels of this signal are compatible with LCD backlight input.<br><br />
(**) On the adapter this signal is routed (via configurable 0R) to multiple pins of the EVB connector to meet all the features of the EVB. Please make sure to configure the Adapter for the use of the LVDS connector.<br />
<br />
==== BoraLiteAdapter BLADP0000R0R ====<br />
<br />
As the BoraLite SOM has fewer signals routed out as the other SOM, some signal are multiplexed via 0R resistors: the following table list these configurations:<br />
{| class="wikitable" | <br />
| align="center" style="background:#f0f0f0;"|'''Reference'''<br />
| align="center" style="background:#f0f0f0;"|'''PmodA conn.'''<br />
| align="center" style="background:#f0f0f0;"|'''LVDS conn.'''<br />
|-<br />
| R33 || 0R || DNP<br />
|-<br />
| R34 || 0R || DNP<br />
|-<br />
| R35 || 0R || DNP<br />
|-<br />
| R36 || 0R || DNP<br />
|-<br />
| R37 || 0R || DNP<br />
|-<br />
| R38 || 0R || DNP<br />
|-<br />
| R39 || 0R || DNP<br />
|-<br />
| R40 || x || DNP<br />
|-<br />
| R41 || 0R || DNP<br />
|-<br />
| R42 || x || 0R<br />
|-<br />
| R43 || DNP || 0R<br />
|-<br />
| R44 || DNP || 0R<br />
|-<br />
| R45 || DNP || 0R<br />
|-<br />
| R46 || DNP || 0R<br />
|-<br />
| R47 || DNP || 0R<br />
|-<br />
| R48 || DNP || 0R<br />
|-<br />
| R49 || DNP || 0R<br />
|-<br />
| R50 || DNP || 0R<br />
|-<br />
|}<br />
<br />
===BoraX + BoraXEVB===<br />
Here is the pinout assignment to drive the LCD:<br />
{| class="wikitable" | <br />
| align="center" style="background:#f0f0f0;"|'''LCD Signal'''<br />
| align="center" style="background:#f0f0f0;"|'''BORA SOM Signal'''<br />
|-<br />
| BackLight (*)||IO_0_13<br />
|-<br />
| LVDS_CLK_P||IO_L13P_T2_MRCC_13<br />
|-<br />
| LVDS_CLK_N||IO_L13N_T2_MRCC_13<br />
|-<br />
| LVDS_D0_P||IO_L12P_T1_MRCC_13<br />
|-<br />
| LVDS_D0_N||IO_L12N_T1_MRCC_13<br />
|-<br />
| LVDS_D1_P||IO_L14P_T2_SRCC_13<br />
|-<br />
| LVDS_D1_N||IO_L14N_T2_SRCC_13<br />
|-<br />
| LVDS_D2_P||IO_L11P_T1_SRCC_13<br />
|-<br />
| LVDS_D2_N||IO_L11N_T1_SRCC_13<br />
|-<br />
|}<br />
<br />
The Vivado project can be downloaded from this [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-Interfacing-to-LCD-display_0.zip link]<br />
<br />
(*) This signal is used to control backlight. It is usually driven by a PWM signal whose duty cycle is proportional to backlight intensity. For the sake of simplicity, in this project this signal is driven by a GPIO, thus only two intensity levels are supported (0% and 100%). This is a CMOS 2.5V level signal. Make sure that voltage levels of this signal are compatible with LCD backlight input.<br />
<br />
==Enabling frame buffer driver in linux kernel==<br />
<br />
To enable frame buffer driver user needs to:<br />
* for Bora get the pre-built binaries [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-bora-sw.zip here]<br />
* for BoraLite get the pre-built binaries [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-boralite-sw.zip here] '''TODO''': add binaries<br />
* for BoraX get the pre-built binaries [https://www.dave.eu/system/files/area-riservata/AN-BELK-004-borax-sw.zip here]<br />
<br />
The Vivado project can also be build with the procedure explained [[Creating_and_building_example_Vivado_project_(BELK/BXELK)|here]] with the following modifications:<br />
* <code>bora</code> -> <code>bora_LVDS</code><br />
* <code>recreate_project_bora_BASE.tcl</code> -> <code>recreate_project_bora_LVDS.tcl</code><br />
* Same changes for borax and boralite targets<br />
<br />
U-boot:<br />
* the default KIT binary files of u-boot (u-boot.img) and SPL (boot.bin) can be used.<br />
* the variable <code>bootcmd</code> has to contain this string: <code>video=borafb:800x480-32 cma=32M</code><br />
<br />
Kernel and device tree can also be built with the following procedure:<br />
* update Bora kernel repository (as described [[Bora_Embedded_Linux_Kit_(BELK)#Updating_the_repositories_from_BELK_2.1.0_to_BELK_2.2.0|here]]) '''TODO''': update repo???<br />
* the default KIT binary files of kernel (uImage) can be used.<br />
* build the <code>bora-an004.dtb</code> devicetree<br />
<br />
Put the binaries on the first (FAT32) partition of your BELK SD card, overwriting the original one if needed. Please note that you need the following files:<br />
* boot.bin<br />
* bora.dtb<br />
* uImage<br />
* fpga.bin<br />
* u-boot.img<br />
* uEnv.txt<br />
<br />
Install root file system on second (ext4) partition of your BELK SD card (firstly deleting all previous rfs files):<br />
* get rfs image [https://mirror.dave.eu/bora/belk-3.0.1/belk-3.0.1_bora-image-devel-bora.tar.gz here]<br />
<br />
Insert the SD card into Bora/BoraX EVB and turn on the board.<br />
<br />
During kernel bootstrap, the following messages are printed out on console, indicating framebuffer driver has been loaded succesfully:<br />
<br />
<pre><br />
[ 0.600840] borafb borafb.0: fb0: Virtual frame buffer device, using 16384K of video memory @ phys 2d900000<br />
</pre><br />
<br />
You will also see two [https://en.wikipedia.org/wiki/Tux Tuxes] on the top left corner of the LCD, indicating that this Linux system has two cores, as shown in the following picture:<br />
<br />
{|style="margin: 0 auto;"<br />
| [[File:An-belk-004-03.jpg|thumb|center|400px|Bora/BoraEVB system with LCD panel]]<br />
| [[File:An-belk-004-05.jpg|thumb|center|400px|BoraX/BoraXEVB system with LCD panel]]<br />
|}<br />
<br />
Once the kernel has completed boot, frame buffer can be accessed from user space applications via <code>/dev/fb0</code> device file (for more details please refer to https://www.kernel.org/doc/Documentation/fb/framebuffer.txt).<br />
<br />
=== How to install Qt4 libraries on rfs ===<br />
* configure BELK for downloading new packages using <code>smart</code>: a useful description for using smart can be found [[AN-XELK-003:_Package_Management_with_Yocto#Installing_packages_on_target |here]] <br />
* configure network interface for accessing DAVE Yocto pre-built images. For example:<br />
<br />
root@bora:~# ifconfig eth0 192.168.0.95 ''<-- BELK IP address''<br />
root@bora:~# echo "nameserver 192.168.0.1" > /etc/resolv.conf ''<-- your DNS, otherwise select a public DNS like Google's one 8.8.8.8''<br />
root@bora:~# route add default gw 192.168.0.254 ''<-- your gateway address''<br />
<br />
* check network connectivity<br />
root@bora:~# ping www.dave.eu<br />
PING www.dave.eu (147.123.240.198): 56 data bytes<br />
64 bytes from 147.123.240.198: seq=0 ttl=49 time=72.510 ms<br />
* add DAVE smart channel and update smart cache<br />
root@bora:~# smart channel --add armv7a_vfp_neon type=rpm-md baseurl=http://yocto.dave.eu/belk-3.0.1/armv7a_vfp_neon/<br />
root@bora:~# smart update<br />
<br />
* install Qt required packages using smart<br />
<br />
root@bora:~# smart install qt4-embedded-4.8.5-r0<br />
...<br />
<br />
root@bora:~# smart install libicui18n51-51.2-r0<br />
... <br />
<br />
root@bora:~# smart install tslib-calibrate-1.1-r0<br />
...<br />
<br />
root@bora:~# smart install tslib-tests-1.1-r0<br />
...<br />
<br />
* configure touchscreen input for Qt and start Qt demo<br />
<br />
root@bora:~# export QWS_MOUSE_PROTO=LinuxInput:/dev/input/event0<br />
root@bora:~# qtdemoE -qws &<br />
<br />
<br />
The following picture shows Qt 4.8.5 ''Affine Transformations'' demo application running on top of it.<br />
<br />
{|style="margin: 0 auto;"<br />
| [[File:An-belk-004-04.jpg|thumb|center|400px|Qt Affine Transformations running on Bora/BoraEVB system]]<br />
| [[File:An-belk-004-06.jpg|thumb|center|400px|Qt Affine Transformations running on BoraX/BoraXEVB system]]<br />
|}<br />
<br />
=== Demo on youtube===<br />
<br />
{| class="wikitable" | width="100%"<br />
| {{#ev:youtube|7kdR9L4D_E0|500|center|Add Qt4 libraries with SMART package manager on BoraEVB/BoraXEVB |frame}}<br />
|}</div>U0002https://wiki.dave.eu/index.php?title=VirtualBox_Network_Configuration&diff=9255VirtualBox Network Configuration2020-01-03T10:45:17Z<p>U0002: additiona network interface help</p>
<hr />
<div>{{InfoBoxTop}}<br />
{{Applies_To_DVDK}}<br />
{{InfoBoxBottom}}<br />
<br />
{{ImportantMessage|text=Different versions of the MVM may use different graphical interfaces (GNOME Unity, LXDE etc.). Hence, the screenshots shown in this page may not look like the same across all of the MVM versions or releases. However, the concepts here described have a general validity.}}<br />
<br />
=== VirtualBox Network Configuration Primer ===<br />
<br />
VirtualBox networking supports different configuration. For a in-depth discussion regarding virtual networking see VBox official documentation [http://www.virtualbox.org/manual/ch06.html here].<br />
<br />
For developing purpose, we are interested in two configuration:<br />
* NAT, which is the default provided with [[:Category:DVDK|DVDK]], and<br />
* Bridged Networking<br />
<br />
=== Network Address Translation (NAT) ===<br />
<br />
[[Wikipedia:Network address translation|Network Address Translation]] is a tecnique used in IP networking that modify IP packet header, by changing IP address, while the routing device processes the packet.<br />
<br />
Only the IP address of the routing device (in case of a Virtual Machine, the host ack at router for the guest) is seen from outside. Usually the routed device (in our case, the guest machine) has an IP address that belongs to a completely different IP subnet.<br />
<br />
NAT make easy to use a virtual machine because:<br />
* it does not require to configure guest network parameters (the router act as DHCP server and give all the needed information to the guest)<br />
* it guarantees that the VM can be executed in any network environment without breaking the existing network.<br />
<br />
However it's really hard to configure NAT to let the VM to act as a server (e.g. as NFS or TFTP server), for this reason the developer usually choose a bridged configuration, with proper IP parameter assignments.<br />
<br />
=== Bridged configuration ===<br />
<br />
<br />
In brief, [[Wikipedia:Bridge (networking)|Bridge Networking]] configure host's physical network interface and guest's virtual network interface as if they are connected with a Ethernet Switch.<br />
<br />
In this way:<br />
* guest (DVDK Virtual Machine) has it's own IP address, usually on the same subnet of the host<br />
* guest is directly accessible (apart from firewall rules that may be configured on the host) from any device on the same subnet<br />
<br />
To change from NAT to Bridge configuration user have to:<br />
* change Virtual Box network setting<br />
* configure, if needed, guest networking. Guest by default uses DHCP so, if DHCP server is available on your network, no additional configuration is needed.<br />
<br />
The procedure here described makes use of graphical tools to configure network interface. To do that, please ensure <code>network-manager</code> applet is installed by issuing this command on a terminal shell:<br />
<pre><br />
dpkg -l network-manager<br />
</pre><br />
If it is not installed, use these commands to install it:<br />
<pre><br />
sudo apt-get update<br />
sudo apt-get install network-manager<br />
</pre><br />
After installing it, please reboot the MVM in order to make the changes to take effect.<br />
==== VirtualBox Bridged configuration ====<br />
<br />
It's easy to change Virtual Box Network configuration:<br />
* open VBox application and start DVDK VM<br />
* from the VBox main window, select your VM and choose ''Settings'' from the toolbar<br />
<br />
<br />
[[File:DVDK_Bridge_Configuration_1.png]]<br />
<br />
<br />
* Choose ''Network'' item and, from the ''Attached To:'' dropdown choose ''Bridged Adapter''<br />
<br />
<br />
[[File:DVDK_Bridge_Configuration_2.png]]<br />
<br />
* Now the ''Name'' dropdown should be enabled. If you have more than one network interface, choose the right one to connect the bridge too<br />
<br />
[[File:DVDK_Bridge_Configuration_3.png]]<br />
<br />
* That's all, click Ok to apply changes.<br />
<br />
----<br />
<br />
An advanced setup is to add another network adapter to be used as ''Bridged Adapter'', while keeping the first network interface with NAT<br />
<br />
This is a useful setup, for example if your're working on a laptop connected to Internet via Wi-Fi, while you're developing using the bridged network adapter on Ethernet. In this case the VM will be able to access the public network using the NATed interface (via host WiFi) while serving TFTP/NFS file to the Embedded Linux system<br />
<br />
To add a new network adapter:<br />
* shutdown the VM<br />
* open the VM <code>Settings</code> dialog<br />
* go to the <code>Network</code> page<br />
* select <code>Adapter 2</code> tab<br />
* tick the <code>Enable Network Adapter</code> checkbox<br />
* select the host network interface to bridge to in the <code>Name</code> dropdown<br />
* hit <code>OK</code><br />
[[File:DVDK adding network adapter.png|none|thumb|699x699px]]<br />
<br />
==== Network Configuration of the VM (guest) ====<br />
By default, the virtual machine image provided with DVDK is configured with DHCP. If you don't have a DHCP server available on your network, you should configure the interface manually.<br />
<br />
<br />
{{ImportantMessage|text=If the configuration is changed from NAT to bridged and no DHCP servers are available on the network, the virtual machine will "hang" for few minutes during the boot process before starting the graphical environment.<br />
<br />
[[File:MVM-bridged-network-DHCP.png|thumb|center|600px]]<br />
}}<br />
<br />
<br />
=====Creation of the network connection=====<br />
The procedure may differ from one graphical environment to the other.<br />
======Unity======<br />
Once the graphical interface is ready, right-click on the NetworkManager Applet on the top Panel and choose ''Edit Connections''<br />
<br />
[[File:DVDK_Ubuntu_Network_Configuration_1.png]]<br />
<br />
<br />
<br />
Now ''Add'' new connection<br />
<br />
[[File:DVDK_Ubuntu_Network_Configuration_2.png]]<br />
<br />
<br />
<br />
Fill all the required fields (name and IPv4 configuration) and hit ''Apply'' button.<br />
<br />
[[File:DVDK_Ubuntu_Network_Configuration_3.png]]<br />
<br />
<br />
<br />
Now the new configuration is added and the Network Manager Applet should tell you that the connection with your network is established<br />
<br />
For more information about ubuntu take a look at its [https://help.ubuntu.com/10.04/index.html official documentation]<br />
======LXDE======<br />
To configure the network connection, the following approaches are available:<br />
*Edit the configuration files as described [https://help.ubuntu.com/community/NetworkConfigurationCommandLine here]<br />
*Using a script like the following:<br />
<pre><br />
#!/bin/bash<br />
ifconfig eth0 192.168.0.82 netmask 255.255.255.0 up<br />
route add default gw 192.168.0.254 eth0<br />
echo "nameserver 8.8.8.8" > /etc/resolv.conf<br />
echo "nameserver 8.8.4.4" >> /etc/resolv.conf<br />
</pre><br />
<br />
===== NFS Configuration =====<br />
<br />
{{ImportantMessage|text=Latest DVDK/MVM use a different default configuration which exports <code>/home</code> directory for all IPs. Even if this is a security hole, it allows using NFS without changing the default configuration on any network<br />
<pre><br />
/home 0.0.0.0/0.0.0.0(rw,sync,no_root_squash,no_subtree_check,crossmnt)<br />
</pre><br />
}}<br />
<br />
[[w:Network_File_System|NFS]] is commonly used to network mount the target root file system. NFS Server is already installed on [[:Category:DVDK|DVDK]] but needs to be configured before using it.<br />
<br />
User just need to edit <code>/etc/exports</code> file to allow the local network to mount NFS shares.<br />
<br />
If the default configuration does not fit your needs just edit <code>/etc/exports</code> and update the latest line, e.g. if you're on a private class A network 10.0.0.0/8, change the line as:<br />
<br />
<pre><br />
/home 10.0.0.0/8(rw,sync,no_subtree_check,no_root_squash,no_all_squash,crossmnt)<br />
</pre><br />
<br />
Changes are applied by running <code>exportfs -a</code> as root, and can be verified with <code>exportfs</code><br />
<br />
<pre class="workstation-terminal"><br />
nelk@nelk-desktop:~$ sudo exportfs -a<br />
nelk@nelk-desktop:~$ sudo exportfs <br />
/home/shared 192.168.0.0/24<br />
</pre><br />
<br />
For more information regarding NFS server and /etc/exports see ''exports'' man page or, for example, [http://linux.die.net/man/5/exports]<br />
<br />
===== TFTP Configuration =====<br />
<br />
[http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol TFTP] is used by the target to download files from the host machine, in particular to retrieve the u-boot and kernel images. On the DVDK the TFTP service is properly configured to serve files stored in the <code>/srv/tftp</code> directory. For more information about the tftp service in Ubuntu, please refer to https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP</div>U0002