[U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
Robert P. J. Day
rpjday at crashcourse.ca
Tue Jul 26 13:22:43 CEST 2016
a short followup to my earlier post after i did a bit more reading
... i can see a bit more clearly the purpose of the Kbuild variable
CONFIG_BOOTCOUNT_AM33XX being used in drivers/bootcount/Makefile:
obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o
since, apparently, only some(?) AM33xx targets use the corresponding
davinci RTC that can be used for this (if i'm reading that correctly):
$ grep -r "#define.*CONFIG_BOOTCOUNT_AM33XX" *
include/configs/am335x_sl50.h:#define CONFIG_BOOTCOUNT_AM33XX
include/configs/bav335x.h:#define CONFIG_BOOTCOUNT_AM33XX
include/configs/baltos.h:#define CONFIG_BOOTCOUNT_AM33XX
include/configs/am335x_evm.h:#define CONFIG_BOOTCOUNT_AM33XX
include/configs/brppt1.h:#define CONFIG_BOOTCOUNT_AM33XX
$
so i can appreciate that you can't just check CONFIG_AM33XX as that
wouldn't apply to all of the other AM33xx targets.
however, rather than invent a whole new variable for this, i think
it would be clearer if that Makefile tested specifically for the
property in question -- the presence of the davinci RTC or something
similar, perhaps checking CONFIG_RTC_DAVINCI in conjunction with
CONFIG_AM33XX?
in short, i think it's cleaner to avoid creating whole new Kbuild
variables if one can use existing ones that make Makefiles easier to
understand. but now i admit i'm just being picky.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
More information about the U-Boot
mailing list