That's a lot of questions! Here are a few answers:
How does one get the compiled binary into an ARM processor?
It varies depending on a number of factors.
Is JTAG the normal method (I think that is what my research has indicated ...)?
Most (perhaps all) modern ARM based devices include a JTAG interface to connect to the on-chip debug (soft-cores on an FPGA perhaps excepted). This can generally be used to program on-chip or external flash or load directly into RAM. The JTAG interface is also the interface to on-chip debug and trace features. Some devices have additional debug/programming interfaces, such as ARM's SWD for example.
Is it the only method?
In some cases. Some ARM based microcontrollers include an on-chip bootloader ROM that may support serial, USB or other means of programming on-chip flash. Sometimes such a facility is very simple and intended only to load and run a secondary bootloader that executes from RAM and does the actual flash programming.
If it is a valid method, exactly how do you use it in that fashion?
By using appropriate host software. JTAG is a very simple interface, and it does not define any particular functionality, only a means of data transfer. Typically the programming software will need to know what device it is communicating with, and if the flash memory is not on-chip, it will need to know the flash device and its address. Often the development toolchain will include support for device programming, especially for devices with on-chip memory. If you are using the GNU toolchain, you can use OpenOCD to both program the device and interface the GNU debugger.
If it isn't then what is/how do I do it?
If your target is a COTS, it may well include a bootloader already allowing software update over USB, serial, or Ethernet for example.
Furthermore, can something such as an Arduino be used to create an impromptu JTAG interface (if that is indeed what is needed to program ARM devices). . .?
Probably, as I said JTAG itself is trivially simple to implement, the problem is making it compatible with whatever host software you will use (or making the software compatible with it). The simplest "wiggler" JTAG adapters are implemented using PC parallel port I/O - not particularly fast, but functional.
I'm basically asking: is JTAG the device programmer of the ARM world?
It was originally defined as a boundary scan test interface, but is now widely used on most microprocessors and microcontrollers that include on-chip debug and programming.
Can I spoof one with an Arduino (Arduino wiggler Clone o.o)? If JTAG isn't, what is, and can I spoof it?
It is not a matter of "spoofing", the interface can be implemented in many ways. How you implemnt it primarly affects the speed of the interface. 16 MHz can be achived, but a simpler parallel port wiggler would probably sustain no more that 500 kHz. It is a synchronous interface, so variable clock rates are not a problem.
Oh... And I might need a better explanation of exactly how JTAG works.
I am sure that I cannot do better than the explanation in Wikipedia's JTAG. But for the implementation on your target device, you should consult the part's reference manual/data sheet.
I have an old Palm Device (LifeDrive), that has the XScale PXA270 processor I believe.
"Believing" is probably not enough; you will need to know. Are the JTAG pins even exposed on the board? It would be usual on a consumer product to omit an actual JTAG connector. Even if there is one, it will likely be a proprietary connector and pin-out (JTAG itself defines neither, and there are several defined for ARM, but what you might find on a development board may not be included on the final consumer product.
Basically, this could be a good way to get to play around with what is essentially a mass of sensors, and other miscellaneous inputs and outputs, and also get used to ARM assembly language.
It is probably better to get an off-the shelf development board with exposed I/O pins and interfaces. On a consumer product, only those pins required by the target application are likely to be exposed, and even then they may not be accessible if they are connected to BGA devices. Also, XScale is at the complex end of ARM devices (falling approximately between ARM9 and ARM11), if you are not familiar with such devices and things like PLL clock control, SDRAM control and timing, and MMU configuration, you may want to look at something simpler. Not only that but since both Flash and RAM will be off-chip, you will require details of the address mapping of the memory and other external devices, as well as the necessary SDRAM timing details. Being a consumer device, such details may not be available other than by reverse engineering.
Now that said, regarding the earlier comment about bootloaders, Palm provide a user installable ROM update for the device, so it must have a bootloader. However you would still need details of the image file format and data transfer protocol. These are unlikely to be published, and probably difficult to reverse engineer.
if I just wanted to play around with embedded programming, I would do so on my Arduino instead.)
There are plenty of low cost ARM development board available. Try Olimex for example: they even have a low cost "Wiggler" clone JTAG adapter.
