The serial console programs¹ you'll use on the other end of the connection will have some way to send a file to the remote side. How exactly you go about it depends on what resources you have available on the remote system.
kermit on the Remote Side
The easiest case is if you have a solid binary file transfer program installed on the remote side such as
kermit. This was once more common than today, but your particular system might still have one of these.
The serial console program you're using on the local side almost certainly has a way to do a Zmodem or Kermit upload, which lets you send whatever you need directly.
In the case of Zmodem, just type
rz on the remote system, which sends out a special string that the local serial terminal should understand, causing it to pop up a file picker dialog.
Kermit is a simpler protocol, so you have to start the transfer manually in that case.
I Don't Have a Binary File Transfer Program, but I Do Have
There are several advantages to using a proper binary file transfer program like
kermit: efficiency, checksumming, automatic retries, aborted transfer resumption, multiple file transfer, etc., but these are luxuries. If you only need to send one file, or you're sending files rarely, you can get away with ASCII uploads.
Because terminal protocols interpret many of the byte values that occur in a binary data file, you can't send the file directly through the same connection; if you do, the terminal emulation code on either end will try to interpret some of the data, corrupting the data and likely confusing the terminal handling code as well.
You get around this by encoding the binary data into a safe subset of ASCII on the local side, then turning it back into raw binary data on the remote side. This is what the
base64 programs do, differing only in minor algorithm choices.
On the local system, you encode the file:²
$ uuencode -o sbf.uue some-binary-file.gz some-binary-file.gz
Then you type this command on the remote system, and send the file using the local serial console's "ASCII upload" feature:
$ cat | uudecode
When the file upload finishes, hit Ctrl-C to get out of
cat. Now you have your decoded file on the remote system, as you wanted.
But I Have Many Files to Send, and Printable ASCII Transcoding Is a Pain!
It is not hard to bootstrap yourself up to a higher level of technology. If the remote system has a C compiler, you can use the prior technique to send the remote system a copy of the
lrzsz source code. On the local side:
$ uuencode -o lrzsz.tgz.uue lrzsz-0.12.20.tar.gz lrzsz-0.12.20.tar.gz
Then on the remote system, type this via the serial console program:
$ cat | uudecode
$ tar xvf lrzsz-0.12.20.tar.gz
...build lrzsz normally
After you start the first command, do an "ASCII upload" of the
lrzsz.tgz.uue file to the remote system. The pipeline accepts the uuencoded data and decodes it to a binary tarball for you, which you can unpack and build.
But I Don't Have a C Compiler on the Remote System
If you don't even have a compiler on the remote system, you can cross-compile the
rz (or whatever) program on the local system and send it to the remote system using the above technique.
minicom, picocom, PuTTY, VanDyke CRT...
You have to give the input file name to this version of
uuencode twice, once to name the source of the input data, and again to declare what the remote system should call the file when it decodes the data to an output file. You could conceivably want the remote system to have a different name for its output file.
Your local version of
uuencode may behave differently.