Network

The phyCORE-AM62x Development Kit can be operated as a disk-less system by hosting its bootloader, kernel, device tree and root filesystem on a remote server and then loading/mounting these artifacts over a Local Area Network. This approach is very convenient throughout development because you can quickly build and test changes to your kernel and root filesystem without having to update a physical boot device (such as the bootable SD Card). Furthermore, it makes file transfers between your Host Machine and phyCORE-AM62x Development Kit easy since they will effectively have shared access to the same directories.

These steps were verified using the same Host Machine outlined in the Host Requirements section of the Build the BSP guide, go check out that guide first if you still haven’t setup an Ubuntu 20.04 Host Machine.

Host Setup (Ubuntu)

First, run the following commands to satisfy some Host dependencies required for network boot:

host:~$ sudo apt update
host:~$ sudo apt install isc-dhcp-server tftpd-hpa nfs-kernel-server

Note

firewalld can be installed to configure iptables if you have an active firewall on your system. Ubuntu ships with UFW (The default firewall manager) disabled.

# To install firewalld
host:~$ sudo apt install firewalld
# To configure the TFTP port
host:~$ sudo firewall-cmd --add-port=69/udp
# To configure the NFS port
host:~$ sudo firewall-cmd --add-port=2049/tcp

We will need our Host Machine’s IPv4 address. Use the following command to check your Host’s IP address:

host:~$ ip addr
Example Output
host:~$ ip addr
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: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:65:f0:c4 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 172.22.10.18/24 brd 172.22.10.255 scope global dynamic noprefixroute ens33
        valid_lft 592193sec preferred_lft 592193sec
    inet6 fe80::31d5:7fa:472f:c8ea/64 scope link noprefixroute
        valid_lft forever preferred_lft forever

In the above example output, it can be seen that this Host Machine has a network interface named “ens33” with the IPv4 address 172.22.10.18 assigned to it. We will need this IPv4 address later so keep it handy.

Note

Depending on your LAN, IT department’s routing rules, and/or your specific Host Machine installation (virtual versus native) there may be additional consideration when establishing a valid network connection between your Host Machine and Target hardware.

In general, you usually need your Target device and Host Machine on the same subnet (ie the Host Machine and Target device should be assigned similar IPv4 addresses where all numbers match, such as 172.22.10.X where only the X is different for the two devices). This usually isn’t a issue if both the Host and Target device are connected to the same network switch.

In the case that your Ubuntu Host Machine is setup as a virtual machine (VM), you may need to modify the VM’s Networking settings:

  • Network Address Translation (NAT) mode is often times the default networking configuration for VMs and causes the underlying Host to route traffic between the VM and the network (the VM is essentially hidden behind the underlying Host from the perspective of the network). While NAT mode is great for anonymously connecting your VM to a network, it makes it invisible to other devices such as the phyCORE-AM62x Development Kit and thus prevents Network Boot from working properly.

  • Bridged mode allows your VM to connect directly to the network, replicating a physical device connection. You’ll generally want your VM in Bridged mode whenever it runs network services, which would allow devices such as the phyCORE-AM62x to access it.

Setup DHCP Server

phyCORE-AM62x supports loading SPL and its bootloader (U-Boot) over the network using DHCP/BOOTP protocol. The DHCP server replying to DHCP/BOOTP requests from the SoC must provide filename to be fetched over TFTP for each stage depending on the Vendor-Class-Identifier (VCI) DHCP field specified in the request. VCI DHCP field is filled out by the ROM and subsequent stages and corresponding binaries files to be sent over TFTP are listed in the table below.

Note

  • Ethernet RGMII boot is supported over ETH0 on phyCORE-AM62x SoC.

  • Link info Bootmode pin needs to be ON along with RGMII boot mode selection Bootmode pins.

Host (Ubuntu)

  • Connect phyCORE-AM62x’s ETH0 port to the host machine with an ethernet cable

  • Configure DHCP server; on Ubuntu: “/etc/dhcp/dhcpd.conf”

Host (DHCP Server)

subnet 192.168.0.0 netmask 255.255.255.0 {
    range dynamic-bootp 192.168.0.2 192.168.0.16;
    if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
    {
    filename "tiboot3.bin";
    } elsif substring (option vendor-class-identifier, 0, 21) = "AM62X U-Boot R5 SPL"
    {
    filename "tispl.bin";
    } elsif substring (option vendor-class-identifier, 0, 22) = "AM62X U-Boot A53 SPL"
    {
    filename "u-boot.img";
    }
    range 192.168.0.17 192.168.0.25;
    default-lease-time 60000;
    max-lease-time 720000;
    next-server 192.168.0.1;
}

Note

Adapt subnet range depending on your network card! In our case, subnet is 192.168.0.0/24

