Re: [PATCH v4 2/4] nvmem: bootcount: add bootcount driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-06-03 11:03, Srinivas Kandagatla wrote:
On 01/06/2021 08:58, Nandor Han wrote:
On 5/28/21 11:23 AM, Srinivas Kandagatla wrote:
On 05/05/2021 11:42, Nandor Han wrote:
In order to have a robust system we want to be able to identify and take
actions if a boot loop occurs. This is possible by using the bootcount
feature, which can be used to identify the number of times device has
booted since bootcount was last time reset. Bootcount feature (1)
requires a collaboration between bootloader and user-space, where
the bootloader will increase a counter and user-space reset it.
If the counter is not reset and a pre-established threshold is reached,
bootloader can react and take action.

This is the kernel side implementation, which can be used to
identify the number of times device has booted since bootcount was
last time reset.


If I understand this correctly, this driver is basically exposing a nvmem cell via sysfs.

Firstly, This sounds like totally a generic functionality that needs to go into nvmem core rather than individual drivers.

Do you see any reason for this not be in core?

I agree that exposing a NVMEM cell via sysfs does look as a generic functionality. However, the bootcount feature contains also a magic
value that needs to be taken in consideration when extracting the
bootcount value. The size of the field storing the magic and value combo
is configurable as well. The driver will handle this values transparentlry for the user and expose only the validated
bootcount value. In case we will only use a generic implementation for
exposing a NVMEM cell via sysfs the aformention functionality will have
to be handled by userspace and this will force the userspace to have
knolwdge about bootcount value format and magic since they will have
to implement it's own functionality about this. In the current solution
the user only have to reset the value to 0 and that's it, the driver
will take care of the rest.

Should this not live in userspace HAL, kernel would provide an abstract interface. User space in this case which is programming the bootcount is already aware of this, so am hoping that it would be able to encapsulate the magic as well with in.

Instead of accessing sysfs directly, its always recommended to access it via a some abstraction HAL programs, so as to not break the userspace across kernel releases, more info at ./Documentation/admin-guide/sysfs-rules.rst

Other problem with having this in kernel is that we would endup with endless number of drivers for each nvmem cell which is totally not necessary.

Personally I do not want to endup in such a situation where people start writing drivers for each cell.

If we look from U-Boot source code (for which the boot count support has been there for long time):

https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/bootcount

In there we do have solutions for:

- Atmel AT91 -- one specific CPU register

- Davinci/Omap/beaglebone -- Uses internal RTC's scratcpad #2 register
- In here Scratcpad #0/#1 were at least one point of time used for deep sleep recovery addresses -- and probably should not be exposed at all to user space

- As U-Boot environment variable -- what ever storage would be

- File system interface -- store as a file

- I2C (version 1) -- store in (volatile) 16 bit RTC register

- RAM -- Use multiple addreses for storing magics and actual boot count value

- I2C EEPROM -- Store in persistent cells in EEPROM

- RTC -- Store in RTC if the chip has support for it

- SPI flash -- Store in special location in serial flash

So we are already in situation that there exists multiple technical solutions :| And best bit here is that some of them can be customized by Kconfig options.

Another observation of that list is that those all are not NVMEM cells -- so more generic solution abstracting it away would be better. Actually the best solution for boot count is probably volatile register that persist over reset of the device and is not subject of flash endurance.

So perhaps there should be "core boot count internal API" for which driver (in this case nvmem specific) can register itself and then that "boot count core" would then expose it to user space. That would most likely be quite slim implementation. And most likely there would only be one solution per device but in theory it could also support case if device supports more than one place to store it then it would handle this transparently from the driver.

I believe the sysfs would be perfect for this especially when the path for the entry would stay the same independent of the solution behind the boot count. This would make it easy for user space to read the boot count in shell scripts or in applications and then resetting would be as easy as echoing "0" to sysfs entry.

Thanks,
Vesa Jääskeläinen



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux