i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
Play MPEG4 Video only gst-launch filesrc location=test.mpeg ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink H.264 Video only gst-launch filesrc location=test.avi ! mfw_avidemuxer ! mfw_vpudecoder codec-type=std_avc ! mfw_v4lsink AVI(H264+MP3) gst-launch filesrc location=test.avi ! mfw_avidemuxer name=demux demux. !  mfw_vpudecoder \     codec-type=std_avc ! mfw_v4lsink demux. ! queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink MP4(H264+MP3) gst-launch filesrc location=test.mp4 ! mfw_mp4demuxer name=demux demux. ! \    mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink demux. ! \    queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink <mp3_decoder_plugin> can be replaced by mad RAW Video Test gst-launch videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 !  mfw_v4lsink
View full article
Sorry I can't find a place to share this input file. It is to reproduce the VPU JPEG decoder issue I reported in Corrupted MJPG decoding result with FSL 3.10.17 BSP on i.MX6Q VPU​
View full article
imx7 supports TRULY-WVGA-TFT3P5581E display, the connector is J30, which is a connector on the imx7d board, normally, one can find the part number from BOM file, but imx7 Sabre-SDB board  BOM file missed this information. got connector information from expert team as below: The connector manufacture’s part number is: DF40C-24DS-0.4V(51)   For more detailed information about sabre board information information is available from nxp.com in the Design files for i.MX7Dual   For data sheet of this, which is under NDA, if you need it, pls create a salesforce case to get this, I couldn’t post this on public community.
View full article
The i.MX 8QXP MEK does not allow the OV5640/LVDS/LCD usage only by changing the device tree anymore. It occurs because the M4 owns the i2c resources, so the A core must use rpmsg to enable virtual drivers. Due to this, if the user changes the device tree, for instance, the *ov5640.dtb, the kernel won't boot, entering in the following loop: [    8.603353] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).      [    8.610025] [drm] No driver support for vblank timestamp query.              [    8.616077] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_) [    8.624978] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_op) [    8.632526] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_op) [    8.639833] imx-drm display-subsystem: failed to bind ldb@562210e0 (ops imx_7 [    8.648428] imx-drm display-subsystem: master bind failed: -517 With the approach provided in this post, it is possible to make this change manually, only by changing the flash.bin at U-boot for a non-m4 one. In order to make the changes to the flash.bin file, it’s needed to obtain the following files: - u-boot.bin from internal u-boot provided by NXP. - scfw_tcm.bin from SCFW porting kit - bl31.bin from ARM Trusted Firmware - SECO firmware container image Disclaimer The described procedures in this document target a GNU/Linux (Ubuntu 20.04 LTS) and it’s focused on iMX8QXP B0 + BSP L4.19.35_1.1.0. Required packages 1 - Install ARM64 ToolChain: 1.1 - Install ARM64 GCC and G++ cross-compilers: # apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu 2 - Install ARM32 GCC6 ToolChain: 2.1 - Download the ARM32 6 Toolchain and install it: $ mkdir ~/gcc_toolchain $ cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ $ cd ~/gcc_toolchain/ $ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 # apt-get update # apt-get install srecord 3 - Download MKimage 3.1 - Create a new directory desired to the packages: $ mkdir flash_build $ cp flash_build 3.1 - Clone the MKimage: $ git clone https://source.codeaurora.org/external/imx/imx-mkimage -b imx_4.19.35_1.1.0 4 - U-boot build 4.1 - Clone the U-boot  $ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2019.04_4.19.35_1.1.0 $ cd uboot-imx 4.2 - Export the ARM64 ToolChain:  $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- 4.3 - Build it:  $ unset LDFLAGS $ make -j4 imx8qxp_mek_defconfig $ make 4.4 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp spl/u-boot-spl.bin ../imx-mkimage/iMX8QX/ $ cp u-boot-nodtb.bin ../imx-mkimage/iMX8QX/ $ cd ..   5 - ARM Trusted Firmware 5.1 - Clone the imx-atf:  $ git clone https://source.codeaurora.org/external/imx/imx-atf -b imx_4.19.35_1.1.0 $ cd imx-atf 5.2 - Build it:  $ unset LDFLAGS $ make PLAT=imx8qx bl31 5.3 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp build/imx8qx/release/bl31.bin ../imx-mkimage/iMX8QX/ $ cd ..   6 - SCFW 6.1 - Export the ARM32 GCC6 Toolchain:  $ export TOOLS=~/gcc_toolchain/ 6.2 - Download the BSP L4.19.35_1.1.0_SCFW and copy it to the flash_build directory:  $ cp ~/Downloads/imx-scfw-porting-kit-1.2.7.1.tar.gz $ tar xvzf imx-scfw-porting-kit-1.2.7.1.tar.gz $ cd packages/ $ chmod a+x imx-scfw-porting-kit-1.2.7.1.tar.gz $ ./imx-scfw-porting-kit-1.2.7.1.bin 6.3 - Build it to i.MX 8QXP MEK B0:  $ cd imx-scfw-porting-kit-1.2.7.1/src/ $ tar xvzf scfw_export_mx8qx_b0.tar.gz $ cd scfw_export_mx8qx_b0/ $ make qx R=B0 B=mek 6.4 - Copy the binary file to the MKimage/iMX8QX directory:  $ cp build_mx8qx_b0/scfw_tcm.bin ../../../../imx-mkimage/iMX8QX/ $ cp ../../../../ 7 - SECO Firmware Container Image 7.1 - Download the SECO firmware binaries and copy it to the flash_build directory $ cp ~/Downloads/firmware-imx-7.9.bin . $ chmod a+x firmware-imx-7.9.bin 7.2 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp firmware-imx-7.9/firmware/seco/mx8qx-ahab-container.img /imx-mkimage/iMX8QX/ 8 - Build flash.bin 8.1 - In a new terminal, open the imx-mkimage directory: $ cd flash_build/imx-mkimage 8.2 - Build it:  $ make SOC=iMX8QX flash 8.3 - Deploy it to the SDCard:  $ sudo dd if=iMX8QX/flash.bin of=/dev/sdX bs=1k seek=32 && sync Now, you are able to use any non-rpmsg.dtb without kernel errors. Author: Pedro Jardim: [email protected]
View full article
U-boot expects uImage format for the kernel image. In order to LTIB generate a uImage file: $ export SYSCFG_KTARG=uImage $ ./ltib -p kernel Setup in U-Boot the kernel bootargs: u-boot> setenv bootargs noinitrd console=ttymxc0,115200 init=/linuxrc root=/dev/nfs nfsroot=10.29.244.27:/tftpboot/rootfs ip=dhcp Change 10.29.244.27 to your host IP. The procedure above is needed when default bootloader used by ltib was redboot. In some ltib releases (before 2010) default bootloader is u-boot. In this case, ltib will create uImage by default
View full article
Overview AVB/TSN Wikipedia: Audio Video Bridging (AVB) is a common name for the set of technical standards which provide improved synchronization, low-latency, and reliability for switched Ethernet networks. AVB was initially developed by the Institute of Electrical and Electronics Engineers (IEEE) Audio Video Bridging task group of the IEEE 802.1 standards committee. In November 2012, Audio Video Bridging task group was renamed to Time-Sensitive Networking (TSN) task group to reflect the expanded scope of its work, which is to "provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks". Further standardization efforts are ongoing in IEEE 802.1 TSN task group.   AVB and TSN technologies and standards: Standard Area of Definition Title of Standard AVB/TSN IEEE 802.1AS Timing and synchronization Timing and Synchronization for Time-Sensitive Applications (gPTP) AVB TSN IEEE 802.1Qav Forwarding and queuing Forwarding and Queuing for Time-Sensitive Streams (FQTSS) AVB IEEE 802.1Qat Path control and reservation Stream Reservation Protocol (SRP) AVB IEEE 802.1BA Bridging Audio Video Bridging (AVB) Systems AVB IEEE 1722 AVTP AV transport Layer 2 Transport Protocol for Time Sensitive Applications AVB IEEE 1722 AVDECC Device manage and control Device Discovery, Enumeration, Connection Management and Control Protocol AVB IEEE 802.1Qbu and IEEE 802.3br Forwarding and queuing Frame preemption TSN IEEE 802.1Qbv Forwarding and queuing Enhancements for scheduled traffic TSN IEEE 802.1Qca Path control and reservation Path control and reservation TSN IEEE 802.1Qcc Central configuration method Enhancements and performance improvements TSN IEEE 802.1Qci Time-based ingress policing Per-stream filtering and policing TSN IEEE 802.1CB Seamless redundancy Frame replication and elimination for reliability TSN   Since many of the standards are only for TSN switch/bridges and i.MX8MP is design to be a TSN/AVB endpoint, this demo does not implement a full stack or full standards. It only demonstrates the basic end-to-end point (talker to listener) A/V streaming without bridge or switch.   Below table shows what this demo supports: Standard Software Hardware IEEE 802.1AS Linuxptp ENET_QoS IP IEEE 802.1Qav/Qbu/Qbv TC qdisc (taprio, mqprio, etf, cbs) ENET_QoS IP (multi queue + EST, FPE, CBS) IEEE 1722 AVTP Libavtp N/A   Demo introduction Two i.MX8MP EVK boards are used for this demo, one act as a AVB talker to send A/V streams, the other one act as a AVB listener to receive A/V streams who can be playback to audio codec and sink video to screen. The two boards are connected by a RJ45 ethernet cable on each ENET2 port (only ENET2 port has TSN features). Three streams’ type and SR (Stream Reservation) class are defined as below to grantee time sensitive (sub-microsecond synchronization), low latency and bandwidth on the ethernet: Stream A: SR class A, AVTP Compressed Video Format, H.264 profile High, 1920x1080, 30 fps. Stream B: SR class B, AVTP Audio Format, PCM 16-bit sample, 48 kHz, stereo, 12 frames per AVTPDU. Other stream: Best-effort streams These three TSN streams would be allocated into different traffic control (TC) class for egress in Linux. Different TC class would be mapped to different hardware queues with dedicated DMA channel, thanks to the multi-queue support by ENET_QoS IP. Then the traffic control apply different scheduling policy on each queues for different types of streams egress, to make sure highest priority or critical packet can be sent in the correct time slot. The TSN streams are transmitted over Virtual LANs (VLANs). Bridges use the VLAN priority information (PCP) to identify Stream Reservation (SR) traffic classes which are handled according to the Forward and Queuing Enhancements for Time-Sensitive Streams (FQTSS) mechanisms described in Chapter 34 of the IEEE 802.1Q standard.   The demo is built up by following blocks: Linux TC (traffic control): streams egress control to meet AVB/TSN requirements, which take advantage of the i.MX8MP TSN ENET IP. Linux PTP: clock sync in network, which take advantage of the i.MX8MP TSN ENET IP. Libavtp: Time Sensitive Applications AV Transport protocol. ALSA: AVTP audio format plugin uses the libavtp to transmit and receive AVTP audio PCM streams. Gstreamer: avtp plugin uses the libavtp to transmit and receive AVTP audio/video streams (video should be encoded as H264, audio PCM). x264enc and libav is a software H.264 video encoder/decoder, which alternative to the on chip VPU acceleration plugin, due to the VPU plugin is not supported in the latest Gstreamer version (1.17.x).     Traffic control This demo can use two different traffic control qdisc settings: mqprio + cbs: use CBS features taprio + pfifo: use EST and FPE features (802.1Qbu/bv). The pfifo is the default traffic control class, which use FIFO schedule policy for egress packets. The CBS class is actually handled by hardware IP to select which queue for transmit in a certain time slot.   Credit Base Shaper (CBS) CBS parameters come straight from the IEEE 802.1Q-2018 specification. They are the following: idleSlope: rate credits are accumulated when queue isn’t transmitting; sendSlope: rate credits are spent when queue is transmitting; hiCredit: maximum amount of credits the queue is allowed to have; loCredit: minimum amount of credits the queue is allowed to have;     Enhancements to Scheduled Traffic (EST) The IEEE 802.1Qbv defines the schedule for each of the queues on every egress port which makes the implementation aware of traffic arrival schedule. This information can be used to block the lower priority traffic from transmission in this time window/slot. This ensures that scheduled traffic is forwarded from sender to receiver through all the network nodes with a deterministic delay. The i.MX8MP uses the gate control list with configurable time slot and frame preempt (IEEE 802.1Qbu) features to support EST. Other than the CBS, the gate control list control the egress transmission by a fixed open interval for that queue.   Build demo Build L5.4.24_2.1.0 $MACHINE=imx8mpevk DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b build-8mp $bitbake  fsl-image-validation-imx Prepare a SD card and burn it with the built out images. To add tc/tcpdump command in iproute2 package, please add package into IMAGE_INSTALL_append variable into conf/local.conf: IMAGE_INSTALL_append = " iproute2 iproute2-tc tcpdump Rebuild kernel Rebuild the kernel after applying the 0001-qenet-add-queue-avoid-panic.patch (attached), and overwrite the Image and imx8mp-evk.dtb on the boot partition of the SD card.   Install the toolchain $bitbake -f fsl-image-validation-imx -c populate_sdk $sh tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-fsl-image-validation-imx-aarch64-imx8mpevk-toolchain-5.4-zeus.sh The toolchain would be installed into /opt/fsl-imx-xwayland/5.4-zeus/   Create a install folder $mkdir <your install folder> Create a folder to install all of the shared libraries, binaries and configure files which built out manually in this doc. After built done, you should copy all of the contents in this folder to target board root.   Build libavtp $source /opt/fsl-imx-xwayland/5.4-zeus/environment-setup-aarch64-poky-linux $git clone https://github.com/Avnu/libavtp.git $cd libavtp $meson build $ninja -C build Copy the built out .so and .pc into the toolchain rootfs: $sudo cp build/libavtp.so* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/ $sudo cp build/meson-private/*.pc /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/pkgconfig/ To make sure you have avtp package installed correctly: $pkg-config --list-all | grep avtp Copy the .so into the install folder: $cp build/libavtp.so* <install folder>/usr/lib/ Copy header files: $cp libavtp/include/* files <toolchain_path>/sysroots/aarch64-poky-linux/usr/lib Build ALSA aaf plugin The AAF (ALSA AVTP Audio Format) plugin is a PCM plugin that uses Audio Video Transport Protocol (AVTP) to transmit/receive audio samples through a Time-Sensitive Network (TSN) capable network. The plugin enables media applications to easily implement AVTP Talker and Listener functionalities.   $cd <yocto build>/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/alsa-plugins-1.1.9 $./configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=<your install folder>/usr --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/opt/samba/nxa23059/jailhouse/yocto-5.x/build-8mp/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/recipe-sysroot  --disable-static  --enable-aaf --disable-jack --disable-libav --disable-maemo-plugin --disable-maemo-resource-manager --enable-pulseaudio --enable-samplerate --with-speex=lib $make $make install   Build Gstreamer AVTP plugins Build Gstreamer 1.17.x (commit e4f7cdb0df7b) $git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git $cd gstreamer $patch -p1 < gstreamer-1.0-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install After Gstreamer is installed into <your install folder>, please fix the “prefix” path in the .pc files by, and copy to the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build gst-plugins-base (commit 22827e8f) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-base.git $cd gst-plugins-base $patch -p1 < gst-plugins-base-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install   Build gst-plugins-bad (commit ed14e0d5a) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad.git $cd gst-plugins-bad $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met gdbus-codegen issue, please remove the “--c-generate-autocleanup” and “--output-directory” parameters in the build/build.ninja If you met issue of include file like: “…/gst/gl/gstglapi.h:24:10: fatal error: gst/gl/gstglconfig.h: No such file or directory.” Please modify the build/build.ninja to correct the -I header file parameter of the build. After gst-plugins-base and gst-plugins-bad installed into <your install folder>, please fix the “prefix” path in the .pc files and copy them into the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build H.264 SW plugins AVTPDU uses H.264 as payload for streaming, this requires H.264 encoder/decoder plugins, either software or hardware accelerations. Since we upgrade the Gstreamer and its plugins to a new version, the VPU plugins cannot be used anymore. So software H.264 plugins are required: x264 for encoder, libav for decoder.   Build x264 As the yocto actually has the x264 recipes, but not included in our bblayers, we need to copy the x264 source into our bblayers path under <yocto>/source to build: $cp -rf ./poky/meta/recipes-multimedia/x264 ./meta-openembedded/meta-multimedia/recipes-multimedia/ $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/x264_git.bb Remove the LICENSE_FLAGS line $bitbake -f x264 -c do_install $sudo cp -rf tmp/work/aarch64-poky-linux/x264/r2917+gitAUTOINC+72db437770-r0/image/usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/ Build gst-plugins-ugly (commit 995a135d) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly.git $cd gst-plugins-ugly$meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met build issue, please remove "if have_cxx" from meson.build Build libav As the yocto actually has the libav recipes, but not included in our bblayers, we need to copy the its source into our bblayers path under <yocto>/source: $cp -rf ./poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.16.1.bb Remove the LICENSE_FLAGS line $bitbake -f gstreamer1.0-libav -c do_install $cp tmp/work/aarch64-mx8mp-poky-linux/gstreamer1.0-libav/1.14.0-r0/image/usr/lib/gstreamer-1.0/libgstlibav.so <your install folder>/usr/lib/gstreamer-1.0 Now you have all of the Gstreamer plugins which required for AVB/TSN audio/video demo: avtpsrc, avtpsink, avtpaafpay, avtpaafdepay, avtpcvfpay, avtpcvfdepay x264_enc (encoder), avdec_h264 (decoder)   Install binaries Final step is to copy all of your built out files from <your install folder> into your board / root, and boot up the board. Verify the Gstreamer plugins install correctly or not: $export GST_PLUGIN_PATH= /usr/lib/gstreamer-1.0/ $gst-inspect-1.0 Check if the above Gstreamer plugins we built out can be found by gst-instpect.   System Setup VLAN The ENTE_QoS is assigned to eth1 instance. So create eth1.5 for vlan id 5: $ip link add link eth1 name eth1.5 type vlan id 5 \         egress-qos-map 2:2 3:3 $ip link set eth1.5 up Qdiscs The TSN control plane is implemented through the Linux Traffic Control (TC) System. The transmission algorithms specified in the Forwarding and Queuing for Time-Sensitive Streams (FQTSS) chapter of IEEE 802.1Q-2018 are supported via TC Queuing Disciplines (qdiscs). Linux currently provides the following qdiscs relating to TSN: Multiply queue qdiscs (These two qdiscs are mutually exclusive, select one for your demo): MQPRIO: Mapping the TC class into different hardware queue in IP. TAPRIO: Implements the Enhancements for Scheduled Traffic introduced by IEEE 1Qbv/Qbu. This is supported by i.MX8MP ENET_QoS IP through EST features: Qbv – Time aware shaper Qbu - frame preemption. CBS qdisc: Implements the Credit-Based Shaper introduced by the IEEE 802.1Qav This is supported by i.MX8MP ENET_QoS IP through EST (Enhancements to Scheduled Traffic) features. It works with mqprio qdisc together. ETF qdisc: While not an FQTSS feature, Linux also provides the Earliest TxTime First (ETF) qdisc which enables the LaunchTime Since the i.MX8MP ENET_QoS IP does not support LaunchTime feature, this qdisc configurations would be ignored.   MQPRIO qdisc $tc qdisc add dev eth1 parent root handle 100 mqprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         hw 1 NOTE, since ENET_QoS Q0 does not support hardware CBS, we have to avoid using Q0 for AVB streaming. Here’s the mapping: socket SO_PRIORITY 2 -> TC CLASS 2 -> Q2 socket SO_PRIORITY 3 -> TC CLASS 1 -> Q1 Other socket priority -> TC CLASS 0 -> Q0   TAPRIO qdisc Create a root qdisc handle to map the different CLASS streams to hardware queues w/ GCL (gate control list). This root handle maps the CLASS A stream to queue Q1, CLASS B stream to Q2, and others to Q0 by the “map” and “queues” parameters, same as mqprio above. The Q1/Q2(CLASS1/2) gates are open in the first 300us interval, then only Q1(CLASS1) gate is open in the next 300us with all other CLASS gated. The last sched-entry defines in after Q1 is open after 300us, all of the CLASS gates are open for next 200us. Then loopback to the first sched-entry for gate control. Please note in this demo, we only enable features to support the 802.1Qbv, the Qbu (Frame preempt) requires patches for iproute2. $tc qdisc add dev eth1 parent root handle 100 taprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         base-time 1000000000 \         sched-entry S 0x6 300000 \         sched-entry S 0x2 300000 \         sched-entry S 0x7 200000 \         flags 0x2   CBS qdisc Q1 CBS for video, Q2 CBS for audio: $tc qdisc replace dev eth1 parent 100:2 handle 777 cbs \         idleslope 98688 sendslope -901312 hicredit 153 locredit -1389 \         offload 1 $tc qdisc replace dev eth1 parent 100:3 handle 888 cbs \         idleslope 3648 sendslope -996352 hicredit 12 locredit -113 \        offload 1 NOTE: By default, the Q0 will be allocated for pfifo qdisc class if we do not define them.   ETF qdisc As ENET_QOS does not support hardware launch time in IP, the ETF qdisc would not be used here.   TimeSync Run the ptp4l and phc2sys in background, and use check_clocks to check the ptp sync works. $ptp4l -i eth1 -f ./gPTP.cfg --step_threshold=1 & $pmc -u -b 0 -t 1 "SET GRANDMASTER_SETTINGS_NP clockClass 248 \         clockAccuracy 0xfe offsetScaledLogVariance 0xffff \         currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 \         ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 \         timeSource 0xa0" $phc2sys -s eth1 -c CLOCK_REALTIME --step_threshold=1 \         --transportSpecific=1 -w &  $./check_clocks -d eth1 The PTP Hardware Clock (PHC)  synced between PTP master/slave means the RMS offset between PHC and GM (master clock) is < 100ns. PHC and system clock (CLOCK_REALTIME) synced means the clock offset < 100ns   NOTE: The check_clocks source code can be downloaded from here. cfg is described below, if you want to identify which is master and which is slave, use “masterOnly 1” or “slaveOnly 1” in this configuration file. #                                                                 # 802.1AS example configuration containing those attributes which # differ from the defaults.  See the file, default.cfg, for the   # complete list of available options.                              #                                                                 [global]                                                          gmCapable               1                                         priority1               248                                        priority2               248                                       logAnnounceInterval     0                                         logSyncInterval         -3                                        syncReceiptTimeout      3                                          neighborPropDelayThresh 800                                       min_neighbor_prop_delay -20000000                                 assume_two_step         1                                         path_trace_enabled      1                                         follow_up_info          1                                         transportSpecific       0x1                                        ptp_dst_mac             01:80:C2:00:00:0E                         network_transport       L2                                        delay_mechanism         P2P                                        Run demo ALSA AAF audio To run the alsa AAF demo, please add aaf0 and converter0 plugin device into /etc/asound.conf: pcm.aaf0 {         type aaf         ifname eth1.5         addr 01:AA:AA:AA:AA:AA         prio 2         streamid AA:BB:CC:DD:EE:FF:000B         mtt 50000         time_uncertainty 1000         frames_per_pdu 12         ptime_tolerance 100 }    pcm.converter0 {         type linear         slave {                 pcm "hw:2,0"                 format S16_LE         } }   The “aaf0” plugin device defines the ethernet interface which AAF runs on, the socket priority which mapping to Traffic Class in kernel TC, the stream-id for the aaf streaming. The “converter0” plugin device is used for convert the S16_BE format to S16_LE for the wm8960 PCM audio.   Select one device as AVB talker, and run: $speaker-test -p 25000 -F S16_BE -c 2 -r 48000 -D aaf0 Select one device as AVB talker, and run: $arecord -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D aaf0 | aplay -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D converter0 You can hear the sound on the listener device. You can also check which qdisc queue is used for AAF by: $tc -s qdisc   Gstreamer AAF audio Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     audiotestsrc samplesperbuffer=12 is-live=true ! \     audio/x-raw,format=S16BE,channels=2,rate=48000 ! \     avtpaafpay mtt=50000000 tu=1000000 streamid=0xAABBCCDDEEFF000B processing-deadline=0 ! \     avtpsink ifname=eth1.5 address=01:AA:AA:AA:AA:AA priority=2 processing-deadline=0 \)   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpaafdepay streamid=0xAABBCCDDEEFF000B ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     audioconvert ! audioresample !  alsasink device="hw:2,0" \)   Gstreamer CVF video Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     videotestsrc is-live=true ! video/x-raw,width=480,height=320,framerate=15/1 ! \     clockoverlay ! x264enc bframes=0  key-int-max=1 speed-preset=1 tune=4 ! h264parse config-interval=-1 ! \     avtpcvfpay processing-deadline=20000000 mtu=1400 mtt=2000000 tu=125000 streamid=0xAABBCCDDEEFF000A ! \     avtpsink ifname=eth1.5 priority=3 processing-deadline=20000000 \) NOTE: To eliminate the h.264 software encoding/decoding overhead with acceptable latency for this demo, we use several parameters for x264enc element: bframes: x264enc and avdec_h264 together was found to have issues, remove bframes in the stream would help. key-int-max: decoder can only decode the frame when a keyframe is present on stream to make sure decoder can work as faster as it can, the distance between two keyframes must be set to closest. speed-preset: to low down the CPU loading for encoding, we use the option to make encoding as faster as we can. (=1 means ultrafast) tune: 4 means zero latency ‘mtu=1400’ parameters for avtpcvfpay element is very important, if using the default mtu=1500, the listener cannot get the AVTPDUs package correctly from VLAN. The reason is unknown yet.   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpcvfdepay streamid=0xAABBCCDDEEFF000A ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     avdec_h264 ! videoconvert ! clockoverlay halignment=right ! waylandsink \)   The demo screenshot below: there are two clocks show on the videotestsrc stream: left one is the timestamp recorded before x264enc encoding on the AVB talker side, right one is the timestamp recorded after avdec_h265 decoding and do video convert to YUV frames on AVB listener side. You can see the timestamp is sync in seconds.     Deep dive Packet sniffer Use tcpdump on board to dump the L2 ethernet packet: ./tcpdump -i eth1 ether proto 0x22f0 -w dump.pcap The AVTP ether protocol code is 0x22f0 embedded inside the ether frame, or you can use "vlan 5" VLAN id for tcpdump parameters to dump. Then open this dump.pcap in the windows/Linux PC by the wireshark tool, it will automatically show the protocol inside the package, it can also parser the IEEE1722 (AVTP) CVF/AFF package header as below:   Precise latency measurement The clockoverlay plugin used in the above talker/listener is actually seconds level precision, which can not reflect the latency from talker videotestsrc -> listener avdec_h264 decoding finish. Here need a little hack to the clockoverlay element in the gst-plugins-base to get the millisecond precision. The patch is attached (gst-plugins-base-clockoverlay-us.patch), please apply and rebuild the gst-plugins-base, then replace the libgstpango.so on the board /usr/lib/gstreamer-1.0/. When doing CVF demo, you can take a picture of the screen, and check the two clock's diff. During my test, the latency is about 50ms, which include all the cost of encoding, AVTP packaging, streaming, ethernet transmit, ethernet receive, AVTP unpack and frame decoding. To measure the package latency from transmit port (talker) to receive port (listener), you can use the tcpdump on both end-points. And compare the Epoch Time the packet dumped: "Epoch Time: 1596252905.688243000 seconds". The delta of the epoch time of the same packet is around 100us~500us. This latency actually includes the AF_PACKET clone cost in kernel netfilter, also the tcpdump application schedule latency.   References Getting started with AVB on Linux: https://tsn.readthedocs.io/avb.html TSN vs AVB: https://dornerworks.com/blog/avb-vs-tsn-choose-the-best-deterministic-ethernet-solution-for-your-networked-devices/ ALSA aaf: https://fossies.org/linux/alsa-plugins/doc/aaf.txt Gstreamer avtp: https://gstreamer.freedesktop.org/documentation/avtp/index.html AVTP: https://avnu.org/wp-content/uploads/2014/05/AVnu-AAA2C_Audio-Video-Transport-Protocol-AVTP_Dave-Olsen.pdf MX8MP RM
View full article
Tips collected from zhaoyang-b49593 and dandouglass-b41520 while enabling redundant boot: Using i.MX 8MQ, same method can be applied for other i.MX devices that support redundant boot, see SoC Reference Manual. As described on the RM, if primary image authentication fails the ROM can reset and try booting a secondary image. This feature is only available on closed mode with properly signed binaries, otherwise the ROM boots the primary image despite the auth failure. For the i.MX 8MQ, the secondary image must start with spl, not HDMI firmware. Note, there is no ROM redundancy for the hdmi fw, if it is corrupt user can store a 2nd copy on a different memory address and update at run time. Steps to generate a dual spl image: 1. Build and Sign bootable binary (spl, u-boot, atf, fw, etc) Use the Yocto BSP or follow this post to build outside the Yocto environment. To sign the binary, follow the documentation on u-boot source: <u-boot>/doc/imx/habv4/guides/mx8m_secure_boot.txt Program image to the SD card: dd if=signed_flash.bin of=<sd path> bs=1024 seek=33 After boot you can use "hab_status" to verify that no events were generated: u-boot=> hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 2. Corrupt spl on your boot image You can corrupt anywhere on the spl signed area. For easier visualization at boot time we can corrupt the SPL banner. First create a copy: cp signed_flash.bin signed_flash_corrupt.bin Find the banner: hexdump -C signed_flash.bin | grep 2019 00020190 26 1c 40 92 04 00 80 d2 05 01 80 52 c4 20 04 aa |&[email protected]. ..| 0002eac0 32 30 31 39 2e 30 34 2d 30 30 30 32 39 2d 67 34 |2019.04-00029-g4| 000dde10 3a 20 20 00 55 2d 42 6f 6f 74 20 32 30 31 39 2e |: .U-Boot 2019.| 0002eac3 is on spl area, where "9" for 2019 is, replace by "X" printf "X" > X dd if=X of=signed_flash_corrupt.bin seek=$((0x2eac3)) bs=1 conv=notrunc Verify corrupt binary hexdump -C -s 0x2eac0 -n 64 signed_flash_corrupt.bin 0002eac0 32 30 31 58 2e 30 34 2d 30 30 30 32 39 2d 67 34 |201X.04-00029-g4| 0002ead0 37 63 31 39 32 32 20 28 41 70 72 20 32 37 20 32 |7c1922 (Apr 27 2| Transfer image to SD Card dd if=signed_flash_corrupt.bin of=<sd path> bs=1024 seek=33 Now, you should see hab events after running "hab_status" on u-boot 3. Create a secondary boot image This can be the same content as your primary image without the HDMI fw or it can be a different spl image. For easier visualization, we can change the SPL banner, on the code this time. Modify banner at ./common/spl/spl.c as: - puts("\nU-Boot " SPL_TPL_NAME " " PLAIN_VERSION " (" U_BOOT_DATE " - " + puts("\nSecondary U-Boot " SPL_TPL_NAME " " PLAIN_VERSION " (" U_BOOT_DATE " - " As mentioned above, we want our boot image without the HDMI fw, when running imx-mkimage use the flash_evk_no_hdmi target: make SOC=iMX8MQ flash_evk_no_hdmi Sign the image as in step 1. If you program the new image to the SD you should see the new banner. Make sure to run hab_status to confirm that no HAB events are generated. 4. Program SRK Hash and Close SoC Follow the documentation on u-boot source for SRK programming and closing the device: <u-boot>/doc/imx/habv4/guides/mx8m_secure_boot.txt Before closing the SoC, but after the SRK is programmed, try your images to confirm no HAB events are generated. Be careful with this step, errors could brick your board. This step is irreversible. After closing the SoC it will only boot signed images. 5. Create dual bootloader image We can concatenate our binaries to create a single file, let's use 2MB distance between primary and secondary images: For the working primary image: objcopy -I binary -O binary --pad-to 0x200000 --gap-fill=0x00 signed_flash.bin 1st-spl_pad.bin cat 1st-spl_pad.bin secondary2_nohdmifw_signed_flash.bin > 1st-spl_pad_2nd-spl.bin Or for the corrupt primary image experiment: objcopy -I binary -O binary --pad-to 0x200000 --gap-fill=0x00 signed_flash_corrupt.bin 1st-spl_pad.bin cat 1st-spl_pad.bin secondary2_nohdmifw_signed_flash.bin > 1st-spl_pad_2nd-spl.bin Program it to the SD card on 0x8400 offset (33k) dd if=1st-spl_pad_2nd-spl.bin of=<sd path> bs=1024 seek=33 && sync 6. Add Secondary image table Follow the format on the RM, this is only 20 bytes long. For a 2MB distance between the table and the secondary image we can use "0x1000" on the firstSectorNumber field. 2MB/512 = 4096 (0x1000) The perl script attached, genSecTable.pl, can be used to generate it. perl genSecTable.pl 0x1000 Program it to the SD card on 0x8200 offset dd if=secTable.bin of=<sd path> bs=1 seek=$((0x8200)) && sync 7. Verify secondary image is booting If using the corrupt primary image, you should see the spl with the "Secondary U-Boot SPL..." banner. You can also read the persist secondary boot bit. u-boot=> md.l 0x30390098 1 30390098: 40000000 ...@ The work can be extended patching spl for in case of u-boot authentication failure, spl can try to authenticate and jump to the secondary u-boot.
View full article
The i.MX6 Multi-Mode DDR Controller (MMDC) has profiling capabilities to monitor the operation of the controller. The profiling capability counts certain events related to a specified AXI-ID during a profiling period. The events that can be counted are: The number of read accesses during the profiling period (MMDCx_MADPSR2[RD_ACC_COUNT] register field) The number of write accesses during the profiling period (MMDCx_MADPSR3[WR_ACC_COUNT] register field) The number of bytes read during the profiling period (MMDCx_MADPSR4[RD_BYTES_COUNT] register field) The number of bytes written during the profiling period (MMDCx_MADPSR5[WR_BYTES_COUNT] register field) The number of MMDC clock cycles during which the MMDC state machine is busy (MMDCx_MADPSR1[BUSY_COUNT] register field) BUSY_COUNT is the number of MMDC clock cycles during the profiling period in which the MMDC state machine is not idle. So this is the time the MMDC spends doing any activity, not just read or write data transfers. The MMDC state machine is active whenever there are any read or write requests in the read and write FIFOs. The MMDC is active during many operations that are not reading or writing data such as arbitration of requests, control cycles, bank open/close, etc. So BUSY_COUNT represents the number of cycles when the controller is busy, not just the number of cycles when the external bus is busy. The number of bytes read and bytes written can be used to determine data throughput and the BUSY_COUNT can be used to determine what part of the time the controller is active/idle. Together these can be used to determine the controller efficiency for a particular application. For detailed information, see the "MMDC profiling" section of the MMDC chapter in the reference manual for the SoC being used.
View full article
Audio, from a file gst-launch filesrc location=test.wav ! wavparse ! mfw_mp3encoder ! filesink location=output.mp3 Audio Recording gst-launch alsasrc num-buffers=$NUMBER blocksize=$SIZE ! mfw_mp3encoder ! filesink location=output.mp3 # where #     duration = $NUMBER*$SIZE*8 / (samplerate *channel *bitwidth) # Example: 60 seconds recording # gst-launch alsasrc num-buffers=240 blocksize=44100 ! mfw_mp3encoder ! filesink location=output.mp3 # # To verify that is correct, do a normal audio playback gst-launch filesrc location=output.mp3 typefind=true ! beepdec ! audioconvert ! 'audio/x-raw-int,channels=2' ! alsasink Video, from a test source gst-launch videotestsrc ! queue ! vpuenc ! matroskamux ! filesink location=./test.avi Video, from a file gst-launch filesrc location=sample.yuv blocksize=$BLOCK_SIZE ! 'video/x-raw-yuv,format=(fourcc)I420, width=$WIDTH, height=$HEIGHT, framerate=(fraction)30/1' ! vpuenc codec=$CODEC ! matroskamux ! filesink location=output.mkv sync=false # where #     BLOCK_SIZE = WIDTH * HEIGHT * 1.5 #     CODEC = 0(MPEG4), 5(H263), 6(H264) or 12(MJPG). # # For example, encoding a CIF raw file gst-launch filesrc location=sample.yuv blocksize=152064 ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! vpuenc codec=0 ! matroskamux ! filesink location=sample.mkv sync=false Video, from Web camera # when the web cam is connected, the device node /dev/video0 should be present. In order to test the camera, without encoding gst-launch v4l2src ! mfw_v4lsink # in recording, run: # gst-launch v4l2src num-buffers=-1 ! queue max-size-buffers=2 ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # where sync=false indicates filesink to to use a clock sync # # In case a specific width/height is needed, just add the filter caps gst-launch v4l2src num-buffers=-1  ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # In case you want to see in the screen what the camera is capturing, add a tee element # gst-launch v4l2src num-buffers=-1 ! tee name=t ! queue ! mfw_v4lsink t. ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false Video, from Parallel/MIPI camera # The camera driver needs to be loaded before executing the pipeline, refer to the BSP document to see which driver to load # MIPI (J5 port): modprobe ov5640_camera_mipi modprobe mxc_v4l2_capture   # Parallel (J9 port): modprobe ov5642_camera modprobe mxc_v4l2_capture   gst-launch mfw_v4lsrc ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false   # Do a 'gst-inspect mfw_v4lsrc' or 'gst-inspect vpuenc' to see other possible settings (resolution, fps, codec, etc.)
View full article
Q: In mfgtool release 1.0.0 I, "Support only Cortex-A5 as primary boot core (Cortex-M4 boot is not supported on this release)." When will a version supporting M4 boot first be available? A: Mfg tool is based on it's counterpart, the ROM code. Rom code is for the A5 and not for the M4 as a matter of fact if you boot with the M4 and the device doesn't enumerate on the USB port at all then you know why and the MfgTool won't be able to do anything about it. Currently there no plans to provide a MfgTool version that supports boot from M4 core. Customers can modify the exisiting code to make it work with M4 as primary core. Booting from USB with the M4 core should work. The image that is booted must be for execution on M4 (thumb mode). MfgTool uses u-boot and a micro linux kernel to download images and program memories. This Linux can only run on the A5 core. To make it work with the M4 core as primary, it should be sufficient to add some code to the exisiting A5 images. Code will execute on M4 and start the A5 at the proper address as if it is booted from the A5.
View full article
Encode From YUV to H.264 gst-launch-0.10 filesrc location=file_in.yuv blocksize=w*h*1.5 ! \ mfw_vpuencoder codec type=std_avc framerate=fr ! filesink location=file_out.mpg Where: file_in.yuv: is the input file, a raw file. w*h*1.5: is the blocksize, it's calculated from input file dimensions: width * height * 1.5 mfw_vpuencoder: is the encoder with hardware acceleration for iMX27 std_avc: chooses the codec type for output file fr: indicates the framerate in that input file was created file_out.mpg: is the output file encoded in H.264 From Camera to H.264 gst-launch-0.10 mfw_v4lsrc ! mfw_vpuencoder codec-type=std_avc \ width=176 height=144 framerate=25 ! filesink location=test.video
View full article
When flashing a Linux System on a SD card using the script mk_mx28_sd on a Ubuntu 12.04 host, one needs to modify it so partitions are created correctly.  Just follow these steps on the console: $ cd $SDK/L2.6.35_10.12.01_SDK_scripts $ cat > first_partition_sector.patch << EOF diff -Naur a/mk_mx28_sd b/mk_mx28_sd --- a/mk_mx28_sd        2010-10-06 09:47:42.000000000 -0500 +++ b/mk_mx28_sd        2012-11-30 13:38:34.508199154 -0600 @@ -178,7 +178,7 @@ n p 1 -1 +2048 +32M t b EOF $ patch -p1 < first_partition_sector.patch then, you can run the mk_mx28_sd command again with the device as parameter                $ cd $LIB $ export PATH=$PATH:$SDK/L2.6.35_10.12.01_SDK_scripts $ mk_mx28_sd /dev/$SDX
View full article
The native Yocto not support chinese, so need to add chinese font . The first step should download Chinese font  files such as  MSYHMONO.ttf and DroidSansFallback.ttf.Then copy fonts files to /usr/share/fonts/truetype and run command  fc-cache .update font cache. use fc-list :lang=zh can see which Chinese fonts are installed:          /usr/share/fonts/truetype/MSYHMONO.ttf: Microsoft YaHei Mono:style=Regular          /usr/share/fonts/truetype/DroidSansFallbackFull.ttf: Droid Sans Fallback:style=Regular The secend step is to change default fonts. In weston-terminal.c we can see:           3119   weston_config_section_get_string(s, "font", &option_font, "mono");           3120   weston_config_section_get_int(s, "font-size", &option_font_size, 14);  weston-terminal default use mono font.Just to modify /etc/fonts/fonts.conf           <edit name="family" mode="assign" binding="same">                       <string>monospace</string> to   <string>Microsoft YaHei Mono</string> or <string>Droid Sans Fallback</string> could display Chinese character   But it have some problem such like as :   the left use Microsoft YaHei Mono font the Chinese character is overlapping ,the right use Droid Sans Fallback font is en-font could not display. If you have a better way to welcome a message!
View full article
The SNVS LDO output (VDD_SNVS_CAP) requires an external capacitor. Freescale's updated recommendation is that this should be a single 0.22 uF capacitor. Freescale is working to get documents in alignment. As of Feb 2013, some documents (such as schematics or user guides) show a single 0.22 uF capacitor, others do not.
View full article
This is a hack to support programming EEPROM I2C devices for MX28 boot. See post at: Re: mx28 boot issues with SSP (SD card) *** USE AT YOUR OWN RISK ***
View full article
This document provides steps to perform the system upgrade/OTA update for Android on i.MX platforms. Compile the Android images and generate an OTA Package: source build/envsetup.sh lunch sabresd_6dq-userdebug make -j4 make otapackage You can find your OTA package in the below path: ls out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip Copy the above OTA zip package to the device in sdcard using adb push adb push out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip /sdcard Move the package from sdcard to the location: /cache/update.zip Make the directory and perform the below steps on the device: mkdir -p /cache/recovery touch /cache/recovery/command echo "--update_package=/cache/update.zip" > /cache/recovery/command reboot recovery The recovery automatically applies the command and installs this update package. Note: In this document, the setup is for the i.MX6Q SABRESD Board. So, PathName and OTA package name subject to change based on target device compilation.
View full article
current imx6 bsp, not only ltib but also yocto couldn't support subtitle. now we have two solution to support subtitle on yocto, 1)one is extract the subtitle, then draw the subtitle on the video by UI, which is supported by the imxplayer. this solution is using QT by imxplayer, so if you build yocto, should choose QT as target. basicly, aiurdemux send the text to the QT by appsink, then QT draw the text on the UI layer. when build the yocot, pls using the command as below: " bitbake fsl-image-qt5" copy the font libary to the /usr/lib/fonts, then when you play the imxplayer, choose the font you need. 2)another one is blending the subtitle on the video buffer by gstreamer, then output with video enable gst pango lib in gstreamer1.0-plugins-base change playbin flag to disable native video flag basetextoverlay apply patch http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/ext/pango/gstbasetextoverlay.c?id=267a8c24af4f02ba6f3075bd589d3c5d1dc826e9 use following command line gst-launch-1.0 playbin flags=0x17 uri=file://$VIDEO_FILE suburi=file://$SUBTITLE_FILE
View full article
   The purpose of this article is to describe how to join together the Processor Expert and ARM GCC toolchain under Eclipse environment.    Freescale provides the Processor Expert, which contains the Pin Settings Tool to support an easy way to configure pin signals, from multiplexing to the electrical properties of pins. With such Tool all the pins can be configured with a graphical user interface, and then generate C code, in order to use it as an example in applications. Please refer to the following Web for more details. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX   The Processor Expert Software for i.MX Processors (Version 1.0) does not include a compiler or linker. Customers should merge the generated code into a build system.   However, it is possible to use common Eclipse-based IDE for the Processor Expert (V 1.0) and GNU ARM “C” toolchains. In particular, the following sequence may be implemented for both Linux and Windows hosts. 1. Install Eclipse (Kepler release) IDE for C/C++ Developers. https://eclipse.org/downloads/packages/eclipse-ide-cc-developers/keplersr2 2. Add Eclipse Processor Expert plug-in, as recommended in the documentation. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PROCESSOR-EXPERT-IMX https://community.freescale.com/docs/DOC-101470 3.  Add GNU ARM Eclipse, which contains configurations for different toolchains, including Linux ones. http://gnuarmeclipse.livius.net/blog/plugins-install/ 4. Install appropriate toolchain. For bare-metal applications Sourcery CodeBench Lite for ARM is sutable one. Sourcery CodeBench Lite Edition including ARM GCC IDE - Mentor Graphics Please use Getting Started Guide document from the CodeBench Lite package, that explains how to install and build applications with the CodeBench Lite.    As an example, let’s consider minimal startup code for i.MX6Q (LED flickering project on i.MX6Q SDB / SDP). Assuming Eclipse IDE with the Processor Expert and GNU ARM tools is installed, we should create new “C” project under Eclipse : New -> C Project. Select “Empty Project” and “Cross ARM GCC”, enter “Project name”. Then : select “Advanced settings” -> C/C++ Build -> Settings Tab “Target Processor” : ARM Family : cortex – a9 Architecture : armv7-a Instruction set : ARM (-marm) Endianness : Little endian (-mlittle-endian) FloatABI : Library with FP (softfp) FPU Type : neon Unaligned access : Disabled (-mno-unaligned-access) “Cross ARM GNU Create Flash Image” : General : Raw binary. TAB “Toolchains” : Name : Sourcery CodeBench Lite for ARM EABI (arm-none-eabi-gcc) (If needed customers can select appropriate toolchain) Architecture : ARM (AArch32) Prefix : arm-none-eabi Check “Use global toolchain path” or select the required path directly.  Source codes may added via Eclipse : File -> Import -> File System -> From directory Example source is enclosed. After sources as included in the project, let’s configure linker options via project properties, C/C++ Build -> Settings -> Tool Settings -> Cross ARM C Linker -> General. Add script file “mx6dq.ld”, uncheck “Remove unused section”, check “Do not use standard start files”.   Note, the article of Miro Samek is very helpful in clarifying of startup code and linker script. Please refer to “Building Bare-Metal ARM Systems with GNU”. Article Published online at www.Embedded.com,  July/August 2007. So, now we can build the project : Project -> Build Project. Two executable file will be generated : test.elf (for JTAG debugger) and test.bin, which may be used to create bootable SD card, using cfimager-imx.exe utility : CMD> cfimager-imx -o 0 -f test.bin -d g: Please use readme files in the enclosed for more details.
View full article
i.CORE M6SX The i.Core M6SX is the latest powerful i.MX6 SoloX based SOM solution provided by Engicam in SODIMM format. The i.MX 6SoloX is the first device utilizing both the ARM Cortex-A9 and ARM Cortex-M4 cores. Its heterogeneous architecture provides a secure and robust implementation to enable concurrent execution of multiple software environments to provide an application-rich system with real-time responsiveness. Optimized for high performance energy efficient processing in general embedded, automotive, industrial and consumer applications i.CORE M6SX Cores Cortex TM -A9 @ 800 MHz core, NEON co-processor. DP FPU, L1 and L2 I/D cache Cortex TM -M4 @ 200 MHz core SP Floating point unit,  I/D chache Memories 256MB 32bit DDR3-800 512MB SLC NAND Flash Graphics and Multimedia 1x Parallel LCD 18bit output 1x LVDS output Hardware 3D/2D engine OpenGL-ES 2.0 and OpenVG1.1 Parallel Camera Interface input Touch screen Peripherals 2x SD Card interface USB OTG HS, USB HS HOST, Uart, I2C, I2S, QSPI,PCI Express SATA ADC and Video ADC input 2x Ethernet 10/100 Dimensions Standard SODIMM footprint 67,4x31.9 mm PCB size Very Low Profile Module
View full article
That Python script exercises the i.MX serial download protocol in UART mode. It can be used with i.MX21/27/25/31/35/51/53, since they are based on the same protocol. The details on the protocol can be found in the "System Boot" section of the used i.MX reference manual. Requirements: - Python 2.7 (not tested with other version) - Pyserial modules (http://pyserial.sourceforge.net) The i.MX must boot in serial mode with a serial cable connected to a host running the script. The COM1 is configured in 115200 - no parity - 1 stop bit - 8-bit. If another COM is used, you will have to make the appropriate changes in the script. That script uses only hexa formatted address and data for the command parameters. The following command returns the HAB status whenever it is used, so it helps to check that the setup is functional. Eventually, when some code was downloaded, this command triggers its execution. The returned value is only useful when doing a secure boot, and does not matter otherwise. By default, it returns in hexa format the following: > iMX_Serial_Download_Protocol.py get_status Status is: F0 F0 F0 F0 Typical usage to download and execute some code: 1. Ensure that the protocol is ready: > iMX_Serial_Download_Protocol.py get_status 2. Configure the memories and other things like I/O, such does the DCD: > iMX_Serial_Download_Protocol.py write_mem memory_address access_size data As this configures only one register at a time, it is necessary to call it several times to configure like a SDRAM. Of course, feel free to enhance that script by adding like a load from file memory write 🙂 3. Download the executable binary: > iMX_Serial_Download_Protocol.py write_file memory_address file memory_address is necessary a valid address from the i.MX memory map, meaning that it must be a directly accessible memory area by the ARM core (registers, RAM). 4. Run the executable by jumping from ROM code to this loaded code: > iMX_Serial_Download_Protocol.py get_status This must returns: 88 88 88 88, which signifies that the ROM has successfully jumped at the entry point of the executable. That entry point must be specified in the flash header or Image Vector Table (IVT) depending of the i.MX. As a consequence, a valid flash header or IVT must be placed at the offset 0x0 of the downloaded code. In each boot image, this is commonly placed at the offset 0x400, so it is easy to build another one at offset 0x0 which is usually an empty space. Pointer to DCD should remain null. The script is provided "as is" without any warranty, and is not an official tool supported by Freescale. The script is here: 19-iMX_Serial_Download_Protocol.py
View full article