Hi Alex,
On Wed, Feb 14, 2018 at 8:53 AM, Lukasz Majewski lukma@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_ land properly.
Ok. I see.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de