Uwe Hermann wrote:
Index: src/mainboard/supermicro/h8dme/Kconfig
--- src/mainboard/supermicro/h8dme/Kconfig (Revision 0) +++ src/mainboard/supermicro/h8dme/Kconfig (Revision 0)
[...]
+config HAVE_HARD_RESET
- bool
- default y
- depends on BOARD_SUPERMICRO_H8DME
This can be a simple "select HAVE_HARD_RESET" above, but I assume you'll do this kind of changes with a script later?
PLEASE don't wait until later!
New code being developed between first introduction of Kconfig and "later" will inherit improper use of Kconfig - I so don't want that.
If a board is not using Kconfig perfectly I think it's better that it does not build!
That is one (IMO good) way to encourage proper Kconfig use.
At this point only very few developers really know how Kconfig is supposed to be used, and the rest of us are fighting the learning curve - with delight. However, it is very easy to use bad examples - which then causes more things that need fixing.
Can we avoid this?
+ifdef POST_EVALUATION
+MAINBOARD_OPTIONS=\
- -DCONFIG_AP_IN_SIPI_WAIT=0 \
- -DCONFIG_USE_PRINTK_IN_CAR=1 \
- -DCONFIG_HAVE_HIGH_TABLES=1
What's the difference between using MAINBOARD_OPTIONS here vs. adding these settings in the Kconfig file for the respective mainboard? Can't we eliminate MAINBOARD_OPTIONS?
Yes, I'd also like to know.
+config BOARD_VIA_PC2500E
- bool "PC2500E"
pc2500e in this case, the vendor also writes it in all-lowercase. Maybe I'll fix this type of strings in one big committ soonish.
Go for it.
ifdef POST_EVALUATION
Again with POST_EVALUATION. What is that?
+CPUTYPE ?= p2
Yep, this kind of fix was on my TODO list also.
Maybe ROMCC_MCPU (a bit more descriptive I guess)?
Yes please!
+++ src/mainboard/intel/truxton/Makefile.inc (Revision 0) @@ -0,0 +1,3 @@ +CPUTYPE := p4 -fno-simplify-phi
Hm, this is a bit of a hack, maybe make a generic ROMCC_CFLAGS then like this?
ROMCC_CFLGAGS = -mcpu=p4 -fno-simplify-phi
Yes please!
Thanks for finding this Uwe.
//Peter