Warning: This program writes to a very critical part of the N900. I will take no responsibility whatsoever if it messes up your N900. Use at your own risk.

Warning 2: It's written by an idiot who has little to no knowledge when it comes to C strings...

While I have survived disabling/enabling R&D Mode (and setting flags) using it and rebooting, you never know.

Nokia released libcal-dev in nokia-binaries for Fremantle. This means you can write to the CAL area and modify settings there.

R&D Mode Control is a program that lets you modify the settings pertaining to R&D Mode on the N900 itself.
No binaries because I don't trust the code enough.



Source: http://slexy.org/view/s21xaSNJe0

Good catch. It is nice we have fuction prototypes for CAL.

And what also is good with N900 is that it looks like libcal now does the dirty work of actually reading/writing config partition. So this makes it possible (not sure how legal) to write safely to config partition from other non-Maemo systems by either statically linking to libcal or copying libcal to target system.

This was not the case with N8x0 and below. For N8x0/770 all the dirty work was done by dsme so if dsme was not running there was no way to read/write CAL except reverse-engineering the format of config partition. That's why I could not easily read root device in bootmenu (via cal-tool -r) early enough to not to display "press menu key for advanced bootmenu .." when the stored root device starts with "ask" (=>the message is not needed). It did not work until dsme was started and then is was too late for the message.

So there was libcal too but all it did on previous devices is sending data to /tmp/dsmesock and letting dsme do it. It was even possible to somehow safely write anything to CAL area too (just strace cal-tool -R ask:mmc and see what it sents to dsme) but it was not so much useful for free Maemo replacement solutions since initfs and dsme is still needed.

Still, if it is useful for Mer etc. on 770/N8x0 it could be done. Or at least I hope so. I started code for writing r&d mode for previous tablets months ago but never finished it (lack of time, low priority). I hope dsme does not do any checking on possible CAL variable name when writing. It is quite likely since in OS2008 there is osso-product-info which writes 'random' values to CAL area too (via /usr/lib/libcal.so.*->dsme->/mnt/initfs/usr/lib/dsme/libcalmodule.so.*)

Just in case, here is the strace for reading writing root device on previous devices
http://slexy.org/view/s20aCfat7r

So all this is cool but the best would be to have CAL area documented so we know format of ConF blocks in config partition and also which ones are used and which ones can be safely erased/rewritten (there are multiple old copies lying around when changing same variable ).

When stracing cal-tool -r on N900 it can be seen that libcal is scanning config partition and reading ConF entries.

This is very cool. What would be *really* ideal is having such settings available in bootmenu config files. For instance, I never (more or less) want R&D when I boot into Maemo, but I want it everytime when I boot into Mer. If it could be set at boot, that would be the ideal time.

- Edit -
I suspect it was some flawed screw up in the CAL area for me, because reflash followed by telling it to turn R&D off explicitly in the flasher has led to it working just fine.
- End Edit -

I realize this is probably one of those "if you can't answer this yourself you shouldn't be messing with it" questions (and my apologies for reviving such a dead thread), but - does this still work for people, and if so, any pointers on how to proceed? On PR1.3 with CSSU 12.5, I just compiled this (on SDK; I did intend to compile on-device but all the requisite -dev libs promised to need more rootfs space than I had left so I decided not to fiddle with optimization of all of them for the time being), and transfered the binary over, chmod'ed/chown'ed appropriately, and stuck it in /usr/sbin (tried /sbin too).

I keep getting a "Failed to read r&d mode area from CAL" error when running it. I found the spot in the source code that prints that error message, but I don't read C well enough yet to make heads or tails of what the cause is. At this point for all I know it's anything from gcc producing more than just one binary when compiling and me not knowing/noticing where it went, to something less mundane that I could never guess at with my current knowledge.