Introduction

This Quickstart guide describes the tools and provides the know-how to install and work with the Linux Board Support Package (BSP) for the phyCORE-AM68x/TDA4x Alpha Kit. This guide shows you how to do everything including installing the appropriate tools and sources, building custom kernels, and deploying the OS in order to operate the software and hardware.

This kit is currently in Alpha Status. There are several topics to keep in mind while working with this kit and guide:

• The phyCORE-AM68x/TDA4x will go through several functional changes during the Alpha Stage of development. Due to this, this Quickstart guide may change without any prior notice.
• The phyCORE-AM68x/TDA4x has some functionality that is not currently operational. Please be aware of this when working with the Alpha Kit.
• This Quickstart guide is only for booting and starting the basic functionality of the phyCORE-AM68x/TDA4x.
• Hardware manual for the phyCORE-AM68x/TDA4x can be found here: https://www.phytec.de/produkte/system-on-modules/phycore-am68x-tda4x/
• The following manuals will be available in future releases of the phyCORE-AM68x/TDA4x:

* Yocto Reference Manual - provides information on Yocto, which is used with most PHYTEC products
* Board Support Package (BSP) Manual - provides detailed instructions on running the tools which are used to build various software
* Development Environment Guide - provides instructions to prepare and start the programs Eclipse and QT Creator, as well as setting up a Linux host system
* Pin Muxing Table - a complete list of all signal chains from processor to carrier board output. Signal level, signal type, and other useful information is also included.

For more information or details regarding the phyCORE-AM68x/TDA4x, please contact the PHYTEC Sales department or find information at https://www.phytec.de/produkte/system-on-modules/phycore-am68x-tda4x/

Requirements

The following components and system requirements are necessary to successfully complete this Quickstart. Deviations from these requirements are possible but may require workarounds.

Known Issues

This evaluation kit is currently in the alpha phase and we know the following issues

• The display backlight PWM is not set to the default value occasionally.
  • The workaround is to set brightness after boot manually for example: "echo 8 > /sys/class/backlight/backlight/brightness"
• The display port is not usable in the current hardware configuration. If you plan to use the display port please contact PHYTEC Support to get a special version of display port-enabled hardware.
• eth0 is configured as 10/100/1000 MBit but works only stable with 10/100 MBit
• The MIPI DSI interface has the RGB colors flipped occasionally.
• The eMMC is limited to HS200 speed mode.
• VDD_CPU_AVS is running at default 800mV for VDD_CORE, which may not be enough for some SoCs to work stably under all conditions 

Hardware

Included in Kit

1. phyCORE-AM68x/TDA4x  SOM (PCM-074-1TG634F2I.A1)
2. phyBOARD-Izar Alpha carrier board (PBA-C-27-001.A0)
3. Power adapter supplying 24 V / 2.5 A (SV063)
   
4. Ethernet cable (WK114)
   
5. USB-A to USB Micro Cable (WK345)
   
6. SD Card with prepared prebuilt images
   
7. Serial Cable (WK548)
8. phyCAM-M camera module (VM-016-M-COL-M12) with camera cable (WF271)

Components

Connecting the phyBOARD-Izar

There are a few manual connections that you will need to make before using the phyBOARD-Izar.

Connecting the USB Debug Interface

For the following steps, a console connection via USB is required. You can use the included USB Type-A to micro USB cable.

1. Connect your PC's USB port with the micro USB connector of the phyBOARD-Izar (X1). After plugging the micro USB cable into X1 a green LED (D13) will light up to indicate a present USB bus voltage.
2. If necessary, install the Driver for FTDI FT2232H: https://ftdichip.com/drivers/vcp-drivers/
3. Your device manager will show two new COM ports. Select the second COM port. On the processor side, MAIN_UART8 is the default debug UART of the SoM.
4. Setup your Terminal with the following parameters:
   • Speed: 115200 baud
   • Data bits: 8
   • Stop bits: 1
   • Parity: None
   • Flow control: None

On Linux a simple serial device tool like tio can be used:

host$ sudo apt update
host$ sudo apt install tio
host$ tio /dev/ttyUSB1

Linux Host PC

Before you can work with the phyCORE-AM68x/TDA4x Board Support Package (BSP), you will need a host PC with the following minimum requirements:

