Firmware is in this case: All software which was installed on the new box, and their updates. So that includes the bootloader, linux, and the userland.
And there is no BIOS. The processor has a build in bootloader which is just smart enough to load a higher level bootloader in memory, and pass execution to it. On most embedded boxes (including the EZ Media) that is
u-boot. It's u-boot's responsibility to fetch a Linux kernel somewhere, and maybe an
initramfs, pass a commandline to the linux kernel, and execute it.
Linux then needs to find and mount it's rootfs, although on some embedded boxes only the initramfs is used. The rootfs can be found because it's location is specified in the commandline (by u-boot, who reads it from it's environment), or because it's location is hardcoded in the kernel, or by means of a script in initramfs.
U-boot can be very powerful, and execute scripts to search for a kernel on several places, including usb-sticks, harddisks, tftp- and nfs servers, but on most systems only a subset of all functions is included, and the bootscript only searches for the kernel on it's stock location.
You can also interrupt u-boot and upload a kernel and initramfs using tftp, and execute them from ram. (Or flash them to flashrom, but not on an EZ-Media. It's flash size is too small)
On your EZ-Media the boot process is:
Processor runs it's internal bootloader, and loads u-boot from flash, and executes it.
U-boot reads it's environment from the same flash, loads a kernel (uImage) and initramfs (uInitrd) from harddisk, at specified (in environment) sector offsets. (U-boot is smart enough to mount a filesystem and read a kernel from file, but Iomega has chosen to write the kernel and initramfs to raw disk space.)
The kernel is executed, it initializes all hardware which it can find, and then executes a script in initramfs (/rclinux IIRC). This script mounts the harddisk, assembles raid arrays and logical volumes, composes the rootfs by mounts, bindmounts and symlinks, and finally starts the 'NAS backend'.
The most common way to change this is by connecting to the serial port, which gives you access to the u-boot command prompt, where you can change the environment. If u-boot has USB support, you can tell it to get it's kernel from an usb stick, and provide a commandline which tells the kernel to find it's rootfs there too. Then you can start *any* ARMv5 compatible distro (which is not dependent on a video card).
Another option is to exchange the kernel and/or initramfs on harddisk, which gives the possibility to load another rootfs either.
is the firmware open source?
Yes. At least u-boot, the Linux kernel and most of the userland. Maybe a few closed source binaries are included.
Free up the stock port? If it's really Linux this should do it <snip>
No, that is about high level terminals. The console is low-level. It's the interface which is used to write the boot messages to, from both bootloaders and the kernel, and sometimes you can also get a shell on it, when the box is booted.
Here can you find the console output of a HMNHD-CE. To free up the serial port you have to pass a command line param which redirects console output to nil. In that case the kernel won't open it, and if you tell the userland not to open a shell on it, you can use it for something else. Although you still have the bootloader output on boot. Your connected device should be able to handle that (or be disconnected on boot). An usb-serial adapter is more convenient.
!