pftf
Time is reset to Oct 19 19:03 even on a warm reboot
Running OpenBSD 7.0-release with the latest 1.32 release, I am seeing a starting time of Oct 19, which presumably corresponds to the time of the release build:
Oct 19 19:03:45 b70-arm64 dhcpleased[88992]: adding 10.X.Y.143 to bse0 (lease from 10.X.Y.1)
Oct 19 19:03:45 b70-arm64 dhcpleased[88992]: adding nameservers 10.X.Y.1 (lease from 10.X.Y.1 on bse0)
Oct 19 19:03:45 b70-arm64 resolvd[78280]: rebuilding: route proposals
Oct 19 19:03:45 b70-arm64 ntpd[73052]: ntp engine ready
Oct 19 19:03:46 b70-arm64 ntpd[73052]: constraint reply from 9.9.9.9: offset 3798343.941306
Dec 2 18:09:30 b70-arm64 ntpd[61073]: set local clock to Thu Dec 2 18:09:30 UTC 2021 (offset 3798344.550977s)
Dec 2 18:09:31 b70-arm64 ...
While this is not unusual for a device with no RTC (it has to pick a time from somewhere, right?), what is strange to me is that the time is reset to Oct 19 even on warm reboots. I do not see this behavior using u-boot, nor any other platforms running OpenBSD, so I'm assuming this time is being forced on all boots with this UEFI.
If that is the case, is there an option to not do so if the existing/warm time is after the release date? I searched all the issues for time-related ones, but came up short. Thanks.
The other problem here, which I suspect is the issue and is partially noted in the readme, is that you don't yet get persistent variable support while the OS is running. So if the OS updates the time/date on shutdown it won't persist to the next reboot. The fixes for this are on list, and if you want to try a test build, I would suggest joining the discord channel where I posted a link to a personal build for people who don't want to try building their own copies. The change is a bit sketchy (we are seeking the updates into unused parts of the rpi foundations eeprom base bootloader), but is safe because their recovery tool seems capable of fixing anything we mess up, and beyond that, the code is fairly careful about enabling the feature if it can't find space/etc, falling back to the existing behavior if something seems out of place.
The uboot comment is unexpected because AFAIK, few of the uboot/efi implementations have working runtime variable support, aka they behave much like the Pi does here and drop updates made while the OS is running. So, I would be curious how the uboot platform(s) you tried this on are working if they have neither a RTC nor persistent storage.
Thank you for taking the time and making such a detailed reply, I appreciate it. I will take a look at the test build.
I may be misremembering the combinations of u-boot/RPi hardware I was testing. I will test again and provide something more concrete if it is as I remember it.
Also, I guess as a further note, the CM4 carrier boards, and various HATs have RTC's on the rpi's. I have a TODO to get at least the cm4 IO board RTC working, but patches/etc are always welcome... :) If your still in Austin TX, I could loan you a board... :)
Thanks for the offer, I am indeed still in the Austin area. Things are a little crazy right now in-between the holidays, but I'll keep it in mind.
To clarify a little further, my work/testing thus far has been pftf/RPi4B, u-boot/RPi3B+, u-boot/RPi3B - using OpenBSD on on all of them (other than to verify my eeprom version/serial setting on the 4). I'll let you know after I poke around some more.
I did some testing to clarify some earlier comments, which now appear incorrect (sorry!). Using an RPi 3B w/o RTC, with U-Boot 2021.07 and OpenBSD 7.0-stable, a warm reboot does not carry over any running time. I am used to seeing that behavior on an i386 platform with no RTC, such as PC Engines ALIX, and wasn't paying close enough attention.
In both the cases of a cold and warm boot with the above RPi configuration, OpenBSD picks up the latest time from the filesystem before correcting with NTP (approx 20s on warm reboot). In the case of the EDK2 UEFI on RPi 4, time is set much further back to Oct 19, which is less ideal, but not really a showstopper either.
I have not investigated deep enough to figure out what logic causes OpenBSD to use the Oct 19 time on RPi 4 UEFI, versus throwing away any existing time and using filesystem time on RPi 3B U-Boot.
Well, I suspect once the variable support code has a bit of review and is merged this will be fixed. Well, fixed enough that it persists the last shutdown time.
See: https://github.com/jlinton/edk2-platforms/tree/cppc6-various-fixes-vc4aml-mailboxspinlock-xhcipci-clocktweaks-spiv5 where I hooked the existing ds1307 driver up to the pi's I2C1 pins.