Ensure our TFTP server is configured and the U-Boot binaries are present in the TFTP folder. Apply power to the board and observe the serial console. Please note that BOOTP requests and replies are mapped via VCI strings → vendor class identification strings.

Setup TFTP Server

TFTP (which stands for “trivial file transfer protocol”) is supported in PHYTEC’s BSP-Yocto-Ampliphy-AM62x-PD23.2.1 U-Boot by default so we will setup a TFTP server on our Ubuntu Host Machine to make our Linux kernel binaries available.

First create a directory to host the TFTP server:

host:~$ sudo mkdir /tftpboot
host:~$ sudo chmod 777 /tftpboot
host:~$ sudo chown nobody /tftpboot

Now we can setup our TFTP server configuration:

host:~$ sudo vim /etc/default/tftpd-hpa

Edit the contents of the TFTP config file such that it reflects the following before saving and closing the file (note that we are basically pointing our TFTP daemon to open up the /tftpboot directory we just created on port 69):

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure --create"

Start the TFTP daemon:

host:~$ sudo systemctl restart tftpd-hpa

Now that the TFTP server is up, we need to copy our desired u-boot and kernel binaries to it. Checkout the Build the BSP guide to give you a basis for customizing your software for your application requirements. For now, we’ll just populate our TFTP server with pre-built binaries:

host:~$ cd /tftpboot

# Required for loading Kernel via Network
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/Image
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/k3-am625-phyboard-lyra-rdk.dtb

# Required for loading Bootloader via Network
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/tiboot3.bin
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/tispl.bin
host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/u-boot.img

Setup NFS

A Network Filesystem Server (NFS) gives other systems the ability to mount a filesystem over a network. Once U-Boot loads our kernel via TFTP and boots it, the Linux kernel will eventually need a Root Filesystem to mount in order to boot all the way into Linux userspace.

Create a directory to host the NFS:

host:~$ sudo mkdir /nfsroot
host:~$ sudo chmod 777 /nfsroot
host:~$ sudo chown nobody /nfsroot

Now modify the NFS export table:

host:~$ sudo vim /etc/exports

Add the following to the end of exports before saving and closing:

/nfsroot        \*(rw,insecure,no_subtree_check,async,no_root_squash)

Start the NFS daemon:

host:~$ sudo systemctl restart nfs-kernel-server

Now that the NFS is up, we just need to populate it with our desired root filesystem. Checkout the Build the BSP guide to give you a basis for customizing your software for your application requirements. For now, we’ll just populate our NFS with a pre-built root filesystem:

host:~$ wget https://download.phytec.de/Software/Linux/BSP-Yocto-AM62x/BSP-Yocto-Ampliphy-AM62x-PD23.2.1/images/ampliphy-xwayland/phyboard-lyra-am62xx-3/phytec-qt5demo-image-phyboard-lyra-am62xx-3.tar.xz
host:~$ sudo tar -xJf phytec-qt5demo-image-phyboard-lyra-am62xx-3.tar.xz -C /nfsroot && sync
host:~$ rm phytec-qt5demo-image-phyboard-lyra-am62xx-3.tar.xz

The NFS should now be ready for network booting the kernel from the bootloader!

Target Setup (phyCORE-AM62x)

Network Boot - Kernel

We can configure our phyCORE-AM62x‘s bootloader to grab the kernel and device trees over the network and use them for boot. This can be done by modifying the bootloader environment directly on the running phyCORE-AM62x.

Refer to the Quickstart guide for the basic steps required to boot your phyCORE-AM62x. When prompted, halt autoboot and stop in the U-Boot bootloader.

Connect your phyCORE-AM62x Development Kit’s ETH0 port to your Local Area Network using a CAT-5e cable.

Note

BSP-Yocto-Ampliphy-AM62x-PD23.2.1 only supports 1x ethernet port in the U-Boot bootloader by default. You MUST use ETH0 (reference designator X7) for these steps to work.

By default, our BSPs boot with the server IP set to 192.168.3.10 and nfsroot to /nfsroot. Enter the following commands to modify the bootloader environment and save it to non-volatile memory.

Here we can replace “<host-ip-address>” with the actual IPv4 address of your Host Machine (found near the beginning of this guide) or change to a different NFS root path:

uboot:~# setenv serverip <host-ip-address>
uboot:~# setenv nfsroot </path/to/nfs>
uboot:~# saveenv

Now we can proceed with boot:

uboot:~# boot

Once fully booted into Linux, you can double check that your root filesystem is mounted over a network (as opposed to the 2nd, unused rootfs partition of the SD Card) with the following command:

phyboard-lyra-am62xx-3:~# mount | grep nfs
Example Output
phyboard-lyra-am62xx-3:~# mount | grep nfs
172.22.10.18:/nfsroot on / type nfs4 (rw,relatime,vers=4.0,rsize=4096,wsize=4096,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=172.22.30.129,local_lock=none,addr=172.22.10.18)