[PATCH] smbios: Fix calculating BIOS Release Date

[PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

BIOS Release Date must be in format mm/dd/yyyy and must be release date.
U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
generated from current build timestamp.

Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
better approximation of U-Boot release date than current build timestamp.
Current U-Boot versioning is in format yyyy.mm so as a day choose 01.

Some operating systems are using BIOS Release Date for detecting when was
SMBIOS table filled or if it could support some feature (e.g. BIOS from
1990 cannot support features invented in 2000). So this change also ensures
that recompiling U-Boot from same sources but in different year does not
change behavior of some operating systems.

Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
so remove it from global autogenerated files and also from Makefile.

Signed-off-by: Pali Roh?r <pali@kernel.org>
---
 Makefile                |  2 --
 doc/develop/version.rst |  1 -
 lib/smbios.c            | 23 +++++++++++++++++++++++
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index e423f6de7468..4cd28bce237b 100644
--- a/Makefile
+++ b/Makefile
@@ -1832,7 +1832,6 @@ define filechk_timestamp.h
 			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \
 			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \
 			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \
-			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
 			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
 			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_EPOCH %s'; \
 		else \
@@ -1842,7 +1841,6 @@ define filechk_timestamp.h
 		LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
 		LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
 		LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
-		LC_ALL=C date +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
 		LC_ALL=C date +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
 		LC_ALL=C date +'#define U_BOOT_EPOCH %s'; \
 	fi)
diff --git a/doc/develop/version.rst b/doc/develop/version.rst
index a7797db41bb2..066901bcd2d9 100644
--- a/doc/develop/version.rst
+++ b/doc/develop/version.rst
@@ -84,7 +84,6 @@ fields. For example::
    #define U_BOOT_DATE "Jan 06 2021"     (US format only)
    #define U_BOOT_TIME "08:50:36"        (24-hour clock)
    #define U_BOOT_TZ "-0700"             (Time zone in hours)
-   #define U_BOOT_DMI_DATE "01/06/2021"  (US format only)
    #define U_BOOT_BUILD_DATE 0x20210106  (hex yyyymmdd format)
    #define U_BOOT_EPOCH 1609948236
 
diff --git a/lib/smbios.c b/lib/smbios.c
index 9eb226ec9fbd..e5cf05073543 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -8,6 +8,7 @@
 #include <common.h>
 #include <dm.h>
 #include <env.h>
+#include <linux/stringify.h>
 #include <mapmem.h>
 #include <smbios.h>
 #include <sysinfo.h>
@@ -18,6 +19,28 @@
 #include <dm/uclass-internal.h>
 #endif
 
