Issue #664 has been updated by Matt DeVillier.
> Is this hardcoded `$(obj)/spd | build/spd` a bug, or can this be worked
> around using the "correct" `Makefile.mk` `subdirs` or other `SPD_SOURCES`
> references?
In the board/baseboard Makefile.mk
```
SPD_SOURCES = apple
LIB_SPD_DEPS := $(foreach f, $(SPD_SOURCES), \
src/mainboard/$(MAINBOARDDIR)/variants/$(VARIANT_DIR)/spd/$(f).spd.hex)
```
should be all you need
----------------------------------------
Bug #664: src/lib/Makefile.mk "build/spd" folder hardcoded fails on VARIANT_DIR
own spd folder?
https://ticket.coreboot.org/issues/664#change-2397
* Author: Walter Sonius
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2026-08-19
----------------------------------------
When completing the variant base for "snb_ivb_macs" starting from the current
`mb/apple/macbookair4_2` and already included upcoming
`macmini6_1/macbookpro9_2/macbookpro10_1` I'm currently hold back when adding
the "macbookbpro10_1" which like the "macbookair4_2" also comes with its own
`spd` folder.
Moving the `spd` folders to their own variants and having a `subdirs-y +=
variants/$(VARIANT_DIR)` inside the `Makefile.mk` of the base variant folder
and a variant specific `Makefile.mk` including `subdirs-y += spd` or
`SPD_SOURCES += apple` depending on the model, I stumble upon this error when
building:
```
#BUILD FAILING
No rule to make target 'build/spd/apple.spd.hex', needed by 'build/spd.bin'.
```
However this can be worked around when `src/lib/Makefile.mk` line ~375 gets
replaced, but I'm certain this will break other coreboot ports:
```
#SPD_OBJ_DIR := $(obj)/spd
SPD_OBJ_DIR := src/mainboard/$(MAINBOARDDIR)/variants/$(VARIANT_DIR)/spd
```
Although there is some wildcard defined at line ~390, adding the variant folder
there won't make it work, but will fix listing the correct location of where
spd files resides but cannot be found...
With this single line hack all 4 "snb_ivb_macs" variants not only build
successful, but also share the same hash `BUILD_TIMELESS=1
CONFIG_INCLUDE_CONFIG_FILE=n` as their original port folder (if taking in
account the following considerations that a ramstage linked file in variant
folder is used on the original port and currently share the same CBFSSIZE &
CMOS OPTIONS shared with the base "macbookair4_2").
I did find a similar SPD situation for some variants in
`mb/lenovo/sklkbl_thinkpad` but that seems to have its own assistive SPD
indexing workaround script `mb/lenovo/sklkbl_thinkpad/spd/spd.c` for the
`memory` folder for "t470s" / "x280" and "t480s" having its own `spd` folder?
Is this hardcoded `$(obj)/spd | build/spd` a bug, or can this be worked around
using the "correct" `Makefile.mk` `subdirs` or other `SPD_SOURCES` references?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
https://ticket.coreboot.org/my/account
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
