There's a regression in the recent rockbox code for the Creative ZEN device. The player doesn't hold the time anymore.
The regression already happened several years ago in g#2601 and g#2616 (patches 7f282b9280 "imx233: rtc: Initialize PERSISTENT0 register" resp. e3f6e9d9f6e1 "imx233: rtc: generalize PERSISTENT0 fix").
I can upload a patch to gerrit, however before doing so I want to understand what's going on in the iMX233.
The current code sets the bits DISABLE_XTALOK (see below) and XTAL24MHZ_PWRUP (keep 24MHz clock alive after powerdown), and resets CLOCKSOURCE (i.e. set the 24MHz crystal as RTC source and disable the 32kHz crystal) in the RTC_PERSISTENT0 register.
On the ZEN however the RTC works correctly if I clear DISABLE_XTALOK and XTAL24MHZ_PWRUP and set CLOCKSOURCE.
Now this is what puzzles me:
(1) I don't understand why DISABLE_XTALOK has an impact. From my understanding this bit enables something like a brownout detector for clock frequencies. Does anybody has an explanation? Does the Fuze+ need this bit set to work correctly?
(2) The HW_RTC_STAT register returns 0xe0000000 on my device. This means: neither the 32kHz nor the 32.768kHz crystal oscillator should be present. How can it be that I have to enable the 32.768 kHz oscillator? Why is it not correctly reported by the SoC? Does it give correct info on other iMX233 or STMP3770 targets?
(3) finally someone should confirm that the present code works for Fuze+ (and maybe other iMX233 targets) as it should.