+/* Safeguard for checking that U_BOOT_VERSION_NUM macros are compatible with U_BOOT_DMI */
+#if U_BOOT_VERSION_NUM < 2000 || U_BOOT_VERSION_NUM > 2099 || \
+    U_BOOT_VERSION_NUM_PATCH < 1 || U_BOOT_VERSION_NUM_PATCH > 12
+#error U_BOOT_VERSION_NUM macros are not compatible with DMI, fix U_BOOT_DMI macros
+#endif
+
+/*
+ * U_BOOT_DMI_DATE contains BIOS Release Date in format mm/dd/yyyy.
+ * BIOS Release Date is calculated from U-Boot version and fixed day 01.
+ * So for U-Boot version 2021.04 it is calculated as "04/01/2021".
+ * BIOS Release Date should contain date when code was released
+ * and not when it was built or compiled.
+ */
+#if U_BOOT_VERSION_NUM_PATCH < 10
+#define U_BOOT_DMI_MONTH "0" __stringify(U_BOOT_VERSION_NUM_PATCH)
+#else
+#define U_BOOT_DMI_MONTH __stringify(U_BOOT_VERSION_NUM_PATCH)
+#endif
+#define U_BOOT_DMI_DAY "01"
+#define U_BOOT_DMI_YEAR __stringify(U_BOOT_VERSION_NUM)
+#define U_BOOT_DMI_DATE U_BOOT_DMI_MONTH "/" U_BOOT_DMI_DAY "/" U_BOOT_DMI_YEAR
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /**
-- 
2.20.1

[PATCH] smbios: Fix calculating BIOS Release Date

[Bin Meng]

Hi Pali,

On Fri, Apr 23, 2021 at 12:10 AM Pali Roh?r <pali@kernel.org> wrote:
>
> BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> generated from current build timestamp.
>
> Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> better approximation of U-Boot release date than current build timestamp.
> Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
>
> Some operating systems are using BIOS Release Date for detecting when was
> SMBIOS table filled or if it could support some feature (e.g. BIOS from
> 1990 cannot support features invented in 2000). So this change also ensures
> that recompiling U-Boot from same sources but in different year does not
> change behavior of some operating systems.
>
> Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> so remove it from global autogenerated files and also from Makefile.
>
> Signed-off-by: Pali Roh?r <pali@kernel.org>
> ---
>  Makefile                |  2 --
>  doc/develop/version.rst |  1 -
>  lib/smbios.c            | 23 +++++++++++++++++++++++
>  3 files changed, 23 insertions(+), 3 deletions(-)
>

With this change the U-Boot date is only the release date, so one
cannot tell exact BIOS date on which U-Boot was built from.

Regards,
Bin

[PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 23 April 2021 10:25:21 Bin Meng wrote:
> Hi Pali,
> 
> On Fri, Apr 23, 2021 at 12:10 AM Pali Roh?r <pali@kernel.org> wrote:
> >
> > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > generated from current build timestamp.
> >
> > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > better approximation of U-Boot release date than current build timestamp.
> > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> >
> > Some operating systems are using BIOS Release Date for detecting when was
> > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > 1990 cannot support features invented in 2000). So this change also ensures
> > that recompiling U-Boot from same sources but in different year does not
> > change behavior of some operating systems.
> >
> > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > so remove it from global autogenerated files and also from Makefile.
> >
> > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > ---
> >  Makefile                |  2 --
> >  doc/develop/version.rst |  1 -
> >  lib/smbios.c            | 23 +++++++++++++++++++++++
> >  3 files changed, 23 insertions(+), 3 deletions(-)
> >
> 
> With this change the U-Boot date is only the release date, so one
> cannot tell exact BIOS date on which U-Boot was built from.

Hello Bin! I understood that this is expected and it should be the
release date, not the build date. But maybe it has different meanings in
different contexts?

[PATCH] smbios: Fix calculating BIOS Release Date

[Mark Kettenis]

> Date: Fri, 23 Apr 2021 10:27:16 +0200
> From: Pali Roh?r <pali@kernel.org>
> 
> On Friday 23 April 2021 10:25:21 Bin Meng wrote:
> > Hi Pali,
> > 
> > On Fri, Apr 23, 2021 at 12:10 AM Pali Roh?r <pali@kernel.org> wrote:
> > >
> > > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> > > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > > generated from current build timestamp.
> > >
> > > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > > better approximation of U-Boot release date than current build timestamp.
> > > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> > >
> > > Some operating systems are using BIOS Release Date for detecting when was
> > > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > > 1990 cannot support features invented in 2000). So this change also ensures
> > > that recompiling U-Boot from same sources but in different year does not
> > > change behavior of some operating systems.
> > >
> > > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > > so remove it from global autogenerated files and also from Makefile.
> > >
> > > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > ---
> > >  Makefile                |  2 --
> > >  doc/develop/version.rst |  1 -
> > >  lib/smbios.c            | 23 +++++++++++++++++++++++
> > >  3 files changed, 23 insertions(+), 3 deletions(-)
> > >
> > 
> > With this change the U-Boot date is only the release date, so one
> > cannot tell exact BIOS date on which U-Boot was built from.
> 
> Hello Bin! I understood that this is expected and it should be the
> release date, not the build date. But maybe it has different meanings in
> different contexts?

To be honest, I think the BIOS data as advertised by SMBIOS is fairly
useless for an open source firmware solution like U-Boot.  With
multiple branches and forks in existence a single date doesn't really
give you a good clue about what bugs might be present in the firmware
or whether you are running the most up-to-date version.

Note that we already advertise the U-Boot release in the EFI firmware
revision:

efi0 at mainbus0: UEFI 2.8
efi0: Das U-Boot rev 0x20200700

so doing the same for SMBIOS doesn't really provide more information.
Using the build date at least tells you how old the firmware is you're
using...

I'm pretty sure traditional closed source firmware on x86 uses the
build date here as well.

[PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 23 April 2021 11:04:26 Mark Kettenis wrote:
> > Date: Fri, 23 Apr 2021 10:27:16 +0200
> > From: Pali Roh?r <pali@kernel.org>
> > 
> > On Friday 23 April 2021 10:25:21 Bin Meng wrote:
> > > Hi Pali,
> > > 
> > > On Fri, Apr 23, 2021 at 12:10 AM Pali Roh?r <pali@kernel.org> wrote:
> > > >
> > > > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> > > > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > > > generated from current build timestamp.
> > > >
> > > > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > > > better approximation of U-Boot release date than current build timestamp.
> > > > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> > > >
> > > > Some operating systems are using BIOS Release Date for detecting when was
> > > > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > > > 1990 cannot support features invented in 2000). So this change also ensures
> > > > that recompiling U-Boot from same sources but in different year does not
> > > > change behavior of some operating systems.
> > > >
> > > > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > > > so remove it from global autogenerated files and also from Makefile.
> > > >
> > > > Signed-off-by: Pali Roh?r <pali@kernel.org>
> > > > ---
> > > >  Makefile                |  2 --
> > > >  doc/develop/version.rst |  1 -
> > > >  lib/smbios.c            | 23 +++++++++++++++++++++++
> > > >  3 files changed, 23 insertions(+), 3 deletions(-)
> > > >
> > > 
> > > With this change the U-Boot date is only the release date, so one
> > > cannot tell exact BIOS date on which U-Boot was built from.
> > 
> > Hello Bin! I understood that this is expected and it should be the
> > release date, not the build date. But maybe it has different meanings in
> > different contexts?
> 
> To be honest, I think the BIOS data as advertised by SMBIOS is fairly
> useless for an open source firmware solution like U-Boot.  With
> multiple branches and forks in existence a single date doesn't really
> give you a good clue about what bugs might be present in the firmware
> or whether you are running the most up-to-date version.
> 
> Note that we already advertise the U-Boot release in the EFI firmware
> revision:
> 
> efi0 at mainbus0: UEFI 2.8
> efi0: Das U-Boot rev 0x20200700
> 
> so doing the same for SMBIOS doesn't really provide more information.
> Using the build date at least tells you how old the firmware is you're
> using...
> 
> I'm pretty sure traditional closed source firmware on x86 uses the
> build date here as well.

There is a difference, that this closed source firmware in most cases
cannot be recompiled therefore its "BIOS Release Date" is not changed
after "releasing" binary blob. So one version of this closed firmware
has only one BIOS Release Date.

But because U-Boot is distributed in source code and "BIOS Release Date"
is filled at compile time, it can be any value and therefore one U-Boot
version may have different values in "BIOS Release Date" section.

So... would not it be better to advertise stable (predictable) U-Boot
version as "BIOS Release Date" and "UEFI revision" instead of
unpredictable compilation timestamp?

Re: [PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 23 April 2021 11:14:44 Pali Rohár wrote:
> On Friday 23 April 2021 11:04:26 Mark Kettenis wrote:
> > > Date: Fri, 23 Apr 2021 10:27:16 +0200
> > > From: Pali Rohár <pali@kernel.org>
> > > 
> > > On Friday 23 April 2021 10:25:21 Bin Meng wrote:
> > > > Hi Pali,
> > > > 
> > > > On Fri, Apr 23, 2021 at 12:10 AM Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> > > > > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > > > > generated from current build timestamp.
> > > > >
> > > > > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > > > > better approximation of U-Boot release date than current build timestamp.
> > > > > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> > > > >
> > > > > Some operating systems are using BIOS Release Date for detecting when was
> > > > > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > > > > 1990 cannot support features invented in 2000). So this change also ensures
> > > > > that recompiling U-Boot from same sources but in different year does not
> > > > > change behavior of some operating systems.
> > > > >
> > > > > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > > > > so remove it from global autogenerated files and also from Makefile.
> > > > >
> > > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > > ---
> > > > >  Makefile                |  2 --
> > > > >  doc/develop/version.rst |  1 -
> > > > >  lib/smbios.c            | 23 +++++++++++++++++++++++
> > > > >  3 files changed, 23 insertions(+), 3 deletions(-)
> > > > >
> > > > 
> > > > With this change the U-Boot date is only the release date, so one
> > > > cannot tell exact BIOS date on which U-Boot was built from.
> > > 
> > > Hello Bin! I understood that this is expected and it should be the
> > > release date, not the build date. But maybe it has different meanings in
> > > different contexts?
> > 
> > To be honest, I think the BIOS data as advertised by SMBIOS is fairly
> > useless for an open source firmware solution like U-Boot.  With
> > multiple branches and forks in existence a single date doesn't really
> > give you a good clue about what bugs might be present in the firmware
> > or whether you are running the most up-to-date version.
> > 
> > Note that we already advertise the U-Boot release in the EFI firmware
> > revision:
> > 
> > efi0 at mainbus0: UEFI 2.8
> > efi0: Das U-Boot rev 0x20200700
> > 
> > so doing the same for SMBIOS doesn't really provide more information.
> > Using the build date at least tells you how old the firmware is you're
> > using...
> > 
> > I'm pretty sure traditional closed source firmware on x86 uses the
> > build date here as well.
> 
> There is a difference, that this closed source firmware in most cases
> cannot be recompiled therefore its "BIOS Release Date" is not changed
> after "releasing" binary blob. So one version of this closed firmware
> has only one BIOS Release Date.
> 
> But because U-Boot is distributed in source code and "BIOS Release Date"
> is filled at compile time, it can be any value and therefore one U-Boot
> version may have different values in "BIOS Release Date" section.
> 
> So... would not it be better to advertise stable (predictable) U-Boot
> version as "BIOS Release Date" and "UEFI revision" instead of
> unpredictable compilation timestamp?

I have looked and basically BIOS Release Date is used by operating
systems as a check that some bugs or functionality may be present.

So it really should be treated as "version" and not as "compile time" in
U-Boot. And I think same applies also for UEFI revision.

Re: [PATCH] smbios: Fix calculating BIOS Release Date

[Simon Glass]

On Thu, 22 Apr 2021 at 10:10, Pali Rohár <pali@kernel.org> wrote:
>
> BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> generated from current build timestamp.
>
> Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> better approximation of U-Boot release date than current build timestamp.
> Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
>
> Some operating systems are using BIOS Release Date for detecting when was
> SMBIOS table filled or if it could support some feature (e.g. BIOS from
> 1990 cannot support features invented in 2000). So this change also ensures
> that recompiling U-Boot from same sources but in different year does not
> change behavior of some operating systems.
>
> Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> so remove it from global autogenerated files and also from Makefile.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
>  Makefile                |  2 --
>  doc/develop/version.rst |  1 -
>  lib/smbios.c            | 23 +++++++++++++++++++++++
>  3 files changed, 23 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH] smbios: Fix calculating BIOS Release Date

[Heinrich Schuchardt]

On 4/22/21 6:09 PM, Pali Rohár wrote:
> BIOS Release Date must be in format mm/dd/yyyy and must be release date.

%s/BIOS/The SMBIOS/

Please add a reference to the System Management BIOS (SMBIOS) Reference
Specification here an as comment in the code.

> U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> generated from current build timestamp.

%s/BIOS/the SMBIOS/

Please, describe in the commit message that you want to achieve
reproducible builds.

>
> Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> better approximation of U-Boot release date than current build timestamp.
> Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
>
> Some operating systems are using BIOS Release Date for detecting when was
> SMBIOS table filled or if it could support some feature (e.g. BIOS from
> 1990 cannot support features invented in 2000). So this change also ensures
> that recompiling U-Boot from same sources but in different year does not
> change behavior of some operating systems.
>
> Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> so remove it from global autogenerated files and also from Makefile.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> ---
>   Makefile                |  2 --
>   doc/develop/version.rst |  1 -
>   lib/smbios.c            | 23 +++++++++++++++++++++++
>   3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index e423f6de7468..4cd28bce237b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1832,7 +1832,6 @@ define filechk_timestamp.h
>   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \
>   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \
>   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \
> -			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
>   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
>   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_EPOCH %s'; \
>   		else \
> @@ -1842,7 +1841,6 @@ define filechk_timestamp.h
>   		LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
>   		LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
>   		LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
> -		LC_ALL=C date +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
>   		LC_ALL=C date +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
>   		LC_ALL=C date +'#define U_BOOT_EPOCH %s'; \
>   	fi)
> diff --git a/doc/develop/version.rst b/doc/develop/version.rst
> index a7797db41bb2..066901bcd2d9 100644
> --- a/doc/develop/version.rst
> +++ b/doc/develop/version.rst
> @@ -84,7 +84,6 @@ fields. For example::
>      #define U_BOOT_DATE "Jan 06 2021"     (US format only)
>      #define U_BOOT_TIME "08:50:36"        (24-hour clock)
>      #define U_BOOT_TZ "-0700"             (Time zone in hours)
> -   #define U_BOOT_DMI_DATE "01/06/2021"  (US format only)
>      #define U_BOOT_BUILD_DATE 0x20210106  (hex yyyymmdd format)
>      #define U_BOOT_EPOCH 1609948236
>
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 9eb226ec9fbd..e5cf05073543 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -8,6 +8,7 @@
>   #include <common.h>
>   #include <dm.h>
>   #include <env.h>
> +#include <linux/stringify.h>
>   #include <mapmem.h>
>   #include <smbios.h>
>   #include <sysinfo.h>
> @@ -18,6 +19,28 @@
>   #include <dm/uclass-internal.h>
>   #endif
>
> +/* Safeguard for checking that U_BOOT_VERSION_NUM macros are compatible with U_BOOT_DMI */
> +#if U_BOOT_VERSION_NUM < 2000 || U_BOOT_VERSION_NUM > 2099 || \
> +    U_BOOT_VERSION_NUM_PATCH < 1 || U_BOOT_VERSION_NUM_PATCH > 12
> +#error U_BOOT_VERSION_NUM macros are not compatible with DMI, fix U_BOOT_DMI macros
> +#endif
> +
> +/*
> + * U_BOOT_DMI_DATE contains BIOS Release Date in format mm/dd/yyyy.

Why should we call this DMI_DATE and not SMBIOS_RELEASE_DATE?

Best regards

Heinrich

> + * BIOS Release Date is calculated from U-Boot version and fixed day 01.
> + * So for U-Boot version 2021.04 it is calculated as "04/01/2021".
> + * BIOS Release Date should contain date when code was released
> + * and not when it was built or compiled.
> + */
> +#if U_BOOT_VERSION_NUM_PATCH < 10
> +#define U_BOOT_DMI_MONTH "0" __stringify(U_BOOT_VERSION_NUM_PATCH)
> +#else
> +#define U_BOOT_DMI_MONTH __stringify(U_BOOT_VERSION_NUM_PATCH)
> +#endif
> +#define U_BOOT_DMI_DAY "01"
> +#define U_BOOT_DMI_YEAR __stringify(U_BOOT_VERSION_NUM)
> +#define U_BOOT_DMI_DATE U_BOOT_DMI_MONTH "/" U_BOOT_DMI_DAY "/" U_BOOT_DMI_YEAR
> +
>   DECLARE_GLOBAL_DATA_PTR;
>
>   /**
>

Re: [PATCH] smbios: Fix calculating BIOS Release Date

[Pali Rohár]

On Friday 16 July 2021 08:39:05 Heinrich Schuchardt wrote:
> On 4/22/21 6:09 PM, Pali Rohár wrote:
> > BIOS Release Date must be in format mm/dd/yyyy and must be release date.
> 
> %s/BIOS/The SMBIOS/

No. In SMBIOS specification and also in U-Boot structures it is called
"BIOS Release Date". Not "SMBIOS Release Date".

> Please add a reference to the System Management BIOS (SMBIOS) Reference
> Specification here an as comment in the code.

Ok, I will include it.

FYI Spec DSP0134 from https://www.dmtf.org/standards/smbios
In version 3.4.0 is "Type 0" "BIOS Release Date" described at page 33.

> > U-Boot currently sets BIOS Release Date from U_BOOT_DMI_DATE macro which is
> > generated from current build timestamp.
> 
> %s/BIOS/the SMBIOS/
> 
> Please, describe in the commit message that you want to achieve
> reproducible builds.

It is not only reproducible build, but also fixing behavior of OSes (as
written below). But I can add info also about reproducible builds.

> > 
> > Fix this issue by setting U_BOOT_DMI_DATE macro to U-Boot version which is
> > better approximation of U-Boot release date than current build timestamp.
> > Current U-Boot versioning is in format yyyy.mm so as a day choose 01.
> > 
> > Some operating systems are using BIOS Release Date for detecting when was
> > SMBIOS table filled or if it could support some feature (e.g. BIOS from
> > 1990 cannot support features invented in 2000). So this change also ensures
> > that recompiling U-Boot from same sources but in different year does not
> > change behavior of some operating systems.
> > 
> > Macro U_BOOT_DMI_DATE is not used in other file than lib/smbios.c
> > so remove it from global autogenerated files and also from Makefile.
> > 
> > Signed-off-by: Pali Rohár <pali@kernel.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> > ---
> >   Makefile                |  2 --
> >   doc/develop/version.rst |  1 -
> >   lib/smbios.c            | 23 +++++++++++++++++++++++
> >   3 files changed, 23 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index e423f6de7468..4cd28bce237b 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1832,7 +1832,6 @@ define filechk_timestamp.h
> >   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DATE "%b %d %C%y"'; \
> >   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TIME "%T"'; \
> >   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_TZ "%z"'; \
> > -			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
> >   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
> >   			LC_ALL=C $${DATE} -u -d "$${SOURCE_DATE}" +'#define U_BOOT_EPOCH %s'; \
> >   		else \
> > @@ -1842,7 +1841,6 @@ define filechk_timestamp.h
> >   		LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \
> >   		LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \
> >   		LC_ALL=C date +'#define U_BOOT_TZ "%z"'; \
> > -		LC_ALL=C date +'#define U_BOOT_DMI_DATE "%m/%d/%Y"'; \
> >   		LC_ALL=C date +'#define U_BOOT_BUILD_DATE 0x%Y%m%d'; \
> >   		LC_ALL=C date +'#define U_BOOT_EPOCH %s'; \
> >   	fi)
> > diff --git a/doc/develop/version.rst b/doc/develop/version.rst
> > index a7797db41bb2..066901bcd2d9 100644
> > --- a/doc/develop/version.rst
> > +++ b/doc/develop/version.rst
> > @@ -84,7 +84,6 @@ fields. For example::
> >      #define U_BOOT_DATE "Jan 06 2021"     (US format only)
> >      #define U_BOOT_TIME "08:50:36"        (24-hour clock)
> >      #define U_BOOT_TZ "-0700"             (Time zone in hours)
> > -   #define U_BOOT_DMI_DATE "01/06/2021"  (US format only)
> >      #define U_BOOT_BUILD_DATE 0x20210106  (hex yyyymmdd format)
> >      #define U_BOOT_EPOCH 1609948236
> > 
> > diff --git a/lib/smbios.c b/lib/smbios.c
> > index 9eb226ec9fbd..e5cf05073543 100644
> > --- a/lib/smbios.c
> > +++ b/lib/smbios.c
> > @@ -8,6 +8,7 @@
> >   #include <common.h>
> >   #include <dm.h>
> >   #include <env.h>
> > +#include <linux/stringify.h>
> >   #include <mapmem.h>
> >   #include <smbios.h>
> >   #include <sysinfo.h>
> > @@ -18,6 +19,28 @@
> >   #include <dm/uclass-internal.h>
> >   #endif
> > 
> > +/* Safeguard for checking that U_BOOT_VERSION_NUM macros are compatible with U_BOOT_DMI */
> > +#if U_BOOT_VERSION_NUM < 2000 || U_BOOT_VERSION_NUM > 2099 || \
> > +    U_BOOT_VERSION_NUM_PATCH < 1 || U_BOOT_VERSION_NUM_PATCH > 12
> > +#error U_BOOT_VERSION_NUM macros are not compatible with DMI, fix U_BOOT_DMI macros
> > +#endif
> > +
> > +/*
> > + * U_BOOT_DMI_DATE contains BIOS Release Date in format mm/dd/yyyy.
> 
> Why should we call this DMI_DATE and not SMBIOS_RELEASE_DATE?

I really do not know. It was called DMI_DATE also prior this my change.
I'm not changing name of this constant. If it is needed / required then
it can be done in other followup patch.

> Best regards
> 
> Heinrich
> 
> > + * BIOS Release Date is calculated from U-Boot version and fixed day 01.
> > + * So for U-Boot version 2021.04 it is calculated as "04/01/2021".
> > + * BIOS Release Date should contain date when code was released
> > + * and not when it was built or compiled.
> > + */
> > +#if U_BOOT_VERSION_NUM_PATCH < 10
> > +#define U_BOOT_DMI_MONTH "0" __stringify(U_BOOT_VERSION_NUM_PATCH)
> > +#else
> > +#define U_BOOT_DMI_MONTH __stringify(U_BOOT_VERSION_NUM_PATCH)
> > +#endif
> > +#define U_BOOT_DMI_DAY "01"
> > +#define U_BOOT_DMI_YEAR __stringify(U_BOOT_VERSION_NUM)
> > +#define U_BOOT_DMI_DATE U_BOOT_DMI_MONTH "/" U_BOOT_DMI_DAY "/" U_BOOT_DMI_YEAR
> > +
> >   DECLARE_GLOBAL_DATA_PTR;
> > 
> >   /**
> > 
>