Lumag's HQ

Prism USB chipsets

2010-11-29T16:29:00.002+03:00

As you maybe know tosa devices contain internal wifi cards based on Prism3-USB chipset (manufactured by Ambit). Wlan-ng driver (present in staging) for such kind of devices is old, mostly-unmaintained and does not really fits current kernel WiFi stack. Non-USB versions of Prism3 devices are supported by HostAP driver, which needs adaptation (kinda big one) to work with USB devices. Working right on tosa isn't really suitable for basic driver debugging. Today I've got normal external card (Siemens SS1022) compatible with tosa one which I can use for my experiments. Happy hacking!

Freescale licensing.

2010-01-03T22:02:00.003+03:00


* No part of this document must be reproduced in any form - including copied,
* transcribed, printed or by any electronic means - without specific written
* permission from Freescale.

Except for the ZigBee Beestack, Freescale grants to you, free of charge, the non-exclusive, non-transferable right, exclusively for activities which support products incorporating a Freescale 802.15.4 Radio Frequency transceiver integrated circuit ("Freescale IC") (1) to use the Software internally, (2) to reproduce the Software for purposes outlined in this Agreement, (3) to prepare derivative works of only that Software provided in source code form and (4) to distribute the Software and any derivative works thereof, other than the BeeKit Tools, in object code form and solely in conjunction with a product that contains the Freescale IC.

Damn those proprietary vendors.

M68HC(S)08 toolchain

2009-12-19T01:11:00.002+03:00

I've regisered a project on sf.net and pushed there my efforts in porting binutils/gdb/sim to the Freescale m68hc08/m68hc908/m68hcs08 platforms. Contributors are welcome!

Dreams...

2009-12-03T00:57:00.001+03:00

Dreaming now about this USB stick.

Living w/o forks

2009-11-10T23:43:00.002+03:00

Yes, currently I'm living without forks. I'm (again) trying to restore OE support for Blackfin platform in a clean way.

One of the major problems is that there is no fork() on Blackfin. And lot's of software expects to have it. E.g. even to build u-boot, via dependancy chain u-boot -> mtd-utils -> e2fsprogs-libs -> util-linux-ng -> udev you get stron dependancy on fork(). I see no way to resolve this, other than build uClibc with UCLIBC_HAS_STUBS, enabling stub for fork().

Chine and Japanese LR-WPAN

2009-11-09T23:33:00.002+03:00

Thanks to GetIEEE802 I can finally read the 802.15.4 ammendments for China and Japan regulations (802.15.4c and 802.15.4d).

What can I say? On the first glance there are no new bicycles invented. However there is one point in 802.15.4d that I've expressed to my wife in the following terms: 'There is a numeric value there. It's equal to 1 in Japan and to 2 in the rest of the world'.

Adding support for those ammendments into our stack should be straightforward. However most of the nasty things will/should be handled (and hidden) into hardware/firmware, and not present in the highlevel stack.

Git repo for binutils, gdb, etc.

2009-11-04T21:24:00.002+03:00

For those fanatics of git who want to access SourceWare trees via git, I've created a repo on github, that is a mirror of the whole SourceWare CVS tree. Yes, everything, including BFD, binutils, gdb, sim, sid, etc.

Clone url: git://github.com/lumag/binutils.git

OMFG

2008-10-22T22:16:00.002+04:00

Today I've installed a windows application under wine. How impressed I was, when I saw the icon of that application hanging in the tray!

Firewire mess

2008-03-27T14:07:00.003+03:00

Yesterday I stumbled upon a task to transfer few recordings from miniDV camera to my laptop. The camera had the iLink output, so did my laptop. I thought that this should be easy. It wasn't.

I prefer to use Debian kernels. Since 2.6.22 they have disabled old ieee1394 stack in favour of new 'juju' one. OK. But the libraries still aren't updated to use it. Fine. Let's build them. Needless to say, that even with libraw1394 updated to include juju supoprt, dvgrab failed to work.

After some experiments I decided to surernder. After a couple minutes, I've built the old ieee1394 stack, fired the dvgrab with original libraw1394 and started grabbing w/o any major glitches.

I won't ask, why the experimental and still uncomplete stack was merged into mainline kernel. I won't ask, why applicatoins still aren't fully updated to use it. But why the hell did Debian kernel maintainers disable old ieee1394 stack?! If they enable such "beautiful" features, why won't they switch off most of the IDE subsystem in favour of PATA which is much more mature?

distros

2008-03-21T00:56:00.003+03:00

There are a lot of differencies between Ubuntu and Debian. It's nothing wrong with having some. OTOH some of them are very... frustrating. E.g. there is still no IcedTea for Debian, but there are Ubuntu packages with it. From my point of view, it's really strange.

Generic pointers mess

2008-03-10T23:12:00.002+03:00

One of my latest bugs gave me 4 days of vandering in the dark. I was getting really strange warning from the lockdep when I was enabling clocks on tmio chip. The code was 1-to-1 converted from working one, so there shouldn't be any problems. But there were. After double-checking all locking logic, increasing lockdep constants to really big values and even looking into lockdep details, I finally found the source of the problem: as a private data I passed not the structure I exected to receive.
Pretty trivial problem for a language w/o runtime type checking functionality. Maybe it's time to implement it
as a wrapper around various magic values and type checking functions? In the userspace IIUC glib permits smth. like that, it manages a class-based system with objects allocation, etc. Would I like to see smth. like this in kernel? Probably no. Would I like to see some generic way to enable such checks for objects like spin locks, mutexes, etc? Definitely yes.

Screen protectors

2008-01-24T13:40:00.000+03:00

I've received a pack with screen protectors for my tosa. Now I do understand, why they are posted in a packs of 3. One was slightly damaged by our post (damn!). Next one was damaged by me, by applying it to the screen. And only the third one is sitting OK, showing the clear screen to me.

going mainline

2008-01-14T03:05:00.000+03:00

During current cleanup & rewrite effort I do generate some side patches related to e.g. UDC or power-management. Most of them are merged into the respective subtrees (and hopefully will propagate to mainline). However today I've received the first Ack to tosa-related patch :) The only thing yet left to discussion is if it will go through the input subsystem or through the ARM patchset. I'm happy.

USB host cable

2008-01-05T02:32:00.000+03:00

I've finally managed to get USB-host port of my tosa working. Before I've tried using a no-name OTG cable. Today I've bought the Hama OTG cable and it just worked! I still dunno what's the difference. Maybe the problem lies in the wiring or the length of cables.

Foreword

2008-01-02T00:31:00.001+03:00

OK, this blog will hold my technical posts, questions, etc. News directly related to tosa linux kernel will be posted at http://tosa.lumag.spb.ru/.