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

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1.   This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi.   Platform:                            imx8qm b0 mek OS:                                    yocto 4.14.78 ga hardware connection:        imx8qm lvds1 ====> it6263 cable =====> hdmi display.   1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4.   2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3.   3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering.   See the atttachments for details.   ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4] 

platform: imx8qxp c0 mek OS: yocto 4.19.35_1.1.0 hardware connection: imx8qxp lvds0 => dummy panel ,  lvds1 => it6263 => display   On imx8qxp there are one DPU(display process unit) and one ISI(image subsystem interface), ISI supports input from dpu.   dpu block diagram: note that only dsi0 and lvds0 can be used for loopback. and this patch only test the lvds0, since lvds support dummy panel.   Please see the readme in the attchment for how to enale this feature.   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]   

  This patch will add bootaux command to imx7ulp uboot.   This would make it easier in start M4 binary image in single boot mode.   Feature: 1. Support using m4 image in .bin format. 2. Support bootaux command in u-boot. 3. Support boot from TCM and DDR (DDR not tested, if any issue, pls let me know.).   Note: 1. SDK TCM entry address is 0x1FFD2000. But TCML base address is 0x1FFD0000. Pls take care to set a correct entry address to m4_loadaddr. 2. If user want to use M4 image generated from imx_mkimage, pls refer to bootaux patch in https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/OTA-upgrade-for-smartlocker-in-i-MX7ULP-kernel/ta-p/1112687.   Test procedure: 1. Set u-boot parameters: setenv m4_loadaddr 0x1FFD2000 setenv m4_copyaddr 0x62000000 setenv m4_image hello_world.bin setenv m4_flash_imglen 0x30000 setenv m4_loadimage "fatload mmc '${mmcdev}':'${mmcpart}' '${m4_copyaddr}' '${m4_image}'; cp.b '${m4_copyaddr}' '${m4_loadaddr}' 0x30000" setenv run_m4_image "run m4_loadimage; dcache flush; bootaux '${m4_loadaddr}'" 2. Copy hello_world.bin to SD card and boot board. Make sure board is in single boot mode. 3. Run "run run_m4_image"   4. On M core console.    

Default system can’t start Weston GUI in monitor after booting with NFS, so I find a solution to fix that issue. 1.Error messages imx8mpevk login: [31.274389] systemd[1]:weston@root.service: Main process exited, code=exited, status=1/FAILURE [ 31.274928] systemd[1]: weston@root.service: Failed with result 'exit-code'. [04:52:59.571] logind: not running in a systemd session [04:52:59.571] logind: cannot setup systemd-logind helper (-61), using legacy fallback 2.Steps Step 1:Add output in the /etc/xdg/weston/Weston.ini [output] name=HDMI-A-1 mode=1920x1080@60 Step 2:ls /sys/class/drm There will be some device nodes like card0,card1-HDMI-A-1. card1-HDMI-A-1 is we need. Step 3:Change drm_device in /etc/xdg/weston/Weston.ini drm-device=card1 Step 4:Set envs export WESTON_DRM_PRIMARY=HDMI-A-1 export WESTON_DRM_MIRROR=1 export WESTON_DRM_KEEP_RATIO=1 export WESTON_DRM_PREFER_EXTERNAL=1 export WESTON_DRM_PREFER_EXTERNAL_DUAL=1 Step 5:Start Weston weston --tty=7 -B=drm-backend.so --idle-time=0&

