Brief update. I’m currently working to get the bootloader to build.
My build platform is Linux, and my toolchain is 4.9.3 - the main spark firmware developers are still using 4.8.x, the code generated by 4.9.3 is slightly too large to fit in the flash area allocated for bootloader - I’m about 128 bytes larger than 4.8.x and about 24 bytes larger than the allocated space, so even the working code is tight now.
If I were under deadline, I’d just find and load up a 4.8.x toolchain, throw a symlink and move on, but I want to understand what is going on, because the main team will hit this eventually, they can’t stay with down-rev toolchains forever. So I’m going to keep on looking at this for a little longer.
For most of the code generation the newer toolchain does better, but for some of the USB stuff it generates larger code - I suspect the culprit is bitfield/union handling when looking at the data structures maintained by the USB OTG hardware. It may be there was a sloppy code generation problem that was fixed, or it may be that this is just collateral damage from some other feature, but disabling the likely candidates (such as Local Register Allocation) has no effect.
Spark are still working the terms of the source code release, so no progress on that front, I’m afraid; I have not put any effort into sanitizing a working code base for development, because I’m scared to death of the integration issues trying to reconcile that tree and push changes back into the official spark repo (whatever that looks like post-release.)
We will need to re-map some pins because of the way peripherals are allocated/connected on the '207 as compared to the '205 - there is work underway to figure out the smartest mapping and then I’ll adapt the bootloader to suit.
Anyway, I wanted to assure people that there was still activity underway.