I have two versions of a setup using the QSXP-ML81 from Ka-Ro Electronics (which itself uses an NXP processor). One one of the setups uses Ka-Ro's evaluation board and this has an Ethernet jack, and the other is on our own custom PCB that doesn't have any Internet capability. The setups also use different images with confusing names, called "weston" even though its the "wayland" backend, and as I understand it it's all Yocto anyway. The board without the 'net has a very bare-bones image on it that does not even have apt available. On the other board, I can download and install packages on the other setup. In theory, I should be able to download a package on one machine and copy it over to the second for install. I did find a description of a process like this but it described downloading tarballs and compiling them on the target machine. In our case the target is such a minimal image I am not going to be able to compile anything on it. Does Yocto not have something similar to Debian where I can just download a DEB file manually and have the target OS process it?
For even more detail, the more complete OS (a custom image we build ourselves based on Ka-Ro's directions) has issues in that we can't correctly access all the GPIO pins. If we export the pin using echo {X} > /sys/class/gpio/export then for some, but not all, of the pins, writes to the /direction files fail to toggle the state of the pin. But we noticed that on the minimal weston build all the GPIOs appear to work correctly. So we wanted to look at the device tree setup on the minimal build and copy whatever it was doing into the custom image, and to do THAT it looks like we need the device tree compile utility installed on the minimal image so we can export the tree and include those settings in our custom build.
@skandigraun is correct. On the machine where I can do the custom build, I found a /tmp/deploy/rpm directory that had a subfolder full of RPM files. I was able to copy the ones I wanted to a flash drive and install them using
rpm --install {packagename}.rpm. One thing I discovered during this process is that if a package has missing dependencies the rpm utility doesn't seem to look for them by default (maybe it's an option, I didn't look into it). So when it reported missing dependencies I had to manually install those first, then go back and try the desired package again.