Change in ...coreboot[master]: Makefile.inc: Fix compilation issue with !CONFIG_ARCH_RAMSTAGE_X86_32/64
Subrata Banik has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/33114
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ARCH_RAMSTAGE_X86_32/64 ......................................................................
Makefile.inc: Fix compilation issue with !CONFIG_ARCH_RAMSTAGE_X86_32/64
Change-Id: Ia6ad9b43dde2d2af40a7b2bc1773c0338ae9552b Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/cpu/x86/Makefile.inc 1 file changed, 3 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/33114/1
diff --git a/src/cpu/x86/Makefile.inc b/src/cpu/x86/Makefile.inc index 3e8a664..5ba8ccf 100644 --- a/src/cpu/x86/Makefile.inc +++ b/src/cpu/x86/Makefile.inc @@ -17,6 +17,8 @@ SIPI_BIN=$(SIPI_ELF:.elf=) SIPI_DOTO=$(SIPI_ELF:.elf=.o)
+ifeq ($(CONFIG_ARCH_RAMSTAGE_X86_32)$(CONFIG_ARCH_RAMSTAGE_X86_64),y) + ifeq ($(CONFIG_PARALLEL_MP),y) ramstage-srcs += $(SIPI_BIN).manual endif @@ -37,3 +39,4 @@ $(call src-to-obj,ramstage,$(SIPI_BIN).manual): $(SIPI_BIN) @printf " OBJCOPY $(subst $(obj)/,,$(@))\n" cd $(dir $<); $(OBJCOPY_rmodules_$(ARCH-ramstage-y)) -I binary $(notdir $<) $(target-objcopy) $(abspath $@) +endif
ron minnich has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33114 )
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ARCH_RAMSTAGE_X86_32/64 ......................................................................
Patch Set 2:
could you add a bit more explanation here? I don't understand what you are fixing.
Hello Aaron Durbin, ron minnich, build bot (Jenkins), Patrick Georgi, Furquan Shaikh,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33114
to look at the new patch set (#3).
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE ......................................................................
Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE
On x86 platform: Case 1: ramstage do exist: CONFIG_STAGE_RAMSTAGE=1
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_STAGE_RAMSTAGE=0
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select CONFIG_STAGE_RAMSTAGE.
Change-Id: Ia6ad9b43dde2d2af40a7b2bc1773c0338ae9552b Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/cpu/x86/Makefile.inc 1 file changed, 3 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/33114/3
Hello Aaron Durbin, ron minnich, build bot (Jenkins), Patrick Georgi, Furquan Shaikh,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33114
to look at the new patch set (#5).
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE ......................................................................
Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE
On x86 platform: Case 1: ramstage do exist: CONFIG_STAGE_RAMSTAGE=1
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_STAGE_RAMSTAGE=0
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select CONFIG_STAGE_RAMSTAGE.
Change-Id: Ia6ad9b43dde2d2af40a7b2bc1773c0338ae9552b Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/cpu/x86/Makefile.inc 1 file changed, 3 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/33114/5
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33114 )
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE ......................................................................
Patch Set 5:
(2 comments)
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG Commit Message:
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG@14 PS5, Line 14: >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_ This one doesn't matter though, right?
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) If we have the Makefile dependencies correct this guard really shouldn't be needed, I think.
Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33114 )
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_STAGE_RAMSTAGE ......................................................................
Patch Set 5:
(2 comments)
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG Commit Message:
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG@14 PS5, Line 14: >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This one doesn't matter though, right?
sorry, i didn't get your point. compiler won't be able to understand "rmodules_" and throw compilation error
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)
If we have the Makefile dependencies correct this guard really shouldn't be needed, I think.
In case of CONFIG_RAMPAYLOAD is enable (means without ramstage) somehow we have to compile this file with any previous stage hence we need this Makefile.
Hello Aaron Durbin, ron minnich, build bot (Jenkins), Patrick Georgi, Furquan Shaikh,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33114
to look at the new patch set (#6).
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE ......................................................................
Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE
On x86 platform: Case 1: ramstage do exist: CONFIG_STAGE_RAMSTAGE=1
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_STAGE_RAMSTAGE=0
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select CONFIG_ENABLE_STAGE_RAMSTAGE.
Change-Id: Ia6ad9b43dde2d2af40a7b2bc1773c0338ae9552b Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/cpu/x86/Makefile.inc 1 file changed, 3 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/33114/6
Aaron Durbin 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:
(2 comments)
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG Commit Message:
https://review.coreboot.org/#/c/33114/5//COMMIT_MSG@14 PS5, Line 14: >> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
sorry, i didn't get your point. […]
The compiler won't even get to this point. It's all just Makefile variable parsing. However, my point is that if there is nothing referencing the root dependency for the Makefiles the variable evaluation doesn't matter since the rules won't be utilized at all.
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)
In case of CONFIG_RAMPAYLOAD is enable (means without ramstage) somehow we have to compile this file […]
But where are these rules being acted upon? e.g. if nothing is referencing sipi.bin then Make should never attempt to execute these rules.
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)
But where are these rules being acted upon? e.g. if nothing is referencing sipi. […]
I'm getting below error when i'm skip guarding
make: *** No rule to make target 'build/rmodules_/cpu/x86/sipi_vector.o', needed by 'build/cpu/x86/sipi_vector.o'. Stop.
Aaron Durbin 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)
I'm getting below error when i'm skip guarding […]
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?
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?
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 $@)
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.
Aaron Durbin 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.
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.
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
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.
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.
Hello Aaron Durbin, ron minnich, build bot (Jenkins), Patrick Georgi, Furquan Shaikh,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/33114
to look at the new patch set (#7).
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE ......................................................................
Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE
On x86 platform: Case 1: ramstage do exist: CONFIG_STAGE_RAMSTAGE=1
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_STAGE_RAMSTAGE=0
rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select CONFIG_ENABLE_STAGE_RAMSTAGE.
Also add option to create sipi_vector.manual based on $(TARGET_STAGE) variable.
$(TARGET_STAGE)=ramstage if user selects CONFIG_ENABLE_STAGE_RAMSTAGE $(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD
Change-Id: Ia6ad9b43dde2d2af40a7b2bc1773c0338ae9552b Signed-off-by: Subrata Banik subrata.banik@intel.com --- M src/cpu/x86/Makefile.inc 1 file changed, 18 insertions(+), 14 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/14/33114/7
Aaron Durbin 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 9:
And maybe squash this with the first as well. It was good to see things separated, but I think they should go in with a single patch because they are logically related.
Subrata Banik has abandoned this change. ( https://review.coreboot.org/c/coreboot/+/33114 )
Change subject: Makefile.inc: Fix compilation issue with !CONFIG_ENABLE_STAGE_RAMSTAGE ......................................................................
Abandoned
-
Aaron Durbin (Code Review) -
ron minnich (Code Review)
-
Subrata Banik (Code Review)