For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.10.53 GA 1.1.0 BSP.   The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI   For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel.   In this patch, we given the example driver for Maxim MAX9286, it was verified working on iMX6DQ SabreAuto board. The input to MAX9286 is four 720P30 cameras. The verified camera boards:     (1) Onsemi AR0140+AP0101+MAX9271 boards.     (2) OmniVision OV10635+MAX9271 boards.   The MIPI CSI2 CVBS camera surround view solution can be found at: iMX6DQ ISL79985/79987 MIPI CSI2 CVBS camera surround view solution for Linux BSP The MIPI CSI2 CVBS HD camera surround view solution can be found at: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP   The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch      Updated IPU common code to support up to four cameras.   0002-Add-Max9286-support-on-SabreAuto-board-which-can-sup.patch      MAX9286 driver, it includes MAX9271, AP0101 and AR0140 drivers.   0003-Remove-the-page-size-align-requirement-for-v4l2-capt.patch      With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly.   0004-Max9286-skip-AP0101-camera-re-initialization.patch      If the camera board's power had been kept after initialized, this patch will bypass the re-initialization to reduce the start up time.   0005-Max9286-set-I2C-speed-to-400Kbps.patch     Set I2C to 400Kbps to reduce the AP0101+AR0140 initialization time.   0006-Max9286-add-retry-for-MAX9271-I2C-access.patch     Added retry for MAX9271 I2C access.   0007-Max9286-Add-support-for-OV10635-camera.patch     Updated code for OV10635 camera.   0008-Max9286-support-auto-detect-camera-number.patch     Make the Max9286 driver can detect the camera number automatically.     How to builld the kernel with MAX9286 support:       make imx_v7_defconfig       make menuconfig (In this command, you should select the MAX9286 driver:             Device Drivers  --->                   <*> Multimedia support  --->                         [*]   V4L platform devices  --->                               <*>   MXC Video For Linux Video Capture                                       MXC Camera/V4L2 PRP Features support  --->                                           <*>Maxim max9286 GMSL Deserializer Input support                                               Select Camera Sensor (OmniVision OV10635 camera sensor)  // Or (Onsemi AP0101 and AR0140 camera sensor)                                           <*>mxc VADC support                                           <*>Select Overlay Rounting (Queue ipu device for overlay library)                                           <*>Pre-processor Encoder library                                           <*>IPU CSI Encoder library)       make zImage       make dtbs   The built out image file:       arch/arm/boot/dts/imx6q-sabreauto.dtb       arch/arm/boot/zImage   "mxc_v4l2_tvin_max9286.tar.gz" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d &   Some hardware check point on AR0140+AP0101+MAX9271 camera board (Please get MAX9286 and OV10635 schematics from Maxim): 1. In this patch, MAX9286's I2C address is 0x4D, so ADD0 and ADD1 should be connected to high. AP0101's I2C address is 0xBA, so SADDR should be connected to high.   2. AP0101's DOUT0~DOUT7 should be connected to MAX9271's DIN7~DIN0, the order should be switched, MSB connected to LSB.   3. MAX9271's GPO pin should be connected to AP0101's FRAME_SYNC pin. The pull down resistance on FRAME_SYNC pin should not be 0 ohm.   Some known limitation: 1. AP0101's VSYNC invalid time, last video line's HSYNC to VSYNC porch's max value is 255 pixel clocks, it is not enough for MAX9286 to generate the Frame End MIPI packets for each camera. So in order to let iMX6DQ to capture 1280x720 video for each camera, we had let AP0101 output 1280*724 frame size, and iMX6 will only capture 720 lines, the remained video data and Frame End will be ignored. This solution will not impact the function, but there will be "Error matching Frame Start with Frame End for Virtual Channel x" error reported from iMX6 MIPI_CSI_ERR1 register. Maxim suggested to use MAX96705 to relace the MAX9271, it can delay the VSYNC invalid time, then the MIPI error will be fixed.     2015-11-17 update: Updated for OV10635 camera support. File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-11-17.zip   2015-12-04 update: File: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2015-12-04.zip Added patch 0009-Max9286-updated-PCLK-edge-setting-for-OV10635.patch to correct the OV10635 PCLK edge setting     2016-03-07 update: File L3.14.38_GA_MAX9286_Surroundview_Patch_2016-03-07.zip Added kernel patch for L3.14.38 GA 1.1.0 BSP.   2016-07-26 update: Files: L3.10.53_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.38_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip; L3.14.52_GA1.1.0_MAX9286_Surroundview_Patch_2016-07-26.zip. Added gstreamer support. Added MAX96705 support. Added patch for L3.14.52_GA1.1.0.   2017-12-11 update: Added CVBS surround view link: iMX6DQ TP2854 MIPI CSI2 720P CVBS camera surround view solution for Linux BSP     2021-04-26 update: Some customer reported, when system loading is heavy, sometimes, some camera will flicker left and right. It is caused by SFMC FIFO data lost. The original patch used IDMAC 0 and IDMAC 1 for two cameras on one IPU, this is not the best setting.  IDMAC 1 is fixed to use 1/4 SMFC FIFO and it will cause IDMAC 0 to use 1/4 SMFC FIFO too. And another 1/2 of SMFC FIFO can't be used in this case. Some code update to improve it: For each IPU, please use IDMAC 0 and IDMAC 2 to capture the two cameras. This needs change the hard coding in "drivers\media\platform\mxc\capture\ipu_csi_enc.c", "CSI_MEM1" and "IPU_IRQ_CSI1_OUT_EOF" should be changed to "CSI_MEM2" and "IPU_IRQ_CSI2_OUT_EOF". In this case, all SMFC FIFO can be used. And in "ipu_common.c", function ipu_probe(), the followed code should be changed to make IDMAC2 use high priority too. /* Set sync refresh channels and CSI->mem channel as high priority */ - ipu_idmac_write(ipu, 0x18800003L, IDMAC_CHA_PRI(0)); + ipu_idmac_write(ipu, 0x1880000FL, IDMAC_CHA_PRI(0));