• A modern Linux operating host system either natively or via a virtual machine.
• The underlying BSP is built using Ubuntu 20.04 LTS 64-bit. Other distributions will likely work but note that some setup information, as well as OS-specific commands and paths, may differ. See Yocto Kirkstone compatible distributions
• VMWare Workstation, VMWare Player, and VirtualBox are possible solutions if you want to use a virtual machine.
• Root access to your Linux host PC. Some commands in this guide will not work if you do not have sudo access (e.g. package installation, formatting an SD card).
• At least 40 GB to 50 GB of free space on the build partition of the host PC.
• An SD card reader, operational under Linux.
• An active internet connection.

Getting Started with the Included SD Card

This section is designed to get the board up and running with the SD card included in the kit, which has been prepared with pre-built images.

Booting from the SD Card

This section describes how to boot the phyBOARD-Izar with the pre-built images on the included SD card.

• Insert the micro SD card into the SD card slot of the board.
• Start your favorite terminal software (e.g. Minicom or Tera Term) on your host PC and configure it for 115200 baud, 8 data bits, no parity, and 1 stop bit (8n1) with no handshake.
• Connect the power supply to the power connector (please note the polarity shown in the picture Power Schematic).
• Set the correct Bootoption <Picture, maybe?>

The console output can be viewed in your terminal window. If everything is done correctly, the login prompt will be shown at the end of the booting process:

ampliPHY XWayland (Phytec XWayland Distribution) BSP-Yocto-Ampliphy-AM68x-ALPHA2 phyboard-izar-am68x-2 ttyS2

phyboard-izar-am68x-2 login:

The default login is:

• User: root
• Password: root

Powering the Board

We recommend powering the phyBOARD-Izar with the power supply (SV063) included in the kit. Connect the power supply to the Power-In connector (X10).

Prebuild Images

PHYTEC provides prebuild images and release notes for the phyBOARD-Izar-TDA4x/AM68x. They can be downloaded here: https://download.phytec.de/Software/Linux/BSP-Yocto-AM68x/BSP-Yocto-Ampliphy-AM68x-ALPHA2/images/

Git Repositories

You can find all PHYTEC Git repositories on:

git://git.phytec.de

or

https://github.com/phytec/

Used u-boot repository:

https://github.com/phytec/u-boot-phytec-ti.git

Our u-boot version is based on the Ti u-boot.

Used Linux kernel repository:

https://github.com/phytec/linux-phytec-ti

Our AM68x/TDA4x kernel is based on theTi Linux kernel.

Building the BSP

This section will guide you through the general build process of the TI Jacinto BSP using Yocto and the phyLinux script

Get the BSP

There are two ways to get the BSP sources. You can download the complete BSP sources from our download page:BSP-Yocto-AM68x; or  build it yourself with Yocto. This is particularly useful if you want to make customizations. 

The phyLinux script is a basic management tool for PHYTEC Yocto BSP releases written in Python. It is mainly a helper to get started with the BSP structure. 

• Create a fresh project folder, get phyLinux, and make the script executable:

host$ mkdir ~/yocto
host$ cd yocto/
host$ wget https://download.phytec.de/Software/Linux/Yocto/Tools/phyLinux
host$ chmod +x phyLinux

• Run phyLinux

host$ ./phyLinux init

• During the execution of the init command, you need to choose your processor platform (SoC), PHYTEC's BSP release number, and the hardware you are working on.

  6 # am68x
  1 # BSP-Yocto-Ampliphy-AM68x-ALPHA2
  3 # phyboard-izar-am68x-2

  y-Branch

  To build the current development state select BSP-Yocto-Ampliphy-AM68x-PD24.1.y instead of BSP-Yocto-Ampliphy-AM68x-ALPHA2

After the execution of the init command, phyLinux will print a few important notes as well as information for the next steps in the build process.

Starting the Build Process

• Set up the shell environment variables:

host$ . sources/oe-core/oe-init-build-env

• The current working directory of the shell should change to build/.

• Build your image:

host$ bitbake phytec-headless-image

BSP Images

All images generated by Bitbake are deployed to ~/yocto/build/deploy/images/<machine>. The following list shows for example all files generated for the  AM68x/TDA4x phyboard-izar-am68x-* machine:

• tiboot3.bin: The first bootloader image, loaded by the boot ROM, contains both the AM68x’s Device Management & Security Controller (DMSC) firmware and the Cortex-R5 Secondary Bootloader (SBL).
• tispl.bin: The second bootloader image, loaded by the R5 SBL, contains the ARM Trusted Firmware (ATF), Open Portable Trusted Execution Environment (OPTEE) and the Cortex-A72 SL.
  
• u-boot.img:Bootloader for Cortex-A72 Linux and for other software destined for the Cortex-R5 cores.
  
