Model 01 ATtiny bootloader not playing nicely with newer keyscan firmware/GCC?

I’ve been wanting to try out newer keyscan firmware on my Model 01, so I built and flashed it using the flasher sketch. (This required a few workarounds; maybe I’ll talk about that later.)

After flashing the regular Kaleidoscope firmware back, the keyboard was totally unresponsive to keypresses, and LEDs were lit up (statically) at random.

I found this attiny_i2c_bootloader/twi_slave.c at 92b2dd069a352e707e07e720e8ff987361395840 · keyboardio/attiny_i2c_bootloader · GitHub

which kind of implies that the Model 01 ATtiny bootloader is expecting the application code to start at 0x38 (produced by GCC 5-) instead of the 0x28 that modern GCC uses.

What is the reason that GCC 5 is required for the Model 01? It doesn’t seem required for building Kaleidoscope on the Model 01. I can’t seem to find additional information about that comment.

Do I have to hunt down an older GCC to build the keyscan firmware, or are there workarounds? (I might end up trying tricky things with linker scripts.)

Also, I’m wondering if it might be more robust if the bootloader could look at the reset vector of the uploaded application firmware, and stash that away somewhere so it can jump to the right place regardless of compiler quirks about code placement. (I notice that the bootloader tries to preserve the INT0 vector as well, even though it doesn’t use it, and neither does the keyscan firmware, so that’s one possible place.)

OK, made a pull request here insert NOPs to work around Model 01 bootloader by tlyu · Pull Request #16 · keyboardio/avr_keyscanner · GitHub that will hopefully work for other people.

I think eventually the ATtiny bootloader should be more robust about this sort of thing, somehow.