P.S. Off the top of my head, I think what Pali did was just make the open cal.h header conform to the Nokia-provided cal.h header. While I understand doing this 'automatically', I think in-depth further consideration (summarized in my little ramble in my prior post), suggests that we need and should not be striving to make our open cal.h as limiting as the closed one was.

Oh, the reason I had actually gotten on to the forum to make a post here in the first place (completely forgot when I saw the cal.h/cal.c update):

I am going to start using C99 features, so from now on (until/unless GCC finally supports C99 enough for the gnu99 dialect of C to be the default in your version of GCC), rdmod will need "--std=gnu99" to compile - or whatever it takes for your compiler of choice to compile in a C99-compatible manner.

Specifically, the reason I am doing this is to enable the use of the restrict keyword (I could use a less portable compiler extension that does the same thing even in the default gnu89 dialect, but I don't like using compiler-specific things), which allows the compiler to make some optimizations in the compiled end result. But since I am enabling it, I am also considering switching to inline declarations of the counter variable 'i' inside all of the loops, instead of declaring it once in main. I'd have to figure out which one executes faster, if the current way is faster then I'll keep it. That's later though. I really need to focus on other things and stop allowing myself to come back to this.

@Mentalist Traceur - please clone libcal on gitorious, make the changes you think should be done and make a merge request. That way we'll be able to keep discussion in one place and will include Pali in it.

@freemangordon. Absolutely the better way to do it, I just needed to (and still do) get around to doing this... I will try to soon now that I have a break between semesters.

So today I saved myself a lot of frustration and bootlooping with this, verifying that there are corner cases where you absolutely need to alter R&D mode flags from inside very early boot.

See, apparently, as per Pali's understanding of getbootstate here, when getbootstate detects the battery as being in certain states, it simply refuses to boot. I have very strong insults I want to hurl at whoever designed it like this because, over the years, I have had many occasions where it seems that this is the cause for my N900s not booting successfully on first try. Sometimes, it gets stuck in a very persistent failure-to-boot, such that I have to leave it plugged in overnight, and it seems that the tiny amount of charging it gets done in between boot loops (since it boots up from detecting the USB cord, but then almost immediately shuts down because of the whole getbootstate system being *****ic; rinse and repeat on and on), finally resets whatever state the battery hardware keeps internally.

Well, one of my N900s apparently decided to get stuck like this for over 24 hours - I guess it discharged overnight Thursday, was off when I woke up Friday, left it charging... nothing when I got back after a full work day. Left it charging all the way through the night until this morning. Nothing. Did some frustrated digging, found the above linked thread. Used rdmod to enable R&D mode, attempted to reboot once (or maybe twice, forgot already) more, and victory was mine, it booted. Of course, I was then able to use rdmod to disable R&D mode right back again, which was also nice, but not really the point of the story.

TL;DR: First time I've legitimately saved myself with this tool of mine, can't begin to describe how happy that makes me right now.

[edit]I always forget the word 'm0ron' gets censored by this forum's software...[/edit]

@Mentalist Traceur,

Nice

Just a piece of advice, to everyone: leave R&D turned on, always. You won't regret it.

As a bit of advice to people doing this, if you do, remember to edit, erm, I think it was /sbin/preinit, to disable the keyboard flashing - or not, if you like it, but battery life will suffer, probably noticeably. Otherwise in the stock configuration, all enabling of R&D mode causes the keyboard leds to flash whenever there's system activity while the screen is off, or something approximately like that. It's not a major drain on a stock N900 lying around idling for days (my stock N900 with R&D mode on being the only non-stock thing has better idle battery life with those keyboard flashes than my actual heavy-use N900s get lying around equally unused, from what I think I've noticed (but I haven't timed it to be absolutely sure)), but it's probably a major drain on an N900 with a bunch of extra stuff installed that's getting used regularly.

Back on topic, interestingly enough, I'm starting to think that, with sufficient age and without other counter measures, that may be exactly what has to be done. I don't know what the cause is, I suspect too many battery drains/removals after the tiny backup battery/capacitor has discharged somehow effecting the motherboard's battery sensors is the culprit, because it seems that a long time ago that's what happened to my first (now perpetually left-as-stock) N900 - it has to be in R&D mode to boot, and now my second N900 (the one mentioned in the previous post) has seemingly gotten to the same predicament - needing R&D mode on to boot. I can definitely confirm that the battery used does NOT seem to have anything to do with it - I can swap in fully or nearly fully charged batteries and still fail to boot on those without R&D mode on. So it's not any given battery wearing out to the point of being a problem. Strange, eh?