• Image: Linux kernel image
• k3-am68-phyboard-izar-rdk.dtb: Kernel device tree file
• k3-am68-phyboard-izar-*.dtbo: Kernel device tree overlay files
• phytec-qt5demo-image-phyboard-izar-am68x-2.tar.xz: Root file system 
  
• phytec-qt5demo-image-phyboard-izar-am68x-2.wic.xz: SD card image

Accessing Development States

PHYTEC ALPHA BSP reflects the development state of the BSP on the way to the first series release. We publish on a regular basis the progress of the BSP development. The latest development state can be checked out.

host$ phyLinux init -p am68x -r BSP-Yocto-Ampliphy-AM68x-PD24.1.y

This will check out the HEAD of the kirkstone branch in the meta-phytec and meta-ampliphy yocto layers. The available manifest for our AM68x/TDA4xboards can be found in our git public repository:

https://git.phytec.de/phy2octo/tree/?h=am68x

Update and Device Management

This section of the product wiki contains guides for common development tasks associated with updating the software on the phyCORE-AM68x/TDA4x SOM.

Create a Bootable SD Card

In order to boot the phyCORE-AM68x/TDA4x development kit into Linux, it must load valid software from a memory storage device. It is typical for production systems to boot software from an onboard (non-removable) memory storage device such as eMMC memory but booting from an SD Card is more convenient during development. The phyCORE-AM68x/TDA4x development kit is configured to boot from an SD Card by default.

A pre-configured SD Card should have been included in the box with your development kit but this guide will walk through the creation of a bootable SD Card using Pre-Built Binaries or images you have generated on your own by following the Build the BSP guide.

Requirements

• Ubuntu 20.04 LTS, 64-bit Host Machine

  • If using a virtual machine, VMWare Workstation, VMWare Player, and VirtualBox are all viable solutions.

• SD Card Reader operational under the Ubuntu Host Machine

• 4GB SD Card or larger

Flashing a Complete Image

Flashing is a term used to describe the process of burning software images to a flash memory storage device, hence flashing. This section of the guide will outline the steps for flashing the complete .wic.xz image format to an SD Card. The .wic.xz image format is a compressed binary consisting of all the necessary binaries, as well as information about the required disk partitions needed for booting the phyCORE-AM68x/TDA4x into Linux. This includes the bootloader, kernel, and root filesystem.

• Install bmap-tools on your host Machine:

host$ sudo apt-get update
host$ sudo apt install bmap-tools

• Run the following command without the SD Card connected to the Host Machine.

