Ok, here is what I know about it.

CAL is where things like the software version and wlan channels are stored.

cal-tool in the initfs can read things that are set (things like whether rd-mode is enabled via flasher etc)

osso-product-info will query cal for information about the software channels, software version.

You can actually modify that bit of CAL on device:
http://i26.tinypic.com/2znv3gx.png

When you flash a FIASCO image, CAL is written to with the new software information (thanks fanoush)

flasher-3.0 writes to CAL to set things like RD Mode and Phoenix (I'm very sure this one accesses CAL)

Nitro queries CAL and craps out if the cal is corrupted. (I've still got the debs )

I'm sure that the "config" partition (/dev/mtd1ro) stores CAL information as I've had RD mode set and dumped my mtd1 and had it show up in N800 emulation (I believe RD mode is CAL thing too)

The CAL software information corrupts very easily. I've only fixed it by reflashing entire bin image. And that is not a fix. I've had it corrupting by flashing a new kernel via flasher-3.0 and by 0xFFFF. In 0xFFFF I saw it corrupting by odd characters appearing.

When CAL is corrupted, your version's in about change to <unknown> and if you run osso-product-info, you will see <cal_read_block> error while reading (something like that) and if your cal is corrupted nitro will not run.

Maybe osso-product-info will fix an <unknown> software version? Haven't tried it.

But I think it would be nice if we could edit the CAL and reflash it (hell, not even that as it doesn't get reflashed). It could mean things like setting RD mode and flags off the device and it probably means a sure fire way to fixing <unknown> and to edit the wlan channels of the device (I believe US N800's have same WLAN chip but channels are locked down - I'm so glad mine is ETSI/EU )
Programs that write to CAL probably are : flasher-3.0, 0xFFFF (not sure on this one) and Phoenix and osso-product-info.

CAL is also the name of the (in)famous MS license

http://en.wikipedia.org/wiki/Client_Access_License

Eew, Microsoft >.<

I don't know what CAL moniker means but it is a system that stores system configuration data in config partition (/dev/mtd1). Data basically means unstructured/flat name=value pairs. It is sort of simple filesystem. Looks like each such variable takes whole block and there are more blocks with same name (old values?). 0xffff can dump name=value pairs.

cal-tool in initfs can write only root device name but can read more values like r&d mode, usb mode etc. other settings stored are - MAC address, partition layout, system version, ...

access to config partition is implemented/guarded by dsme daemon via /usr/lib/dsme/libcalmodule.so. Other tools just tell dsme to read/write value for them (not sure about new stuff in Diablo).

Would be useful to reverese-engineer exact format so we can write there or even just read when dsme is not running (early in initfs).

some config settings (at least internal flash partition layout = where kernel, initfs, rootfs begins) are parsed also by NOLO loader so in theory corrupting it can make NOLO crash or hang => cold flashing needed

see also dump_config() in http://news.nopcode.org/miau/pvc.cgi...-pancake@pluna

EDIT: also according to /usr/lib/pkgconfig/cal.pc in initfs CAL stands for "Configuration Access Library"

I'll be captain obvious and make you want to hate me.

My version number did go to <unknown>. osso-product-info can fix it. I ran the postinst script of osso-software-version-rx34-unlocked (diablo here) but this one should do it as root:
wlan-cal is ran at initfs time to set countries, default values etc.
bt-cal sets the default bluetooth address.

Fanoush, do you know if the config partition is checksummed in any way? I don't want to be the owner of a brick that way :/

I'll happily make any changes, provided I know I can flash back my old one incase I **** up.

Yes, one can strace dsme and see what config parameters those programs tell dsme to read from config partition for them. I tried this for root device when running cal-tool, did not try wlan-cal and bt-cal


I don't know. Like said above, there is slight chance NOLO will not like it and won't boot so I did not mess with it. Knowing how to cold flash device over serial would be great for such experiments. Also now there is almost working QEMU emulation of N800 so this stuff can be safely tested there (including tracing bootloader etc.).

See also http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/

Thanks (btw, I'm not blaming you if something goes wrong, it's just that you actually know what you are talking about)

I may end up getting a serial cable for this, I went and bought one for my phone when I killed it :/

When checking QEMU emulation code, it currently starts via loading kernel so sadly no easy bootloader tracing.