Hello Petr, thanks for reporting this. Are you using your host toolchain to build coreboot by any chance (CONFIG_ANY_TOOLCHAIN)? or do you use `make crossgcc*`?
On 10.07.22 05:40, Petr Cvek wrote: > but on my setup there is no ORBC magic ID. Instead it seems a > ".note.gnu.property" > section has been copied by objcopy into the final image (conincidentally it is > the last section in the object file too). > > Does anybody have the same problem? The missing header will cause seabios to > fail to > detect secondary payloads (ex. memtest and nvramcui) and probably the rest of > CBFS stuff > too. > > My binutils version is 2.38 (exactl version is: GNU objcopy version > 2.38-slack151). > But for coreboot 4.16 the image seems to be compiled correctly (so the > problem would be > only with a singular object file?). I've heard about `objcopy -O binary` copying .note sections before. So it might rather be the compiler or linker that makes the difference in your case (because it emits that .note which is unexpected). > > I was able to force the correct section copy by changing the Makefile.inc > near this code: > > cbfs-files-processor-struct= \ > $(eval $(2): $(1) $(obj)/build.h $(obj)/fmap_config.h > $(KCONFIG_AUTOHEADER); \ > printf " CC+STRIP $(1)\n"; \ > $(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) > --param asan-globals=0 $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) > -MT $(2) -o $(2).tmp -c $(1) && \ > - $(OBJCOPY_ramstage) -O binary --set-section-flags > .bss*=alloc,contents,load $(2).tmp $(2); \ > + $(OBJCOPY_ramstage) -O binary --only-section=.data.* > --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \ I'm not an expert on ELF sections. But given that this is about very simple C structs, I guess adding the following should be safe: --only-section='.data*' --only-section='.bss*' That should also catch all-0 structs. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
