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_ land properly. -- Alex Kiernan _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
