В Thu, 17 Dec 2009 09:16:07 +0100
Wolfgang Denk <w...@denx.de> пишет:
> Dear Vitaly Bordug,
>
>
> repl: bad addresses:
> linuxppc-...@ozlabs.org <linuxppc-...@ozlabs.org> -- junk
> after lo...@domain (<) In message <20091216024730.455b9...@vitb-lp>
> you wrote:
> >
> > From: Heiko Schocher <h...@denx.de>
> >
> > This driver provides (read/write) access to the
> > U-Boot bootcounter via PROC FS or sysFS.
> >
> > in u-boot, it uses a 8 byte mem area (it must hold the value over a
> > soft reset of course), for storing a bootcounter (it counts many
> > soft resets are done, on hard reset it starts with 0). If the
> > bootcountvalue exceeds the value in the env variable "bootlimit",
> > and alternative bootcmd stored in the env variable "altbootcmd" is
> > run.
> >
> > The bootcountregister gets configured via DTS.
> > for example on the mgsuvd board:
> >
> > bootco...@0x3eb0 {
> > device_type = "bootcount";
> > compatible = "uboot,bootcount";
> > reg = <0x3eb0 0x08>;
> > };
> >
> > This driver is tested on the mgcoge(82xx) and mgsuvd(8xx) board.
> >
> > Signed-off-by: Heiko Schocher <h...@denx.de>
> > Signed-off-by: Wolfgang Denk <w...@denx.de>
> > Signed-off-by: Vitaly Bordyug <v...@kernel.crashing.org>
>
> I think it would be good if the text of the commit message could be
> reworked by a native English speaker.
>
OK.
> Regarding the subject: it is probably important to point out that this
> driver implements the Linux kernel half of the boot count feature -
> the boot counter can only be reset after it is clear that the
> application has been started and is running correctly, which usually
> can only be determined by the application code itself. Thus the reset
> of the boot counter must be done by application code, which thus needs
> an appropriate driver.
>
I'll rework the commit message to make it more clear, thanks for the
details!
-Vitaly
> > I think there is no reason not to have this in mainline. Thoughts?
> > And I'm not sure what is right direction to push this - it's
> > representation of u-boot feature in fact, pretty useful tho.
>
> It's not only useful, it's actually a required feature by the Carrier
> Grade Linux Requirements Definition; see for example document "Carrier
> Grade Linux Requirements Definition Overview V3.0" at
> https://www.linux-foundation.org/images/1/1a/Cgl_req_def_overview_30.pdf
> Page 49:
>
> ID PLT.4.0 (2.3 in v1.1) Boot Cycle Detection
>
> Description: OSDL CGL specifies that carrier grade Linux
> shall provide support for detecting a repeating reboot cycle
> due to recurring failures and going to an offline state if
> this occurs.
>
>
>
>
> Best regards,
>
> Wolfgang Denk
>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
