Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33114 )
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE ......................................................................
Patch Set 6:
(1 comment)
https://review.coreboot.org/#/c/33114/5/src/cpu/x86/Makefile.inc File src/cpu/x86/Makefile.inc:
https://review.coreboot.org/#/c/33114/5/src/cpu/x86/Makefile.inc@20 PS5, Line 20: ifeq ($(CONFIG_STAGE_RAMSTAGE),y)
Got it. Then that means someone is requesting sipi vector to be in the build. Taking a step back. Why would sipi not be needed for !RAMSTAGE? What is your solution to the larger problem?
We are planning to pull Mp init into earlier stage hence we might need to compile the same code with postcar.
postcar-$(CONFIG_PARALLEL_MP) += mp_init.c postcar-y += backup_default_smm.c
ifeq ($(CONFIG_PARALLEL_MP),y) postcar-srcs += $(SIPI_BIN).manual endif rmodules_$(ARCH-postcar-y)-$(CONFIG_PARALLEL_MP) += sipi_vector.S
$(SIPI_DOTO): $(call src-to-obj,rmodules_$(ARCH-postcar-y),src/cpu/x86/sipi_vector.S) $(CC_rmodules_$(ARCH-postcar-y)) $(CFLAGS_rmodules_$(ARCH-postcar-y)) -nostdlib -r -o $@ $^
ifeq ($(CONFIG_ARCH_POSTCAR_X86_32),y) $(eval $(call rmodule_link,$(SIPI_ELF), $(SIPI_DOTO), 0,x86_32)) else $(eval $(call rmodule_link,$(SIPI_ELF), $(SIPI_DOTO), 0,x86_64)) endif
$(SIPI_BIN): $(SIPI_RMOD) $(OBJCOPY_postcar) -O binary $< $@
$(call src-to-obj,postcar,$(SIPI_BIN).manual): $(SIPI_BIN) @printf " OBJCOPY $(subst $(obj)/,,$(@))\n" cd $(dir $<); $(OBJCOPY_rmodules_$(ARCH-postcar-y)) -I binary $(notdir $<) $(target-objcopy) $(abspath $@)
Looks like this should be parameterized against the targeted stage.
yes, something like that would be perfect
I think i can use $(target-stage) variable to avoid duplicate code for ramstage and/or postcar.
$(target-state) could be set based on ENV_PAYLOAD_LOADER ?
Assuming this is the resulting intent (though, I disagree) I think you need to work out *why* these recipes are getting evaluated. ramstage-blah should never be acted upon because ramstage's root dependency should not be referenced. The fact that ramstage-srcs is being evaluated in some form is the root of the problem, I suspect. What if you just guard line 23? Does that work correctly?
Same problem. make: *** No rule to make target 'build/rmodules_/cpu/x86/sipi_vector.o', needed by 'build/cpu/x86/sipi_vector.o'. Stop.
We need to figure out what is pulling this in to the dependency chain. I'm sure Make has some options to help w/ that, but it'll be instructive.