Package Management
The Yocto build system enables its users to not only build custom operating systems for their custom hardware, it also allows for the convenient setup of debian-style package feeds. These package repositories allow package manager software such as apt-get or opkg, running on the phyCORE-AM64x Development Kit, to search for pre-compiled libraries and utilities on the internet and install them for quick use. These near instant upgrades and changes to a Linux distribution are great for rapid prototyping.
As an example of who this guide might benefit: This guide might be very useful for a development team where 1 individual is in charge of the low-level stuff (like the Yocto BSP or Linux Kernel) and the rest of the team depends on that individual to provision their software images with the appropriate support for higher-level application software. Setting up a package feed would allow the team to download pre-built packages over a local area network to add software support on-the-fly to their booted phyCORE-AM64x Development Kits, making it less necessary to flash and re-flash SD Cards all the time.
Note
This guide will help you setup a debian-style package feed, allowing you to maintain it yourself. PHYTEC does not currently maintain a package feed for its customers.
Package Feed Setup (Ubuntu Host Machine)
First, head over to the Build the BSP guide and build the default BSP-Yocto-Ampliphy-AM64x-PD23.2.0.
With the BSP built, use your Ubuntu Host Machine and navigate into the $BUILDDIR/deploy/ipk directory.
Host (Ubuntu)
cd $BUILDDIR/deploy/ipk
We will need our Host Machine’s IP address in order to setup a HTTP server on it that will serve-up our built packages (which are deployed here in the current directory in .ipk format). Use the following command to get the IPv4 address of the Host Machine:
Host (Ubuntu)
ip addr
Example Output
phytec@ubuntu2004:~/BSP-Yocto-Ampliphy-AM64x-PD23.2.0/build/deploy/ipk$ 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: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:28:c1:c8:a0 brd ff:ff:ff:ff:ff:ff altname enp3s0 inet 172.21.3.77/24 brd 172.22.3.255 scope global dynamic noprefixroute ens160 valid_lft 603024sec preferred_lft 603024sec inet6 fe81::14d7:9892:aef5:8cd5/64 scope link noprefixroute valid_lft forever preferred_lft forever
In the above example output it can be seen that this Ubuntu Host Machine has the IPv4 address of 172.21.3.77. Keep the address for your host machine handy, you will need it in the following steps.
Use the following command to implement an HTTP server in the current working directory, binding it to the same IPv4 address as your Host Machine (we’ll ope this up on a random 5678 port too):
Note
The ‘&’ at the end of the command allows this to run as a background process, which prevents it from completely hijacking the terminal session we are in.
Host (Ubuntu)
python3 -m http.server 5678 --bind <host ip address> &
Now our server is up and running, but it’s not a useful or functional package feed yet.
So far, every .ipk in $BUILDDIR/deploy/ipk is an artifact of the image you built earlier, so they should all be installed already and thus aren’t so useful. In order to make this HTTP server a useful AND functional package feed, we’ll want to deploy an additional package to it that isn’t available by default on the target AND deploy a package index so that the OPKG package manager running on the target knows what packages are available.
We’ll use the packagegroup-core-buildessential package for our example, since it’s not available in PHYTEC’s pre-built images by default. This package contains common development tools such as gcc and make so it’s very useful for native development directly on the target hardware. We can build this package easily with the following:
Host (Ubuntu)
cd $BUILDDIR
bitbake packagegroup-core-buildessential
Once built, we can also easily deploy a package index by leveraging a recipe provided by Open Embedded (you’ll need to run this every time you deploy a new .ipk in order for the package index to get updated with the new .ipk):
Host (Ubuntu)
bitbake package-index
Connecting the phyCORE-AM64x to the Package Feed
With your phyCORE-AM64x Development kit booted into Linux (using the software we prepared in the steps above), open the following opkg configuration file:
Target (Linux)
vi /etc/opkg/arch.conf
Note
opkg is a package manager included by default in Ampliphy Linux Distro from PHYTEC.
The arch.conf file is a configuration file used by the opkg package manager and can be used to set the location a package feed server. We need to manually set the location of the package feed we just created within it.
Modify /etc/opkg/arch.conf to reflect the following. Be sure to replace “<host ip address>” with your Host Machine’s IPv4 address (found in the previous steps):
Target (Linux)
arch all 1 arch any 6 arch noarch 11 arch aarch64 16 arch phyboard_electra_am64xx_2 21 src/gz all <host ip address>:5678/all src/gz aarch64 <host ip address>:5678/aarch64 src/gz phyboard_electra_am64xx_2 <host ip address>:5678/phyboard_electra_am64xx_2
You only need to do this once for a given SD Card. However, if you re-flash the SD Card’s root filesystem with a fresh BSP-Yocto-Ampliphy-AM64x-PD23.2.0 image you’ll have to repeat these setup steps again (unless you set this up in your own meta-layer).
Usage
In order to use the package feed, your development kit will first need to be connected to your Local Area Network (the same one your Host Machine is connected to). Checkout the Ethernet peripheral guide for more information.
With a valid network connection, you can use opkg to update a list of the packages available in the feed:
Target (Linux)
opkg update
We can output a list of available packages in the feed and search for specific ones (remember that we’ve only really added packagegroup-core-buildessential and its dependencies to the feed at this time. This example of searching the feed is mostly provided as a reference for after you have deployed additional packages to it):
Target (Linux)
opkg list
opkg list | grep packagegroup-core-buildessential
And we can install anything that is available with the following command:
Target (Linux)
opkg install packagegroup-core-buildessential
Note
Depending on the size of the package you are installing, you may need to expand the root filesystem partition. The default phytec-headless-image has a root filesystem with only about 144MiB of extra capacity.
If you followed this guide exactly, then you can now install packagegroup-core-buildessential like so (just make sure you ran opkg update first!):
Target (Linux)
opkg install packagegroup-core-buildessential
Similarly, you could remove specific packages with the following:
Target (Linux)
opkg remove <package name>
Conclusion
If you work through the process outlined in this guide and the process outlined in the Hello World guide, it should become readily apparent how much time you can save by leveraging package management, when compared to the alternative.
Previously, in the Hello World guide, in order to add additional software to our bootable image we had to:
Build the desired package as a part of our overall disk image.
Update the entire boot media of our phyCORE-AM64x to gain access to the new support.
Now we can just build the packages by themselves and whoever needs them can grab them at runtime using the network, while at the same time preserve the root filesystem and whatever work it contained, which can greatly accelerate development.