You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Bringing findings from discussions in #12947 and #9657 to one place.)
Boards based on a K20x MCU currently get their "FlexMemory" partitioned as a 32 byte EEPROM by default, unless partitioned by something else than QMK before. This is becoming an issue since 32 bytes is less than the current EECONFIG_SIZE (35), and out-of-bounds read/write attemps are just ignored in that EEPROM driver. Case in point.
This partitioning can only be changed after a "clear all blocks" command, which will wipe the entire MCU flash. For Teensy boards, this isn't a problem since their bootloader resides in an external chip, but for (at least) Input:Club keyboards, which are using K20x MCUs with the bootloader residing in the MCU's program flash, this would require reflashing the bootloader using e.g. a J-link or Bus Pirate. One thing to note is that the Kiibohd firmware for these boards doesn't seem to use the EEPROM at all, so it's most probably QMK that has partitioned these boards to the 32 byte size.
Just increasing the default EEPROM_SIZE will cause issues for already partitioned boards, since out-of-bounds (read?/)write attempts will cause the EEERDY flag to stay low and therefore causes an infinite loop in flexram_wait().
One way to solve this is to check what size EEPROM the MCU has been set to (in the SIM->FCFG1 register) before the first EEPROM access, and adapt from that size so out-of-bounds accesses are avoided. One can also go further and switch the FlexRAM over to act as traditional RAM (making the same EEPROM driver act as 2048 bytes of transient storage instead) if the partitioned EEPROM size is deemed too small, but that is optional. I have made a working prototype of this behaviour (this block is the optional extra step of going transient), and if that is deemed an adequate solution to the issue, I'll make a PR of this after #12947 has been merged (would cause lots of merge conflicts otherwise).
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.
stalebot
added
the
stale
Issues or pull requests that have become inactive without resolution.
label
Sep 11, 2021
This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.
(Bringing findings from discussions in #12947 and #9657 to one place.)
Boards based on a K20x MCU currently get their "FlexMemory" partitioned as a 32 byte EEPROM by default, unless partitioned by something else than QMK before. This is becoming an issue since 32 bytes is less than the current
EECONFIG_SIZE
(35), and out-of-bounds read/write attemps are just ignored in that EEPROM driver. Case in point.This partitioning can only be changed after a "clear all blocks" command, which will wipe the entire MCU flash. For Teensy boards, this isn't a problem since their bootloader resides in an external chip, but for (at least) Input:Club keyboards, which are using K20x MCUs with the bootloader residing in the MCU's program flash, this would require reflashing the bootloader using e.g. a J-link or Bus Pirate. One thing to note is that the Kiibohd firmware for these boards doesn't seem to use the EEPROM at all, so it's most probably QMK that has partitioned these boards to the 32 byte size.
Just increasing the default
EEPROM_SIZE
will cause issues for already partitioned boards, since out-of-bounds (read?/)write attempts will cause theEEERDY
flag to stay low and therefore causes an infinite loop inflexram_wait()
.One way to solve this is to check what size EEPROM the MCU has been set to (in the
SIM->FCFG1
register) before the first EEPROM access, and adapt from that size so out-of-bounds accesses are avoided. One can also go further and switch the FlexRAM over to act as traditional RAM (making the same EEPROM driver act as 2048 bytes of transient storage instead) if the partitioned EEPROM size is deemed too small, but that is optional. I have made a working prototype of this behaviour (this block is the optional extra step of going transient), and if that is deemed an adequate solution to the issue, I'll make a PR of this after #12947 has been merged (would cause lots of merge conflicts otherwise).The text was updated successfully, but these errors were encountered: