<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>hi ,</div><div><br></div><div>thank you for your help. I didn't test this, but I want ask a question, if this package hasn't been updated, the time will be updated automatically or not?</div><div><br></div><div>Thanks,</div><div>Byron</div><br><br><br><br><div style="position:relative;zoom:1"></div><div id="divNeteaseMailCard"></div><br>At 2019-11-22 17:06:04, "rgrs" <rgrs@protonmail.com> wrote:<br> <blockquote id="isReplyContent" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div>Hi Byron,<br></div><div><br></div><div>We had a similiar need, and we use IPMI aux version for this purpose.<br></div><div><br></div><div>To get the behavior you describe, you can change <a href="https://github.com/openbmc/openbmc/blob/master/meta-ibm/meta-witherspoon/recipes-phosphor/ipmi/phosphor-ipmi-config.bbappend">your platform's phosphor-ipmi-config.bbappend</a><br></div><div><br></div><div>Witherspoon for example, calculates Aux rev info from VERSION_ID (git tag, I guess).<br></div><div>In our platforms, we instead write DDMMYYYY into IPMI Get Dev ID's aux rev info (4bytes, BCD)<br></div><div><br></div><div>"ipmitool mc info" would looks something like below:<br></div><div>Aux Firmware Rev Info :<br></div><div> 0x22<br></div><div> 0x11<br></div><div> 0x19<br></div><div> 0x20<br></div><div><br></div><div>Thanks,<br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user protonmail_signature_block-empty"><br></div><div class="protonmail_signature_block-proton">Raj<br></div></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Thursday, November 21, 2019 6:32 AM, www <ouyangxuan10@163.com> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div>Dear Joseph & Vijay Khemka,<br></div><div><br></div><div>No matter what your version is, build date only represents the time when the image was created.<br></div><div><br></div><div>thanks,<br></div><div>Byron<br></div><div><br></div><div><br></div><div style="position:relative;zoom:1"><br></div><div><br></div><div><br></div><pre><div><br></div><div>At 2019-11-21 02:08:40, "Vijay Khemka" <vijaykhemka@fb.com> wrote:
>
>
>On 11/20/19, 8:40 AM, "openbmc on behalf of Joseph Reynolds" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jrey@linux.ibm.com> wrote:
>
>
> On 11/18/19 7:23 PM, www wrote:
> > Dear Joseph，
> >
> > Thank you very much for your help. I just want to show the compile
> > time of firmware to the user. If only show the version, it can't
> > correspond to the time. When both are displayed at the same time, the
> > information will be clearer. thanks again.
> >
>
> Byron, thanks for that. I think I understand your use case. However,
> does this practice assume the build date is close to the date when the
> software version was created?
> - For example, I assume you'll merge a git commit to create a new
> software version, and then build an image based on that commit. In this
> way, the build date correlates closely with the version.
> - However, if you build an image from an older commit, or wait a long
> time before building an image, the build date will not correlate closely
> with the version. This can be misleading and lead to errors in handling
> images.
>
>I guess build date should be the date version was released or created.
>
> Is that a concern for you?
>
> - Joseph
>
> > thanks,
> > Byron
> >
> ...snip...
>
>
>
<br></div></pre></div><div><br></div><div><br></div><span title="neteasefooter"><p> <br></p></span></blockquote><div><br></div></blockquote></div><br><br><span title="neteasefooter"><p> </p></span>