host$ ls /dev/disk/by-id/*

• Connect the SD Card to the Ubuntu Host Machine.
• Run the following command again with the SD Card connected to the Host Machine.

host$ ls /dev/disk/by-id/*

• Navigate to the directory containing the ‘.wic.xz’ and ‘.wic.bmap’ files you wish to flash. This might be wherever you downloaded the pre-built image or it could be the deployment directory of your local BSP build at $BUILDDIR/deploy/images/phyboard-izar-am68x-1/

host$ cd <image location>

• Flash the .wic.xz image to the SD Card:

host$ sudo bmaptool copy phytec-qt5demo-image-phyboard-izar-am68x-2.wic.xz /dev/disk/by-id/<your device>

• To boot from the SD-Card select the bootmode: S8 00000000 S7 01000001

Updating Individual Parts

Once the SD Card has been formatted the first time via flashing the complete .wic.xz image, you do not need to flash the entire contents of the SD Card image again to update the image components. The bootloader, kernel, and root filesystem can be updated individually (depending on the changes being tested) to potentially save a lot of time during development.

Updating the Kernel and the Bootloader

• First, remove the existing kernel image and device tree files:

host$ rm /media/<user>/boot/Image
host$ rm /media/<user>/boot/k3-am68-phyboard-izar-rdk.dtb
host$ rm /media/<user>/boot/tiboot3.bin
host$ rm /media/<user>/boot/tispl.bin
host$ rm /media/<user>/boot/u-boot.img

• Copy the new Linux kernel, device tree binaries, applicable device tree overlays, and the bootloader binaries to the SD Card’s Boot partition:

host$ cp Image /media/<user>/boot/
host$ cp k3-am68-phyboard-izar-rdk.dtb /media/<user>/boot/
host$ cp tiboot3.bin /media/<user>/boot/ 
host$ cp tispl.bin /media/<user>/boot/ 
host$ cp u-boot.img /media/<user>/boot/ 
host$ sudo sync /media/<user>/root/

Updating the Root Filesystem

• Connect your SD Card to the Host Machine and identify the root filesystem’s mount point. This can be done using the mount utility from above:

host$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1975752k,nr_inodes=493938,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=400172k,mode=755)
/dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro)
...
/dev/sde1 on /media/<user>/boot type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sde2 on /media/<user>/root type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)

We can see in this example output the SD Card’s two partitions are mounted on /media/<user>/boot and /media/<user>/root respectively.

• Delete the contents of the SD Card’s root filesystem partition:

host$ sudo rm -rf /media/<user>/root/*

• Unpack the root filesystem tarball into the SD Card’s existing root filesystem partition’s mount point:

host$ sudo tar -xf tisdk-default-image-phyboard-izar-am68x-1.tar.xz -C /media/<user>/root/
host$ sudo sync /media/<user>/root/

Device Tree Settings

Change the Device Tree

By default, U-Boot loads the dtb file named oftree which is a copy of k3-am68-phyboard-izar-rdk.dtb as the active device tree during boot. This portion of the guide will instruct how to change U-boot to load a different device tree by a different name.

• Power on the board and press any key to stop autoboot and enter U-boot.
• Change the default device tree.

=> setenv fdtfile <dtb name>
=> saveenv

U-Boot will now load the dtb file named ‘<dtb name>’ automatically during subsequent boots (just replace it with the appropriate file name when you run the command)

Working with Overlays

The PHYTEC BSP comes with various device tree overlays to support removable components for the phyBOARD. These dtbo files are all available on the default development kit SD card. The following list shows an overview of all available overlays:

1. k3-am68-phyboard-izar-lvds-ac199.dtbo
2. k3-am68-phyboard-izar-lvds-ac200.dtbo
3. k3-am68-phyboard-izar-pwm-fan.dtbo
4. k3-am68-phyboard-izar-vm016-mipi-csi0.dtbo
5. k3-am68-phyboard-izar-vm016-mipi-csi1.dtbo
6. k3-am68-phyboard-izar-vm017-mipi-csi1.dtbo
7. k3-am68-phyboard-izar-vm017-mipi-csi1.dtbo
8. k3-am68-phyboard-izar-vm020-mipi-csi1.dtbo
9. k3-am68-phyboard-izar-vm020-mipi-csi1.dtbo

• U-boot has an extra environment variable to apply overlays. Therefore, set the environment variable “overlays” with one of the available overlay name and boot.

=> setenv overlays k3-am68-phyboard-izar-lvds-ac200.dtbo

• Moreover, it’s possible to enable multiple overlays by separating them with a space.

=> setenv overlays k3-am68-phyboard-izar-lvds-ac200.dtbo k3-am68-phyboard-izar-vm016-mipi-csi0.dtbo
=> boot

• The previous section only enables overlays for the current boot. Run “saveenv” after setting the environment variable will store it permanently on the storage device currently booted from.

• In order to revert the U-Boot environment back to its original settings, run the following:

  => env default -f -a
  => saveenv
  => boot

• In Linux, the /boot/bootenv.txt located on the FAT partition of the SD Card can also be used to enable overlays.
• Therefore, enable an overlay in a similar way by writing overlays=overlay1 overlay2 ...

root@phyboard-izar-am68x-1:~# cat /boot/bootenv.txt 
overlays=k3-am68-phyboard-izar-lvds-ac200.dtbo k3-am68-phyboard-izar-vm016-mipi-csi0.dtbo

eMMC

By default, the phyCORE-AM68x/TDA4x development kit is configured to boot from an SD Card. This is generally one of the most convenient methods to boot your hardware throughout development because it allows for easy software updates and file transfers between your Host and target systems. In addition to creating a standard bootable SD card formatted with the phyCORE-AM68x/TDA4x Linux BSP, the following steps can be used to burn bootable software images to the onboard eMMC flash memory of the SOM, thus freeing up the SD Card slot on the carrier board.

The easiest way to access the SOM’s eMMC is to boot the SOM into Linux from an SD Card (you may already be doing this). The Linux instance running from the SD Card will need access to software binaries to flash to the eMMC.

Erasing the Device

It is possible to erase the eMMC device directly rather than overwriting it with zeros. The eMMC block management algorithm will erase the underlying MLC memory cells or mark these blocks as discard. The data on the device is lost and will be read back as zeros.

• After booting from the SD card execute:

target$ blkdiscard -s /dev/mmcblk0

The option -s ensures that the command waits until the eMMC device has erased all blocks.

Start from a Clean eMMC

• After logging in as root, check the eMMC for existing filesystem partitions:

You should see something like the following:

target$ fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 28.83 GiB, 30937186304 bytes, 60424192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Flashing the eMMC

• Now we can flash our eMMC using the same SD Card binary we used to create the bootable SD Card. For example from a mounted USB drive:

root@phyboard-izar-am68x-2:~#  bmaptool copy /run/media/sda1/phytec-qt5demo-image-phyboard-izar-am68x-2.wic.xz /dev/mmcblk0

• To boot from the eMMC user partition select the bootmode: S8 00000000 S7 10001011
  

To boot from the eMMC boot partition 0 the bootloader binaries need to be flashed first.

• First, the read-only bit of the eMMC boot partition 0 needs to be disabled:

root@phyboard-izar-am68x-2:~# echo 0 > /sys/class/block/mmcblk0boot0/force_ro

• Then the binaries can be flashed:

root@phyboard-izar-am68x-2:~# dd if=/boot/tiboot3.bin of=/dev/mmcblk0boot0 count=1024 conv=fsync
root@phyboard-izar-am68x-2:~# dd if=/boot/tispl.bin of=/dev/mmcblk0boot0 seek=1024 count=3072 conv=fsync
root@phyboard-izar-am68x-2:~# dd if=/boot/u-boot.img of=/dev/mmcblk0boot0 seek=5120 count=3072 conv=fsync

• Now the boot partition can be configured and enabled for booting:

root@phyboard-izar-am68x-2:~# mmc bootpart enable 1 1 /dev/mmcblk0
root@phyboard-izar-am68x-2:~# mmc bootbus set single_backward x1 x8 /dev/mmcblk0

• Now the bootmode can be selected: S8 00000010 S7 10001011

Copying Files to the Device

There are several ways of transferring files to and from your target device. Please reference the following for some possible methods.

Secure Copy Protocol

Secure Copy Protocol (SCP) is built around a Secure Shell connection (SSH) and offers all the same security features. One advantage of using this method for transferring single files is that it is generally pretty fast but you won’t get interactive functionality when pulling multiple files from a remote server. For example, you won’t be able to list out directory contents and see what other files are available. SCP also has no file size limitations.

• Use the following command to transfer your file:

host$ scp <insert-path-to-file> root@<insert-IP-address>:~

• Your copied file will appear in the root directory on the target device.
• To go the other direction and retrieve files from the Target Hardware, just flip the source and destination arguments:

host$ scp root@<insert-IP-address>:<insert-name-of-file> <insert-path-to-destination>

USB Storage Device

USB storage devices should mount automatically, the mount utility can help show where:

target$ mount | grep sda
/dev/sda1 on /run/media/sda1 type vfat (rw,relatime,gid=6,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

In the above example output we can see that the device sda (located at /dev/sda) has a single partition /dev/sda1 mounted on /run/media/sda1.

• Generate a random 10 MB file to test transferring data from the storage device.

target$ dd if=/dev/urandom of=test.file count=10 bs=1M

• Copy the file to your storage device.

target$ cp test.file /run/media/sda1 && sync

• Copy the test file we previously created during the write process back to the host:

target$ cp /run/media/sda1/test.file readback-usb.file && sync

• We can double-check that the file was successfully copied to and from the USB device by checking the md5sum of the file:

root@phyboard-izar-am68x-1:~# md5sum test.file readback-usb.file
eab3b13f7ffa7f5c22e8b0c9c061c874  test.file
eab3b13f7ffa7f5c22e8b0c9c061c874  readback-usb.file

• Make sure the drive is unmounted prior to physically disconnecting the device. Failure to do so may result in loss of data and corruption of files

target$ umount /run/media/sda1/

The Bootable SD Card (Root Partition)

Since our Host Machines have access to the SD Card readers, we can use the bootable SD Card itself to transfer files to and from the development kit too, the only downside for this is that you will want to poweroff the development kit before removing the primary boot media.

• Remove the SD Card and connect it to your Host Machine. You will not be able to place files on the SD Card using Windows because the SD Card is formatted for Linux and Windows won't recognize it.

• In order to copy files to the SD Card using the Terminal, this can be done with the standard cp (copy) command. See the above section utilizing a USB storage device for more information.

Accessing Peripherals

Network

Ethernet links are provided via the ETH0 and ETH1 RJ45 connectors on the phyCORE-AM68x/TDA4x development kit. This guide shows you how to connect and use these interfaces.

Establishing a Connection

If a valid connection between the phyCORE-AM68x/TDA4x development kit and a DHCP-enabled network is made then the phyCORE-AM68x/TDA4x will automatically negotiate a connection and will be assigned a unique IPv4 address.

root@phyboard-izar-am68x-1:~# [ 4195.635691] am65-cpsw-nuss 46000000.ethernet eth0: Link is Down
[ 4210.995759] am65-cpsw-nuss 46000000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

After the connection is established, you can try the following command to ping a host. We’ll ping google.com in this example:

root@phyboard-izar-am68x-1:~# ping google.com -c 10
PING google.com (142.250.181.206): 56 data bytes
64 bytes from 142.250.181.206: seq=0 ttl=57 time=11.777 ms
64 bytes from 142.250.181.206: seq=1 ttl=57 time=11.742 ms
64 bytes from 142.250.181.206: seq=2 ttl=57 time=11.664 ms
64 bytes from 142.250.181.206: seq=3 ttl=57 time=11.602 ms
...

Finding the phyCORE-AM68x’s IPv4 address

To view the IP address assigned to your device’s network interfaces, use the following command:

root@phyboard-izar-am68x-2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 28:b5:e8:e2:fa:f5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.11/24 brd 192.168.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2ab5:e8ff:fee2:faf5/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c2:90:7d:3c:11:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.11/24 brd 192.168.4.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::c090:7dff:fe3c:1198/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:a0:c9:00:00:00 brd ff:ff:ff:ff:ff:ff
5: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can 
6: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can 
7: can2: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can 
8: can3: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can 

SSH into the phyCORE-AM68x/TDA4x

Once the phyCORE-AM68x/TDA4x’s IPv4 address is known, we can use it to interact with the development kit over the network. This section of the guide will walk through establishing an SSH connection with the hardware which can be a handy way to quickly get a second terminal session up and running. This might be useful if you are doing development directly on the target and need to process a second task in parallel with something running in the standard hardware UART console. In order to most easily follow this section of the guide, you will want both the phyCORE-AM68x/TDA4x’ and your Host Machine connected to the same local area network (LAN).

Using your Ubuntu Host Machine, start a new Terminal session and use the following command to ensure that ssh is installed:

host$ sudo apt update
host$ sudo apt install ssh

The phyCORE-AM68x/TDA4x Linux BSP has an SSH server installed and enabled by default so it is already pre-configured to accept SSH connections. Establish a connection with the development kit using the Host Machine:

host$ ssh root@192.168.3.11 

SPI Master

The AM68x/TDA4x has several SPI interfaces for general purposes and two to connect an OSPI or QSPI flash. On the SoM itself, an OSPI Nor flash is populated where the QSPI interface is routed to the main connector.

SPI NOR flash

phyCORE-AM68x/TDA4x is equipped with an OSPI NOR Flash and the phyBOARD-Izar mounts an additional QSPI NOR Flash. From Linux userspace, the NOR Flash partitions are accessible via /dev/mtd<N> devices where <N> is the MTD device number associated with the NOR flash partition to access. To find the correct MTD device number for a partition, run on the target:

target$ mtdinfo --all
Count of MTD devices:           2
Present MTD devices:            mtd0, mtd1
Sysfs interface supported:      yes

mtd0
Name:                           47040000.spi.0
Type:                           nor
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          512 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:0
Bad blocks are allowed:         false
Device is writable:             true

mtd1
Name:                           47050000.spi.0
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          1024 (67108864 bytes, 64.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:2
Bad blocks are allowed:         false
Device is writable:             true

GPIOs

The phyBOARD-Izar has a set of pins especially dedicated to a user I/Os. Those pins are connected directly to AM68x/TDA4x pins and are muxed as GPIOs. They are directly usable in Linux userspace. The processor has organized its GPIOs into two banks, one WKUP_GPIO with a maximum of 88 and one MAIN_GPIO with a maximum of 65 pins. But due to mixing, not all can be used.

In the schematic GPIOs are identified as <X>_GPIO0_<Y> (e.g. MAIN_GPIO0_07). <X> identifies the GPIO bank, while <Y> stands for the GPIO within the bank.

By contrast, the Linux kernel uses a single integer to enumerate all available GPIOs in the system. The formula to calculate the right number is:

Linux GPIO number: <N> = (<X> - 1) * 32 + <Y>

Accessing GPIOs from userspace will be done using the libgpiod. It provides a library and tools for interacting with the Linux GPIO character device. The used pins have to be configured as GPIO in the kernel before usage. Examples of the usage for some of the tools:

• Detecting the gpiochips on the chip:

root@phyboard-izar-am68x-2:~# gpiodetect
gpiochip0 [42110000.gpio] (89 lines)
gpiochip1 [600000.gpio] (66 lines)
gpiochip2 [tps6594-gpio] (11 lines)
gpiochip3 [pca9672] (8 lines)
gpiochip4 [4-0022] (24 lines)
 

• Show detailed information about the gpiochips. Like their names, consumers, direction, active state, and additional flags:

target$ gpioinfo gpiochip0

• Read the value of a GPIO (e.g GPIO 20 from chip0):

target$ gpioget gpiochip0 20

• Set the value of GPIO 20 on chip0 to 0 and exit tool:

target$ gpioset --mode=exit gpiochip0 20=0

RS232

The AM68x/TDA4x SoC provides up to 5 UART units. For hardware revision 0 only RS232 is supported. On the phyBOARD-Izar, they are configured as follows:

RS232

Configuration of the UART interface can be done with stty. For example:

target$ stty -F /dev/ttyS3 115200 raw -echo

CAN FD

The phyBOARD-Izar provides four CAN interfaces supporting CAN FD. They are supported by the Linux standard CAN framework which builds upon then the Linux network layer. Using this framework, the CAN interfaces behave like ordinary Linux network devices, with some additional features special to CAN. More information can be found in the Linux Kernel documentation:

https://www.kernel.org/doc/html/latest/networking/can.html

• To get information on can0, such as bit rate and error counters, type:

target$ ip -d -s link show can0

The information for can0 will look like:

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group de
fault qlen 10
       link/can promiscuity 0 minmtu 0 maxmtu 0 
       can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
            bitrate 500000 sample-point 0.875 
            tq 25 prop-seg 37 phase-seg1 32 phase-seg2 10 sjw 1
           flexcan: tseg1 2..96 tseg2 2..32 sjw 1..16 brp 1..1024 brp-inc 1
           flexcan: dtseg1 2..39 dtseg2 2..8 dsjw 1..4 dbrp 1..1024 dbrp-inc 1
           clock 40000000
           re-started bus-errors arbit-lost error-warn error-pass bus-off
           0                 0                    0                0                   0                  0 numtxqueues 1
numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
          RX: bytes packets errors dropped overrun mcast 
           0               0               0          0               0               0 
TX: bytes packets errors dropped carrier collsns 
0                0              0           0               0           0 

The CAN configuration is done in the systemd configuration file /lib/systemd/system/can0.service. For a persistent change of (as an example, the default bitrates), change the configuration in the BSP under ./meta-yogurt/recipes-core/systemd/systemd-machine-units/can0.service in the root filesystem and rebuild the root filesystem. In this ALPHA1 release so far the configuration over systemd is only done for the can0 and the can1 interface.

[Unit]
Description=can0 interface setup
 
[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/sbin/ip link set can0 up type can bitrate 500000
ExecStop=/sbin/ip link set can0 down
 
[Install]
WantedBy=basic.target

The can0.service is started by default after boot. You can start and stop it using:

target$ systemctl stop can0.service
target$ systemctl start can0.service

The bitrate can also be changed manually, for example, to make use of the flexible bitrate:

target$ ip link set can0 down
target$ ip link set can0 txqueuelen 10 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on

You can send messages with cansend or receive messages with candump:

target$ cansend can0 123#45.67
target$ candump can0

To generate random CAN traffic for testing purposes, use cangen:

target$ cangen

cansend --help and candump --help provide help messages for further information on options and usage.

I²C Bus

The AM68x/TDA4x contains four Multimaster fast-mode I²C modules called WKUP_I2C2, MAIN_I2C2, MAIN_I2C4 and MAIN_I2C5. PHYTEC boards provide plenty of different I²C devices connected to the I²C modules of the AM68x/TDA4x. This chapter will describe the basic device usage of some of the I²C devices integrated into our phyBOARD-Izar.

EEPROM

phyCORE-AM68x/TDA4x has two I²C EEPROMs populated connected to the WKUP_I2C0 bus and the phyBOARD-Izar mounts an additional EEPROM.

It is possible to read and write directly to the device

• To read and print the first 1024 bytes of the EEPROM as a hex number, execute:

target$ dd if=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=1 count=1024  | od -x

• To fill the whole EEPROM with zeros, use:

target$ dd if=/dev/zero of=/sys/class/i2c-dev/i2c-0/device/0-0051/eeprom bs=4096 count=1

RTC

RTCs can be accessed via /dev/rtc*. Because PHYTEC boards have often more than one RTC, there might be more than one RTC device file.

• To find the name of the RTC device, you can read its sysfs entry with:

target$ cat /sys/class/rtc/rtc*/name

