Hi Richard, indeed here are my steps git clone -b m65-dev --recurse-submodules https://github.com/alinelena/qmk_firmware.git cd qmk_firmware virtualenv ~/venv/qmk2 source ~/venv/qmk2/bin/activate pip install qmk make m65/rev1:uk .rwxr-xr-x 1 134M drFaustroll users 10 May 13:52 -I m65_rev1_uk.bin now edit keyboards/m65/rev1/rules.mk and add at the end EXTRALDFLAGS = -Wl,--build-id=none make clean .rwxr-xr-x 1 30k drFaustroll users 10 May 13:55 -I m65_rev1_uk.bin there is another option where there is no need for the extra flags make m65/rev1:uk OBJCOPY="arm-none-eabi-objcopy -R .note.gnu.build-id" these are my installed packages i+ | cross-arm-binutils | package | 2.36-410.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-gcc11 | package | 11.1.1+git67-91.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-arm-none-newlib-devel | package | 4.1.0-35.1 | x86_64 | rpms i+ | cross-avr-binutils | package | 2.36-409.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i+ | cross-avr-gcc7 | package | 7.5.0+r278197-185.1 | x86_64 | GNU Compiler Collection container (openSUSE_Factory) i had to create by hand the -size link(I already opened a bug on this) ll /usr/bin/arm-none-eabi-size 10/05/21 13:59:18 Permissions Links Size User Group Date Modified Name lrwxrwxrwx 1 36 root root 4 May 23:15 /usr/bin/arm-none-eabi-size -> /usr/bin/arm-suse-linux-gnueabi-size for the big size bin this is the output of you big command objdump -h .build/m65_rev1_uk.elf 10/05/21 14:00:43 .build/m65_rev1_uk.elf: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000 00000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .mstack 00000400 20000000 20000000 00030000 2**0 ALLOC 2 .pstack 00000800 20000400 20000400 00030000 2**0 ALLOC 3 .vectors 00000160 08002000 08002000 00012000 2**10 CONTENTS, ALLOC, LOAD, READONLY, CODE 4 .xtors 00000008 08002160 08002160 00012160 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .text 000063d8 08002168 08002168 00012168 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .init 00000004 08008540 08008540 00018540 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 7 .fini 00000004 08008544 08008544 00018544 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .rodata 00000ee0 08008548 08008548 00018548 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .ARM.exidx 00000008 08009428 08009428 00019428 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .data 00000184 20000c00 08009430 00020c00 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 0000086c 20000d88 080095b4 00020d88 2**3 ALLOC 12 .ram0_init 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 13 .ram0 00000000 200015f4 200015f4 00020d84 2**2 CONTENTS 14 .ram1_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 15 .ram1 00000000 00000000 00000000 00020d84 2**2 CONTENTS 16 .ram2_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 17 .ram2 00000000 00000000 00000000 00020d84 2**2 CONTENTS 18 .ram3_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 19 .ram3 00000000 00000000 00000000 00020d84 2**2 CONTENTS 20 .ram4_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 21 .ram4 00000000 00000000 00000000 00020d84 2**2 CONTENTS 22 .ram5_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 23 .ram5 00000000 00000000 00000000 00020d84 2**2 CONTENTS 24 .ram6_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 25 .ram6 00000000 00000000 00000000 00020d84 2**2 CONTENTS 26 .ram7_init 00000000 00000000 00000000 00020d84 2**2 CONTENTS 27 .ram7 00000000 00000000 00000000 00020d84 2**2 CONTENTS 28 .heap 00003a0c 200015f4 200015f4 00030000 2**0 ALLOC 29 .ARM.attributes 0000002f 00000000 00000000 00020d84 2**0 CONTENTS, READONLY 30 .comment 000000bb 00000000 00000000 00020db3 2**0 CONTENTS, READONLY 31 .debug_info 0002adae 00000000 00000000 00020e6e 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_abbrev 0000944c 00000000 00000000 0004bc1c 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_loclists 0000a12a 00000000 00000000 00055068 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 34 .debug_aranges 000015f0 00000000 00000000 0005f198 2**3 CONTENTS, READONLY, DEBUGGING, OCTETS 35 .debug_rnglists 00001a6c 00000000 00000000 00060788 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 36 .debug_line 00012eac 00000000 00000000 000621f4 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 37 .debug_str 00007e1b 00000000 00000000 000750a0 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 38 .debug_frame 000033cc 00000000 00000000 0007cebc 2**2 CONTENTS, READONLY, DEBUGGING, OCTETS 39 .stab 000003fc 00000000 00000000 00080288 2**2 CONTENTS, READONLY, DEBUGGING 40 .stabstr 000000ed 00000000 00000000 00080684 2**0 CONTENTS, READONLY, DEBUGGING 41 .debug_line_str 00000038 00000000 00000000 00080771 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 10 May 2021 at 08:33, Richard Biener <rguenther@suse.de> wrote:
On Fri, 7 May 2021, Alin Marin Elena wrote:
Hi,
so a workaround was to pass this to the linker -Wl,--build-id=none personally I understand little on the side effects of this so I do no know if that can be some default setting in the linker. but with that flag the size is the same as stm32 toolchain.
That's quite unbelievable ... if you can reproduce this and share the linker input files it's worth reporting a bug for. Please provide the output of the linker gcc command with -v appended as well.
Richard.
Regards, Alin
Regards, Alin
Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________
On Fri, 7 May 2021 at 12:35, Stefan Brüns <stefan.bruens@rwth-aachen.de> wrote:
On Freitag, 7. Mai 2021 08:07:18 CEST you wrote:
Hi Stefan,
I got the rpm and installed now seems to work, in the sense I do not get a linker error anymore... however the size of the binary produces is crazy big .rwxr-xr-x 1 134M drFaustroll users 7 May 06:54 -I m65_rev1_uk.bin vs .rwxr-xr-x 1 30k drFaustroll users 7 May 07:05 -I m65_rev1_uk.bin by using the stm32 toolchain..
now since the hex files produced are more or less the same 30K I suspect the issue may be more complex and maybe related to the other bug.
I suspect an incomplete/insufficient linker script, including too much in the binary.
Have a look at the size of the sections in the corresponding elf files: $> objdump -h m65_re1_uk.elf
If in doubt, post the results on the list.
Kind regards,
Stefan
-- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)