On Wed, 2 Nov 2016, I wrote: > > For the official Debian release, I would find it helpful to include > > the kernel option that sets the date in the kernel before mounting > > filesystems; at first boot, vmlinux-4.1.35-mac_scsi-egret+ took a long > > time to check all the filesystems (thinking they hadn't been checked > > in thousands of days). > > It's a good idea. The problem is that Linux doesn't have any support for > the RTC on some Macs (i.e. Quadra 900/950 and early Powerbooks) and I'm > not sure how a kernel configured with CONFIG_RTC_HCTOSYS=y will handle > it. ISTR seeing a boot hang from this. I have a Powerbook 180 here so > I'll test it.
I've since tested CONFIG_RTC_HCTOSYS=y on PMU "v1" (Powerbook 180) and it doesn't hang (no idea about Caboose). However, CONFIG_RTC_HCTOSYS assumes that the RTC value is in UTC, whereas MacOS keeps the RTC in local time. > > In the past, it has been suggested that the kernel could get the date > and time from the bootinfo records as a workaround. Not sure if Emile > provides for this, but Penguin does. It appears that the GMT bias is stored in PRAM on m68k just as it is on powermacs (see PMAC_XPRAM_MACHINE_LOC). That could be the best way to convert UTC into a local time value suitable for storing in the RTC, and back again. (I'm ignoring the difference between GMT and UTC for this purpose because I doubt that MacOS deals in UTC at all.) Unfortunately, we can't get at the GMT bias directly, because Linux PRAM support is miserable. (Unfortuately, not all of the relevant maintainers reviewed my generic NVRAM patch series which would have fixed this...) But the bootinfo records may offer a solution since they also include a "GMT bias", and both Emile and Penguin have code to support this. --