The Register Programming Aid (RPA) provides a default DRAM PLL setting (DRAM frequency) based on the default setting supported in u-boot.  It is highly recommended to use the default DRAM frequency settings in the RPA for ease of use and to align with u-boot.  Otherwise, in addition to updating the RPA for the new DRAM frequency, the u-boot SPL code itself will need to be manually updated with the new DRAM PLL setting.   Should the user wish to change the DRAM frequency, the following steps are required:   First, the user needs to update the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to the desired DRAM frequency       2. Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054”.  The address “0x30360054” is for the DRAM PLL register address and its setting needs to be updated to the desired frequency.        Note that there is another place where the DRAM frequency is also updated “freq0 set 0x30360054” but it is automatically updated based on the setting above.    Below is a table of various frequencies to choose from.  For frequencies not listed in the table below, it is up to the user to calculate a new register setting based on the formula:     (24MHz x m)/(p x 2^s)   Where “m” represents the PLL_MAIN_DIV, “p” represents the PLL_PRE_DIV, and “s” represents the PLL_POST_DIV.  NOTE:  The DRAM frequency is double the DRAM PLL frequency DRAM_freq = DRAM_PLL x 2   The DRAM PLL register and bit settings are shown below:          The following table provides examples of the various settings to create the desired frequency:       For example, in the i.MX 8M Mini LPDDR4 RPA where the default DRAM frequency is 1500MHz, let’s assume that the user instead wants 1200MHz.    First, the user changes the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to 1200.   Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054” and replace “0xFA080” (original setting from DRAM frequency 1500MHz) with “0x000C8022” (updated for DRAM frequency 1200MHz).  Note that for a DRAM frequency of 1200MHz, the DRAM PLL is configured for 600MHz, as the DRAM frequency is double the DRAM_PLL.   The steps outlined above are sufficient in order to create a DDR script for use with the DDR stress test tool to run the calibration and execute the DDR stress test.  However, to deploy the generated code in SPL, more steps are needed as the u-boot SPL DDR driver does not automatically change the DRAM PLL according to the generated code. Hence the user will need to manually modify related code in u-boot.  It is highly recommended to work with a software engineer familiar with u-boot when making the following modifications.    3. Modify DRAM PLL configuration in uboot-imx/drivers/ddr/imx8m.c, specifically the code highlighted below (function call dram_pll_init).  Note that the files and file paths in u-boot change frequently, so if this particular file (or file path) does not exist in the current u-boot, simply search for dram_pll_init or ddr_init.   void ddr_init(struct dram_timing_info *dram_timing) { ……    debug("DDRINFO: cfg clk\n");      if (is_imx8mq())           dram_pll_init(DRAM_PLL_OUT_800M);      else          dram_pll_init(DRAM_PLL_OUT_750M); ……  }   In the above code, the user should update the macro “DRAM_PLL_OUT_750M” with the new DRAM PLL value.  Note that the default DRAM_PLL_OUT_750M results in the DRAM frequency of 1500MHz, where the DRAM frequency is double the DRAM PLL (as previously stated above).   For example, if the user desires to run the DRAM at 1200MHz, they would change the above to: dram_pll_init(DRAM_PLL_OUT_600M);   Note that DRAM_PLL_OUT_600M is a supported macro in the dram_pll_init() API.  If the desired DRAM PLL configuration does not exist in dram_pll_init(), you will need to add support in uboot-imx/arch/arm/mach-imx/imx8m.c  (as stated above, if this file path does not exist in the current u-boot simply search for dram_pll_init):   void dram_pll_init(enum dram_pll_out_val pll_val) { …… }   Related Links i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 

