tag:blogger.com,1999:blog-90623436014840726072024-03-05T18:40:37.111-06:00an Internet weblog, by Bryan HintonUnknownnoreply@blogger.comBlogger48125tag:blogger.com,1999:blog-9062343601484072607.post-47609414911074283242023-04-06T19:56:00.008-05:002023-11-13T18:41:48.534-06:00Multidimensional arrays of function pointers in C<div>Embedded hardware typically includes an application processor and one or more adjacent processor(s) attached to the printed circuit board. The firmware that resides on the adjacent processor(s) responds to instructions or commands. Different processors on the same board are often produced by different companies. For the system to function properly, it is imperative that the processors communicate without any issues, and that the firmware can handle all types of possible errors.</div><div><br /></div><div>Formal requirements for firmware related projects may include the validation and verification of the firmware on a co-processor via the application programming interface (API). Co-processors typically run 8, 16, or 32-bit embedded operating systems. If the co-processor manufacturer provides a development board for testing the firmware on a specific co-processor, then the development board may have it's own application processor. Familiarity with all of the applicable bus communication protocols including synchronous and asynchronous communication is important. High-volume testing of firmware can be accomplished using function-like macros and arrays of function pointers. Processor specific firmware is written in C and assembly - 8, 16, 32, or 64-bit. Executing inline assembly from C is straightforward and often required. Furthermore, handling time-constraints such as real-time execution on adjacent processors is easier to deal with in C and executing syscalls, low-level C functions, and userspace library functions, is often more efficient. Timing analysis is often a key consideration when testing firmware, and executing compiled C code on a time-sliced OS, such as Linux, is already constrained.</div><div><br /></div><div>To read tests based on a custom grammar, a scanner and parser in C can be used. Lex is ideal for building a computationally efficient lexical analyzer that outputs a sequence of tokens. For this case, the tokens comprise the function signatures and any associated function metadata such as expected execution time. Creating a context-free grammar and generating the associated syntax tree from the lexical input is straightforward. Dynamic arrays of function pointers can then be allocated at run-time, and code within external object files or libraries can be executed in parallel using multiple processes or threads. The symbol table information from those files can be stored in multi-dimensional arrays. While C is a statically typed language, the above design can be used for executing generic, variadic functions at run-time from tokenized input, with constant time lookup, minimal overhead, and specific run-time expectations (stack return value, execution time, count, etc.).</div><div><br /></div><div>At a high level, lists of pointers to type-independent, variadic functions and their associated parameters can be stored within multi-dimensional arrays. The following C code uses arrays of function pointers to execute functions via their addresses. The code uses list management functions from the Linux kernel which I ported to userspace.</div><p><a href="https://github.com/brhinton/bcn">https://github.com/brhinton/bcn<br /></a></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-32428939638439347812022-01-12T07:47:00.017-06:002023-03-28T20:21:49.849-05:00Concurrency, Parallelism, and Barrier Synchronization - Multiprocess and Multithreaded ProgrammingOn preemptive, timed-sliced UNIX or Linux operating systems such as Solaris, AIX, Linux, BSD, and OS X, program code from one process executes on the processor for a time slice or quantum. After this time has elapsed, program code from another process executes for a time quantum. Linux divides CPU time into epochs, and each process has a specified time quantum within an epoch. The execution quantum is so small that the interleaved execution of independent, schedulable entities – often performing unrelated tasks – gives the appearance of multiple software applications running in parallel.<br /><br />When the currently executing process relinquishes the processor, either voluntarily or involuntarily, another process can execute its program code. This event is known as a context switch, which facilitates interleaved execution. Time-sliced, interleaved execution of program code within an address space is known as concurrency.<br /><br />The Linux kernel is fully preemptive, which means that it can force a context switch for a higher priority process. When a context switch occurs, the state of a process is saved to its process control block, and another process resumes execution on the processor.<br /><br />A UNIX process is considered heavyweight because it has its own address space, file descriptors, register state, and program counter. In Linux, this information is stored in the task_struct. However, when a process context switch occurs, this information must be saved, which is a computationally expensive operation.<br /><br />Concurrency applies to both threads and processes. A thread is an independent sequence of execution within a UNIX process, and it is also considered a schedulable entity. Both threads and processes are scheduled for execution on a processor core, but thread context switching is lighter in weight than process context switching.<br /><br />In UNIX, processes often have multiple threads of execution that share the process's memory space. When multiple threads of execution are running inside a process, they typically perform related tasks. The Linux user-space APIs for process and thread management abstract many details. However, the concurrency level can be adjusted to influence the time quantum so that the system throughput is affected by shorter and longer durations of schedulable entity execution time.<div><br /></div><div>While threads are typically lighter weight than processes, there have been different implementations across UNIX and Linux operating systems over the years. The three models that typically define the implementations across preemptive, time-sliced, multi-user UNIX and Linux operating systems are defined as follows - 1:1, 1:N, and M:N where 1:1 refers to the mapping of one user-space thread to one kernel thread, 1:N refers to the mapping of multiple user-space threads to a single kernel thread. M:N refers to the mapping of N user-space threads to M kernel threads.<br /><br />In the 1:1 model, one user-space thread is mapped to one kernel thread. This allows for true parallelism, as each thread can run on a separate processor core. However, creating and managing a large number of kernel threads can be expensive.<br /><br />In the 1:N model, multiple user-space threads are mapped to a single kernel thread. This is more lightweight, as there are fewer kernel threads to create and manage. However, it does not allow for true parallelism, as only one thread can execute on a processor core at a time.<br /><br />In the M:N model, N user-space threads are mapped to M kernel threads. This provides a balance between the 1:1 and 1:N models, as it allows for both true parallelism and lightweight thread creation and management. However, it can be complex to implement and can lead to issues with load balancing and resource allocation.<p>Parallelism on a time-sliced, preemptive operating system means the simultaneous execution of multiple schedulable entities over a time quantum. Both processes and threads can execute in parallel across multiple cores or processors. Concurrency and parallelism are at play on a multi-user system with preemptive time-slicing and multiple processor cores. Affinity scheduling refers to scheduling processes and threads across multiple cores so that their concurrent and parallel execution is close to optimal.</p>It's worth noting that affinity scheduling refers to the practice of assigning processes or threads to specific processors or cores to optimize their execution and minimize unnecessary context switching. This can improve overall system performance by reducing cache misses and increasing cache hits, among other benefits. In contrast, non-affinity scheduling allows processes and threads to be executed on any available processor or core, which can result in more frequent context switching and lower performance.</div><div><br /></div><div>Software applications are often designed to solve computationally complex problems. If the algorithm to solve a computationally complex problem can be parallelized, then multiple threads or processes can all run at the same time across multiple cores. Each process or thread executes by itself and does not contend for resources with other threads or processes working on the other parts of the problem to be solved. When each thread or process reaches the point where it can no longer contribute any more work to the solution of the problem, it waits at the barrier if a barrier has been implemented in software. When all threads or processes reach the barrier, their work output is synchronized and often aggregated by the primary process. Complex test frameworks often implement the barrier synchronization problem when certain types of tests can be run in parallel. Most individual software applications running on preemptive, time-sliced, multi-user Linux and UNIX operating systems are not designed with heavy, parallel thread or parallel, multiprocess execution in mind.</div><div><br /></div><div>Minimizing lock granularity increases concurrency, throughput, and execution efficiency when designing multithreaded and multiprocess software programs. Multithreaded and multiprocess programs that do not correctly utilize synchronization primitives often require countless hours of debugging. The use of semaphores, mutex locks, and other synchronization primitives should be minimized to the maximum extent possible in computer programs that share resources between multiple threads or processes. Proper program design allows schedulable entities to run parallel or concurrently with high throughput and minimum resource contention. This is optimal for solving computationally complex problems on preemptive, time-sliced, multi-user operating systems without requiring hard, real-time scheduling.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-57481382540497894982021-02-24T15:10:00.012-06:002023-03-28T20:21:36.941-05:00A hardware design for variable output frequency using an n-bit counterThe DE1-SoC from Terasic is an excellent board for hardware design and prototyping. The following VHDL process is from a hardware design created for the Terasic DE1-SoC FPGA. The ten switches and four buttons on the FPGA are used as an n-bit counter with an adjustable multiplier to increase the output frequency of one or more output pins at a 50% duty cycle.<p>As the switches are moved or the buttons are pressed, the seven-segment display is updated to reflect the numeric output frequency, and the output pin(s) are driven at the desired frequency. The onboard clock runs at 50MHz, and the signal on the output pins is set on the rising edge of the clock input signal (positive edge-triggered). At 50MHz, the output pins can be toggled at a maximum rate of 50 million cycles per second or 25 million rising edges of the clock per second. An LED attached to one of the output pins would blink 25 million times per second, not recognizable to the human eye. The persistence of vision, which is the time the human eye retains an image after it disappears from view, is approximately 1/16th of a second. Therefore, an LED blinking at 25 million times per second would appear as a continuous light to the human eye.</p><p style="text-align: left;"></p><pre><code>scaler <= compute_prescaler((to_integer(unsigned( SW )))*scaler_mlt);<br />gpiopulse_process : process(CLOCK_50, KEY(0))<br />begin<br /> if (KEY(0) = '0') then -- async reset<br /> count <= 0;<br /> elsif rising_edge(CLOCK_50) then<br /> if (count = scaler - 1) then<br /> state <= not state;<br /> count <= 0;<br /> elsif (count = clk50divider) then -- auto reset<br /> count <= 0;<br /> else<br /> count <= count + 1;<br /> end if;<br /> end if;<br />end process gpiopulse_process;</code></pre>The scaler signal is calculated using the compute_prescaler function, which takes the value of a switch (SW) as an input, multiplies it with a multiplier (scaler_mlt), and then converts it to an integer using to_integer. This scaler signal is used to control the frequency of the pulse signal generated on the output pin.<br /><br /><div>The gpiopulse_process process is triggered by a rising edge of the CLOCK_50 signal and a push-button (KEY(0)) press. It includes an asynchronous reset when KEY(0) is pressed.<br /><br /></div><div>The count signal is incremented on each rising edge of the CLOCK_50 signal until it reaches the value of scaler - 1. When this happens, the state signal is inverted and count is reset to 0. If count reaches the value of clk50divider, it is also reset to 0.<br /><br /></div><div>Overall, this code generates a pulse signal with a frequency controlled by the value of a switch and a multiplier, which is generated on a specific output pin of the FPGA board. The pulse signal is toggled between two states at a frequency determined by the scaler signal.</div><br />It is important to note that concurrent statements within an architecture are executed concurrently, meaning that they are evaluated concurrently and in no particular order. However, the sequential statements within a process are executed sequentially, meaning that they are evaluated in order, one at a time. Processes themselves are executed concurrently with other processes, and each process has its own execution context.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-14730910570051772782020-08-25T15:30:00.005-05:002023-03-21T23:04:26.367-05:00Creating stronger keys for OpenSSH and GPG<p>Create Ed25519 SSH keypair (supported in OpenSSH 6.5+). Parameters are as follows:</p>-o save in new format<br />-a 128 for 128 kdf (key derivation function) rounds<br />-t ed25519 for type of key <pre><code>ssh-keygen -o -a 128 -t ed25519 -f .ssh/ed25519-$(date '+%m-%d-%Y') -C ed25519-$(date '+%m-%d-%Y')<br /></code></pre> Create Ed448-Goldilocks GPG master key and sub keys.<code></code><pre><code>gpg --quick-generate-key ed448-master-key-$(date '+%m-%d-%Y') ed448 sign 0<br />gpg --list-keys --with-colons "ed448-master-key-08-03-2021" | grep fpr<br />gpg --quick-add-key "$fpr" cv448 encr 2y<br />gpg --quick-add-key "$fpr" ed448 auth 2y<br />gpg --quick-add-key "$fpr" ed448 sign 2y</code></pre>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-81574217481405150422018-09-02T18:58:00.021-05:002023-03-23T18:02:21.805-05:0096Boards - JTAG and serial UART configuration for ARM powered, single-board computers<p>The 96boards CE specification calls for an optional JTAG connection. The specification also indicates that the optional JTAG connection shall use a 10 pin through hole, .05" (1.27mm) pitch JTAG connector. The part is readily available on most electronics sites. Breaking out the pins with long wires and shrink wrapping them is ideal for making sure that each connection is labeled and separate when connecting to a JTAG debugger. While a JTAG connection is not required for flashing or loading the bootloaders onto the board, the JTAG connection is useful for advanced chip-level debugging. The serial UART connection is sufficient for loading release or debug versions of bl0, bl1, bl2, bl31, bl32, the kernel, and userspace. Last but not least, ARM-powered boards, with 12V power input, often require external fans to keep the board cool. As seen in the below photos, two 5V fans were powered from an external power supply. Any work on microcontroller boards should be performed on a grounded surface. Proper grounding procedures should always be followed as most microcontroller boards contain ESD sensitive components.<br /></p><p>In the below photos, a 96Boards SBC is mounted on an IP65, ABS plastic junction box for durability. The pins are extended and mounted with screws underneath the junction box. The electrical conduit holes on the side of the junction box are ideal for holding small, project fans. The remaining electrical conduit holes provide a clean place to place the remaining wires from the board - micro USB, USB-C, and 12V power. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1dlLRqHPZdnlFFVjqYT2hAE1cTjnrT-bPPx4Cn-DLBd1WQ7to-jewERHmWZHK4iOvw5epSmQun3zmDcR6fyT2pYV1GJYIGYdQUPuQN8gsGUUT80xrZUy4S2MxPIkby78Kve9uYOCUX4AuupbqfrdESDusck8UWPZi6i3220OtdvGDgl4dFpTPdRa_/s640/IMG_20180714_004056.jpg" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="480" data-original-width="640" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1dlLRqHPZdnlFFVjqYT2hAE1cTjnrT-bPPx4Cn-DLBd1WQ7to-jewERHmWZHK4iOvw5epSmQun3zmDcR6fyT2pYV1GJYIGYdQUPuQN8gsGUUT80xrZUy4S2MxPIkby78Kve9uYOCUX4AuupbqfrdESDusck8UWPZi6i3220OtdvGDgl4dFpTPdRa_/w640-h480/IMG_20180714_004056.jpg" width="640" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1xYKfkGy98UyZimpVMxw4-GXL523v1T0CCiabPUmSFFRI91c58NXpj3qFzKttNz1yzIStBKLU7TB6bLUyyXNQRqoGlHyzjHETd6Pi9TWAG5wjewp7vMJ5K_vjVs8iBEcosNmjnRA1vfcZj6F0r02Oa0laxhFHj6nSwE6PSewFIOXhlrG-9DT1L64g/s640/IMG_20180714_004338_2.jpg" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="640" data-original-width="480" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1xYKfkGy98UyZimpVMxw4-GXL523v1T0CCiabPUmSFFRI91c58NXpj3qFzKttNz1yzIStBKLU7TB6bLUyyXNQRqoGlHyzjHETd6Pi9TWAG5wjewp7vMJ5K_vjVs8iBEcosNmjnRA1vfcZj6F0r02Oa0laxhFHj6nSwE6PSewFIOXhlrG-9DT1L64g/w480-h640/IMG_20180714_004338_2.jpg" width="480" /></a></div><br /><p><br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-78210770387998505792018-06-07T04:03:00.040-05:002023-03-28T20:32:57.689-05:00HiKey 960 Linux Bridged Firewall<p>The Kirin 960 SoC and on-board USB 3.0 make the HiKey 960 SBC an ideal platform for running a Linux Bridged firewall. The number of single-board computers with an SoC as powerful as the HiSilicon Kirin 960 are limited.<br /> <br /> When compared with the Raspberry Pi series of single board computers (SBC), the HiKey 960 SBC is significantly more powerful. The Kirin 960 also stands above the ARM powered SoCs which reside in most commercial routers.<br /> <br /> USB 3.0 makes the HiKey 960 board an attractive option for bridging or routing, filtering network traffic, or connecting to an external gateway via IPSec. Both network traffic filtering and IPSec tunneling can be computationally expensive operations. However; the multicore Kirin 960 is well suited for these types of tasks.<br /> <br /> In order to be able to run an IPSec client tunnel and a Linux Bridged firewall connected over 1G ethernet links, certain kernel configuration modifications are needed. Furthermore, the Android Linux kernel for the HiKey 960 board does not boot on a standard Linux root filesystem because it is designed to boot an Android customized rootfs.<br /> <br /> The latest googlesource Linux kernel (hikey-linaro-4.9) for Android (designed to boot Android on the HiKey 960 board) has been customized to remove the Android specific components so that the kernel boots on a standard Linux root filesystem, with the proper drivers enabled for network connectivity via attached 1000Mb/s USB 3.0 to ethernet adapters. The standard UART interface on the board should be used for serial connectivity and shell access. WiFi and Bluetooth have been removed from the kernel configuration. The kernel should be booted off of a microSDHC UHS-I card. The 96boards instructions should be followed for configuring the HiKey 960 board, setting the jumpers on the board, building and flashing the l-loader, firmware package, partition tables, UEFI loader, ARM Trusted Firmware, and optional Op-TEE. Links for the normal Linux kernel configuration, multi-interface bridge configuration, and single interface IPSec configuration are below. Additional kernel config modifications may be needed for certain types of applications.</p><h4 style="text-align: left;">kernel build instructions</h4><br/>
<div style="background: rgb(255, 255, 255); border-width: .0em .0em .0em 0em; border: 0em solid gray; overflow: auto; padding: 0em 0em; width: auto;"><pre style="line-height: 125%; margin: 0px;">mkdir /usr/local/toolchains
cd /usr/local/toolchains/
wget https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz
tar -xJf gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz
export ARCH=arm64
export CROSS_COMPILE=/usr/local/toolchains/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export PATH=/usr/local/toolchains/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/gcc-aarch64-linux-gnu/bin:$PATH
cd /usr/local/src
git clone https://android.googlesource.com/kernel/hikey-linaro</pre><pre style="line-height: 125%; margin: 0px;">cd hikey-linaro
git checkout -b android-<span face="Roboto, arial, sans-serif" style="color: #5f6368; font-size: 14px; font-weight: bold;">hikey</span><span face="Roboto, arial, sans-serif" style="color: #4d5156; font-size: 14px;">-</span><span face="Roboto, arial, sans-serif" style="color: #5f6368; font-size: 14px; font-weight: bold;">linaro</span><span face="Roboto, arial, sans-serif" style="color: #4d5156; font-size: 14px;">-</span><span face="Roboto, arial, sans-serif" style="color: #5f6368; font-size: 14px; font-weight: bold;">4.9</span><span face="Roboto, arial, sans-serif" style="color: #4d5156; font-size: 14px;"> </span></pre><pre style="line-height: 125%; margin: 0px;">make hikey960_defconfig
make -j8
</pre></div><br/><h4>multi-interface bridge configuration </h4><p style="text-align: left;"></p><p>Bridged configuration, no ip addresses on dual nic interfaces. (crossover cable is useful for testing). Bridge interface obtains dhcp address(/11) from wlan router. aliased interface added to br0 and assigned private subnet ip on different subnet (/8). Spanning tree set on bridge interface. Basic ebtables and iptables ruleset below.
</p><div style="background: rgb(255, 255, 255); border-width: .0em .0em .0em 0em; border: 0em solid gray; overflow: auto; padding: 0em 0em; width: auto;"><pre style="line-height: 125%; margin: 0px;">brctl addbr <br>
brctl addif <br> <eth1> <eth2>
ifconfig <br> up
ifconfig <eth1> up
ifconfig <eth2> up
brctl stp <br> yes
dhclient <br>
ifconfig <br>:0 <a.b.c.d/sn> up
iptables --table nat --append POSTROUTING --out-interface <br> -j MASQUERADE
iptables -P INPUT DROP
iptables --append FORWARD --in-interface <br>:0 -j ACCEPT
ebtables -P FORWARD DROP
ebtables -P INPUT DROP
ebtables -P OUTPUT DROP
ebtables -t filter -A FORWARD -p IPv4 -j ACCEPT
ebtables -t filter -A INPUT -p IPv4 -j ACCEPT
ebtables -t filter -A OUTPUT -p IPv4 -j ACCEPT
ebtables -t filter -A INPUT -p ARP -j ACCEPT
ebtables -t filter -A OUTPUT -p ARP -j ACCEPT
ebtables -t filter -A FORWARD -p ARP -j REJECT
ebtables -t filter -A FORWARD -p IPv6 -j DROP
ebtables -t filter -A FORWARD -d Multicast -j DROP
ebtables -t filter -A FORWARD -p X25 -j DROP
ebtables -t filter -A FORWARD -p FR_ARP -j DROP
ebtables -t filter -A FORWARD -p BPQ -j DROP
ebtables -t filter -A FORWARD -p DEC -j DROP
ebtables -t filter -A FORWARD -p DNA_DL -j DROP
ebtables -t filter -A FORWARD -p DNA_RC -j DROP
ebtables -t filter -A FORWARD -p LAT -j DROP
ebtables -t filter -A FORWARD -p DIAG -j DROP
ebtables -t filter -A FORWARD -p CUST -j DROP
ebtables -t filter -A FORWARD -p SCA -j DROP
ebtables -t filter -A FORWARD -p TEB -j DROP
ebtables -t filter -A FORWARD -p RAW_FR -j DROP
ebtables -t filter -A FORWARD -p AARP -j DROP
ebtables -t filter -A FORWARD -p ATALK -j DROP
ebtables -t filter -A FORWARD -p 802_1Q -j DROP
ebtables -t filter -A FORWARD -p IPX -j DROP
ebtables -t filter -A FORWARD -p NetBEUI -j DROP
ebtables -t filter -A FORWARD -p PPP -j DROP
ebtables -t filter -A FORWARD -p ATMMPOA -j DROP
ebtables -t filter -A FORWARD -p PPP_DISC -j DROP
ebtables -t filter -A FORWARD -p PPP_SES -j DROP
ebtables -t filter -A FORWARD -p ATMFATE -j DROP
ebtables -t filter -A FORWARD -p LOOP -j DROP
ebtables -t filter -A FORWARD --log-level info --log-ip --log-prefix FFWLOG
ebtables -t filter -A OUTPUT --log-level info --log-ip --log-arp --log-prefix OFWLOG -j DROP
ebtables -t filter -A INPUT --log-level info --log-ip --log-prefix IFWLOG
</pre></div><br/><h4>single-interface ipsec gateway configuration
</h4><br />
<div style="background: rgb(255, 255, 255); border-width: .0em .0em .0em 0em; border: 0em solid gray; overflow: auto; padding: 0em 0em; width: auto;"><pre style="line-height: 125%; margin: 0px;">iptables -t nat -A POSTROUTING -s <clientip>/32 -o <eth> -j SNAT --to-source <virtualip>
iptables -t nat -A POSTROUTING -s <clientip>/32 -o <eth> -m policy --dir out --pol ipsec -j ACCEPT
</pre></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-7219480910837464582018-02-01T12:10:00.006-06:002023-03-28T20:22:19.998-05:00a Hardware Design for XOR gates using sequential logic in VHDL<div><br /><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjb6m8QRy0eFVZza2yC81oPQ1iko2oh6yJ5ow4q25z5eWk2O24S-QnOuDYPO8RS1wfKvh4pRC1Efo2d55HbnX0CBltEWmwgXRh1vfW2m9ox7hy9xY50zGTfFj1pYaUujknSRbIDcAXb2jao/s640/modelsim-full-window.png"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjb6m8QRy0eFVZza2yC81oPQ1iko2oh6yJ5ow4q25z5eWk2O24S-QnOuDYPO8RS1wfKvh4pRC1Efo2d55HbnX0CBltEWmwgXRh1vfW2m9ox7hy9xY50zGTfFj1pYaUujknSRbIDcAXb2jao/s16000/modelsim-full-window.png" /></a><br />ModelSim Full Window view with wave form output of xor simulation. ModelSim-Intel FPGA Starter Edition © Intel<br /><br /><br />XOR logic gates are a fundamental component in cryptography, and many of the typical stream and block ciphers use XOR gates. A few of these ciphers are ChaCha (stream cipher), AES (block cipher), and RSA (block cipher). <br /><br />While many compiled and interpreted languages support bitwise operations such as XOR, the software implementation of both block and stream ciphers is computationally inefficient compared to FPGA and ASIC implementations. <br /><br />Hybrid FPGA boards integrate FPGAs with multicore ARM and Intel application processors over high-speed buses. The ARM and Intel processors are general-purpose processors. On a hybrid board, the ARM or Intel processor is termed the hard processor system or HPS. Writing to the FPGA from the HPS is typically performed via C from an embedded Linux build (yocto or buildroot) running on the ARM or Intel core. A simple bitstream can also be loaded into the FPGA fabric without using any ARM design blocks or functionality in the ARM core for a hybrid ARM configuration.<br /><br />The following is a simple hardware design written in VHDL and simulated in ModelSim. The image contains the waveform output of a simulation in ModelSim. The HPS is not used. On boot, the bitstream is loaded into the FPGA fabric. VHDL components are utilized, and a testbench is defined for testing the design. The entity and architecture VHDL design units are below.</div><pre><code>- --three input xnor gate entity declaration - external interface to design entity<br />entity xnorgate is<br />port (<br /> a,b,c : in std_logic;<br /> q : out std_logic);<br />end xnorgate;<br /><br />architecture xng of xnorgate is<br />begin<br /> q <= a xnor b xnor c;<br />end xng;<br /><br />- --chain of xor / xnor gates using components and sequential logic<br />entity xorchain is<br />port (<br /> A,B,C,D,E,F : in std_logic;<br /> Av,Bv : in std_logic_vector(31 downto 0);<br /> CLOCK_50 : in std_logic;<br /> Q : out std_logic;<br /> Qv : out std_logic_vector(31 downto 0));<br />end xorchain;<br /><br />architecture rtl of xorchain is<br />component xorgate is<br />port (<br /> a,b : in std_logic;<br /> q : out std_logic);<br />end component;<br /><br />component xnorgate is<br />port (<br /> a,b,c : in std_logic;<br /> q : out std_logic);<br />end component;<br /><br />component xorsgate is<br />port (<br /> av : in std_logic_vector(31 downto 0);<br /> bv : in std_logic_vector(31 downto 0);<br /> qv : out std_logic_vector(31 downto 0));<br />end component;<br /><br />signal a_in, b_in, c_in, d_in, e_in, f_in : std_logic;<br />signal av_in, bv_in : std_logic_vector(31 downto 0); <br /><br />signal conn1, conn2, conn3 : std_logic;<br /><br />begin<br /> xorgt1 : xorgate port map(a => a_in, b => b_in, q => conn1); <br /> xorgt2 : xorgate port map(a => c_in, b => d_in, q => conn2);<br /> xorgt3 : xorgate port map(a => e_in, b => f_in, q => conn3); <br /> xnorgt1 : xnorgate port map(conn1, conn2, conn3, Q);<br /> xorsgt1 : xorsgate port map(av => av_in, bv => bv_in, qv => Qv);<br /><br /> process(CLOCK_50)<br /> begin<br /> if rising_edge(CLOCK_50) then --assign inputs on rising clock edge<br /> a_in <= A;<br /> b_in <= B;<br /> c_in <= C;<br /> d_in <= D;<br /> e_in <= E;<br /> f_in <= F;<br /> av_in(31 downto 0) <= Av(31 downto 0);<br /> bv_in(31 downto 0) <= Bv(31 downto 0);<br /> end if;</code></pre><pre><code> end process;<br />end rtl;<br /><br />entity xorchain_tb is<br />end xorchain_tb;<br /><br />architecture xorchain_tb_arch of xorchain_tb is<br /> signal A_in,B_in,C_in,D_in,E_in,F_in : std_logic := '0';<br /> signal Av_in : std_logic_vector(31 downto 0);<br /> signal Bv_in : std_logic_vector(31 downto 0);<br /> signal CLOCK_50_in : std_logic;<br /> signal BRK : boolean := FALSE;<br /> signal Q_out : std_logic;<br /> signal Qv_out : std_logic_vector(31 downto 0);<br /><br />component xorchain<br />port (<br /> A,B,C,D,E,F : in std_logic;<br /> Av : in std_logic_vector(31 downto 0);<br /> Bv : in std_logic_vector(31 downto 0);<br /> CLOCK_50 : in std_logic;<br /> Q : out std_logic;<br /> Qv : out std_logic_vector(31 downto 0));<br />end component;<br /><br />begin<br /> xorchain_instance: xorchain port map (A => A_in,B => B_in, C => C_in, <br /> D => D_in, E => E_in, F => F_in, Av => Av_in,<br /> Bv => Bv_in, CLOCK_50 => CLOCK_50_in, Q => Q_out,<br /> Qv => Qv_out);<br />clockprocess: process<br /> begin<br /> while not BRK loop<br /> CLOCK_50_in <= '0';<br /> wait for 20 ns;<br /> CLOCK_50_in <= '1';<br /> wait for 20 ns;<br /> end loop;<br /> wait;<br />end process clockprocess;<br /> <br />testprocess : process<br /> begin<br /> A_in <= '1';<br /> B_in <= '0';<br /> C_in <= '1';<br /> D_in <= '0';<br /> E_in <= '1';<br /> F_in <= '1';<br /> wait for 40 ns;<br /> A_in <= '1';<br /> B_in <= '0';<br /> C_in <= '1';<br /> D_in <= '0';<br /> E_in <= '1';<br /> F_in <= '0';<br /> wait for 20 ns;<br /> A_in <= '0';<br /> B_in <= '0';<br /> C_in <= '1';<br /> D_in <= '0';<br /> E_in <= '1';<br /> F_in <= '0';<br /> wait for 40 ns;<br /> BRK <= TRUE;<br /> wait;<br /> end process testprocess;<br />end xorchain_tb_arch;<br /><br />entity xorgate is<br />port (<br /> a,b : in std_logic;<br /> q : out std_logic);<br />end xorgate;<br /><br />architecture xg of xorgate is<br />begin<br /> q <= a xor b;<br />end xg;<br /><br />entity xorsgate is<br />port (<br /> av : in std_logic_vector(31 downto 0);<br /> bv : in std_logic_vector(31 downto 0);<br /> qv : out std_logic_vector(31 downto 0));<br />end xorsgate;<br /><br />architecture xsg of xorsgate is<br />begin<br /> qv <= av xor bv;<br />end xsg;<br /></code></pre>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-31208761168862908242016-09-16T23:49:00.004-05:002023-03-25T21:50:23.097-05:00Implementing Software-defined radio and Infrared Time-lapse Imaging with Tensorflow on a custom Linux distribution for the Raspberry Pi 3<p></p><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-IaMD7xJYNCoZWxr04BozejlnOImpcuq5eOIYJjVZn_mZF-XD6rVPy7dgW5SHI118wgW0cWsgBoI8S9A9JJjRg3hy-j4PZQzJ313TmKb0nUVzbJ5YYDpNQnqViiCVk4tINSvL0OLt8vLz/s400/gnuradio.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="308" data-original-width="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-IaMD7xJYNCoZWxr04BozejlnOImpcuq5eOIYJjVZn_mZF-XD6rVPy7dgW5SHI118wgW0cWsgBoI8S9A9JJjRg3hy-j4PZQzJ313TmKb0nUVzbJ5YYDpNQnqViiCVk4tINSvL0OLt8vLz/s16000/gnuradio.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">GNURadio Companion Qt Gui Frequency Sync - multiple FIR filter taps <br />sample running on Raspberry Pi 3 custom Linux distribution</td></tr></tbody></table><p>The Raspberry Pi 3 is powered by the ARM Cortex-A53 processor. This 1.2GHz 64-bit quad-core processor fully supports the ARMv8-A architecture. For this project, a custom Linux distribution was created for the Raspberry Pi 3. </p><p>The custom Linux distribution includes support for GNURadio, several FPGA and ARM Powered SDR devices, D-STAR (hotspot, repeater, and dongle support), hsuart, libusb, hardware real-time clock support, Sony 14 megapixel NoIR image sensor, HDMI and 3.5mm audio, USB Microphone input, X-windows with Xfce, Lighttpd and PHP, Bluetooth, WiFi, SSH, TCPDump, Docker, Docker registry, MySQL, Perl, Python, QT, GTK, IPTables, x11vnc, SELinux, and full native-toolchain development support. <br /></p>The Sony 14 megapixel image sensor with the infrared filter removed can be connected to the Raspberry Pi 3's MIPI camera serial interface. Image capture and recognition can then be performed over contiguous periods of time, and time-lapsed video can be created from the images. With support for Tensorflow and OpenCV, object recognition within images can be performed.<div><br /><div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghnVKSzqSL_bCZkEFSD9fseN-VccUo9jskut8fblCt9Zc2GaIk1np6UErhS7jlcoyhm-JaVsYSLLK49v44PLveQeE5OZbxazJy-FOxY0h3Mzb3if5hCyshghTW5K_Zzxzg4nHP0Ip2nv2S/s640/time-lapsed-infrared.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="479" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEghnVKSzqSL_bCZkEFSD9fseN-VccUo9jskut8fblCt9Zc2GaIk1np6UErhS7jlcoyhm-JaVsYSLLK49v44PLveQeE5OZbxazJy-FOxY0h3Mzb3if5hCyshghTW5K_Zzxzg4nHP0Ip2nv2S/s16000/time-lapsed-infrared.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">D-STAR hotspot with time-lapsed infrared imaging.</td></tr></tbody></table><br /><br /></div>For the initial run, an infrared Time-lapse Video was created from an initial image capture run of one 3280x2460 infrared jpeg image captured every 15 seconds for three hours. 40, 5mm, 940nm LEDs, powered by 500ma over 12v DC, provided infrared illumination in the 940nm wavelength.<br /><br />Tensorflow ran in the background (on v4l2 kmod) and provided continuous object recognition and scoring within each image via a sample model. Finally, OpenCV was also installed in the root file system.<br /><br />The time-lapse infrared video was captured of the living room using the above setup. Below this image are images of Tensorflow running in a terminal in the background on the Raspberry Pi 3 and recognizing/scoring objects in the living room. <p></p><p></p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjHwnSvE-dDbNLz1WNj74mzMLCJQJ6d3k3p-NLTPi7Zr3JiEqtsMBjaAGEk_3zq3oObnpYmPG4vJ3NA4epKdNaavC7PiLCXqmLNv0HpO5EEBEZKqWv3w64w-i5HReSFeqn3S_gXhGcxTxn/s640/tensorflow.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="296" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjHwnSvE-dDbNLz1WNj74mzMLCJQJ6d3k3p-NLTPi7Zr3JiEqtsMBjaAGEk_3zq3oObnpYmPG4vJ3NA4epKdNaavC7PiLCXqmLNv0HpO5EEBEZKqWv3w64w-i5HReSFeqn3S_gXhGcxTxn/s16000/tensorflow.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Tensorflow running on the Raspberry Pi 3 and continuously capturing frames from the image sensor and scoring objects</td></tr></tbody></table> <p><br /><br /></p><p> </p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg-IQRgW6zDaCT6SNrVTzJeHWESOu59ho_8KCYzdn2Yq9BLBKdgPz-UG9WqH6mAZuXUfh07m1fSOR9YRyKhvSfrong23MzjpLjKpuV43nlkeWw62w5r9FPJ0WenbDR83va3DNYcRyF2DO3/s640/gnuradio-2.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="345" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgg-IQRgW6zDaCT6SNrVTzJeHWESOu59ho_8KCYzdn2Yq9BLBKdgPz-UG9WqH6mAZuXUfh07m1fSOR9YRyKhvSfrong23MzjpLjKpuV43nlkeWw62w5r9FPJ0WenbDR83va3DNYcRyF2DO3/s16000/gnuradio-2.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">GNURadio Companion running on xfce on the Raspberry Pi 3<br /></td></tr></tbody></table><br /><p></p><p></p> </div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-81918772485542172142016-08-16T14:22:00.001-05:002023-03-23T21:05:47.222-05:00Profiling Multiprocess C programs with ARM DS-5 StreamlineThe ARM DS-5 Streamline Performance Analyzer is a powerful tool for debugging, profiling, and analyzing multithreaded and multiprocess C programs. Instructions can easily be traced between load and store operations. Per process and per thread function call paths can be broken down by system utilization percentage. Branch mispredictions and multi-level CPU caches can be analyzed. Furthermore, disk I/O usage, stack and heap usage, and a number of other useful metrics can quickly be referenced within the debugger. These are just a few of its capabilities. <br /><div><br /></div><div>In order to capture meaningful information from the DS-5 Streamline Performance Analyzer tool, a Linux, multiprocess, C program was modified to insert 1000 packets into a packet processing simulation buffer. A code excerpt from the program is below. The child processes were modified to sleep and then wake 1000 times in order to simulate process activity. The program was analyzed using the DS-5 Streamline Performance Analyzer tool. There are two screenshots below the code excerpt where the program is loaded into the DS-5 Streamline Performance Analyzer.<br /></div><div><br /></div><code></code><pre><code>void *insertpackets(void *arg) {<br /> <br /> struct pktbuf *pkbuf;<br /> struct packet *pkt;<br /> int idx;<br /><br /> if(arg != NULL) {<br /> <br /> pkbuf = (struct pktbuf *)arg;<br /><br /> /* seed random number generator */<br /> ...<br /><br /> /* insert 1000 packets into the packet buffer */<br /> for(idx = 0; idx < 1000; ++idx) {<br /><br /> pkt = (struct packet *)malloc(sizeof(struct packet));<br /><br /> if(pkt != NULL) {<br /><br /> /* set the packet processing simulation multiplier to 3 */<br /> pkt->mlt=...()%3;<br /><br /> /* insert packet in the packet buffer */<br /> if(pkt_queue(pkbuf,pkt) != 0) {<br /> <br /> ...<br /> ... <br /> ...<br /> ...<br /> ...<br />...<br /><br />int fcnb(time_t secs, long nsecs) {<br /> <br /> struct timespec rqtp;<br /> struct timespec rmtp;<br /> int ret;<br /> int idx;<br /><br /> rqtp.tv_sec = secs;<br /> rqtp.tv_nsec = nsecs; <br /><br /> for(idx = 0; idx < 1000; idx++) {<br /><br /> ret = nanosleep(&rqtp, &rmtp);<br /><br /> ...<br /> ...<br />... </code></pre><pre><code> </code></pre><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://www.blogger.com/#" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZmOGyNp5bYQM7Xx9LwNdvMYSyeatEntbU3FsjWDHlDAQJX-2leLKeyEPQbqfKLShSnKGnbVorqkS5mzrIL4HMtCgdOk8bP07BmQY8bauTEBmSVU3tjrot9TYJqxhu_GsC-ULjd6TkY08f/s16000/ds5-a.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">ARM DS-5 Streamline - Profiling the process creation application</td></tr></tbody></table><br /><p></p><p></p><p></p><p></p><p></p><p></p><p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://www.blogger.com/#" style="margin-left: auto; margin-right: auto;"><span style="color: black;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjvmDZXOsvp7SudANbj5dG3BuvNJBgSc57iGbW_iGG_pGRG475S0GII0HiJYdl8NTjQDCUNr7Su-oF2qz9UdXAa1i1MqIt0wQtU93lVL9KK00Eb96gQvnNxiX0xAWYv38hW0Pn-sq8FXWYw/s16000/ds5-b.png" /></span></a></td></tr><tr><td class="tr-caption" style="text-align: center;">ARM DS-5 Streamline - Code View with C code in the top window <br />and ARM assembly instructions in the bottom window<br /><br /></td></tr></tbody></table>https://github.com/brhinton/de0-nano-soc/blob/main/run.cUnknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-33238403823403247102016-06-30T17:00:00.004-05:002023-03-28T20:22:29.082-05:00VHDL Processes for Pulsing Multiple GPIO Pins at Different Frequencies on Altera FPGA<div> <table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5qHLtss1rPXgUVOVoi792JIvm5quFifNEaRKf9ivLLYq0zEQZTZCeNRi4Qijpqv8otQVJoLhOBaf_XhEoZ_Ei18N-L-pQMJI3Ry_ouDTwwExDcw-HMvRdAMYAgo6PKQ0tbYE0QyxBs3u5/s640/de1-soc.jpeg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="480" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5qHLtss1rPXgUVOVoi792JIvm5quFifNEaRKf9ivLLYq0zEQZTZCeNRi4Qijpqv8otQVJoLhOBaf_XhEoZ_Ei18N-L-pQMJI3Ry_ouDTwwExDcw-HMvRdAMYAgo6PKQ0tbYE0QyxBs3u5/s16000/de1-soc.jpeg" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">DE1-SoC GPIO Pins connected to 780nm Infrared Laser Diodes, 660nm Red Laser Diodes, and Oscilloscope</td></tr></tbody></table><br /></div> <p></p><p>The following VHDL processes pulse the GPIO pins at different frequencies on the Altera DE1-SoC using multiple Phase-Locked Loops. Several diodes were connected to the GPIO banks and pulsed at a 50% duty cycle with 16mA across 3.3V. Each GPIO bank on the DE1-SoC has 36 pins. Pin 1 is pulsed at 20Hz from GPIO bank 0, and pins 0 and 1 are pulsed at 30Hz from GPIO bank 1. A direct mode PLL with locked output was configured using the Altera Quartus Prime MegaWizard. The PLL reference clock frequency is set to 50MHz, the output clock frequency is set to 50MHz, and the duty cycle is set to 50%. The pin mappings for GPIO banks 0 and 1 are documented on the DE1-SoC datasheet.</p><div><pre><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTeeptWoQxNndNppbCEJK_gGThF2l7xsWYAUlVj8cRz0MGKTxwZ4QD9cwQJtGTIkrinDUJxim2I_kIlThaSUI8vsJ8WEW1ZK0r8meAKuAQlyDakgSMjwtARM72G_JSxg7oSlW6evTG2Uc1/s640/de1-soc-a.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="429" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTeeptWoQxNndNppbCEJK_gGThF2l7xsWYAUlVj8cRz0MGKTxwZ4QD9cwQJtGTIkrinDUJxim2I_kIlThaSUI8vsJ8WEW1ZK0r8meAKuAQlyDakgSMjwtARM72G_JSxg7oSlW6evTG2Uc1/s16000/de1-soc-a.png" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Pulsed Laser Diodes via GPIO pins on DE1-SoC FPGA</td></tr></tbody></table><code></code></pre> <p></p> <p></p> <pre><code>- <span style="font-style: italic;">-- ---------------------</span><br />- <span style="font-style: italic;">-- CLOCK A AND B PROCESSES --</span><br />- <span style="font-style: italic;">-- INPUT: direct mode pll with locked output </span><br />- <span style="font-style: italic;">-- and reference clock frequency set to 50MHz, </span><br />- <span style="font-style: italic;">-- output clock frequency set to 50MHz with 50% duty </span><br />- <span style="font-style: italic;">-- cycle and output frequency scaled by freq divider constant</span><br />- <span style="font-style: italic;">-- -----------------------------------------------------------</span> </code></pre><pre><code>clk_a_process : process (lkd_pll_clk_a)<br />begin<br /> if rising_edge(lkd_pll_clk_a) then<br /> if (cycle_ctr_a < FREQ_A_DIVIDER) then<br /> cycle_ctr_a <= cycle_ctr_a + 1;<br /> else<br /> cycle_ctr_a <= 0;<br /> end if;<br /> end if;<br />end process clk_a_process;<br /> <br />clk_b_process : process (lkd_pll_clk_b)<br />begin<br /> if rising_edge(lkd_pll_clk_b) then<br /> if (cycle_ctr_b < FREQ_B_DIVIDER) then<br /> cycle_ctr_b <= cycle_ctr_b + 1;<br /> else<br /> cycle_ctr_b <= 0;<br /> end if;<br /> end if;<br />end process clk_b_process; </code></pre><pre style="line-height: 125%; margin: 0px;"><code>- <span style="font-style: italic;">-- ---------------------</span><br />- <span style="font-style: italic;">-- GPIO A AND B PROCESSES --</span><br />- <span style="font-style: italic;">-- INPUT: direct mode pll with locked output</span><br />- <span style="font-style: italic;">-- ------------------------------------------------------- </span><br />gpio_a_process : process (lkd_pll_clk_a)<br />begin<br /> if rising_edge(lkd_pll_clk_a) then<br /> if (cycle_ctr_a = 0) then<br /> gpio_sig_0 <= NOT gpio_sig_0;<br /> end if;<br /> end if;<br />end process gpio_a_process;<br /><br />gpio_b_process : process (lkd_pll_clk_b)<br />begin<br /> if rising_edge(lkd_pll_clk_b) then<br /> if (cycle_ctr_b = 0) then<br /> gpio_sig_1 <= NOT gpio_sig_1;<br /> end if;<br /> end if;<br />end process gpio_b_process;<br />GPIO_0 <= gpio_sig_0;<br />GPIO_1 <= gpio_sig_1;</code>
</pre></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-24404417878493735472016-06-02T21:00:00.003-05:002023-03-28T20:22:44.932-05:00FPGA Audio Processing with the Cyclone V Dual-Core ARM Cortex-A9<p>The DE1-SoC FPGA Development board from Terasic is powered by an integrated Altera Cyclone V FPGA and ARM MPCore Cortex-A9 processor. The FPGA and ARM core are connected by a high-speed interconnect fabric. Linux can be booted on the ARM core and the FPGA and ARM core can communicate.<br /></p><p>The DE1-SoC board below has been programmed via Quartus Prime running on Fedora 23, 64-bit Linux. The FPGA bitstream was compiled from the Terasic Audio codec design reference. After the bitstream was loaded on to the FPGA over the USB blaster II interface, the NIOS II command shell was used to load the NIOS II software image onto the chip. A menu-driven, debug interface is running from a terminal on the host via the NIOS II shell with the target connected over the USB Blaster II interface.<br /><br />A low-level hardware abstraction layer was programmed in C to configure the on-board audio codec chip. The NIOS II chip is stored in on-chip memory and a PLL driven, clock signal is fed into the audio chip. The Verilog code for the hardware design was generated from Qsys. The design supports configurable sample rates, mic in, and line in/out.<br /><br />Additional components are connected to the DE1-SoC board in this photo. The Linear DC934A (LTC2607) DAC is connected to the DE1-SoC and an oscilloscope is connected to the ground and vref pins on the DAC.<br /><br />The DC934A features an LTC2607 16-Bit Dual DAC with i2c interface and an LTC2422 2-Channel 20-Bit uPower No Latency Delta Sigma ADC.<br /><br />3.5mm audio cables are connected to the mic in and line out ports, respectively. The DE1-SoC is connected to an external display over VGA so that a local console can be managed via a connected keyboard and mouse when Linux is booted from uSD.<br /><br />With GPIO pins accessible via the GPIO 0 and 1 breakouts, external LEDs can be pulsed directly from the Hard Processor System (HPS), FPGA, or the FPGA via the HPS.</p>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-76804077816405927012015-11-08T22:00:00.000-06:002022-12-19T23:51:02.967-06:00Configuring the Altera Cyclone V FPGA SoC Boot loader on a DE0-Nano-SoC board<div><p>Understanding the boot loader on a computer system is probably the most important aspect of security. Most computer systems have multiple boot loaders that run in sequence immediately after a power reset is applied to the processor on the computer system. This applies to embedded, desktop, and server systems.<br /></p>The Altera Cyclone V SoC has an FPGA and a Hard Processor System (HPS) woven into a single processor package. The HPS is a dual core ARM Cortex A9. Building everything from scratch is the best way to figure out how the system works.<br /><br />The boot sequence on a Cyclone V HPS works like this:<br /><br />The On-chip ROM (for which source code is not provided) loads the preloader (1st stage bootloader). The preloader then loads U-boot. U-boot then loads the kernel and root file system. <br /><br />There are two well thought out options for the preloader according to the Cyclone V boot guide. The two options are licensed differently depending on how the source code is built. One is licensed under a BSD license and the other under GPL v2 with U-Boot.<br /><br /></div><div style="text-align: left;">Building a pre-loader image for the DE0-Nano-SoC board was straightforward. Altera provides the bsp-editor utility for customizing the preloader configuration and generating the BSP HPS preloader source code, after which, make is used to build the sources using the Mentor ARM cross toolchain.<br />The preloader settings directory can be found on the DE0-Nano-SoC CD in the DE0_NANO_SOC_GHRD subdirectory.<br /></div><div><br /><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgzqAknaEEIUYy9lXhzSkQ_TxRqPNoQIZk8JanZw8F2PF19ThxTQx2hFkeV1I-ht1l6JitfmRLNwDWcaAcp377yoMh-g2P9zEv7NQbwVi7RSbqMldvMqRVh3oVRDl3wM2GGCMLeR0r_a5u-aXOn1XXn5mkRUgvwAAIf0oMWSvXrpzsSdzSRL4ABKtOD=s640" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="566" data-original-width="640" height="566" src="https://blogger.googleusercontent.com/img/a/AVvXsEgzqAknaEEIUYy9lXhzSkQ_TxRqPNoQIZk8JanZw8F2PF19ThxTQx2hFkeV1I-ht1l6JitfmRLNwDWcaAcp377yoMh-g2P9zEv7NQbwVi7RSbqMldvMqRVh3oVRDl3wM2GGCMLeR0r_a5u-aXOn1XXn5mkRUgvwAAIf0oMWSvXrpzsSdzSRL4ABKtOD=w640-h566" width="640" /></a></div><br /><br /></div>The preloader load address can be set via the bsp-editor so that the on chip ROM either loads the preloader from an absolute zero address on the sdcard or from a fat partition with id equal to a2 on the sdcard. These are the options for booting from the sdcard.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhBRKLv4F5HGmP8WsYCrSkwAkex_sXuy5-csfGBNrV6r6M8_4t6VyEo-6-nqs9eGiGmT8kNpokaoVbppuiNFSUFIcFrfbIq5bmBtVPjENI8-7QFN3uhL3P9VwOeC562bVoUf-XbtKywj1xoasNtFLa7XC0aa2t0hkk3HnK-jI77TqPMH6mppOV--1m1=s400" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="285" data-original-width="400" height="228" src="https://blogger.googleusercontent.com/img/a/AVvXsEhBRKLv4F5HGmP8WsYCrSkwAkex_sXuy5-csfGBNrV6r6M8_4t6VyEo-6-nqs9eGiGmT8kNpokaoVbppuiNFSUFIcFrfbIq5bmBtVPjENI8-7QFN3uhL3P9VwOeC562bVoUf-XbtKywj1xoasNtFLa7XC0aa2t0hkk3HnK-jI77TqPMH6mppOV--1m1=s320" width="320" /></a></div><br />After the sources are generated and the preloader image is built using the Makefile, U-boot must be compiled. An Altera port of U-Boot is available on github for the Cyclone V FPGA SoC. U-Boot is built using the Linaro ARM cross toolchain.<br /><br />There's quite a bit that can be done with the Cyclone V FPGA SoC boot configuration. FPGA images can be loaded from U-boot. The jumpers on the board can be configured to boot from the on-board serial flash (QSPI), bare metal applications can be loaded from the preloader, the FPGA can be configured from serial flash, and the list goes on. <a href="http://web.archive.org/web/20160117143123/https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an709.pdf" target="_blank">The HPS SoC Boot Guide for the Cyclone V SoC </a> is a valuable reference and contains all of the boot configuration information.</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-65398372499922080852015-10-28T19:28:00.001-05:002023-03-25T21:48:09.302-05:00The "Three Fives" Discrete 555 Timer Kit<div></div>The NE555 timer IC is a classic and widely used component in electronic circuits, so building a transistor-scale replica of it is a great way to understand how it works at a fundamental level. It's also a good way to develop your soldering skills and learn how to use an oscilloscope to measure signals in a circuit.<br /><br />I picked up a "Three Fives" Discrete Timer Kit this weekend. As it turns out the kit was well worth the money. The "Three Fives" Discrete Timer Kit is a transistor-scale replica of the NE555 timer IC. The printed circuit board (PCB) is high-quality and soldering the transistors and resistors was alot of fun. Thanks to <a href="http://tubetime.us/">Eric Schlaepfer</a> and <a href="http://www.evilmadscientist.com/2013/555-kit/">Evil Mad Scientist Labs</a> for this high quality circuit kit.<br /><br />The size of the board makes it easy to measure what's going on inside the circuit. Just connect the probes from an oscilloscope to any of the solder or test points on the board.<br /><br />A photo of the board that I built is below. I also wired a sample test circuit for blinking a pink LED and then connected a scope to the board so that I could look at the square wave.<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpnYixcCKbrKMltlw5Rf3amOHBCwNPQDaNkawJ8i1t7QiTZo4aazt189WSvRWPpBehzL76ReUf9OIiXYyVNXwZQwcsxnbAMlcqtdMkB9YovRpV1iozNagJWFuCwCaMH1nEzsQJ1rlOHn3QeFun4ptyNr4KzQK13C7M4EgzxIR1YwCYo3wdiP5RhdTB/s640/IMG_20150817_204935-2.jpg" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="480" data-original-width="640" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpnYixcCKbrKMltlw5Rf3amOHBCwNPQDaNkawJ8i1t7QiTZo4aazt189WSvRWPpBehzL76ReUf9OIiXYyVNXwZQwcsxnbAMlcqtdMkB9YovRpV1iozNagJWFuCwCaMH1nEzsQJ1rlOHn3QeFun4ptyNr4KzQK13C7M4EgzxIR1YwCYo3wdiP5RhdTB/w640-h480/IMG_20150817_204935-2.jpg" width="640" /></a></div><br /><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1o2kOLxMfermZVjHQkMA4kJfRKZwFpLKVc7lEJk7B6JuPwU65EFSKuq9In0xjDLs_oRm_8UB7F93jb3YkUbapPm7olS94IewvftCGAacW8Ksv_4puXgl5gTs7Ss6KEh5SYKdLHLFwKgdCiCi3eCryL3QoSvFuJRNhauvHsHl9odhNJd3GnrRPalG4/s347/circuit-flashing-led-schematic.gif" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" data-original-height="272" data-original-width="347" height="502" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1o2kOLxMfermZVjHQkMA4kJfRKZwFpLKVc7lEJk7B6JuPwU65EFSKuq9In0xjDLs_oRm_8UB7F93jb3YkUbapPm7olS94IewvftCGAacW8Ksv_4puXgl5gTs7Ss6KEh5SYKdLHLFwKgdCiCi3eCryL3QoSvFuJRNhauvHsHl9odhNJd3GnrRPalG4/w640-h502/circuit-flashing-led-schematic.gif" width="640" /></a></div><br /><div><br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-25404280505875071932015-07-16T23:55:00.001-05:002023-03-25T21:47:13.433-05:00Creating a custom Linux BSP for an ARM Cortex-A9 SBC with Yocto 1.8 - Part III<p>In part III of this guide, the installation of the final image to the SD card will be covered. The SD card will then be booted on the target. Finally, audio recording and playback will be tested.</p>Part III of this guide consists of the following sections.<br /><br /><ol><li>Write the GNU/Linux BSP image to an SD card.</li><li>Set the physical switches on the RioTboard (<a href="https://en.wikipedia.org/wiki/Internet_of_things" target="_blank">Internet of Things</a>) to boot from the uSD or SD card.</li><li>Connect the target to the necessary peripherals for boot.</li><li>Test audio recording, audio playback, and Internet connectivity.</li></ol><div><br /></div><div style="-webkit-text-stroke-width: 0px; color: black; font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant-caps: normal; font-variant-east-asian: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px;"><div style="margin: 0px;"><h3><b>1. Write the GNU/Linux BSP image to an SD card</b></h3><h3><span style="font-size: small; font-weight: normal;">At this point, the build should be complete, without errors. The output should be as follows.</span></h3></div></div><br /><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> real<span class="Apple-tab-span" style="white-space: pre;"> </span>254m28.335s<br /> user<span class="Apple-tab-span" style="white-space: pre;"> </span>737m9.307s<br /> sys<span class="Apple-tab-span" style="white-space: pre;"> </span>133m39.529s</code></pre><span style="font-size: small;"><br /></span> <span style="font-size: small;">Insert an SD card into an SD card reader, connect it to the host, and execute the following commands on the host.</span><br /><span style="font-size: small;"><br /></span> <br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>host]$</b> cd $HOME/src/fsl-community-bsp/build /tmp/deploy/images/imx6dl-riotboard<br /><b> host]$</b> sudo umount /dev/sd<X><br /><b> host]$</b> sudo dd if=bsec-image-imx6dl-riotboard.sdcard of=/dev/sd<X> bs=1M<br /><b> host]$</b> sudo sync<br /></code></pre></div><br /><br /><div><div style="background-color: white; color: #666666; font-family: "Trebuchet MS", Trebuchet, Verdana, sans-serif; font-size: 13.2px; line-height: 18.48px;"><code style="overflow-wrap: normal; word-wrap: normal;"></code></div><div style="-webkit-text-stroke-width: 0px; color: black; font-family: "Times New Roman"; font-style: normal; font-variant-caps: normal; font-variant-east-asian: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px;"><h3 style="font-size: medium; font-weight: normal; margin: 0px;">2. Set the physical switches on the RioTboard to boot from the uSD or SD card.</h3><div style="margin: 0px;"><br /><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;">For booting from the SD card on the bottom of the target, set the physical switches as follows.</div><div style="color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;"><span style="background-color: white;"><b>SD (J6, bottom) 1 0 1 0 0 1 0 1</b></span></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;">For booting from the uSD card on the top of the target, set the physical switches as follows.</div><div style="color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;"><span style="background-color: white;"><b>uSD (J7, top) 1 0 1 0 0 1 1 0</b></span></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;"><br /></div><h3 style="font-size: medium; font-weight: normal;">3. Connect the target to the necessary peripherals for boot.</h3><h3><span style="font-size: small;"><span style="background-color: white; font-weight: normal;">There are two options</span></span></h3><div style="font-size: medium; font-weight: normal;"><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><b>Option 1</b></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Connect one end of an ethernet cable to the target. Connect the other end of the ethernet cable to a hub or DHCP server. </div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Connect the board to the host computer via the J18 serial UART pins on the target. This will require a serial to USB breakout cable. Connect TX, RX, and GND to RX, TX, and GND on the cable. The cable must have an FTDI or similar level shifter chip. Connect the USB end of the cable to the host computer.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Connect the speakers to the light green 3.5 mm audio out jack and the microphone to the pink 3.5 mm MIC In jack.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Connect a 5V / 4 AMP DC power source to the target.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Run minicom on the host computer. Configure minicom at 115200 8N1 with no hardware flow control and no software flow control. If a USB to serial cable with an FTDI chip in it is used, then the cable should show up in /dev as ttyUSB0 in which case, set the serial device in minicom to /dev/ttyUSB0.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">If this option was chosen, drop into U-boot after power on by pressing Enter on the host keyboard with minicom open and connected.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">If enter is not pressed after power-on, the target will boot and a login prompt will appear.</div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><div>A login prompt will not appear.</div><div><br /></div></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><b>Option 2</b></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><br /></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Connect one end of an ethernet cable to the target. Connect the other end of the ethernet cable to a hub or DHCP server. </div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;"><div><br /></div><div><div>Connect a USB keyboard, USB mouse, and monitor (via an HDMI cable) to the target.</div><div></div></div><div><br /></div><div>Connect the speakers to the light green 3.5 mm audio out jack and the microphone to the pink 3.5 mm MIC In jack.</div><div><br /></div><div>Connect a 5V / 4 AMP DC power source to the target.</div><div><br /></div><div><span style="background-color: transparent;">A login prompt will now appear.<br /></span><br /><h3><span style="background-color: transparent;">4. Test audio recording, audio playback, and Internet connectivity</span></h3><span style="background-color: transparent;"><br /></span></div></div></div><div style="font-size: medium; font-weight: normal;"><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; line-height: normal;">Type root to log in to the target. The root password is not set.<br /><br />Execute the following commands on the target</div></div><div style="background-color: white; color: black; font-family: "Times New Roman"; font-size: medium; font-weight: normal; line-height: normal;"><br /></div></div></div></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>root@imx6dl-riotboard:</b> alsamixer </code></pre></div><br />Press F6.<br />Press arrow down so that 0 imx6-riotboard-sgtl5000 is highlighted.<br />Press Enter.<br />Increase Headphone level to 79<>79.<br />Increase PCM level to 75<>75.<br />Press Tab.<br />Increase Mic level to 59.<br />Increase Capture to 80<>80.<br />Press Esc.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>root@imx6dl-riotboard:</b> cd /usr/share/alsa/sounds<br /> <b>root@imx6dl-riotboard:</b> aplay *.wav </code></pre></div><br />A sound should be played through the speakers.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>root@imx6dl-riotboard:</b> cd /tmp<br /> <b>root@imx6dl-riotboard:</b> arecord -d 10 micintest.wav</code></pre></div><br />Talk into the microphone for ten seconds.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>root@imx6dl-riotboard:</b> aplay micintest.wav<br /></code></pre></div><br />A recording should play through the speakers.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>root@imx6dl-riotboard:</b> ping riotboard.org<br /></code></pre></div><br />An ICMP reply should be received.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-36819731281224833492015-07-15T00:30:00.000-05:002022-12-19T23:51:05.198-06:00Creating a custom Linux BSP for an ARM Cortex-A9 SBC with Yocto 1.8 - Part II<div class="separator" style="clear: both; text-align: left;"><div class="separator" style="clear: both;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEirSsxmrEAWhIbxUScZ3HpFggSGCqhMg8EngiKxYd264pLYySjtfEDDf7B4FXXuQQHnnAEXDVTqNL_Q9Z2Q1XWNBX44fxJ_HFszcKntHCyzKrnneor_QRR2BkT-TjD-l9qVcKRCQ1rJmC0S7AImuyD1Pz29bxHMTCOo2DqxAal7w1yAt7K4ZjiCTlSl=s640" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="182" data-original-width="640" height="182" src="https://blogger.googleusercontent.com/img/a/AVvXsEirSsxmrEAWhIbxUScZ3HpFggSGCqhMg8EngiKxYd264pLYySjtfEDDf7B4FXXuQQHnnAEXDVTqNL_Q9Z2Q1XWNBX44fxJ_HFszcKntHCyzKrnneor_QRR2BkT-TjD-l9qVcKRCQ1rJmC0S7AImuyD1Pz29bxHMTCOo2DqxAal7w1yAt7K4ZjiCTlSl=w640-h182" width="640" /></a>In the second part of this guide, the source code will be pulled, the build configuration will be customized, and the build will be executed. Part II of this guide consists of the following sections.</div></div><p></p><ol><li>Pull the Freescale community BSP platform source code from github. </li><li>Setup the build environment using the predefined imx6dl-riotboard RioTboard (<a href="https://en.wikipedia.org/wiki/Internet_of_things" target="_blank">Internet of Things</a>) machine.</li><li>Create a new layer for the custom Linux distribution.</li><li>Customize the image in the meta-bsec layer. </li><li>Create layer.conf file in the meta-bsec layer. </li><li>Create the distribution configuration file in the meta-bsec layer. </li><li>Add the new layer to bblayers.conf.</li><li>Customize the local configuration.</li><li>Execute <br />the build.</li></ol><div><br /></div><h3>1. Pull the Freescale community BSP platform source code from github.</h3><br /><div>Execute the following commands on the host. </div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"><b> host]$</b> mkdir $HOME/bin <br /><b> host]$</b> curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo <br /><b> host]$</b> chmod a+x $HOME/bin/repo <br /><b> host]$</b> echo "PATH=$PATH:$HOME/bin" >> $HOME/.bashrc <br /><b> host]$</b> source .bashrc <br /><b> host]$</b> mkdir -p $HOME/src/fsl-community-bsp <br /><b> host]$</b> cd $HOME/src/fsl-community-bsp <br /><b> host]$ </b>repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b fido <br /><b> host]$</b> repo sync <br /></code></pre><br /><h3>2. Setup the build environment using the predefined imx6dl-riotboard machine.</h3></div><div><div><br />Execute the following commands on the host.</div></div><div><br /></div><div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"><b> host]$</b> MACHINE=imx6dl-riotboard . ./setup-environment build <br /></code></pre></div><div></div><div></div></div><div><br /></div><h3>3. Create a new layer for the custom Linux distribution</h3><div><div><div style="-webkit-text-stroke-width: 0px; color: black; font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px;"><div><div style="margin: 0px;"><br />Execute the following commands on the host.</div></div></div><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>host]$</b> cd $HOME/src/fsl-community-bsp/sources <br /><b> host]$</b> mkdir -p meta-bsec/conf/distro <br /><b> host]$</b> mkdir -p meta-bsec/recipes-bsec/images <br /><b> host]$</b> cd poky/meta/recipes-extended/images <br /><b> host]$</b> cp core-image-full-cmdline.bb \<br /> ../../../../meta-bsec/recipes-bsec/images/bsec-image.bb</code></pre></div><div><br /><h3>4. Customize the image in the meta-bsec layer.</h3></div><div><br /></div><div><div><div><div>Execute the following commands on the host.</div><div><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b> host]$</b> cd $HOME/src/fsl-community-bsp/sources/meta-bsec/recipes-bsec/images<br /></code></pre></div><div></div><div></div></div></div></div><br />Customize bsec-image.bb as follows. Lines with bold text indicate lines to add to the file.<br /><br /><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> DESCRIPTION = "A console-only image with more full-featured Linux system \<br /> functionality installed."<br /><br /> # customize IMAGE_FEATURES as follows<br /> IMAGE_FEATURES += "dev-pkgs tools-sdk tools-debug tools-profile tools-testapps \<br /> debug-tweaks splash ssh-server-openssh package-management"<br /><br /> # packagegroup-core-tools-profile will build and install tracing and profiling tools to the target image.<br /> # packagegroup-core-buildessential will build and install autotools, gcc, etc. to the target image.<br /> # kernel-modules for install of the kernel modules.<br /> # kernel-devsrc for building out of tree modules.<br /> # IMAGE_ROOTFS_EXTRA_SPACE_append for adding extra space to the target rootfs image.<br /><br /> # customize IMAGE_INSTALL as follows<br /> IMAGE_INSTALL = "\<br /> packagegroup-core-boot \<br /> packagegroup-core-full-cmdline \<br /> <b>packagegroup-core-tools-profile \</b><br /> <b>packagegroup-core-buildessential \</b><br /> <b>kernel-modules \</b><br /> ${CORE_IMAGE_EXTRA_INSTALL} \<br /> <b>kernel-devsrc \</b><br /> "<br /> inherit core-image<br /> <br /> # Add extra space to the rootfs image<br /> <b>IMAGE_ROOTFS_EXTRA_SPACE_append += "+ 3000000"</b><br /></code></pre></div><br /><h3>5. Create layer.conf file in the meta-bsec layer.</h3></div><div><div><br />Create <i>sources/meta-bsec/conf/layer.conf</i> with the below contents.<br /><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">BBPATH .= ":${LAYERDIR}" <br /> BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ <br /> ${LAYERDIR}/recipes-*/*/*.bbappend" <br /> BBFILE_COLLECTIONS += "bsec" <br /> BBFILE_PATTERN_bsec = "^${LAYERDIR}/" <br /> BBFILE_PRIORITY_bsec = "6" </code><span style="overflow-wrap: normal; word-wrap: normal;"><br /></span></pre></div><div><br /></div><h3>6. Create the distribution configuration file in the meta-bsec layer.</h3></div><div><br />Create <i>sources/meta-bsec/conf/disro/bsecdist.conf</i> with the below contents.</div><div><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> require conf/distro/poky.conf <br /> # distro name<br /> DISTRO = "bsecdist" <br /> DISTRO_NAME = "bsecdist distribution" <br /> DISTRO_VERSION = "1.0" <br /> DISTRO_CODENAME = "bsc" <br /> DISTRO_FEATURES_append = " alsa usbhost usbgadget keyboard bluetooth"<br /> SDK_VENDOR = "-bsecdistsdk" <br /> SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}" <br /> MAINTAINER = "bsecdist " <br /> INHERIT += "buildhistory" <br /> BUILDHISTORY_COMMIT = "1"</code></pre></div><div><h3></h3><h3>7. Add the new layer to bblayers.conf</h3><br />Execute the following commands on the host.<br /><br /><div><div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> <b>host]$</b> cd $HOME/src/fsl-community-bsp/build/conf<br /></code></pre></div><div></div><div></div></div><br />Customize bblayers.conf by adding the meta-bsec layer to BBLAYERS as follows.<br /><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> LCONF_VERSION = "6"<br /><br /> BBPATH = "${TOPDIR}"<br /> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}"<br /><br /> BBFILES ?= ""<br /> BBLAYERS = " \<br /> ${BSPDIR}/sources/poky/meta \<br /> ${BSPDIR}/sources/poky/meta-yocto \<br /> \<br /> ${BSPDIR}/sources/meta-openembedded/meta-oe \<br /> ${BSPDIR}/sources/meta-openembedded/meta-multimedia \<br /> \<br /> ${BSPDIR}/sources/meta-fsl-arm \<br /> ${BSPDIR}/sources/meta-fsl-arm-extra \<br /> ${BSPDIR}/sources/meta-fsl-demos \<br /> <b>${BSPDIR}/sources/meta-bsec \</b><br /> "<br /></code></pre><div><br /><h3>8. Customize the local configuration</h3><div><br />Customize local.conf as follows.<br /><br /></div><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> MACHINE ??= 'imx6dl-riotboard'<br /> # set distro name<br /> <b>DISTRO ?= 'bsecdist'</b><br /> PACKAGE_CLASSES ?= "package_rpm package_deb"<br /> EXTRA_IMAGE_FEATURES = " "<br /> USER_CLASSES ?= "buildstats image-mklibs image-prelink"<br /> PATCHRESOLVE = "noop"<br /> BB_DISKMON_DIRS = "\<br /> STOPTASKS,${TMPDIR},1G,100K \<br /> STOPTASKS,${DL_DIR},1G,100K \<br /> STOPTASKS,${SSTATE_DIR},1G,100K \<br /> ABORT,${TMPDIR},100M,1K \<br /> ABORT,${DL_DIR},100M,1K \<br /> ABORT,${SSTATE_DIR},100M,1K" <br /> PACKAGECONFIG_append_pn-qemu-native = " sdl"<br /> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"<br /> ASSUME_PROVIDED += "libsdl-native"<br /> CONF_VERSION = "1"<br /> BB_NUMBER_THREADS = '4'<br /> PARALLEL_MAKE = '-j 4'<br /> DL_DIR ?= "${BSPDIR}/downloads/"<br /> ACCEPT_FSL_EULA = "1"<br /><b> # archive source code for all of the packages that will be built into the image<br /> INHERIT += "archiver"<br /> ARCHIVER_MODE[src] = "original"<br /> # ensure that license files accompany each binary in final image<br /> COPY_LIC_MANIFEST = "1"<br /> COPY_LIC_DIRS = "1"<br /> # setup source mirror<br /> # make sure that bitbake checks for all of the source tarballs in a local directory <br /> # before going to the Internet to fetch them.<br /> SOURCE_MIRROR_URL ?= "file://${BSPDIR}/source-mirror/"<br /> INHERIT += "own-mirrors"<br /> # create a shareable cache of source code management backends<br /> BB_GENERATE_MIRROR_TARBALLS = "1"</b></code></pre></div><div></div></div></div></div><br /><h3>9. Execute the build</h3><br /><div>Execute the following commands on the host.</div><br /><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"><b> host]$</b> cd $HOME/src/fsl-community-bsp/build <br /><b> host]$</b> time bitbake bsec-image </code></pre></div><br />While the image is building, please take note of the following.<br /><br />The input specifications for the GNU/Linux kernel and U-boot segments of the BSP are in the below files. These specifications include such things as GNU/Linux kernel patch files for i.MX 6 processor features, kernel boot args, kernel load address, cortex specific tuning parameters, etc.<br /><br /><div><pre style="background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; width: 646.463px;"><code style="overflow-wrap: normal; word-wrap: normal;"> sources/meta-fsl-arm-extra/conf/machine/imx6dl-riotboard.conf <br /> sources/poky/meta-yocto/conf/distro/poky.conf <br /> sources/meta-fsl-arm/recipes-kernel/linux/linux-imx.inc <br /> sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc_4_0.bb <br /> sources/poky/meta/conf/machine/include/tune-cortexa9.inc</code></pre></div><br />In part III of this guide, the image will be booted on the target and then audio will be tested, including recording and playback. Continue to part III of this guide. <br /><br /><a href="http://web.archive.org/web/20160117143123/http://www.bryanhinton.com/2015/07/creating-custom-linux-bsp-for-riotboard_99.html" target="_blank">Continue to Part III</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-35399708818050232302015-07-13T23:52:00.001-05:002023-03-25T21:46:36.066-05:00Creating a custom Linux BSP for an ARM Cortex-A9 SBC with Yocto 1.8 - Part I<p><br /></p><div class="post-header"> </div> <div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhe1IMh1tKQAsG4Nn3z9-qVjq0EXBrvGLNvu12jREoiMFwDqD1JI9IIjPAZ1C9l9wA_lSpK5ZU0oSrNGyGZSBxQDNyKv7R3cyZaYr1KvwvBb2qGyLPg_J-zLpZvATppTqCXPIXYlqtnpsFumKPSbBXR-JXqstF7cEZt9hErLscgQZJNPLSdbBXe57W6=s640" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="213" data-original-width="640" height="214" src="https://blogger.googleusercontent.com/img/a/AVvXsEhe1IMh1tKQAsG4Nn3z9-qVjq0EXBrvGLNvu12jREoiMFwDqD1JI9IIjPAZ1C9l9wA_lSpK5ZU0oSrNGyGZSBxQDNyKv7R3cyZaYr1KvwvBb2qGyLPg_J-zLpZvATppTqCXPIXYlqtnpsFumKPSbBXR-JXqstF7cEZt9hErLscgQZJNPLSdbBXe57W6=w640-h214" width="640" /></a></div><br />This guide is an update to "Creating a custom Linux distribution for an ARM® Cortex®-A9 based SBC" and provides directions for building a GNU/Linux BSP for the RioTboard (<a href="https://en.wikipedia.org/wiki/Internet_of_things" target="_blank">Internet of Things</a>) with Yocto 1.8 on a 64-bit Fedora 21 GNU/Linux host. The latest stable version of Yocto 1.8 has been incorporated along with build instructions for version 4.0.7 of the GNU/Linux kernel with i.MX 6 patches, U-boot, audio recording and playback support, and a full kernel and application development environment on the target.<br /><br />This guide is split into three parts as follows.<br /><br /><b>I. Creating a custom Linux BSP for the RioTboard (</b><b><a href="https://en.wikipedia.org/wiki/Internet_of_things" target="_blank">Internet of Things</a>) with Yocto 1.8- Part I</b><br /><ol><li>Hardware and software prerequisites.</li><li>Required Packages for a 64-bit Fedora 21 Host development system.</li></ol><p><b>II. Creating a custom Linux BSP for the RioTboard with Yocto 1.8 - Part II</b><br /></p><ol><li>Pull the Freescale community BSP platform source code from github. </li><li>Setup the build environment using the predefined imx6dl-riotboard machine.</li><li>Create a new layer for the custom Linux distribution.</li><li>Customize the image in the meta-bsec layer. </li><li>Create layer.conf file in the meta-bsec layer. </li><li>Create the distribution configuration file in the meta-bsec layer. </li><li>Add the new layer to bblayers.conf.</li><li>Customize the local configuration.</li><li>Execute the build.</li></ol> <b>III. Creating a custom Linux BSP for the RioTboard with Yocto 1.8 - Part III</b><br /><ol><li>Write the GNU/Linux BSP image to an SD card.</li><li>Set the physical switches on the RioTboard to boot from the uSD or SD card.</li><li>Connect the target to the necessary peripherals for boot.</li><li>Test audio recording, audio playback, and Internet connectivity.</li><div></div></ol><br />The BSP will consist of a GNU/Linux 4.0.7 kernel, an EXT3 root filesystem, and the U-Boot bootloader. All components will be compiled from the latest, public sources. The GNU/Linux system will include support for audio recording and playback via the RioTboard's MIC In and Audio Out jacks. Support will be built for ethernet, ipv4, bluetooth, USB host and USB gadget, and an ssh server. The final target image will also contain native ARM compilers, a full SDK, strace, GDB, package management tools, and the GNU/Linux 4.0.7 kernel source code with i.MX 6 patches already applied.<br /><br />In the first guide for Yocto 1.7, a custom distribution and target image was created by extending the core-image-minimal image. In this guide, a custom distribution and target image will be created by extending the core-image-full-cmdline image. The resulting target image will be larger in size but will include a much richer set of features for kernel and application level development and debugging on the target.<br /><br />Finally, Yocto will be configured so that all source packages are archived in their original format with accompanying license files.<br /><br />To start with, please read <a href="http://www.bryanhinton.com/2014/12/setting-up-arm-cortex-a9-based-sbc.html" target="_blank">Setting up an ARM® Cortex®-A9 based SBC</a> which outlines the necessary components to get started. A microphone and a set of powered speakers will be needed, both with 3.5mm connectors. An Audio-Technica ATR4650 microphone and a pair of Logitech S-00134 powered speakers will be onnected to the RioTboard. These will be needed for testing audio recording and playback.<br /><br /><h3></h3><h3>1. Hardware and software prerequisites</h3><div><br /><br /><h4>Host Operating System</h4>Fedora release 21 for x86_64<br />GNU/Linux kernel 4.0.7-200.fc21.x86_64 #1 SMP</div><div><br /></div><div><h4>Host Hardware</h4>Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz<br />Physical Memory 12 GB<br />My /home partition is 414 GB and resides on a solid state hard drive.<br /><br /><br />The Yocto build requires a large amount of space so it is recommend keeping a scratch area in the /home partition of at least 100 GB.<br /><h3>2. Required Packages for a 64-bit Fedora 21 Host development system</h3></div> <br /><span style="font-size: x-small;"><a href="http://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html" target="_blank">from the Yocto Project Mega Manual Revision 1.8</a></span><br /><br />Execute the following commands on the host.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: none 0% 0% repeat scroll rgb(240, 240, 240); border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"><b> host]$</b> sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \<br /> diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \<br /> ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue socat \<br /> findutils which<br /> <b>host]$</b> sudo yum install SDL-devel xterm perl-Thread-Queue<br /> <b>host]$</b> sudo yum install make docbook-style-dsssl docbook-style-xsl \<br /> docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc<br /> <b>host]$</b> sudo yum install autoconf automake libtool glib2-devel<br /></code></pre><br /></div><p>In Part II, the source code for the kernel, boot loader, and root file system packages will be pulled. All components will then be built from source and the GNU/Linux BSP image will be created for the target.</p><p><a href="http://www.bryanhinton.com/2015/07/creating-custom-linux-bsp-for-riotboard_13.html" target="_blank">Continue to Part II</a> <br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-36215263157467223912014-12-30T23:57:00.001-06:002023-03-28T20:22:55.141-05:00Customizing a Linux distribution for an ARM Cortex-A9 SBC<p>The Yocto 1.7.1 (Dizzy branch) from Freescale source will be used for building a BSP for the i.MX 6 RIoTboard. The final image will consist of the following components</p><div class="post-body entry-content" id="post-body-5482572012956095765" itemprop="description articleBody"><ul><li>U-Boot version 2014.10 from the Freescale git repositories.</li><li>Linux kernel version 3.17.4 from the Freescale git repositories.</li><li>ext3 root filesystem with selected packages</li></ul><div class="post-body entry-content" id="post-body-5482572012956095765" itemprop="description articleBody">The image will be built from the custom distribution (bsecdist) and custom image (bsec-image) defined in the last post. bsec-image is derived from core-image-minimal. The configuration changes below will add support for package tests to the baec-image. In addition, the profiling tools and static development libraries and header files will be added to the image. Finally, several standard userspace packages will be added to baec-image; namely, bison, flex, and and gunning. Last, several configuration directives will be added to the local configuration file so that source code archives, package versions, and accompanying license files are stored and cached in a local directory for future builds and compliance purposes.</div><br /><br /><b>1. Add profiling tools and static development packages to image</b><br /><br />First, add the following profiling tools contained within the tools-profile package to the final image. Add static versions of the development packages to the target image. Therefore, add the IMAGE_FEATURES line to bsec-image.bb as follows.<br /><br />sources/meta-bsec/recipes-bsec/images/bsec-image.bb should contain the following<br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">SUMMARY = "A small image just capable of allowing a device to boot."<br />IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"<br />IMAGE_LINGUAS = " "<br />LICENSE = "MIT"<br />inherit core-image<br /><b>IMAGE_FEATURES += " tools-profile staticdev-pkgs"</b><br />IMAGE_ROOTFS_SIZE ?= "8192"</code><br /></pre></div><br /><b>2. Add bison, flex, and gnupg packages to image</b><br /><br />Now add bison, flex, and gnupg to the list of packages installed to the target image.<br />Add the following line to bsec-image.bb after the IMAGE_FEATURES line as follows.<br /><br />sources/meta-bsec/recipes-bsec/images/bsec-image.bb should contain the following<br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">SUMMARY = "A small image just capable of allowing a device to boot."<br />IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"<br />IMAGE_LINGUAS = " "<br />LICENSE = "MIT"<br />inherit core-image<br />IMAGE_FEATURES += " tools-profile staticdev-pkgs"<br /><b>CORE_IMAGE_EXTRA_INSTALL += "bison flex gnupg"</b><br />IMAGE_ROOTFS_SIZE ?= "8192"</code><br /></pre></div><br /><b>3. List available packages</b><br /><br />The full list of available packages can be viewed by executing the following command<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">$ bitbake -s</code><br /></pre></div><br /><b>4. Setup source code archiving for all packages contained within image</b><br /><br />Next, archive the source code for all packages contained within the image.<br />This can be achieved by adding the following two lines to the end of the build/conf/local.conf file<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">INHERIT += "archiver"<br />ARCHIVER_MODE[src] = "original"</code><br /></pre></div><br /><b>5. Ensure license files are archived and included with binaries.</b><br /><br />Subsequently, ensure that the license files accompany each binary in the final image by adding the following two lines to the end of the build/conf/local.conf file.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">COPY_LIC_MANIFEST = "1"<br />COPY_LIC_DIRS = "1"</code></pre></div><br /><b>6. Add package testing to build</b><br /><br />Now, add package testing to the build by adding the following two lines to bsec-image.bb<br /><br />The contents of sources/meta-bsec/recipes-bsec/images/bsec-image.bb should be as follows<br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">SUMMARY = "A small image just capable of allowing a device to boot."<br />IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"<br />IMAGE_LINGUAS = " "<br />LICENSE = "MIT"<br />inherit core-image<br />IMAGE_FEATURES += " tools-profile staticdev-pkgs"<br />CORE_IMAGE_EXTRA_INSTALL += "bison flex gnupg"<br /><b>DISTRO_FEATURES_append = " ptest"<br />EXTRA_IMAGE_FEATURES += "ptest-pkgs"</b><br />IMAGE_ROOTFS_SIZE ?= "8192"</code><br /></pre></div><br /><b>7. Setup source code mirror so that package sources can be fetched from cache</b><br /><b><br /></b>Next, make sure that bitbake checks for all of the source tarballs in a local directory before going to the Internet to fetch them. This can be achieved by adding the following lines to the end of the build/conf/local.conf file.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">SOURCE_MIRROR_URL ?= "file://${BSPDIR}/source-mirror/"<br />INHERIT += "own-mirrors"</code><br /></pre></div><br /><b>8. Create shareable cache of git and svn backends</b><br /><br />Finally, create a shareable cache of source code management backends by adding the following to the end of the build/conf/local.conf file.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">BB_GENERATE_MIRROR_TARBALLS = “1”</code><br /></pre></div><br />After an initial build is performed, the directory contents of download/ can be recursively copied into source-mirror/ and the following line can be added to the end of the build/conf/local.conf file.<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">BB_NO_NETWORK = “1”</code></pre></div><br />Consequently, all future builds will not fetch anything from the Internet and all package sources will be obtained from the sources in source-mirror.<br /><br /><b>9. Kick off the build</b><br /><br />Kick off the build as follows<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">$ cd $HOME/src/fsl-community-bsp<br />$ MACHINE=imx6dl-riotboard . ./setup-environment build <br />$ bitbake bsec-image</code></pre></div><br /><br /><b>10. Copy sources to mirror</b><br /><br />Copy the sources from the downloads directory to source-mirror by executing the following commands<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">$ cd ..<br />$ cp -R downloads/*.* source-mirror/</code></pre></div><br /><br />After the build is complete, the license file for each package will be contained within the appropriately named subdirectory of build/tmp/deploy/licenses<br /><br />The image manifest file <i>build/tmp/deploy/images/imx6dl-riotboard/bsec-image-imx6dl-riotboard.manifest</i> will contain a list of package names and associated versions for each of the packages in the image.<br /><br /><br /><b>11. Boot the custom distribution image</b><br /><br />After the build is complete, write the image to an SD Card as follows<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">$ cd build/tmp/deploy/images/imx6dl-riotboard</code></pre><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;">$ sudo umount /dev/sdX<br />$ sudo dd if=bsec-image-imx6dl-riotboard.sdcard of=/dev/sdb bs=1M<br />$ sudo sync</code></pre></div><br /><br />Insert the SD Card in the J6 SD Card slot on the bottom of the RiOTboard, connect the board to the Host over Serial UART, run minicom at 115200,8N1 from a terminal on the Host, and power on the board.<div style="clear: both;"></div></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-30605759965977275962014-12-29T18:21:00.001-06:002023-03-28T20:23:05.721-05:00Creating a custom Linux distribution for an ARM Cortex-A9 SBC<div class="post-body entry-content" id="post-body-4630528737206562678" itemprop="description articleBody">The Yocto project provides an ideal platform for building a custom Linux distribution. It's design was intended to model a machine. The Yocto project or machine should take a number of inputs and produce an output. The inputs to the machine are the specifications for the Linux distribution. The output of the machine is the Linux distribution.</div><div class="post-body entry-content" id="post-body-4630528737206562678" itemprop="description articleBody"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjzDnTklS6eX54Yl9vuNDn8m_8ODSSUYUBU6KpOPBj5SdJTBm-gGeo5tULT6mBX_81wmnYLF99Dy4WhxqHQ8mmi7VRzKqgejJc7UWspwPIsTIq9KIf6Kp-FhY29K7IK9isMbFVePY5Ev5qvFOpthS9W8mogrBd1aG0yJWtyMJvImzkBNFv7m6vfOAbW=s511" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="293" data-original-width="511" src="https://blogger.googleusercontent.com/img/a/AVvXsEjzDnTklS6eX54Yl9vuNDn8m_8ODSSUYUBU6KpOPBj5SdJTBm-gGeo5tULT6mBX_81wmnYLF99Dy4WhxqHQ8mmi7VRzKqgejJc7UWspwPIsTIq9KIf6Kp-FhY29K7IK9isMbFVePY5Ev5qvFOpthS9W8mogrBd1aG0yJWtyMJvImzkBNFv7m6vfOAbW=s16000" /></a></div><br /> </div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="post-body entry-content" id="post-body-4630528737206562678" itemprop="description articleBody"><div><div>The Yocto project is the most widely supported system for building custom Linux distributions.</div><div>The Yocto project is very well supported by both communities and companies. The project consists of a tool called bitbake and a build system that is based off of OpenEmbedded. Together, these two components along with a defined set of metadata comprise what is called the Poky reference platform.</div><div><div><br /></div><div>Yocto supports numerous architectures through OpenEmbedded. These include x86, ARM®, MIPS, and PowerPC. Yocto's most attractive feature is its support of what are called layers. Layers allow the abstraction of individual components or sets of components within a board support package (BSP). New layers can be derived from existing layers to enhance functionality, patch source code, or remove subsets of unneeded components. </div></div></div><div><br /></div><div>Building support for a custom boot loader, custom kernel, custom rootfs, and development application layer is both very clean and straightforward. SELinux has become a necessary component of almost every Linux distribution. It is very simple to integrate SELinux into Yocto via an OpenEmbedded layer. Consequently, building a "Carrier Grade" Linux distribution for one of the many (several hundred) processors is attainable in a short amount of time.</div><div><br /></div><div>Embest Technology created the RIoTboard. The board design is fairly simple. The board contains an i.MX 6 Solo processor. Embest Technology and Element 14 provide links to download prebuilt Linux and Android images. Embest Technology also has a github repository where source code can be downloaded to build a complete BSP. The complete BSP consists of the u-boot boot loader, kernel, and root filesystem.</div><div><br /></div><div>Embest Technology took a snapshot of the Freescale Community BSP Platform source code repository at some point in the past. The BSP source download from github, which consists of the Yocto layers for building a riotboard BSP, is not up to date with Freescale, Yocto, and OpenEmbedded.<br /></div><div><br /></div><div>Consequently, Freescale's community BSP platform will be used. The platform is comprised of both the Poky reference build system and an additional series of layers which will allow us to build a custom Linux distribution for the i.MX 6 processor architecture. </div><div><br /></div><div>A custom Linux distribution that will be used for development should include support for only the peripheral components that will be used. The custom development distribution should be minimized to the maximum extent possible. All I/O interfaces should be clearly documented. Bootable media types should be documented and partition maps should be created. These steps greatly ease development and debugging, and prevent unknown issues from cropping up after production release. Layering in SELinux at a later time is simple. Creating new layers for shared library development, or userspace application development is also simple and layers can be added for slicing out pieces of the kernel that aren't now, but may be needed later on. Last but not least, blowing the appropriate fuses prior to production is critical.</div><div><br /></div><div>To keep things simple, a new BSP or custom Linux distribution will be derived from the riotboard specifications that have already been incorporated into Freescale's community BSP platform. </div><div><br /></div><div>The goal here is to produce a minimal Linux distribution that can be used for development and easily extended from any level in the stack - u-boot, kernel, root filesystem, and userspace libraries or executables. Most importantly, the architecture of this distribution will conform to the standards that have been outlined by the Yocto Project and OpenEmbedded. This means anyone can easily pick up.</div><div><br />The input specifications for a generic i.MX 6 solo machine have been mostly documented in the meta-fsl-arm-extra layer. The output image that is produced from these input specifications is an image that consists of the u-boot boot loader, i.MX 6 Solo/Dual kernel, and ext3 root filesystem.<br />In an effort to build a custom Linux distribution for the i.MX 6 Solo/Dual with the least amount of packages in the shortest amount of time, slimming down the input specifications, configuring the distribution, and naming it should only require modification of a few files. Here are the steps.<br /><br /></div><div>First, the riotboard or target must be connected to the Fedora 20 x86_64 host via serial UART (see last blog post). A card reader must be connected to the host via USB. <br /></div><div><br />The new distribution will be called the bsec distribution. The bsec distribution will consist of a minimal Linux image, u-boot boot loader, and ext3 root filesystem configured for the i.MX 6 based riotboard. <br /><br />Perform the following steps on the host.<br /><br /></div><div><b>1. Pull the Freescale community BSP platform source code from github.</b> Dizzy is the Yocto 1.7.1 branch. Execute the following commands on the host.<br /><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ mkdir $HOME/bin <br /> $ <span class="pln" style="font-family: arial; font-size: 13px; line-height: 1.5;">curl https</span><span class="pun" style="color: #666600; font-family: arial; font-size: 13px; line-height: 1.5;">:</span><span class="com" style="color: #880000; font-family: arial; font-size: 13px; line-height: 1.5;">//storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo</span><span style="font-family: arial;"> </span><br /> $ chmod a+x $HOME/bin/repo <br /> $ echo "PATH=$PATH:$HOME/bin" >> $HOME/.bashrc <br /> $ source .bashrc <br /> $ mkdir -p $HOME/src/fsl-community-bsp <br /> $ cd $HOME/src/fsl-community-bsp <br /> $ repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b dizzy <br /> $ repo sync <br /></code></pre></div><div><br /></div><div><b>2. Setup the build environment using the predefined imx6dl-riotboard machine.</b></div><div><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ MACHINE=imx6dl-riotboard . ./setup-environment build <br /></code></pre></div><div></div><div><br /></div><div><b>3. Create a new layer for the custom Linux distribution</b></div><div><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ cd $HOME/src/fsl-community-bsp/sources <br /> $ mkdir -p meta-bsec/conf/distro <br /> $ mkdir -p meta-bsec/recipes-bsec/images <br /> $ cd poky/meta/recipes-core/images <br /> $ cp core-image-minimal.bb ../../../../meta-bsec/recipes-bsec/images/bsec-image.bb <br /></code></pre></div><div><br /></div><div><b>4. Create the layer.conf file in the meta-bsec layer. </b><br /><br />sources/meta-bsec/conf/layer.conf should contain the following</div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> BBPATH .= ":${LAYERDIR}" <br /> BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ <br /> ${LAYERDIR}/recipes-*/*/*.bbappend" <br /> BBFILE_COLLECTIONS += "bsec" <br /> BBFILE_PATTERN_bsec = "^${LAYERDIR}/" <br /> BBFILE_PRIORITY_bsec = "6" </code></pre><div><br /></div><div><b>5. Create the distribution configuration file in the meta-bsec layer. </b><br /><br />sources/meta-bsec/conf/distro/bsecdist.conf should contain the following</div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> require conf/distro/poky.conf <br /> DISTRO = "bsecdist" <br /> DISTRO_NAME = "bsecdist distribution" <br /> DISTRO_VERSION = "1.0" <br /> DISTRO_CODENAME = "bsc" <br /> SDK_VENDOR = "-bsecdistsdk" <br /> SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}" <br /> MAINTAINER = "bsecdist <e-mail-address>" <br /> INHERIT += "buildhistory" <br /> BUILDHISTORY_COMMIT = "1" </code></pre></div><div><b><br /></b><b>6. Added the new layer to bblayers.conf</b><br /><br />build/conf/bblayers.conf should contain the following</div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> LCONF_VERSION = "6" <br /> BBPATH = "${TOPDIR}" <br /> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + '/../..')}" <br /> BBFILES ?= "" <br /> BBLAYERS = " \ <br /> ${BSPDIR}/sources/poky/meta \ <br /> ${BSPDIR}/sources/poky/meta-yocto \ <br /> \ <br /> ${BSPDIR}/sources/meta-openembedded/meta-oe \ <br /> ${BSPDIR}/sources/meta-openembedded/meta-multimedia \ <br /> \ <br /> ${BSPDIR}/sources/meta-fsl-arm \ <br /> ${BSPDIR}/sources/meta-fsl-arm-extra \ <br /> ${BSPDIR}/sources/meta-fsl-demos \ <br /> ${BSPDIR}/sources/poky/meta-selinux \ <br /> ${BSPDIR}/sources/meta-bsec \ <br /> " <br /></code></pre><div><b><br /></b><b>7. Set the distribution to the bsec distribution in local.conf</b><br /><br />build/conf/local.conf should contain the following</div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> MACHINE ??= 'imx6dl-riotboard' <br /> DISTRO ?= 'bsecdist' <br /> PACKAGE_CLASSES ?= "package_rpm" <br /> EXTRA_IMAGE_FEATURES = "debug-tweaks" <br /> USER_CLASSES ?= "buildstats image-mklibs image-prelink" <br /> PATCHRESOLVE = "noop" <br /> BB_DISKMON_DIRS = "\ <br /> STOPTASKS,${TMPDIR},1G,100K \ <br /> STOPTASKS,${DL_DIR},1G,100K \ <br /> STOPTASKS,${SSTATE_DIR},1G,100K \ <br /> ABORT,${TMPDIR},100M,1K \ <br /> ABORT,${DL_DIR},100M,1K \ <br /> ABORT,${SSTATE_DIR},100M,1K" <br /> PACKAGECONFIG_append_pn-qemu-native = " sdl" <br /> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" <br /> ASSUME_PROVIDED += "libsdl-native" <br /> CONF_VERSION = "1" <br /> BB_NUMBER_THREADS = '1' <br /> PARALLEL_MAKE = '-j 1' <br /> DL_DIR ?= "${BSPDIR}/downloads/" <br /> ACCEPT_FSL_EULA = "1" <br /></code></pre><div><b><br /></b><b>8. Pull the OpenEmbedded SELinux meta layer for later configuration</b><br /><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ cd sources/poky <br /> $ git clone -b dizzy git://git.yoctoproject.org/meta-selinux <br /> $ cd ../.. <br /></code></pre></div><div><b><br /></b><b>9. Perform the build</b><br /><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ cd build <br /> $ bitbake bsec-image <br /></code></pre></div></div><div><b><br /></b><b>10. Write the image to the SD card</b><br /><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> $ cd tmp/deploy/images/imx6dl-riotboard <br /> $ sudo dd if=bsec-image-imx6dl-riotboard.sdcard of=/dev/sdX bs=1M <br /> $ sudo sync </code></pre></div><div><br />At this point, the jumpers on the riotboard should be set to boot from the SD card. Next, power on the riotboard with the new SD card. If HDMI is connected, the Das u-boot software engineering logo should appear on the display. <br /><br /></div><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> bsecdist distribution 1.0 imx6dl-riotboard /dev/ttymxc1 <br /> imx6dl-riotboard login: <br /></code></pre></div><br />Review the input specifications for the riotboard machine should be simple. Start with the following files<br /><br /><div><pre style="background-attachment: scroll; background-color: #f0f0f0; background-image: none; background-position: 0% 0%; background: rgb(240, 240, 240) none repeat scroll 0% 0%; border: 1px dashed rgb(204, 204, 204); color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; overflow-wrap: normal; word-wrap: normal;"> sources/meta-fsl-arm-extra/conf/machine/imx6dl-riotboard.conf <br /> sources/poky/meta-yocto/conf/distro/poky.conf <br /> sources/meta-fsl-arm/recipes-kernel/linux/linux-imx.inc <br /> sources/meta-fsl-arm/recipes-kernel/linux/linux-fslc_3.17.bb <br /> sources/poky/meta/conf/machine/include/tune-cortexa9.inc <br /></code></pre></div><div><br />The input specifications for this image are raw and generic. They define software support for ALL of the on-board peripherals with the e-fuses left open.<br /><br />Finally, the output image was 29 MB and is comprised of the u-boot boot loader, the Linux kernel, and the root file system. This is a decent place to start before adding more software to the BSP.<br /><br /></div><div style="clear: both;"></div></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-48798195892917163122014-12-23T18:11:00.005-06:002023-03-22T18:40:54.462-05:00Setting up an ARM Cortex®-A9 based SBC <h2 style="text-align: left;">The RiOTboard - an ARM Cortex-A9 based SBC</h2><p><br /><br />The RIoTboard is an ARM Cortex-A9 based single board computer (SBC). The RIoTboard has a Freescale i.MX6 Solo application processor and an integrated Freescale Kinetis MCU for additional debugging and development. The i.MX6 Solo supports the single ARM Cortex-A9 MPCore Platform. The i.MX6 Solo contains ARM TrustZone technology and the i.MX 6 SoC on the RIoTboard has a 96 KB Boot Rom with support for high assurance boot. Other features of the board include 1 GB of DDR3 memory, 4 GB eMMC, JTAG, Serial, mini USB for OpenSDA, mini USB for USB OTG, LVDS, parallel RGB expansion, 4 USB-A ports, HDMI, audio, reset button, microSD card slot, SD card slot, and boot onboard boot switches. The board is very reasonably priced. Last but not least, the Freescale i.MX 6 ARM Cortex-A9 application processor has ARM TrustZone technology.</p><p>The i.MX6 Solo processor on the RIoTboard is labeled MCIMX6S8DVM10AB. According to the i.MX6 Solo data sheet, the processor supports a number of security related features. The list includes ARM TrustZone technology with TZ architecture support, a secure JTAG controller for locking down and protecting the JTAG port, a cryptographic acceleration and assurance module with secure RAM and a true PRNG, a central security unit (CSU) including secure non-volatile storage, high assurance boot, and the separation of memory and interrupts between secure world and normal world. There are more security related features but this is a general list.<br /></p><div><h3><a name="more"></a>Setting up a RIoTboard</h3><div>Embedded devices used for development purposes often have network controllers on them. From mobile phones to radios, routers, watches, and wearables, these devices are sending and receiving IP datagrams to external Internet hosts via one or many of their network interfaces; WiFi, 3G, 4G, and Bluetooth. Most of the processors being sold today can run rich operating systems with full software support for multiple network interface controllers. In addition, many of the processors being sold today contain support for both virtualization and trusted execution. </div><div><br /></div><div>A network router that is isolated from the Internet and any local computers can be connected to the embedded device via the device's primary network interface. If there are multiple network interfaces on the embedded device, then multiple routers can be connected to the embedded device - one for each interface type. 3G and 4G routers, while not widely available, can be connected to the 3G or 4G modem on the embedded device.</div><div><br /></div><div>IP traffic can be sent and received from both secure world and normal world via multiple network interfaces. Raw packet analysis tools on the router can be used to inspect incoming and outgoing traffic from the embedded device. After the router is connected to the embedded device, data that is transmitted over the embedded device's network interface can be recorded to a format such as PCAP and saved for later analysis. A firewall can also be deployed on the router and all outgoing traffic originating from the embedded device can be blocked. Inexpensive routers with ARM based processors and ARM TrustZone technology can be purchased from most retail stores.</div><div><br />Short of having access to JTAG hardware debuggers, a Bus Pirate can be used in conjunction with OpenOCD for debugging the i.MX 6 processor on the RiOTboard. A bus pirate can also be used in transparent UART bridge mode for connecting the host to the target (the RiOTboard).<br /><br />This type of setup can be very useful for debugging embedded devices, analyzing embedded devices, developing software for embedded devices, and testing embedded devices prior to production. <div><br /><br /></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhY-QpO456YRFl275Pwckkj2CH6szZ3LUkN_HoZLEoefeUNkIKaFvAgYyQBum4GcUiXB-l2J8meo0c-sR8wiVLRBJcqhibJ1myRYiIL_Uqa5-zKurnCYDhQ7AsA6OBdfbfV2FhlzVxGmDXoZl8FZOI4twya6a9Ju0tUfEht0vff87PjcdJlYpnCA2bH=s1600" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1443" data-original-width="1600" height="578" src="https://blogger.googleusercontent.com/img/a/AVvXsEhY-QpO456YRFl275Pwckkj2CH6szZ3LUkN_HoZLEoefeUNkIKaFvAgYyQBum4GcUiXB-l2J8meo0c-sR8wiVLRBJcqhibJ1myRYiIL_Uqa5-zKurnCYDhQ7AsA6OBdfbfV2FhlzVxGmDXoZl8FZOI4twya6a9Ju0tUfEht0vff87PjcdJlYpnCA2bH=w640-h578" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The Netgear WNR3500U (right) can run multiple operating systems.</td></tr></tbody></table><br /><br /><ul><li>Digital multimeter for testing continuity of JTAG, SWD, and Serial cables</li><li>Proper ground and wrist strap</li><li>2x ethernet cable</li><li>WNR3500U router</li><li>microSD card 8 GB Class I</li><li>SD card 8 GB Class I</li><li>RiOTboard</li><li>5 VDC power supply for RiOTboard</li><li>2x Bus Pirate</li><li>Cortex SWD 10 to 20 pin adapter</li><li>2x 5-pin female to female breakout cable</li><li>FTDI mini USB to 5-pin female breakout board</li><li>4-pin female to female breakout cable</li><li>HDMI cable</li><li>USB mouse</li><li>USB keyboard</li><li>Display</li><li>Host computer with Linux (Fedora 21)</li><li>4x mini USB to USB-A cables</li><li>10-pin female to female SWD / JTAG cable</li><li>Card reader</li></ul><h3>Using the Bus Pirate as a transparent UART bridge</h3><div>Bus Pirate Pin 01 GND <---> RiOTboard J18 Pin 3 GND</div><div>Bus Pirate Pin 08 MOSI <---> RiOTboard J18 Pin 1 UART2 TX</div><div>Bus Pirate Pin 10 MISO <---> RiOTboard J18 Pin 2 UART2 RX</div><div><br /></div><div>Flashing the PIC on the Bus Pirate is straightforward (see documentation) and should be performed so that the Bus Pirate is running the latest firmware.</div><br /></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEjMyBpz-wNFf6dXaC0OZq8XVP0Vbnsy7OKu0sya4a7UhZhQnd7kTozMdhE_9pGOYlYwGdxV7befD53DV38arZYv5ja2pbR2NzWq_7rdxb47ZwLsFMV-gBtcfAf3LSluJN8xR7PXbqr38ZL3bZJElBFqZV1fA1PYI3fHe9WYYdbj-OLVIfCazqpZsFSZ=s1600" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1404" data-original-width="1600" height="562" src="https://blogger.googleusercontent.com/img/a/AVvXsEjMyBpz-wNFf6dXaC0OZq8XVP0Vbnsy7OKu0sya4a7UhZhQnd7kTozMdhE_9pGOYlYwGdxV7befD53DV38arZYv5ja2pbR2NzWq_7rdxb47ZwLsFMV-gBtcfAf3LSluJN8xR7PXbqr38ZL3bZJElBFqZV1fA1PYI3fHe9WYYdbj-OLVIfCazqpZsFSZ=w640-h562" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">RiOTboard connected via JTAG and UART to Host</td></tr></tbody></table><br /></div><br /><br /><br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-3617035580196476072014-12-15T14:01:00.014-06:002023-03-22T01:55:03.694-05:00 ARM, NFC Technology, and the Single Wire Protocol At the heart of an ARM Powered smartphone with NFC technology is the contactless front end or CLF. The CLF is responsible for managing radio-frequency communication at 13.56 MHz. <br /><br />A mobile phone with NFC technology contains only one CLF. The CLF is connected to the ARM processor or application processor via UART, I²C, and SPI. These protocols are relatively basic and facilitate straightforward communication between the application processor and CLF via a typical Linux or UNIX-based kernel. Updating the firmware on the CLF is a typical operation performed over the UART serial line.<br /><br />While a mobile phone with NFC technology contains only one CLF, the phone may contain multiple secure elements. A secure element may reside on the UICC card, on the microSD card, or embedded with the CLF on the PCB. Applets residing on each of the secure elements can serve both similar and different purposes. Both the secure element and the CLF are small, self-contained computers with I/O communications interfaces. In the case where multiple secure elements reside on the phone, each of the secure elements is a small, self-contained computer with I/O communication interfaces. A secure element differs from a normal computer in that it is embedded and has limited resources available for performing computations. <br /><br />A typical secure element also contains dedicated hardware co-processors for performing common cryptographic operations. Implementing standard cryptographic algorithms at the software level on the secure element is not always practical due to the resource constraints of the secure element components. At a high level, the applet(s) 's responsibility resides on the secure element is to handle the secure storage and transmission of private data. For these types of use cases, encryption and decryption are common operations. Consequently, they are refactored into hardware blocks on most secure elements.<br /><br />UICC-based SEs, eSEs, and microSD-based SEs all use cryptography to store private data. UICC-based SEs, eSEs, and microSD-based SEs are typically manufactured by different companies. Consequently, multiple types of operating systems run on secure elements.<br /><br />When the secure element is packaged with the CLF on the PCB, it is called the embedded secure element (eSE). The eSE is connected to the CLF via S2C (NFC-WI) for such a configuration.<br /><br />By design, the inclusion of the embedded SE into the IC package with the CLF means that the provisioning of trusted applets, such as those used for e-ticketing, can occur via a communications channel external to that of the carrier-controlled, baseband processor. Updates and network communication with a UICC-based SE occur via the baseband processor. On the contrary, an eSE is not typically provisioned by the MNO when the phone is purchased. If the user has access to the proper access keys, communication with an embedded SE (eSE) can occur via the CLF through the application processor. The eSE is connected to the CLF in the IC package via the S2C bus. The S2C or NFC-WI interface was initially proposed by Philips and subsequently standardized by ECMA. The S2C interface consists of two lines, SigIn and SigOut, implemented as two physical wires between the CLF and embedded secure element. This S2C protocol allows for full-duplex communication over two physical wires between the CLF and eSE. A common eSE is called the NXP SmartMX.<br /><br />In contrast, the UICC on a mobile phone has traditionally been used by the mobile network operators (MNOs) for carrier-specific purposes such as network subscriber information. Mobile phones with NFC technology and a UICC also utilize the secure element on the UICC for e-ticketing applications. The MNOs have primarily been involved in utilizing the secure element on the UICC for storing private data. The UICC-based SE manufacturer is most likely some entity other than NXP. The applets that reside on the UICC-based SE are inherently the domain of the mobile network operators. Applets running on the UICC are used for multiple purposes, including carrier network and subscriber information and NFC e-ticketing applications. Applications responsible for storing private data are provisioned by trusted external entities associated with the MNOs. Currently, the UICC-based SE is provisioned by a trusted MNO entity prior to purchase. Carrier network activities such as call initiation and SMS receipt can be communicated to/from applets running on the UICC via the radio interface software layer running on the application processor's operating system as the application processor is connected to the baseband processor. This exchange occurs in the form of APDUs. APDUs are exchanged between a contactless point of sale terminal and an applet running on the UICC-based SE or eSE during an NFC e-ticketing activity.<br /><br />Since the inception of NFC hardware on ARM Powered smartphones, NFC e-ticketing applets have been added to the secure element on the UICC. The UICC is physically connected to the phone's baseband processor. The UICC is connected to the CLF via the single wire protocol (SWP) for a phone with NFC technology. A single, physical wire is connected between the CLF and one of the contact pins on the UICC. SWP defines the connection between the UICC and CLF. SWP is intended for use when the UICC-based SE houses trusted applets responsible for e-ticketing applications and private data storage. SWP allows full-duplex communication over a single physical wire between the CLF and UICC. ETSI TS 102 613 defines the physical and data layers of SWP. SWP was established by Gemplus (now Gemalto).<br /><br />In the United States, MNOs utilize the secure element on the UICC card for hosting e-ticketing applications and storing private data. Android phones with NFC technology may an application that uses the RF controller on the phone. If this is the case, the phone most likely contains a UICC-based secure element connected to the internal CLF via the SWP.<br /><br />The mobile phone may contain an NXP PN544 pin-to-pin compatible PN65N, in which case, the SWP line is wired to the UICC SWP contact pin via a single physical wire. Alternatively, the phone may contain a PN544 CLF, in which case the same SWP line is wired to the UICC SWP contact pin via a single physical wire. When an embedded secure element is connected to the CLF via S2C (NFC-WI) and the CLF is also connected to the UICC-based SE over the single wire protocol (SWP), then applications (applets) can be selected by id from either secure element.<br /><br />The provisioning of applets to either the eSE, microSD SE, or UICC-based SE occurs via different channels. The MNOs have primarily been responsible for the provisioning of applets to the UICC-based SE via trusted third parties. In contrast, device manufacturers can provision parts of the embedded secure element before it leaves the factory. The physical connection to the secure element is one of its key differentiating factors. Embedded secure elements are connected to the CLF via S2C. In contrast, UICCs use the SWP pin to connect with the CLF. When an e-ticketing transaction occurs via NFC, it does so over the contactless communication interface. The remote e-ticketing terminal sends information back and forth between the applet running on the secure element. This communication occurs via the CLF to the SE, either over the single wire connection to a UICC-based SE or over the two-wire (S2C) connection to the eSE; depending on which SE is running the issuers e-ticketing applet. The MNO may provision the UICC-based SE with special applications. The microSD card is also connected to the CLF; however, this is not mentioned since microSD-based secure elements are not as prevalent yet in the United States.<br /><br />It has been the intent of the OEMs (not all), silicon manufacturers (not all), and those in favor of open ecosystems to utilize the onboard embedded secure element (eSE) for hosting the applications that are responsible for e-ticketing applications.<br /><br />There are multiple parties involved in this ecosystem; they include and are not limited to trusted third parties responsible for provisioning applets to the secure element via the carrier network, credit card issuers, silicon manufacturers, original equipment manufacturers (OEMs), banks, mobile network operators (MNOs), software vendors such as Google, credit card manufacturers, credit card issuers global standards bodies such as ISO and EMVCo, trusted service managers, service providers, certificate authorities, industry associations such as Global Platform, and numerous regulating entities. The ecosystem is complex, and there are currently several successful efforts underway to standardize NFC technology and how it is used in the United States.<br /><br />As a critical point to consider and in contrast to the solutions that have been implemented for the safe execution and storage of NFC related e-ticketing applications and private data, ARM TrustZone technology in the processor core can be utilized in a similar light to that of the technologies on the eSE, UICC-based SE, and microSD SE. ARM TrustZone technology provides an ideal platform for secure keypad entry and user authentication.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-48970268906656230612014-12-12T20:17:00.010-06:002023-03-25T21:44:15.970-05:00ARM Powered smartphones with NFC technologyThere are many Near Field Communication (NFC)-enabled phones (devices) available on the consumer market. LG, Huawei, Motorola, Samsung, HTC, Nokia, ZTE, Sony, RIM, Amazon, and Apple are among the companies that manufacture and sell mobile phones with NFC technology.<br /><br />There are many common denominators at the hardware and software levels among all the phones that have NFC technology. First, all mobile phones contain a main (application) processor, and if the phone is manufactured by one of the companies listed above, the application processor is an ARM microprocessor. There may be one or two exceptions, but if 150 current phones were sampled across all of these manufacturers, one would find that 99% of the phones contain ARM technology. Operating systems that run on the ARM Powered processors contained within phones from these manufacturers are similar in that they support preemptive multitasking. Most of these devices run the Linux operating system or a UNIX-based operating system.<br /><br />An ARM Powered smartphone with NFC technology contains other microprocessors on its printed circuit board (PCB). These other microprocessors consist of the radio frequency (RF) controller or contactless front end (CLF) and an optional embedded secure element (eSE). The CLF is responsible for managing contactless communication at 13.56MHz. The eSE and SE (external UICC-based or microSD card-based) are responsible for secure application execution and the secure storage of sensitive payment or identification information. A trusted OS runs on the eSE and/or SE. A mobile phone may contain both an eSE and a UICC-based or microSD-based SE. For such a configuration where multiple secure elements exist on the phone, different trusted operating systems may run on the phone's secure elements, and different trusted applications (client applications) may run on the trusted operating systems. One trusted application may be responsible for secure VISA payments, and another trusted application may be responsible for electronic identification (eIdentification).<br /><br />The RF controller and the embedded secure element (eSE) are soldered directly to the PCB, typically within the same IC package. The RF controller may exist on the circuit board without the eSE. The eSE is an optional hardware component on a mobile phone that contains NFC technology. The RF controller and eSE are soldered to the PCB by the phone manufacturer. Alternatively, the secure element used for NFC may be external. An external secure element is one that is located on the mobile phone's UICC or microSD card. When a mobile phone is purchased from a local cell phone store, a UICC card is usually inserted into the phone by the person at the store. If purchased from one of the leading operators in the United States, the UICC card contains a secure element. It is important to note that the existence of an embedded secure element and a UICC-based or microSD-based secure element on the same mobile phone is not mutually exclusive. The secure elements may serve different purposes.<br /><br />As mentioned above, ARM Powered smartphones with NFC technology may contain a single type of secure element. Such a phone may only contain a CLF or RF controller. Mobile phones with a CLF and no secure element may emulate the software running on the secure element via the operating system and application software running on the application processor. This is called host card emulation (HCE).<br /><br />There are numerous configurations of NFC technology on mobile phones. Each of the described components exposes one or more hardware interfaces for communication and interconnection with neighboring components on the printed circuit board. Hardware bus protocols and software communication protocols run on top of the wires that connect the individual components on the printed circuit board. These include standard bus protocols such as I²C, S2C (NFC-WI), SWP, and SPI (more on this later). It is important to note that a typical ARM-powered smartphone with NFC technology has a CLF that is connected to the application processor via both I²C and UART. This is good because I²C device drivers are not complicated, and reading/writing to a tty on an ARM-powered smartphone is straightforward. Lastly, the CLF typically contains an optimized 80C51 processor. The CLF may be packaged with a secure element, and the secure element may contain an optimized 8051 core or newer RISC-based core. The secure element will also contain dedicated crypto co-processors for performing asymmetric or symmetric cryptographic operations (i.e., FameX). Custom firmware runs on the CLF, and it can usually be updated via the host operating system over UART. 80C51 firmware for the CLF is usually C code (more on this later). A trusted OS (e.g., JCOP) and trusted applications (applets) run on the secure element. Lastly, if the CLF and secure element are contained within a single IC soldered onto the PCB, they are usually connected via S2C (NFC-WI) internally. As a side note, ARM designs and manufactures ARM Keil development boards. Arm Keil and Ashling are two of the most prevalent companies that sell compilers and development toolkits for embedded microprocessors such as the 80C51. Ashling sells an excellent series of in-circuit emulators (ICE) for debugging SmartMX and SmartMX2 microcontrollers.Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-23869242784574575302014-12-08T22:26:00.006-06:002023-03-25T21:41:17.351-05:00The ARM Cortex-A9 Processor - Real World Uses The ARM Cortex-A processor is commonly used in compute-intensive applications. These processors are capable of running full or rich operating systems such as Linux or UNIX. In the previous blog post, I mentioned the ARM Cortex-A9 based MPCore. The ARM Cortex-A9 processor is highly configurable and is implemented by Freescale Semiconductor in their i.MX 6 processor. The i.MX 6 processor is available in a variety of configurations, including lite, single, dual, dual-lite, and quad-core, and is used in critical applications across multiple industries, including aerospace, medical, and industrial. i.MX processors can be found in devices such as Medical-CT scanners, ultrasound machines, automotive telematics systems, e-readers, and more. Due to their power efficiency, i.MX 6 processors are also suitable for wearables such as glasses and watches.<br /><br />One example of a device powered by the i.MX 6 is the OrCam, a clip-on wearable designed for users with vision impairments. The OrCam clips onto a pair of eyeglasses and scans the user's field of vision, detecting objects and providing aural feedback via a bone conduction earpiece.<br /><br />Another device that uses the i.MX 6 processor is the Kindle Fire HD 6 tablet. It's worth keeping an eye out for other wearables, watches, and glasses that use the i.MX 6 processor.<br /><br />In terms of development, the i.MX 6 is an ideal choice. Although the manuals and data sheets for the processor are quite lengthy, the one-time programmable memory locations or eFuses on the i.MX 6 are highly configurable. eFuses are standard in higher-end microprocessors and can be read or blown (one-time write to an on-chip memory location) using u-boot or the Freescale manufacturing tool. They can also be pulled via the Linux sysfs interface. Typically, there are over 100 eFuses on higher-end microprocessors, and they store important values such as the MAC address, boot configuration parameters, high-assurance boot (HAB) configuration parameters, and master key. U-boot conveniently supports reading and writing (blowing) the eFuses on many different microprocessors. U-boot is open source and supports one-time programmable memory (eFuses or OTP) on ARM-based processors. The U-Boot bootloader also supports a large number of chipsets, including ARM, AVR32, Blackfin, MicroBlaze, MIPS, PPC, and x86.
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-40823485581631447682014-12-07T21:00:00.009-06:002023-03-25T21:39:45.021-05:00ARM TrustZone technology - from Monitor Mode to Dedicated Security Co-Processing and the Secure Element(s) "A design that places sensitive resources in the Secure world and implements robust software running on the secure processor cores can protect assets against many possible attacks, including those that are normally difficult to secure, such as passwords entered using a keyboard or touch-screen. By separating security-sensitive peripherals through hardware, a designer can limit the number of sub-systems that need to go through security evaluation and therefore save costs when submitting a device for security certification." - ARM.com<br /><br />NOTE: There are variations in how software is implemented in the secure world - from a simple synchronous library of code to a full-blown operating system.<br /><br />The execution of the normal OS and secure OS is interleaved over time via a context-switching mechanism called monitor mode. Monitor mode is responsible for time-slicing the execution of the normal OS and secure OS via context switching the state of each world on the physical processor. Monitor mode is explicitly triggered via a dedicated instruction or special type of exception. The explicit methods by which monitor mode is triggered contrast the typical scheduling algorithms that trigger context switching in modern-day preemptive operating systems.<br /><br />There are varying levels of complexity regarding how the physical hardware in which the secure world runs is designed. These range from both worlds running on the same physical processor core to the secure world running on a completely separate processor core.<br /><br />Another type of physical hardware design entails an additional microprocessor that is separate from the main processor. The secure world software stack (secure OS and secure applications) runs on a dedicated co-processor. This design is not exclusive to a secure OS running on the main ARM processor. The normal OS still runs on the main ARM processor, and a secure OS can still run on the main ARM processor if the main ARM processor has ARM TrustZone technology. A different secure OS and secure application software can run on the dedicated co-processor.<br /><br />Client applications running on a secure OS can communicate with the main ARM processor via a set of APIs and commands. There are certain benefits to the secure OS always running on a dedicated security processor core or co-processor.<br /><br />The operating system that runs on the co-processor can be optimized for just the co-processor. There are many types of dedicated co-processors. The ARM SecurCore microprocessor is one type of dedicated co-processor. ARM SecurCore microprocessors are used in systems that require dedicated processors for security-sensitive applications such as SIM cards, e-Government, Banking, and Identification. Designs that incorporate ARM SecurCore microprocessors can realize multiple key benefits including build performance improvements, energy efficiency, and physical security. Designing and building an operating system for a single chip means that the operating system can be built to use all of the features and only those features that the chip provides.<br /><br />In summary, here are the key points:<br /><ul style="text-align: left;"><li>Operating system software runs on the main ARM processor or application processor. Software applications run on the application processor. ARM processors in ARM-based mobile phones may or may not have TrustZone processor security technology. If the ARM processor has TrustZone processor security technology, then it may or may not be used.</li><li>There are additional processors on mobile phones that act as dedicated security co-processors. These include the secure element on the UICC or SIM card (UICC-based SE) and the secure element that has been soldered on the printed circuit board. The secure element that has been soldered to the printed circuit board is called the embedded SE. The iPhone 6, iPhone 6 Plus, Samsung S5, Galaxy Nexus, Nexus S, Nexus 7, Sony Xperia series, and a host of others contain a secure element soldered onto the printed circuit board. If the phone has a secure element that has been soldered onto the printed circuit board, then it is most likely contained within the packaging of a larger SoC that also contains the Near Field Communication (NFC) Radio-Frequency (RF) controller. Last but not least, it is entirely possible that the phone contains a secure element on the microSD card.</li><li>The embedded SE and UICC-based SE run a trusted OS. Trusted applications run on top of the trusted OS. In contrast to the trusted OS that runs within the secure world on a main ARM processor with ARM TrustZone processor security technology, the trusted OS that runs on the embedded SE and UICC-based SE does not share full hardware peripheral or direct normal world software access on the main application processor.</li><li>The UICC-based SE and embedded SE are protected by cryptographic keys. Client software applications running on the trusted OS in a processor with ARM TrustZone architecture security extensions are also protected by cryptographic keys.</li><li>There are multiple standards bodies that have established APIs, architecture documents, design documents, and so forth for the trusted operating system and trusted applications that run on the UICC-based SE and embedded SE. These entities are also responsible for the hardware interface on the physical secure element.</li></ul>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-88629136754805209872014-12-07T19:28:00.007-06:002023-03-25T21:36:04.505-05:00 ARM TrustZone technology - a Few Good Boards ARM provides the Juno ARM Development Platform, a reference platform for software and hardware developers building systems based on ARM Cortex-A processors. This platform contains a board that houses an ARM Cortex-A57 processor and the ARM Cortex-A53 MPCore processor. Both processors are 64-bit and implement the ARMv8-A instruction set architecture (ISA). Developers can build a board support package for this board using OpenEmbedded/Yocto.<br /><br />The Apple A7 and Apple A8 chips found in the iPhone 5c, iPhone 5s, iPhone 6, and iPhone 6 Plus are based on the ARM Cortex-A53 and the ARM Cortex-A57. Additionally, the Samsung Exynos 5433 Octa SoC contains the ARM Cortex-A57 and the ARM Cortex-A53 MPCore, while the Samsung Galaxy Note 4 has an 8-core Exynos 5433 processor.<br /><br />The Nvidia TK1 development board, which has a quad-core ARM Cortex-A15 processor, is currently available for purchase. However, the latest board from Nvidia, known as "Denver", which is rumored to contain the ARM Cortex-A57 and the ARM Cortex-A53 MPCore, is not yet available for purchase.<br /><br />The Freescale I.MX 6 processor has been widely adopted across various industries for a range of embedded products. Freescale offers the SABRE board for intelligent devices, a development board that features the I.MX 6 Quad-Core ARM Cortex-A9 processor. Boundary Devices also sells their variation of this board with the same ARM Cortex-A9 MPCore. Developers can build a board support package for both the Freescale SABRE board and the Boundary Devices board using OpenEmbedded/Yocto.<br /><br />When working with ARM development boards, it is important to take into account a few critical features. Specifically, e-fuses should not be blown out of the box and should be left open. The fuses can be blown to fit a specific configuration.<div><br />Here is a quick overview of the processors and boards.</div><div><br /><div><table border="1" class="tftable"><tbody><tr><th><div style="text-align: left;">Processor</div></th><th><div style="text-align: left;">Manuf</div></th><th><div style="text-align: left;">ISA</div></th><th><div style="text-align: left;">Dev Board</div></th><th><div style="text-align: left;">TrustZone</div></th></tr><tr><td>ARM Cortex-A57 and ARM Cortex-A53 MPCore</td><td>ARM</td><td>ARMv8-A</td><td><a href="http://arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php">Juno Ref Platform</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A15</td><td>Nvidia</td><td>ARMv7</td><td><a href="https://developer.nvidia.com/jetson-tk1">TK1</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A15</td><td>Samsung</td><td>ARMv7</td><td><a href="http://www.arndaleboard.org/wiki/index.php/Main_Page">Arndale Exynos 5420</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A9 MPCore</td><td>Freescale</td><td>ARMv7</td><td><a href="http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RDIMX6SABREBRD">Freescale SABRE</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A9 MPCore</td><td>Freescale</td><td>ARMv7</td><td><a href="http://boundarydevices.com/product/nitrogen6x-board-imx6-arm-cortex-a9-sbc/">Boundary Devices</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A9 MPCore + Zync 7000 FPGA</td><td>Xilinx</td><td>ARMv7</td><td><a href="http://zedboard.org/product/zedboard">Zed Board</a></td><td>Yes</td></tr><tr><td>ARM Cortex-A9 MPCore + Zync 7000 FPGA</td><td>Xilinx</td><td>ARMv7</td><td><a href="http://digilentinc.com/Products/Detail.cfm?Prod=ZYBO">Digilent <span> </span><span> </span><span> </span><span> </span><span> </span><span></span><span> </span><br /></a></td><td>Yes</td></tr></tbody></table><br />
</div></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-9062343601484072607.post-84199894943826479312014-11-21T23:54:00.001-06:002023-03-25T21:33:07.109-05:00C++ - Generative Programming<p>C++ IOStreams are a powerful mechanism for transforming input into output. Most programmers are at least familiar with C++ IOStreams in the context of reading and writing bytes to a terminal or file.</p><div class="post-body entry-content" id="post-body-3492576831143978460" itemprop="description articleBody" style="-webkit-text-stroke-width: 0px; line-height: 1.4; position: relative; text-decoration-color: initial; text-decoration-style: initial; text-decoration-thickness: initial; width: 656px;">When a file or terminal is opened for reading or writing by a process, the operating system returns a numerical identifier to the process. This numerical identifier is known as a file descriptor. In turn, the file or terminal can be written to by the process via this file descriptor. The read and write system calls, which are implemented as wrappers in libc, are passed this numerical file descriptor.<br /><br />Many layers of abstraction reside on top of the read and write system calls. These layers of abstraction are implemented in both C and C++. Examples of C-based layers of abstraction are fprintf and printf. Internally, these functions call the write system call. An example of a C++-based layer of abstraction is the IOStreams hierarchy. Out of the box, most C++ compiler toolchains provide an implementation of IOStreams. IOStreams are an abstraction on top of the read and write system calls. When data is written to a terminal via an IOStream, the IOStream implementation calls the write system call. Lastly, these layers of abstraction handle things such as buffering and file synchronization.<br /><br />In UNIX, everything is a file. Consequently, network devices, virtual terminals, files, block devices, etc., can all be written to via a numerical file descriptor - this in turn is why UNIX is referred to as having a uniform descriptor space. With this being said, the basic IOStreams and printf abstractions I mentioned above are not designed to be used with network sockets, pipes, and the like. The lower-layer read and write system calls can be used, but there are a number of functions that must be called before writing raw bytes to an open file descriptor that points to a network socket.<br /><br />The additional functionality that is needed for communicating with network sockets, shared memory, and the like can be implemented in classes that are derived from the C++ iostream class. It is for this reason that the IOStreams classes are extended via inheritance.<br /><br />Over the years, several popular C++ libraries have implemented classes that are derived from the base classes in the iostreams hierarchy. The C++ Boost library is a popular example. However, this has not always been the case. Going back to 1999, the Boost library did not exist, and there were one or two examples on the entire Internet as to how to properly extend the C++ IOStreams classes.<br /><br />In 1999, the source code for the GNU compiler toolchain that is available on gcc.gnu.org was obtained, and a class hierarchy was derived to support sockets, pipes, and shared memory. The methods in the classes derived from the base classes in the iostreams library were designed to be reentrant and easy to use. Generative programming techniques and template metaprogramming were used to create objects that could be instantiated using familiar C++ iostreams syntax and semantics. The library created was called mls, and it was licensed under version 2 of the GPL.<br /><br />Since 1999, Boost has come a long way. It provides support for cryptographic IOStreams, sockets, and all kinds of other fancy stuff. It uses generative programming techniques.The GCC compiler toolchain can be obtained from gcc.gnu.org. Ctags can then be used to dig into the internals of the IOStreams hierarchy. The following book is recommended: Generative Programming - Methods, Tools, and Applications.<br /><br />The gcc compiler toolchain can be obained from gcc.gnu.org. Ctags can then be used to dig into the internals of the iostreams hierarchy.. The following book is recommended.<br /><a href="https://www.amazon.com/Generative-Programming-Methods-Tools-Applications/dp/0201309777">Generative Programming - Methods, Tools, and Applications</a></div><div class="post-body entry-content" id="post-body-3492576831143978460" itemprop="description articleBody" style="-webkit-text-stroke-width: 0px; line-height: 1.4; position: relative; text-decoration-color: initial; text-decoration-style: initial; text-decoration-thickness: initial; width: 656px;"><br /></div><div class="post-body entry-content" id="post-body-3492576831143978460" itemprop="description articleBody" style="-webkit-text-stroke-width: 0px; line-height: 1.4; position: relative; text-decoration-color: initial; text-decoration-style: initial; text-decoration-thickness: initial; width: 656px;">namespace mls <br />{<br /> template<class BufType, int direction, class BaseType=mlbuf> class mlstreamimpl;<br /> template<class Parent, class BaseType=mlbuf> class mloutputimpl;<br /> template<class Parent, class BaseType=mlbuf> class mlinputimpl;<br /> template<class BufType, int direction, class BaseType=BufType><br /> struct StreamConfig;<br /> template<class BufType, int direction, class BaseType><br /> struct StreamConfig<br /> {<br /> typedef typename SWITCH<(direction),<br /> CASE<0,mlinputimpl<mlstreamimpl<BufType, direction, BaseType>, BufType>,<br /> CASE<1,mloutputimpl<mlstreamimpl<BufType, direction, BaseType>, BufType>,<br /> CASE<10,mlinputimpl<mloutputimpl<mlstreamimpl<BufType, direction, BaseType>, <br /> BufType>, BufType >,<br /> CASE<DEFAULT,mlinputimpl<mlstreamimpl<BufType, 10, BaseType>, <br /> BufType > > > > > >::RET Base;<br /> };<br />}</div>Unknownnoreply@blogger.com0