Rockbox

I just remembered that the official bootloader doesn’t have the alarm code needed for the unit to autopower on.
So until a new bootloader (revision 12546 and later) is flashed this patch is useless. :(

P.S: Keep in mind that recent svn bootloader revisions have a bug currently that will not let you boot into rockbox.

That patch schould also enable it for X5/M5 targets.

Now tested, it works on my X5 with default bootloader.
Hug on OF remnants.

Patch updated to enable alarm on X5.
Thanks I didn’t notice that X5 used the same chip.

Sorry again, it seems that the patch works on M5 too.
I hope that I didn’t forget another target.

Works on my H300 with bootloader h12547.

Now I’m going to try to write a plugin to slowly ramp up the volume while playing, and this will be the perfect wake-up device

Why duplicate all the code? Wouldn’t it be better to unify the code into one file somehow?

Thom, probably you are right, but I have to check for some parts of the code that maybe need some slight changes.
Anyway, all rtc code will eventually change when date is incorporated as a trigger on the rtc alarms.

After using the patch my year had always been reseted to “2035”, there are my changes I did to fix the bug.

ups, wrong file

I’m going crazy -_-

Note: the dual-bootloader ( FS#5289 ) needs a small fix to support RTC.

hmm, i’m using an old dualbootloader and also testet the official bootloader and both recognized the alarm and woke rockbox up on my x5.
so I thought that a part of the hard implemented OF (like charging and usb, when powered off) sends the wakeup singnal.

The preloader (what you call “hard” OF) sets a byte in memory to notify OF that RTC alarm has occurred;
The dual bootloader checks this byte and should boot OF if it is set.
No idea why it works….

This seems to work fine on H300, with an SVN bootloader, any idea what’s stopping it being committed? Just the bootloader release?

I think yes. (at least for H300)

But as preglow said the code might need to be merged with pcf50605 instead of copying it, though I want to make sure for some bits on the alarm setting that might not be needed on other targets.

Hmm, I’ve noticed that when using this patch, occasionally my H340 internal clock is unset (as in Rockbox displays a time of –:–). When I go into the time/date setting screen, the time is displayed as 00:00:00, but the date is correct.

I’m not sure whet triggers this behaviour yet, but I’m certain it only happens with this patch. Will carry on diagnosing…

Steve: I get a similar thing with the clock (–:–) (heh, that looks a bit like a bum emoticon) but only for a few seconds from time to time; then the clock seems to get the correct time back. I’m not certain if this is related to this patch or not (I do have it applied, but have others too). I’m also on an H340.

Further to my previous comment (”the date is correct”), Llorean informs me that if the date is unset then the build date is displayed as a sensible starting point, so the date was very likely lost too.

Warning: Undefined array key "useheading" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 1099 Warning: Undefined array key "target" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557 Warning: Trying to access array offset on value of type null in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557

Hi,
when i tried the patch on my h300 i experienced the same behavior like pondlife.
When the time display disappears and you open the clock plugin then the correct time is still shown, the date is also correct except for the date which is shown as 1999.
So the clock doesn’t get completely unset, but only the date is wrong. The reason that the time disappears in the statusbar and WPS is that the function valid_time() (which returns false for years earlier than 2000) is called before displaying the time (the clock plugin doesn’t do this check)

The reason that this happens seems to be that the functions pcf50606_read* and pcf50606_write* without using disable_irq_save() before and restore_irq() afterwards. This seems to be necessary on H300 in order to avoid conflicts with the button driver.
See here: http://www.rockbox.org/irc/log-20080605#12:54:12

When i use disable_irq_save() and restore_irq() similarly like it is done in rtc_read_datetime() (in \firmware\drivers\rtc\rtc_pcf50606.c) then the clock doesn’t disappear anymore.

Does this work, then? Sorry, my H300 is not with me at the moment…

Take 3, much better, I hope!

I’ve been using this with no problems on my H300 for the past week, and would like to commit it. Are there any X5 or M5 owners out there who have tested it? If not, I think I’ll commit it for the H300 but leave them out for now.

I have used this patch on the X5 with no problems and wish it to be commited for the x5 aswell please.

Working well in iAudio X5 here too.

Any M5 owners out there? Or is it similar enough to the X5?

Latest Iaudio Bootloader(v4) blocks the wake-up during autopower on. Alarm check code is needed for x5(and probably for m5) to boot into Rockbox.
Except the bootloader it worked fine enough.

Yes, I see the same on M5 too, that the alarm is triggered but the v4 bootloader prevents a normal power up as already said in IRC (there already was an explanation why).

And I also saw 2 small problems: the manuals wouldn’t build correctly for the 3 targets with this patch and a button action conflict in the alarm settings screen on the M5/X5 pad that wouldn’t let me increase the hour by pressing “right” - which would only accept the alarm setting and leave the screen. I had a look at alarm_menu.c and the button actions and contexts that’s used there and could solve the problem (I wonder whether it actually shows somewhere else currently even without the patch). As it is a button action conflict it also shows in an X5 or M5 sim in case someone wants to try.

Attached are 2 patches (1 fix for each problem). I also tested whether the X5 keymap change (the same file is used for the M5 too) needs all 3 added actions in the settings context but it seems it’s really needed to have the full controls. The manual patch was needed because the alarm settings section is automatically included through the features.tex (parsed from the lang’s feature.txt) and this section uses a macro for the buttons which was simply missing in the platform files, so I added it there. Both patches are independent from the main alarm patch here because they touch different files, of course it’s somehow related.

Most of the work needed by the bootloader to correctly identify RTC alarm is already done by the preloader, which sets the byte in 0×30000000 to 1 if the device woke up due to RTC alarm. We just need not to overwrite this byte until we decide whether to boot or to shut down.

Patch from Steve (Thursday, 05 June 2008) works fine for my X5 too.
Thank you for waking me up ;)

Resynced the code patch - also synced firmware/drivers/rtc/rtc_pcf50606.c with the existing firmware/drivers/rtc/rtc_pcf50605.c - it can be seen they are identical apart from the low-level calls e.g. disable_irq_save()/pcf50606_read_multiple()/restore_irq() vs. pcf50605_read_multiple(). I’ve synced the comments too, even when they refer to iPods…

I don’t know if it’s possible to merge the two completely, or whether an #ifdef hell could be used, but ideas are welcome.

Bug report - with the last patch, I’m finding that my clock occasionally gets set to –:–.

I’m not sure what’s changed - the only functional chsnge was to explicitly disable the alarm by:
+ /* Make sure we don’t wake on RTC after shutting down */
+ pcf50606_write(0×8, pcf50606_read(0×8) & ~0×10);

In the last version of the patch it looks like in the function ‘rtc_check_alarm_flag()’ that ‘pcf50606_read()’ is used without ‘disable_irq_save()’ and ‘restore_irq()’

Ah, well spotted! Here’s an update. /me wonders why the pcf50605 code doesn’t need to do any IRQ disabling…

Anyone object if his is committed or should it be merged with the pcf50605 driver? If so, what’s the best/conventional way to handle the differences?