Active Topics

 


Reply
Thread Tools
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#1
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.

Last edited by qwerty12; 2008-05-27 at 10:34.
 

The Following 4 Users Say Thank You to qwerty12 For This Useful Post:
Bundyo's Avatar
Posts: 4,708 | Thanked: 4,649 times | Joined on Oct 2007 @ Bulgaria
#2
CAL is also the name of the (in)famous MS license

http://en.wikipedia.org/wiki/Client_Access_License
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
 

The Following User Says Thank You to Bundyo For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#3
Eew, Microsoft >.<
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#4
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
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 

The Following 4 Users Say Thank You to fanoush For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#5
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"
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 2008-05-27 at 11:54.
 

The Following 2 Users Say Thank You to fanoush For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#6
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:
Code:
osso-product-info -s OSSO_VERSION=`cat /etc/osso_software_version` || true
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.
 

The Following User Says Thank You to qwerty12 For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#7
Originally Posted by qwerty12 View Post
wlan-cal is ran at initfs time to set countries, default values etc.
bt-cal sets the default bluetooth address.
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


Originally Posted by qwerty12 View Post
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 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/
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 

The Following User Says Thank You to fanoush For This Useful Post:
qwerty12's Avatar
Posts: 4,274 | Thanked: 5,358 times | Joined on Sep 2007 @ Looking at y'all and sighing
#8
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 :/
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#9
Originally Posted by fanoush View Post
including tracing bootloader etc.)
When checking QEMU emulation code, it currently starts via loading kernel so sadly no easy bootloader tracing.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.
 
Reply


 
Forum Jump


All times are GMT. The time now is 18:38.