• You will get, for example:

rtc-rv3028 3-0052
tps6594-rtc tps6594-rtc.4.auto

Date and time can be manipulated with the hwclock tool, using the -w (systohc) and -s (hctosys) options. To set the date, first, use date mmddhhMMyyyy.sec and then run hwclock -w to store the new date into the RTC. For more information about this tool, refer to the manpage of hwclock.

target$ date 061513482023.26
target$ hwclock -w -f /dev/rtc0

LEDs

There is a PCA9533 RGB LED controller mounted on the phyBOARD-Izar. Its LEDs can be configured via sysfs:

target$ echo default-on > /sys/class/leds/user-led1/trigger 
target$ echo 255 > /sys/class/leds/user-led2/brightness
target$ echo heartbeat > /sys/class/leds/user-led3/trigger

Display (LVDS)

phyBOARD-Izar has one dedicated LVDS interface.  LVDS (X46) is supported in the ALPHA release. We support a 10''EDT,ETML1010G3DRA display. LVDS is defined as a default display output.

Backlight Control

If a display is connected to the PHYTEC board, you can control its backlight with the Linux kernel sysfs interface. All available backlight devices in the system can be found in the folder /sys/class/backlight. Reading the appropriate files and writing to them allows you to control the backlight.

• To get, for example, the maximum brightness level (max_brightness) execute:

