On Wed, Feb 14, 2018 at 8:53 AM, Lukasz Majewski <lu...@denx.de> wrote:
>> >> Whatever we do, I think CONFIG_SYS_BOOTCOUNT_ADDR wants splitting
>> >> into at least two:
>> >> - I2C - an offset from an I2C base for the bootcounter
>> > - RAM/SoC memory - location of special register to store
>> > bootcounter
>> >> - Others - an actual address used for storing the bootcounter
>> >> I'm struggling to see why EXT is the way it is - AFAICS the
>> >> location it uses to access/return the bootcounter is basically
>> >> local to the two functions in bootcount_ext and could just be a
>> >> local variable.
>> > Maybe we can replace it with local, static variable then?
>> > As said above - I would remove the (wrongly?) used BOOTCOUNT_ADDR in
>> > Kconfig.
>> Just removing SYS_BOOTCOUNT_ADDR from Kconfig and putting the default
>> back into bootcount_ext seems like the simplest correct change. I'll
>> add that onto the series and throw it at Travis.
> Great. I'm looking forward for next verison of the code - as I do have
> some code to be put on top of it.
So the super-trivial approach doesn't work, because
CONFIG_SYS_BOOTCOUNT_ADDR isn't in the whitelist anymore
(7af2e3648f3f6d726f6476745c2eec5de709a702) and I think the only reason
it was getting through before is because scripts/check-config.sh
doesn't parse conditionals in Kconfig so thought it was allowed :(
I expect reintroducing CONFIG_SYS_BOOTCOUNT_ADDR to
config_whitelist.txt would "fix" the problem, but that's not going to
make it in.
Which I think means I have to do the work to migrate it out of CONFIG_
U-Boot mailing list