Compiling kernel module qca9377 in new bsp L5.10.9 has lots of errors.This is because lots of kernel apis has been dropped or changed from kernel5.4 to kernel5.10.But kernel module QCA9377 still using old api.So i fixed this compile errors and attach this patch.

  Some customers are using sgtl5000 in android. So i generate this patch of sgtl5000 in Android11(i.MX8QM)

Low power demo on i.MX8MM.   9/28/2020: Attachments updated. 1. Fix a bug in 5.4.24 kernel that system can only wakeup once. 2. Remove 0x104 from atf patch. On 5.4.24, tested OK without PLL2.   9/8/2020: Attachments updated. Add patches for 5.4.24 kernel.   We use it to test power consumption on i.MX8MM EVK.   Usage: 1. Kernel: echo "mem" > /sys/power/state   2. M4: Select a power mode from menu and wait for wakeup. Default wakeup method is GPT.   Add more patches, which will add functions for the case: 1. M core RUN and A core in suspend with DDR OFF. 2. M core wakeup A core without DDR support.   Descriptions: freertos_lowpower.zip. A simple freertos example for M4 RUN when A core in DSM. Generally, we use MU_TriggerInterrupts(MUB, kMU_GenInt0InterruptTrigger); to do wakeup. low_power_demo.zip A simple baremetal example for M4 RUN when A core in DSM. Generally, we use MU_TriggerInterrupts(MUB, kMU_GenInt0InterruptTrigger); to do wakeup. Note that the freertos version will have more options in menu. atf patch: Allow A53 to enter fast-wakeup stop when M4 RUN. Also avoid bypass of some plls, which is important to make M4 RUN when A53 enters suspend. 0001-iMX8MM-GIR-wakeup.patch: GIR wakeup patch for kernel. Need kernel to use fsl-imx8mm-evk-m4.dtb. 0002-Don-t-keep-root-clks-when-M4-is-ON.patch. Don't keep root clocks when M4 is ON. 0001-plat-imx8mm-keep-the-necessary-clock-enabled-for-rdc.patch. There's a design issue that when wakeup from DSM, described in patch: "if NOC power down is enabled in DSM mode, when system resume back, RDC need to reload the memory regions config into the MRCs, so PCIE, DDR, GPU bus related clock must on to make sure RDC MRCs can be successfully reloaded." Note that this patch will keep PCIE, DDR and GPU clock on, which will increase the power. An optimization will be decrease PCIE, DDR and GPU clock before entering DSM.   Power measurement: Supply Domain Voltage(V) I(mA) P(mW) peak avg peak avg peak avg VDD_ARM(L6) 1.010029 1.009513 1.109 1.030 1.120 1.039 VDD_SOC(L5) 0.855199 0.854857 190.110 189.973 162.582 162.400 VDD_GPU_VPU_DRAM(L10) 0.977240 0.977050 19.865 19.800 19.413 19.346 NVCC_DRAM(L15) 1.094407 1.094168 2.059 1.984 2.253 2.171 Total         185.367 184.956   Notes: This power measurements is got by putting Cortex-A in DSM and Cortex-M in RUNNING. In other tests, if M core can be put to STOP mode, additional power can be saved (5 - 20mA in VDD_SOC). From the table, we can see that by putting DDR to retain, a lot of power can be saved in VDD_SOC and NVCC_DRAM.