target$ cat /sys/class/backlight/backlight/max_brightness

Valid brightness values are 0 to <max_brightness>.

• To obtain the current brightness level, type:

target$ cat /sys/class/backlight/backlight/brightness

• Write to the file brightness to change the brightness:

target$ echo 4 > /sys/class/backlight/backlight/brightness

Display Server

By default, the phytec-qt demo runs on Wayland. To stop the demo, type:

root@phyboard-izar-am68x-2:~# systemctl stop phytec-qtdemo

To stop Weston, the Wayland compositor, type:

root@phyboard-izar-am68x-2:~# systemctl stop weston 

phyCAM-M Camera Module

To support a phyCAM-M phyBOARD-Izar the Device Tree overlay has to be enabled and the camera needs to be initialized, e.g. a VM-016 on CSI1 (x55):

• Enable the overlay :

  root@phyboard-izar-am68x-2:~# vi /boot/bootenv.txt
  
  ...
  root@phyboard-izar-am68x-2:~# cat /boot/bootenv.txt 
  overlays=k3-am68-phyboard-izar-lvds-ac200.dtbo k3-am68-phyboard-izar-pwm-fan.dtbo k3-am68-phyboard-izar-vm016-mipi-csi1.dtbo
  
  
  

• Check if the camera has been loaded:

  root@phyboard-izar-am68x-2:~# media-ctl -d0 -p

