-
-
Notifications
You must be signed in to change notification settings - Fork 42.4k
Fix firmware size check with avr-libc 1:2.0.0+Atmel3.6.2-1.1 (Debian bullseye) #12951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…bullseye) Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the <avr/io.h> header for ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`, and that `U` suffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculate `MAX_SIZE` does not support those C-specific suffixes. As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation that is used to expand those macros; in this case avr/iom32a.h defines `FLASHEND` without the `U` suffix, and everything works as it did before with older avr-libc versions. The exact same code is present in two places; they are both changed, even though the code in `tmk_core/avr.mk` is actually never used for ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to `FLASHEND` for some reason).
drashna
approved these changes
May 22, 2021
fauxpark
approved these changes
May 22, 2021
drashna
approved these changes
Jun 7, 2021
|
Thanks! |
mechlovin
pushed a commit
to mechlovin/qmk_firmware
that referenced
this pull request
Jul 30, 2021
…bullseye) (qmk#12951) Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the <avr/io.h> header for ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`, and that `U` suffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculate `MAX_SIZE` does not support those C-specific suffixes. As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation that is used to expand those macros; in this case avr/iom32a.h defines `FLASHEND` without the `U` suffix, and everything works as it did before with older avr-libc versions. The exact same code is present in two places; they are both changed, even though the code in `tmk_core/avr.mk` is actually never used for ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to `FLASHEND` for some reason).
mechlovin
pushed a commit
to mechlovin/qmk_firmware
that referenced
this pull request
Jul 30, 2021
…bullseye) (qmk#12951) Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the <avr/io.h> header for ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`, and that `U` suffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculate `MAX_SIZE` does not support those C-specific suffixes. As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation that is used to expand those macros; in this case avr/iom32a.h defines `FLASHEND` without the `U` suffix, and everything works as it did before with older avr-libc versions. The exact same code is present in two places; they are both changed, even though the code in `tmk_core/avr.mk` is actually never used for ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to `FLASHEND` for some reason).
nhongooi
pushed a commit
to nhongooi/qmk_firmware
that referenced
this pull request
Dec 5, 2021
…bullseye) (qmk#12951) Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the <avr/io.h> header for ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`, and that `U` suffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculate `MAX_SIZE` does not support those C-specific suffixes. As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation that is used to expand those macros; in this case avr/iom32a.h defines `FLASHEND` without the `U` suffix, and everything works as it did before with older avr-libc versions. The exact same code is present in two places; they are both changed, even though the code in `tmk_core/avr.mk` is actually never used for ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to `FLASHEND` for some reason).
BorisTestov
pushed a commit
to BorisTestov/qmk_firmware
that referenced
this pull request
May 23, 2024
…bullseye) (qmk#12951) Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the <avr/io.h> header for ATmega32A (avr/iom32a.h) now defines the FLASHEND constant as `0x7FFFU`, and that `U` suffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculate `MAX_SIZE` does not support those C-specific suffixes. As a workaround, add `-D__ASSEMBLER__` to the C preprocessor invocation that is used to expand those macros; in this case avr/iom32a.h defines `FLASHEND` without the `U` suffix, and everything works as it did before with older avr-libc versions. The exact same code is present in two places; they are both changed, even though the code in `tmk_core/avr.mk` is actually never used for ATmega32A (and the header for ATmega32U4 does not add that `U` suffix to `FLASHEND` for some reason).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Debian bullseye (testing at the moment, but seems close to release) has avr-libc 1:2.0.0+Atmel3.6.2-1.1 with some changes taken from the Atmel-distributed toolchain. In particular, the
<avr/io.h>header for ATmega32A (avr/iom32a.h) now defines theFLASHENDconstant as0x7FFFU, and thatUsuffix breaks the firmware size check code, because the shell arithmetic expansion that is used to calculateMAX_SIZEdoes not support those C-specific suffixes.As a workaround, add
-D__ASSEMBLER__to the C preprocessor invocation that is used to expand those macros; in this caseavr/iom32a.hdefinesFLASHENDwithout theUsuffix, and everything works as it did before with older avr-libc versions.The exact same code is present in two places; they are both changed, even though the code in
tmk_core/avr.mkis actually never used for ATmega32A (and the header for ATmega32U4 does not add thatUsuffix toFLASHENDfor some reason).The problematic code in new
avr/iom32a.h:For some reason the ATmega32U4 header does not have a similar change, therefore only boards using ATmega32A are affected. The build error for
jj40:defaultlooks like this:Lots of other MCUs are affected, but the only one that has been used with QMK is apparently ATmega32A:
Maybe
bootloader_size.cshould be changed tobootloader_size.Sinstead (and preprocessed using assembler options); I did not try that variant yet.Types of Changes
Issues Fixed or Closed by This PR
Checklist