tarball created by Curtis Wald and Leonardo Sandoval containing patches to fix ltib issues for Ubuntu 12.04.   Steps to use this tarball   # go to ltib folder $ cd <ltib full path>   # untar the tarball $ tar -xzvf ubuntu-ltib-patch.tgz   # go to untared folder $ cd ubuntu-ltib-patch   #install patches $ ./install-patches.sh <ltib full path>     You above steps are contained in this script:   https://community.freescale.com/servlet/JiveServlet/downloadBody/93455-102-2-2825/patch-ltib-ubuntu12.04.sh,   so instead of typing them manually you can execute the following command   curl -L https://community.freescale.com/servlet/JiveServlet/downloadBody/93455-102-2-2825/patch-ltib-ubuntu12.04.sh | bash   under your ltib folder.

Linux kernel provide some apis to allow changing dtb node after system booted. But the node change must happen before the driver loading. We can use gereral dtb file and add some dts node after system boot.

This solution change the pf1550 driver in i.MX6ULL,fixed the cpu freq errors!  

    Below mentioned are the step to enable secure boot in imx8m nano board. Mentioned each step log and address for imx8m nano board tested with LPDDR4.   secure boot feature uses digital signatures to prevent unauthorized software execution during the device boot sequence. In case a malware takes control of the boot sequence, sensitive data, services and network can be impacted. Download the CST(code signing tool) from the below mentioned link https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 1. Generating a PKI tree The Code Signing Tools package contains an OpenSSL based key generation script under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI tree containing up to 4 Super Root Keys (SRK) as well as their subordinated IMG and CSF keys. $ ./hab4_pki_tree.sh ... Do you want to use an existing CA key (y/n)?: n Do you want to use Elliptic Curve Cryptography (y/n)?: n Enter key length in bits for PKI tree: 2048 Enter PKI tree duration (years): 5 How many Super Root Keys should be generated? 4 Do you want the SRK certificates to have the CA flag set? (y/n)?: y 2. Generating a SRK Table and SRK Hash The next step is to generated the SRK Table and its respective SRK Table Hash from the SRK public key certificates created in one of the steps above. The srktool can be used for generating the SRK Table and its respective SRK Table Hash. - Generating SRK Table and SRK Hash in Linux 64-bit machines: $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \ SRK_1_2_3_4_fuse.bin -d sha256 -c \ SRK1_sha256_2048_65537_v3_ca_crt.pem,\ SRK2_sha256_2048_65537_v3_ca_crt.pem,\ SRK3_sha256_2048_65537_v3_ca_crt.pem,\ SRK4_sha256_2048_65537_v3_ca_crt.pem The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further steps as explained in HAB guides available under doc/imx/habv4/guides/ directory. 3. step-by-step procedure on how to sign and securely boot a bootloader image on i.MX8M Nano devices 3.1 Enabling the secure boot support in U-Boot clone the u-boot from the git link https://source.codeaurora.org/external/imx/uboot-imx Enable the secure boot support in u-boot - Defconfig: CONFIG_SECURE_BOOT=y CONFIG_IMX_HAB=y from 2020.04 u-boot Build images $ make imx8mn_evk_defconfig $ make Output images $(UBOOT_SRC)/u-boot-nodtb.bin $(UBOOT_SRC)/spl/u-boot-spl.bin $(UBOOT_SRC)/arch/arm/dts/fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3.2 ARM Trusted Firmware Get the ATF from the below mentioned source link https://source.codeaurora.org/external/imx/imx-atf Build images $ make PLAT=imx8mn bl31 Output images $(ATF_SRC)/build/imx8mn/release/bl31.bin‍‍‍‍‍‍‍‍‍‍‍‍ 3.3 Get DDR FW images $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin $ chmod 777 firmware-imx-8.0.bin $ ./firmware-imx-8.0.bin Accept the LICENSE AGREEMENT $ cd firmware-imx-8.0.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍/firmware/ddr/synopsys‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Output images $(DDRFW_SRC)/lpddr4_* 3.4 Get IMX-MKIMAGE source https://source.codeaurora.org/external/imx/imx-mkimage Below mentioned are the steps to generate bootloder using mkimage Gather necessary images SPL and U-boot images - u-boot-nodtb.bin - u-boot-spl.bin - fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ATF image - bl31.bin DDR firmware images - lpddr4_pmu_train_1d_dmem.bin - lpddr4_pmu_train_1d_imem.bin - lpddr4_pmu_train_2d_dmem.bin - lpddr4_pmu_train_2d_imem.bin Copy these files to imx-mkimage/iMX8M directory 3.5 Build i.MX8MN boot image flash.bin $ make SOC=iMX8MN flash_evk ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 dcd_off 0x0 image_off 0x40 csf_off 0x24a00 spl hab block: 0x911fc0 0x0 0x24a00 Second Loader IMAGE: sld_header_off 0x58000 sld_csf_off 0x59020 sld hab block: 0x401fcdc0 0x58000 0x1020 $ make SOC=iMX8MN print_fit_hab ./print_fit_hab.sh 0x60000 evk.dtb 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 3.6 Creating the CSF description file The build log provided by imx-mkimage can be used to define the "Authenticate Data" parameter in CSF. - SPL "Authenticate Data" addresses in flash.bin build log: spl hab block: 0x911fc0 0x0 0x24a00 - "Authenticate Data" command in csf_spl.txt file: Blocks = 0x911fc0 0x0 0x24a00 "flash.bin" - FIT image "Authenticate Data" addresses in flash.bin build log: sld hab block: 0x401fcdc0 0x57c00 0x1020 - FIT image "Authenticate Data" addresses in print_fit_hab build log: 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 - "Authenticate Data" command in csf_fit.txt file: Blocks = 0x401fcdc0 0x57c00 0x1020 "flash.bin", \ 0x40200000 0x5B000 0xC3AB0 "flash.bin", \ 0x402C3AB0 0x11EAB0 0x78F0 "flash.bin", \ 0x960000 0x1263A0 0xA1B0 "flash.bin", \ 0xBE000000 0x130550 0x10 "flash.bin"   3.7 Avoiding Kernel crash in closed devices - Add Unlock MID command in csf_spl.txt: [Unlock] Engine = CAAM Features = MID 3.8 Signing the flash.bin binary The CST tool is used for singing the flash.bin image and generating the CSF binary. Users should input the CSF description file created in the step above and receive a CSF binary, which contains the CSF commands, SRK table, signatures and certificates. - Create SPL CSF binary file: $ ./cst -i csf_spl.txt -o csf_spl.bin - Create FIT CSF binary file: $ ./cst -i csf_fit.txt -o csf_fit.bin 3.8 Assembling the CSF in flash.bin binary ------------------------------------------- The CSF binaries generated in the step above have to be inserted into the flash.bin image. The CSF offsets can be obtained from the flash.bin build log: - SPL CSF offset: csf_off 0x24a00 - FIT CSF offset: sld_csf_off 0x59020 The signed flash.bin image can be then assembled: - Create a flash.bin copy: $ cp flash.bin signed_flash.bin - Insert csf_spl.bin in signed_flash.bin at 0x24a00 offset: $ dd if=csf_spl.bin of=signed_flash.bin seek=$((0x24a00)) bs=1 conv=notrunc - Insert csf_fit.bin in signed_flash.bin at 0x59020 offset: $ dd if=csf_fit.bin of=signed_flash.bin seek=$((0x59020)) bs=1 conv=notrunc - Flash signed flash.bin image: $ sudo dd if=signed_flash.bin of=/dev/sd<x> bs=1K seek=33 && sync 3.9 Verifying HAB events ------------------------ The next step is to verify that the signatures included in flash.bin image is successfully processed without errors. HAB generates events when processing the commands if it encounters issues. Prior to closing the device users should ensure no HAB events were found, as the example below: - Verify HAB events: => hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 3.10 Programming SRK Hash ------------------------- The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs. - Dump SRK Hash fuses values in host machine: $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin 0x20593752 0x6ACE6962 0x26E0D06C 0xFC600661 0x1240E88F 0x1209F144 0x831C8117 0x1190FD4D - Program SRK_HASH[255:0] fuses on i.MX8MN devices: => fuse prog 6 0 0x20593752 => fuse prog 6 1 0x6ACE6962 => fuse prog 6 2 0x26E0D06C => fuse prog 6 3 0xFC600661 => fuse prog 7 0 0x1240E88F => fuse prog 7 1 0x1209F144 => fuse prog 7 2 0x831C8117 => fuse prog 7 3 0x1190FD4D 3.10 Completely secure the device ---------------------------------- Additional fuses can be programmed for completely secure the device, more details about these fuses and their possible impact can be found at AN4581[1]. - Program SRK_LOCK: => fuse prog 0 0 0x200 - Program DIR_BT_DIS: => fuse prog 1 3 0x8000000 - Program SJC_DISABLE: => fuse prog 1 3 0x200000 - JTAG_SMODE: => fuse prog 1 3 0xC00000

