QorIQ Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

QorIQ Knowledge Base

Labels

Knowledge Base Articles

The Precision Time Protocol (PTP) is a protocol used to synchronize clock throughout a computer network. PTP was originally defined in IEEE1588-2002 standard. To use PTP functionality in DPDK, users can use DPDK example application “ptpclient” present in DPDK source code, ptpclient application uses DPDK IEEE1588 API to communicate with a PTP master clock to synchronize the time on NIC and, optionally, on the Linux system. IEEE1588 Introduction Compile the Application Running the Application Code Explanation
View full article
1. Different connecting for USB Super-Speed signals. 2. Pin MUX configuration for USB1(USB 3.0) 3. Linux Kernel configuration 4. Device Tree updating 5. Verify on the target board.
View full article
This document introduce OpenIL Baremetal framework architecture using NXP Layerscape platforms, describes how to run a sample baremetal project and inter-core Communication application development based on OpenIL Baremetal framework. Inter-core communication(ICC) application works on Linux core(master) and Baremetal core(slave), provides the data transfer between cores via SGI inter-core interrupt and share memory blocks. Baremetal Framework architecture for QorIQ Layerscape platforms. Running Baremetal Binary Inter-core communication(ICC) application Development Based on Baremetal Framework Running ICC demo application
View full article
This document introduces how to implement Ethernet flow control in DPDK by setting BMAN hardware and software portal depletion entry and exit thresholds. Hardware and Software Portal Depletion Threshold Registers   BMAN Pool hardware Threshold configuration in DPDK.   Pause Quanta Configuration in DPDK Flow control configuration Implementation in DPDK  
View full article
ARM Cortex A57 and A53 L1/L2 cache error reporting The attached patch adds error detection for A53 and A57 cores. Hardware error injection is supported on A53. Software error injection is supported on both. For hardware error injection on A53 to work, proper access to L2ACTLR_EL1, CPUACTLR_EL1 needs to be granted by EL3 firmware. This is done by making an SMC call in the driver. Failure to enable access disables hardware error injection. For error interrupt to work, another SMC call enables access to L2ECTLR_EL1. Failure to enable access disables interrupt for error reporting.   CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be used for checking L1 and L2 memory errors. However, only A53 supports double-bit error injection to L1 and L2 memory. This driver uses the hardware error injection when available, but also provides a way to inject errors by software. Both A53 and A57 supports interrupt when multi-bit errors happen.   To use hardware error injection and the interrupt, proper access needs to be granted in ACTLR_EL3 (and/or ACTLR_EL2) register by EL3 firmware SMC call. Correctable errors do not trigger such interrupt. This driver uses dynamic polling internal to check for errors. The more errors detected, the more frequently it polls. Combining with interrupt, this driver can detect correctable and uncorrectable errors. However, if the uncorrectable errors cause system abort exception, this driver is not able to report errors in time.     Building PPA Image Please make sure the PPA source which you are using includes commit 781d7b513c2b44e7, PPA source code in LSDK later than1809, which includes this commit, so you could use PPA image provided in LSDK 1809 or the later release. In addition, You need to enable "dbg" when building PPA. If you use LSDK build environment, please add "dbg" in ppa build command in packages/firmware/Makefile as the following, then rebuild ppa with command "$ flex-builder -c ppa -m ls1043ardb" and get ppa image in build/firmware/ppa/soc-ls1043/ppa.itb. socname=`echo $(MACHINE)|tr -cd [:digit:]` && \ ./build rdb-fit dbg ls$$socname && cp soc-ls$$socname/build/obj/ppa.itb $(FBDIR)/build/firmware/ppa/soc-ls$$socname && \ If you want build PPA manually with the standalone Toolchain, you could build PPA image with the command "./build prod rdb-fit dbg ls1043". Please deploy PPA image at 0x60400000 on NOR flash(the current bank).   L1/L2 cache error detection and correction EDAC feature verification   NXP LSDK 19.03 devel localhost login: root Password: Last login: Fri May 17 00:11:26 UTC 2019 on ttyS0 Welcome to NXP LSDK 19.03 devel (GNU/Linux 4.14.16-dirty aarch64)    * Support:        https://www.nxp.com/lsdk  * Documentation:  https://lsdk.github.io setting 31 rows and 111 columns root@localhost:~# ls /sys/devices/system/edac/cpu_cache/ cpu_cache0  l1_ce_sw_inject  l1_ue_sw_inject  l2_ue_hw_inject  log_ce  panic_on_ue device      l1_ue_hw_inject  l2_ce_sw_inject  l2_ue_sw_inject  log_ue  poll_msec   root@localhost:~#  echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [   74.831916] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [   74.831916] ' echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject^C root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject [   80.192338] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [   80.192338] ' root@localhost:~# root@localhost:~# root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [  109.647966] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  109.647966] ' [  109.659012] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  109.659012] '   root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_sw_inject root@localhost:~# [  136.271980] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  136.271980] ' [  136.283027] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  136.283027] '   root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l1_ue_hw_inject [  157.352298] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 2 [  157.352298] ' root@localhost:~# echo 1 > /sys/devices/system/edac/cpu_cache/l2_ue_sw_inject root@localhost:~# [  183.375947] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  183.375947] '   root@localhost:~#  echo 1 > /sys/devices/system/edac/cpu_cache/l2_ue_hw_inject [  186.928679] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  186.928679] ' root@localhost:~# [  191.055944] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  191.055944] '   root@localhost:~# dmesg | grep EDAC [    1.819380] EDAC MC: Ver: 3.0.0 [    3.423554] EDAC DEVICE0: Giving out device to module edac-a53 controller cortex_edac_l1_l2: DEV edac-a53 (POLLED) [   74.831898] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [   74.831910] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [   74.831916] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [   80.192307] EDAC cortex_edac_l1_l2: CPU 1 L1-D Data RAM error(s) detected [   80.192326] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000089000002) [   80.192338] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  109.647919] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [  109.647938] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [  109.647942] EDAC cortex_edac_l1_l2: CPU 1 L1-I Tag RAM error(s) detected [  109.647955] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000080000000) [  109.647966] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  109.659012] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  136.271933] EDAC cortex_edac_l1_l2: CPU 0 L1-I Tag RAM error(s) detected [  136.271951] EDAC cortex_edac_l1_l2: CPU 0 L1 fatal error(s) detected (0x8000000080000000) [  136.271956] EDAC cortex_edac_l1_l2: CPU 1 L1-I Tag RAM error(s) detected [  136.271969] EDAC cortex_edac_l1_l2: CPU 1 L1 fatal error(s) detected (0x8000000080000000) [  136.271980] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 0 [  136.283027] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 1 [  157.352268] EDAC cortex_edac_l1_l2: CPU 2 L1-D Data RAM error(s) detected [  157.352287] EDAC cortex_edac_l1_l2: CPU 2 L1 fatal error(s) detected (0x8000000089180002) [  157.352298] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L1 'Fatal error(s) on CPU 2 [  183.375931] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x8000000080000000) [  183.375947] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  186.928662] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x80000000910c4058) [  186.928679] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 [  191.055928] EDAC cortex_edac_l1_l2: CPU 0 L2 fatal error(s) detected (0x80000000910d0868) [  191.055944] EDAC DEVICE0: UE: cortex_edac_l1_l2 instance: cpu_cache0 block: L2 'Fatal error(s) on CPU 0 root@localhost:~#
View full article
Time Sensitive Networking(TSN) is an extension to traditional Ethernet networks, providing a set of standards compatible with IEEE 802.1 and 802.3. TSN aims to provide guarantees for deterministic latency and packet loss under congestion, allowing critical and non-critical traffic to be converged in the same network. This document introduces basic concept of Time Sensitive Networking, LS1028 TSN switch and using TSN features on LS1028ARDB. TSN Introduction TSN in LS1028 Using TSN features on LS1028ARDB
View full article
This document describes how to setup the LS1046A RDB as a PCIe End Point(EP) to be link trained and enumerated by the host system. The LS1046A RDB in this scenario is essentially being used to emulate a PCIe Add-in Card in PCIe-EP mode. LS1046ARDB Modifications for PCIe-EP Environment setting up MSI interrupt testing
View full article
SPDK (Storage Performance Development Kit) is an optimized storage reference architecture. It is initiated and developed by Intel. SPDK provides a set of tools and libraries for writing high performance, scalable, user-mode storage applications. It achieves high performance by moving all of the necessary drivers into userspace and operating in a polled mode, like DPDK.
View full article
DPDMUX is a device like DPSW (Switch) which allows switching of packets within the DPAA2 blocks. This application adds DPDMUX support in DPDK, uses LS2088ARDB as an example platform for demonstrating the use case that traffic bifurcation between DPDK and Linux Kernel using DPDMUX on DPAA2 platform.
View full article
DPDK is a user space packet processing framework. OVS-DPDK is a popular software switching package which uses DPDK as the underlying platform. 1. LSDK 1809 Images Deployment 2. Ovs-dpdk Basic Switching 3. Ovs-dpdk MPLS (MultiProtocol Label) Pop_mpls Example 4. DPDK PACKETGEN
View full article
This document describes rate limiting solution implementation with QoS features of SJA1105 switch to handle the congestion of competing traffic flows, including the software architecture on TSN platforms, ingress traffic policer, prioritizing configuration, Time-Aware Scheduler in 802.1Qbv engine through SJA1105 switch and using IEEE 1588(Precision Time Protocol) to synchronize the SJA1105 PTP clocks.       Software Solution Architecture on TSN Platform        Ingress Traffic Policer        Prioritizing Configuration        Time-Aware Scheduler         Using IEEE 1588 to Synchronize the SJA1105 PTP Clocks
View full article
Secure edge computing solution is required in secure manufacturing, secure Enrollment, secure device monitoring, secure container and application deployment. This documents introduces trust architecture on Layerscape platform, trust software solution and user application development with OpenSSL Engine to offload encrypt/decrypt on hardware secure module.
View full article
Trusted Execution Environment(TEE) is for ARM-based chips supporting TrustZone technology. NXP released LSDK integrates Open Portable TEE(OP-TEE), which is an open source project which contains a full implementation to make up a complete Trusted Execution Environment. This document will introduce OP-TEE architecture, OP-TEE OS loading and initialization, TA and CA communication in OPTEE runtime workflow, how to develop OP-TEE Trusted Application in LSDK environment.
View full article
This session will take an in-depth look at QorIQ Data Path Acceleration Architecture (DPAA) and how each component interact with each other and the e500mc core. Discussion will include FMAN, QMAN, BMAN, SEC4, PME, SRIO manager and RAID Engine.
View full article
The T1023WALN board supports AQR105 only. Adding this patch file for AQR106 support.
View full article
Sometimes you encoutner thisSD/eMMC issue ," Card did notrespond to voltage select! ". You could add debug message to see the communication between SD/eMMC and host. #define  DEBUG #define CONFIG_MMC_TRACE  & add debug message in mmc.c (driver/mmc) int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) { .. printf("CMD_SEND:%d\n",cmd->cmdidx); printf("\t\tARG\t\t\t0x%08X\n", cmd->cmdarg); .. } => mmcinfo CMD_SEND:0                ARG                     0x00000000              MMC_RSP_NONE CMD_SEND:8 ARG                     0x000001AA            MMC_RSP_R1,5,6,7        0x00000001 CMD_SEND:55 ARG                     0x00000000 MMC_RSP_R1,5,6,7         0x00000001 CMD_SEND:0 ARG                     0x00000000 MMC_RSP_NONE
View full article
NXP T1040 and T1020 SoC have an 8-port gigabit Ethernet switch integrated on the device. QorIQ SDK includes an L2 Switch user space driver and a small demo application that uses the API provided by the switch driver. The L2Switch demo application is useful to configure switch in T1040. Attached document include steps modify the source code and add command to access switch registers, read or write, in SDK1.9. Before doing this, SDK1.9 needs to be installed and useable.  In the SDK manual, there are description about how to install the SDK, how to prepare host environment and how to setup poky for specific target.
View full article
For QorIQ Processors you could find documents from official website: Submit Form And below document list in this place: SDK/DPAA/Networking: Using QMAN Dedicated and Pool Channels in USDPAA and Linux Kernel LS2085 NADK Based IPSEC Application Communicating with AIOP DPAA Ethernet Interfaces Shared-MAC between two Linux Partitions under Hypervisor(Topaz) IPv6+AES.docx T1040 L2Switch Software Support IPSec demo on T1040RDB hv.dts IPSec on Freescale Hypervisor (Topaz) and T1040 (T1042) Rate limiting in DPAA QorIQ QMan CEETM Implementation in USDPAA Read T2080 XFI link status Shared-MAC and MAC-less Implementation in DPAA Linux Kernel Driver P2020RDB IPV4 forwarding performance test.pdf Set up NAT on QorIQ RDB Set up VLAN on QorIQ RDB SDK/Virtualization: FTF-DES-F1254_QorIQ Device Virtualization.pdf Virtualization Solutions in Freescale Linux SDK(1)– Hypervisor(topaz) Tools/Build/Debug: FTF-DES-F1321-QorIQ-Debug.pptx AMF-DES-T1053 - Open Source Tools Development Tools for ARM® Architectures .pptx AMF-DES-T1052 - QorIQ DevTools for Layerscape Family Products Applications.pptx AMF-SNT-T1045-Freeescale-Solutions-targeting-SDN-NFV-markets-with-ARM64-processors.pptx Modify T2080 rev1.1 MEM_PLL_RAT w/ using QCVS4.1.1 Using external GNU toolchain with CodeWarrior for QorIQ LS series – ARMv7 ISA QorIQ SDK build for T4240QDS - Beginner's guide Introducing the Scenarios Tool QorIQ Linux SDK 1.6 Working With Yocto T4240QDS_Altivec_example_with_MEPL.zip Building uboot/kernel/test-application out of Yocto Changing RootFS in SDK 1.3.2 Adding a new Flash Device to Codewarrior 10.x Building SDK 1.3.2 Boot/Board: LS2085 u-boot Workflow T2080PCIeRDB_SPI_reboot failure.pdf How to Flash/Reflash U-Boot and Linux to a Freescale Digital Networking Board System Boot from SD/MMC Card with SDK 1.6 images Secure boot for Non-PBL Platform Booting from QSPI on LS102xA Firmware update for LS1-TWR Switches on PSC9131RDB Re-flashing the P3041DS Deploying SDK 1.3.2 Solutions: AMF-SNT-T1045-Freeescale-Solutions-targeting-SDN-NFV-markets-with-ARM64-processors.pptx NEXCOM Introduces Appliance Based on Freescale QorIQ T4240 SoC and Aims for Gbps UTM Throughput Others: T4240QDS_Altivec_example_with_MEPL.zip A quick demo setup to toggle hue bulb using LS1021A IoT host processor and MKW20 zigbee QorIQ_Linux_kernel_GPIO_enable.pdf Announcements I2C NCSW Use Case FTF-DES-F1253 Lunch and Learn: Expedite Your Product Development with Linux SDK Backport Technolog Processors/Cores: L1 D-Cache Flushing Using CPC as SRAM
View full article
Recently I was handling a problem of E500 Data Cache flush. I have a study on this. Below is a summary/record of the study, here to post it for someone who may be interested in. 1. L1 D-Cache Flushing About Data Cache flush, there’s some description in E500 reference manual as below: Any modified entries in the data cache can be copied back to memory (flushed) by using a dcbf instruction or by executing a series of 12 uniquely addressed load or dcbz instructions to each of the 128 sets. The address space should not be shared with any other process to prevent snoop hit invalidations during the flushing routine. Exceptions should be disabled during this time so that the PLRU algorithm is not disturbed. The following methods can be used to flush a region in the L1 cache: • Perform reads to any 48-Kbyte region, then execute dcbf instructions to that region. Note that a 48-Kbyte region must be used to ensure that the PLRU algorithm flushes all of the cache entries (12 x 128 sets x 32 bits = 48 Kbytes). • Perform reads from any 48-Kbyte region that is guaranteed to not be modified in the L1 cache (for example, a ROM region). • Execute dcbz instructions to any 48-Kbyte scratch section, then invalidate the cache. Note that it is necessary to use a scratch region because some zeroed lines will be cast out. … On the e500v2 the HID0 register contains a field, DCFA (data cache flush assist), that, when set, forces the data cache to ignore invalid sets on miss replacement selection and follow the replacement sequence defined by the PLRU bits. This reduces the series of uniquely addressed load or dcbz instructions to eight per set. The bit should be set just before beginning a cache flush routine and should be cleared when the series of instructions is complete. 2. The Questions As the Data Cache size is 32 Kbytes, why 48 Kbytes region needs to be performed on? The manual uses an equation “12 x 128 sets x 32 bytes = 48 Kbytes” (here I assume it should be 32 bytes instead of 32 bits), it says a series of 12 uniquely addressed load to each of the 128 sets, but there is no explanation why it’s 12, and why uniquely? And more, it mentions the HID0 register filed DCFA. It says setting this field reduces the series of uniquely addressed load to eight per set. Why? This time there are more words “forces the data cache to ignore invalid sets on miss replacement selection and follow the replacement sequence defined by the PLRU bits”, how to understand? 3. Data Cache Basics To answer the questions above, we need to focus on the miss replacement selection algorithm as it refers to. But before this we should be clear about the Data Cache organization first, and know the “invalid sets” status. The E500 reference manual use below figure to describe the L1 D-Cache organization From this figure, we get 128 sets, 8 ways per set, and 32 bytes per way, which is 128 x 8 x 32 = 32 Kbytes. Here a block, also called a line/way, contains 8 words, or 32 bytes. Where a piece of data in memory should be placed into D-Cache? In other words what’s the mapping method between memory and the Cache? Each block is loaded from 8-words boundary, i.e. physical address bits PA[27:31] are zeros. Byte within a block is located by PA[27:31]. The set is selected by physical address bits PA[20:26], totally 2 7 =128, there is one set for each PA[20:26], or we say it’s one to one mapping. The tags consist of physical address bit PA[0:19], there are totally 2 20 kinds of tags but there are only 8 ways in each set, it’s one to multiple mapping. So we need replacement algorithm, in e500 the PLRU (pseudo-least-recently-used) replacement algorithm is used. 4. Miss Replacement In the reference manual it says “This algorithm prioritizes the replacement of invalid entries over valid ones (starting with way 0). Otherwise, if all ways are valid, one is selected for replacement according to the PLRU bit encodings shown in Table 11-8 .” This is where the difference happened. Let’s analyze the easy case first, if HID0 register filed DCFA is set, all the ways are treated the same, valid or invalid will be ignored, only PLRU take effect. Assume PLRU bits are all zeros, below table shows the order ways be selected: B0 B1 B2 B3 B4 B5 B6 Ways selected 0 0 0 0 0 0 0 L0 1 1 1 0 0 0 0 L4 0 1 1 0 0 1 0 L2 1 0 1 0 1 1 0 L6 0 0 0 0 1 1 1 L1 1 1 0 0 1 1 1 L5 0 1 1 0 1 0 1 L3 1 0 1 0 0 0 1 L7 After 8 replacements, all the 8 ways are selected. Change PLRU bits to other values it’s still 8 replacements, that’s way it reduce 12 uniquely addressed load to 8. Then why it’s 12 if DCFA field is not set? Assume way 0,1,2,3 are invalid and way 4,5,6,7 are valid, and PLRU bits are all zeros, we have again the table as below: B0 B1 B2 B3 B4 B5 B6 Ways selected 0 0 0 0 0 0 0 L0 1 1 0 1 0 0 0 L1 1 1 0 0 0 0 0 L2 1 0 0 0 1 0 0 L3 1 0 0 0 0 0 0 L4 0 0 1 0 0 1 0 L0 1 1 1 1 0 1 0 L6 0 1 0 1 0 1 1 L2 1 0 0 1 1 1 1 L5 0 0 1 1 1 0 1 L1 1 1 1 0 1 0 1 L7 After 11 replacements, all the 8 ways are selected. Assume way 0,1,2,3,6,7 are invalid and way 4,5 are valid, and PLRU B5 is zero, we have again the table as below: B0 B1 B2 B3 B4 B5 B6 Ways selected - - - - - 0 - L0 1 1 - 1 - 0 - L1 1 1 - 0 - 0 - L2 1 0 - 0 1 0 - L3 1 0 - 0 0 0 - L6 0 0 0 0 0 0 1 L7 0 0 0 0 0 0 0 L0 1 1 1 0 0 0 0 L4 0 1 1 0 0 1 0 L2 1 0 1 0 1 1 0 L6 0 0 0 0 1 1 1 L1 1 1 0 0 1 1 1 L5 After 12 replacements, all the 8 ways are selected. Here 12 is the maximum replacement number, any other case will finish all 8 ways selected within 12 replacements. There are Cache operation code examples in NCSW for e500, including L1 D-Cache flushing, as attached. Also the whole article in attached as individual document.
View full article
        A quick demo setup to toggle hue bulb using LS1021A IoT host processor and MKW20 zigbee. Here we make a lighting  demo through two steps setup. The first step is using TWR-KW20 EVB to control hue bulb through PC tool called test tool.  The next step is moving to LS1021 as host processor instead of PC test tool.  We use KW20 USB dongle, LS1021A and Hue Bulb. KW20 USB dongle is configured as Zigbee Coordinator through Beekit and LS1021A connect this KW20 USB dongle, then LS1021A issue On/Off commands to toggle hue bulb. Then you can make a quick demo using Freescale’s LS1021A and MKW20 series
View full article