Hello,I prepared new version of the series, it's available in branch named avrdx_flmap_v2 (and also attached.)
The changes are based on the feedback both from the mailing list and from PR:
1) the #endif alignment was fixed. Checkpatch doesn't complain about assembly files unfortunately and I missed this one as well.
2) since no one was happy with the naming of the new configuration options, they are renamed to what xiaoxiang781216 suggested, ie.
- AVR_HAVE_FLMAP to denote chip with memory-mapping support- AVR_HAVE_BOARD_FLMAP to denote board with linker script that responds to configuration values set by the user
I did not rename AVR_HAS_RAMPZ for the time being, the patch series would then affect AtMega family as well. Now it only affects AVR DA/DB and I don't want to broaden the scope.
As for the HAVE/HAS discussion on GitHub, I think it depends on the view of the speaker - AVR (architecture - singular) has but AVR (chips - plural) have. I am not native speaker though.
I have been using AVR_HAS_something for configuration options because it matches AVR_HAS_MEMX_PTR which was present in the code before I started working on it (as opposed to - unless I missed something - no AVR_HAVE_something.) If AVR_HAVE is preferable for new code, I don't have any problem with that but I would rather avoid renaming the existing options to prevent needless (IMO) code churn.
Feel free to let me know if there's something else to work out.
0001-boards-avr-avrdx-breadxavr-fix-path-in-license-heade.patch.gz
Description: application/gzip
0002-Documentation-platforms-avr-document-options-of-keep.patch.gz
Description: application/gzip
0003-arch-avr-avrdx-do-not-copy-const-variables-into-RAM.patch.gz
Description: application/gzip
0004-arch-avr-avrdx-avrdx_serial-make-uart_ops_s-structur.patch.gz
Description: application/gzip
