(so far, avrfreaks is leaning toward "install the 2010 version of WinAVR, and replace the compiler bits with the new files from the Atmel Toolchain.) (Actually, WINAVR alone is sufficient to compile Optiboot, even with the old compiler.)

How does Optiloader deal with an alternate clock frequency? I have a custom designed board with the ATMega328 running an internal clock. The bootloader must have an "awareness" of the clock frequency in order to set a known baud rate. It is unclear to me how to do this. The internal clock is set for 8 MHz.

Related, when creating a sketch to download to the bootloader, what should be selected for the board type in Sketch? There doesn't appear to be a valid board configuration that matches the 328 (not 328P) with an 8MHz clock.

You need to either compile an optiboot for your changed clock rate, or adjust the baud rate in boards.txt (which is easier.)

For a 328 at 8MHz, the "semi-official" preferred method is to load the stock 328P 16MHz bootloader, and use a boards.txt entry that says "328p at 8MHz, 57600bps upload speed." The sketch/compile step doesn't need to know about 328 vs 328p issues, and the bootloader will lie and say it's a 328p anyway.

The optiboot version number is stored in the last two bytes of the chip. or .hex file.You can read this from the .hex file or with a programmer, but it is usually protected from the arduino sketches by the lock bits (sigh. I tried to change the lockbits, but it "seemed too dangerous" to make official code. If you're using the optiboot boards.txt or makefies to burn the new bootloader, you'll get a "readable" bootloader, and a program like FuseBytes will show the version number. But not if you have a stock arduino.)

Note that the bytes show up "reversed" in the hex file, so ending with 0x02 0x06 is version 6.2

Still 6.2, actually.The development plan is sort of: add additional platforms that do not change the code for existing chips (notably the "virtual boot partition tiny chips: tiny1634, tiny841) update version to 7.0 work on features/bugs that DO affect the popular platforms.(however, this has been the plan for several months now, without me making any progress on it. :-( )

Note that assorted "third parties" have been known to distribute slightly modified versions of Optiboot without changing the version number. And various fourth party individuals who are compiling their own Optiboot almost certainly do not change the version number, so it's possible that some chip/hex with "6.2" in the version field may have code that doesn't actually match any "official" version. Since one of the things that tends to break Optiboot is "new compiler does things differently", this can be a real problem.

The .hex file is already an ascii-ized file of hex characters, so if you use "hexdump", you are dumping the ascii data rather than the binary content represented by the .hex file. You either want "avr-objdump" or "tail":

For a .hex file, I think it assumes that any discontinuity in the data starts a new "section." (I can delete a line from the middle of the contiguous code space, and suddenly I have three sections instead of two.)

For .elf and .o files, sections are a "big deal", and too complicated to explain here.The optiboot implementation uses a separate section for the version number, which is what permits it to be place "at the end of Flash" while the code itself is placed "at the beginning of the bootloader section." (note that "bootloader section" is a hardware thing that is not particularly related to the .elf file "code sections.")