This document shows how to build genivi step by step, but I haven’t tested the images yet, before building the images, pls refer to the host setup and host packages according to the yocto project user’s guide, I don’t mention here again, this is for imx8mq as example, you can choose the different board name to build   Before building the genivi package, customer also can refer to the kernel and image name from: https://github.com/GENIVI/meta-ivi/tree/master   4.9.88 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo    2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH    3. Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-rocko -m imx-4.9.88-2.0.0_genivi.xml $ repo sync   4.update Weston 3.0.0 to Weston 4.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build DISTRO=nxp-imx-genivi-wayland MACHINE=imx8mqevk source ./nxp-setup-genivi.sh -b genivi-wayland   $bitbake  pulsar-image    6.Error fix if you don’t update Weston, you should get the error message like The error shows required Weston >=4.0.0, but current bsp includes Weston version is 3.0.0, so you need to update the Weston to the 4.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/   $ bitbake -c cleansstate wayland-ivi-extension $ bitbake  wayland-ivi-extension $ bitbake  pulsar-image   4.14.95 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-warrior -m imx-4.19.35-1.1.0_genivi.xml $ repo sync   4. change Weston 6.0.1 to Weston 5.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    6.Error fix if you don’t change Weston, you should get the error message like so try to change the Weston to the 5.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics   $ bitbake -c cleansstate weston $ bitbake  weston $ bitbake  meta-ivi-image     5.4.24 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.24-2.1.0_genivi.xml $ repo sync   4. image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    

Voltage overshoot (>1.8V) is found on VDD_ARM_SSOC_IN when the EVK board is powered down by POWER BUTTON long pressed after the Linux kernal loaded. It would not happen if only U-boot is run. It happens also when the system recovers from idle. The overshoot is out of i.MX6UL maximum rating.

    The document is about how to use WSL2 to compile yocto(android is the same process)