• Setup the camera:

  root@phyboard-izar-am68x-2:~# media-ctl -d0 -V "'ar0144 5-0010':0[fmt:SGRBG8_1X8/1280x800 (0,4)/1280x800]" -v

• To start a camera stream using the LVDS Display, launch a GStreamer pipeline for example:

  root@phyboard-izar-am68x-2:~# systemctl stop phytec-qtdemo
  
  root@phyboard-izar-am68x-2:~# systemctl stop weston
  
  root@phyboard-izar-am68x-2:~# gst-launch-1.0 v4l2src device=/dev/video2 ! video/x-bayer, width=1280, height=800, format=grbg ! bayer2rgb ! videoconvert ! kmssink sync=false driver-name=tidss force-modesetting=true

  Information

  Since the VPAC/ISP is not configured yet in this Alpha release all the format conversion has to be done in software which causes a high cpu load.

Thermal Management

SoC Thermal Management

The Linux kernel has integrated thermal management which is capable of monitoring SoC temperatures, reducing the CPU frequency, driving fans, advising other drivers to reduce the power consumption of devices, and – worst case – shutting down the system efficiently (https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt).

This section describes how the thermal management kernel API is used for the AM68x/TDA4x SoC platform. The  AM68x/TDA4x has internal temperature sensors for the SoC.

• The current temperature can be read in Millicelsius with:

target$ cat /sys/class/thermal/thermal_zone*/temp

• If mounted the I²C sensors on the SoM can be read using hwmon:

target$ cat /sys/class/hwmon/hwmon0/temp1_input 
and 
target$ cat /sys/class/hwmon/hwmon1/temp1_input 

PWM Fan

ThephyBOARD^®-Izar kit comes with a heatsink and a PWM fan mounted by default.

To see the status of the fan, check it's systemd service:

root@phyboard-izar-am68x-2:~# systemctl status fancontrol

The configuration for the fan is located at /etc/fancontrol and is set to keep the SoC at 60°C by default.