Hello,
It seems since version 4.17 and since commit:
75226bb879837e2e4aa710aadb27dbadb4044ed3 Makefile.inc: Generate master header and pointer as C structs
The coreboot miscompiles the ROM image. At the beginning of the image there should be usually something like:
"cbfs_master_header" and "ORBC"
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 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); \
but this is most like really dirty hack. With this change the ORBC header is generated correctly, but I didn't have a chance to test if the image boots.
How should I fix it correctly.
best regards, Petr
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
Dne 10. 07. 22 v 13:16 Nico Huber napsal(a):
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*`?
I do use CONFIG_ANY_TOOLCHAIN.
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 could be, but having no specific section defined for copying seems to be dangerous. Is the default behavior for objcopy to choose at random/last one?
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.
Me neither :D so I hope this change here won't break some other source file.
P.S. I was able to boot nvramtui with my patch and it seems OK. I need to test your patch yet.
Petr
Nico
-
Nico Huber -
Petr Cvek