[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