mainboard/pcengines: fix sign-of-life coreboot build date

[markmentovai]

The coreboot build date shown by print_sign_of_life at early boot was incorrectly presented in yyyyddmm format, when it should have been yyyymmdd.

For example, the current version, 4.16.0.4, was built on 2022-05-25 and released on 2022-05-26. It boots with the following sign-of-life message:

PC Engines apu2
coreboot build 20222505
BIOS version v4.16.0.4

yyyyddmm is not a date format that any ordinary person would expect or understand. It presents as a standard yyyymmdd date seemingly referring to the 5th day of the 25th month of 2022, which of course is incorrect. The string should be presented as coreboot build 20220525, in proper yyyymmdd format.

There’s a bit of history to this string, and I wanted to make sure that this wasn’t actually intentional, so I did all of the code archaeology to confirm that yyyyddmm was indeed unintentional and should be fixed to the expected yyyymmdd.

Legacy History

commit	commit date	pr	release	release date	sign-of-life format	SMBIOS/DMI format	notes
88a4f96	2016-03-04		4.0.1		yyyymmdd	mm/dd/yyyy	romstage.c, version.c, smbios.c, Makefile.inc
ca048fd	2017-01-02		4.0.3		yyyymmdd	mm/dd/yyyy	mainboard.c (duplicates romstage.c)
8d1dbd4	2017-09-29		4.0.13	2017-09-29	yyyymmdd	yyyymmdd	removes duplicate from mainboard.c, breaks SMBIOS/DMI date
a27c678	2018-10-22	#213			mm/dd/yyyy	mm/dd/yyyy	fixes SMBIOS/DMI date, breaks sign-of-life date
904102b	2018-10-22	#213			yyyymmdd	mm/dd/yyyy	fixes sign-of-life date
7de39fa	2018-10-23	#213	4.0.21	2018-11-08	yyyyddmm	mm/dd/yyyy	breaks sign-of-life date

Mainline History

commit	commit date	pr	release	release date	sign-of-life format	SMBIOS/DMI format	notes
05e02e4	2017-01-23				POSIX locale	mm/dd/yyyy	sign-of-life broken; mainboard.c, version.c, smbios.c, genbuild_h.sh
6333e2c	2017-02-24				mm/dd/yyyy	mm/dd/yyyy	breaks sign-of-life date differently
59b86e1	2017-07-18		4.6.1	2017-08-30	mm/dd/yyyy	mm/dd/yyyy	sign-of-life moved to romstage.c
2abb157	2017-10-26				mm/dd/yyyy	mm/dd/yyyy
ba77b6c	2017-09-25		4.6.2	2017-09-29	yyyymmdd	yyyymmdd	fixes sign-of-life date, breaks SMBIOS/DMI date
87c0ee4	2018-07-17				mm/dd/yyyy	mm/dd/yyyy	reverts ba77b6c, breaks sign-of-life date, fixes SMBIOS/DMI date
10fa08f	2018-07-18				yyyyddmm	yyyyddmm	breaks sign-of-life date differently, breaks SMBIOS/DMI date
e7b562b	2018-07-24		4.8.0.3	2018-08-07	yyyyddmm	yyyyddmm
a3249e8	2018-09-18	#197	4.8.0.5	2018-10-04	yyyyddmm	mm/dd/yyyy	fixes SMBIOS/DMI date
2a07f6a	2020-11-17				yyyyddmm	mm/dd/yyyy	moves sign-of-life to bootblock.c
d120418	2020-11-25		4.13.0.4	2021-02-26	yyyyddmm	mm/dd/yyyy	reverts 2a07f6a

Discussion

Both the sign-of-life date format and SMBIOS/DMI date format were variously correct and broken throughout time on both legacy and mainline branches, and were correct until late 2017, when the formats started changing during the DMI date fiasco. The current yyyyddmm format can be traced to mainline 10fa08f which attempted to fix both the sign-of-life date and the SMBIOS/DMI date, but failed on both counts. The SMBIOS/DMI date was subsequently fixed in #197 without any real discussion of the sign-of-life date.

Shortly thereafter, #213 fixed the SMBIOS/DMI date on the legacy branch, while simultaneously breaking the sign-of-life date. That pull request has some discussion of the unusual format, starting at #213 (comment). Unfortunately, the discussion was resolved incorrectly at #213 (comment) by stating that yyyyddmm was intentionally chosen to match what was then current on the mainline branch. This occurred just months after the mainline branch had acquired the bug in 10fa08f, so while the legacy branch was being synced with the then-current mainline behavior, it was actually mimicking a recently introduced bug. #213 (comment) also claims to have corroborated with an APU2 ROM binary purportedly dated 2016-09-12 and identifying itself in its sign-of-life as 20161209. I haven’t found a binary bearing this date, but I did find:

• apu2 release 20160304 (from 88a4f96) built 2016-03-04, identifying in sign-of-life as coreboot build 20160304 (yyyymmdd)
• apu2 4.0.7 built 2017-02-28, identifying in sign-of-life as coreboot build 20170228 (yyyymmdd)
• apu2 4.0.9 released 2017-05-30, identifying in sign-of-life as coreboot build 20170531 (yyyymmdd)

Having found three apu2 firmware versions from both before and after the purported 2016-09-12 (or is it 2016-12-09?) firmware that adhere properly to the yyyymmdd format, I question the claim in #213 (comment) that yyyyddmm was ever valid, and that employing this format was in fact maintaining the status quo.

This analysis clarifies that yyyyddmm is an error, and it should be corrected to yyyymmdd which is the proper historical form dating to the beginning of the visible legacy branch history in early 2016, as well as the sensible form for this date.

[markmentovai]

@miczyg1, @krystian-hebel, @pietrushnic, and @michaelsteinmann who have all touched, merged, or commented on these date formats before.

[pietrushnic]

@markmentovai let us analyze what you wrote, but please note it all is more about backward compatibility for customers who use sign-of-life in industrial environment parsing that strings over serial, then about some logic behind. We will try to revisit that with PC Engines and will get back to you.

Thank you for your contribution.

[krystian-hebel]

@markmentovai thank you for this analysis. I recall there was a discussion that resulted in current format, but I can't find any trace of it anymore, other than #213 you already linked. I'm OK with fixing it to something sane, if anyone will have an issue with that we can always revert it (assuming there is a good reason to do so).

In order to preserve your excellent research, and to provide easy-to-find place for history of changes, I would like you to create a document in https://github.com/pcengines/apu2-documentation (or we can do this instead if you prefer, but I figure you may want to do the honors to have your name next to the commit). Just copying your first message into a new file will be good, after adding a new entry for your change.

[markmentovai]

@krystian-hebel Sure, I’ll send a patch to pcengines/apu2-documentation. I’ll base it on the description above, but will update it to present it as fixed, changing all of the yyyyddmm stuff to the past tense.