May 9th, 2006

How not to charge nokia 6230, part III

After some hints from vojtech, I found out that 6230 will actually charge from 5x NiMH. From some docs, it should resist up-to 15V, so of course my next idea was "lets try with 12V/500mA power supply". No luck. Then I found out that it will also charge from 6x NiMH, 7x NiMH and 8x NiMH... and found suitable 9.3V, 550mA power supply from old Dancall phone. I connected it directly.

It worked okay.. when battery was nearly full. When battery was empty, Dancall charger started putting out *really* ugly sound, and charge stopped at 3/7 :-(, with nokia getting warm. Too bad, time for more experiments.

To comment on p910... it is not really _that_ bad smartphone. But it is not a good _phone_, not in basic config. Lots of issues could probably be fixed by add-on applications, but a) they are non-free and b) stability would probably suffer. And I have an PDA already; so... my current plan is to get sharp zaurus sl-5500 into usable state, connect it with 6230 over bluetooth, and get some phone features running on Zaurus.

Practical wearable computer, try #4

Try #4 -- Zaurus sl-3000c + Nokia 6230 over bluetooth + Fortuna GPS over bluetooth

Works nicely. Zaurus is great for email and GPS handling with
GPSdrive. 6230 can handle email, too (mujmail) and can handle GPS, too
(javaphone, see
). Nice combination; I'm only worried that sl-3000c zaurus
contains 4GB microdrive, and that sounds fragile.

Now... it would be nice to figure out how to do track saving
without zaurus, and to improve map displaying capabilities of navlet
-- I don't dare to take zaurus to horseback.

There are some updates on collie side, too:


It boots, display and keyboard works, internal flash works with
extremely ugly hack, pcmcia works, backlight & leds work. Touchscreen
works somehow, but userspace filtering needs to be developed. Have not
played with MMC, IrDA or USB device, yet; I'd assume they don't
work. Battery charging is half-done and broken, so is battery status.

Collie will very slowly charge even without software support,
however, so all is not lost.

How not to write an operating system

Andrew S. Tanenbaum is at it, again, with next part of "how not to write an operating system" series.

Its true that most bugs are in the drivers, fortunately driver bugs usually bring the system down quickly, and so are easy to debug. Also he conviently misses to mention that each user runs less than 2.5 million lines of code -- because he only has very small part of all possible hardware. He proposes few solutions, and first of them might actually be useful for debugging: protect kernel memory at the driver entry point... I'd like to see the patch on linux-kernel list, and preferably also list of bugs it discovered.

Other ideas are basically "add virtualization to separate drivers"... oops, and debug all the hard bugs in virtualization layer, too?

Clasical microkernel approach... and then goes to say it performs reasonably because it can compile itself in 6 seconds. Very wrong benchmark... how long does it take to compile linux on that machine would be reasonable benchmark. But I guess his "super reliable" operating system would probably die before finishing that. (Or perhaps his make process would die because of bugs in emulation; end result is the same).

Next idea is to rewrite os into java. Oops.

...all these approaches conviently forget that most devices (sound card, disk, video card, USB) do DMA these days, and machines do not contain IOMMU, so bad driver can still overwrite anything, and if you poke the buggy hardware the machine dies, anyway.

Oh, and that article actually mentions that "Protecting the kernel against malicious drivers is not a goal. The initial implementation was on Linux, but the ideas apply equally well to other legacy kernels.", yet trumpets security advantages in all that.

So, Andrew, please don't make my machine as reliable as my cellphone is. You know, my Linux machine actually works much better than my cellphone.