To preface all of this, overclocking is a HACK not a FEATURE; running your Maple above the design frequency could damage it irreparably and we won't replace your board for free if you break it this way. That being said it's pretty fun...
As described (discovered?) by Thomas Jespersen (http://elec.tkjweb.dk/blog/2010/02/stm32-overclocking/ ), the regular 72MHz system clock on certain stm32 chips can be upped by simply changing the PLL multiplier. I wrote a junky usercode implementation with libmaple; see http://gist.github.com/407140. This demonstrates resetting the clock multiplier on-the-fly by dropping to the internal (HSI) clock while reconfiguring the PLL to multiply the external 8MHz crystal (HSE) by 16x instead of 9x. I confirmed with a scope; an inefficient, high-level GPIO read/write usually takes about 945ns. After calling overclock() this was reduced to 532ns, the ratio of ~1.77 indicating a SYSCLK speed around 128MHz. I'm not sure if the GPIO peripheral bus can keep up with that SYSCLK, but the uC gears are definitely spinning faster.
Bumping the clock speed will break a lot of things, some of which could be configured around and some probably not. Notably USB stops working and you'll have to reprogram by resetting and uploading during the DFU wait period. Most of the peripheral clocks could probably be reconfigured to work, but the internal FLASH memory almost certainly will probably not work at these speeds.
Right now this overclock() function takes about 50us to switch speeds, but this could optimized.
PS: I think there's a #define typo in rcc.h that is taken advantage of here; can you find it?
