There's lots of bits and pieces of 7970 information floating about on the Internet. Kerry Garrison's excellent Cisco 7970 tutorial was brief, but formed the kernel of the working configuration I now have. Configuration file hacking on the 7970 isn't all it's cracked up to be. I've found several interesting tidbits supporting this, such as the fact that the phone will not error noticeably during boot when it fails to parse a configuration file pulled from the TFTP server, it will just use the last config file it had. This gets interesting, since it fails to correctly parse an XML configuration file where the <phoneLabel> tag contains a value with a space character in it. Apparently, you can only name your phone Cher, Prince, or Twiggy. When this occurs, the phone does pull the file from the TFTP server, so packet sniffing will still show the file transfer, but there's no quick way of knowing if the phone is running from a cached or current config. Also, apparently some phones and/or firmware revs will request files with different capitalization from the TFTP server at boot. XMLDefault.cnf.xml, XmlDefault.cnf.xml and xmlDefault.CNF.XML may appear similar to the casual observer, but they're very different files.
I really like the 7970, though. The voice quality is superb, and it just looks fantastic on a desk, but the SIP firmware needs some polish, including a functional message waiting light. Since Cisco isn't so interested in keeping up with the SIP firmware vs. their proprietary SCCP version, that might take awhile.
But back to my PBX build. I downloaded Trixbox 2.0 beta 1 at first, but had problems with the phone connecting to the assigned extension. Backing off to v1.2.3 with Asterisk v126.96.36.199 brought the phone up properly, but that was only after playing with different 7970 SIP firmware revs, settling on version 8.0.3. Trixbox is just dead easy. Download the CentOS-based ISO, install, log in. Beautiful.
Loading firmware on the 7970 is interesting, as the phone will always query a TFTP server at boot, and will load a new firmware image from the same server if the XML configuration file includes a version that the phone isn't running. It's a relatively odd way to do it, but it does work once you've figured out exactly what the phone wants to see in that file, and have determined that the Cisco firmware release .cop file is just a tar.gz. Toss everything in that file into your TFTP root, reference the version.loads file in the phone's XML configuration (without the .loads) and reboot the phone. It should update the firmware on the resulting boot.