anarsoul's blog

Recently I spent few evenings for hacking wayland . I like idea of wayland - rendering is done completely on client (in whatever way), compositor (server part) is responsible in rendering buffers from clients on the screen. Issue for me was rendering part of weston (reference compositor for wayland) - it uses GLES for compositing, but I want to try wayland and weston on devices without hw acceleration (pure software rendering), and running software GL on PXA270@312MHz does not sound like a good idea, does it? :) So I asked on #wayland@irc.freenode.org if it possible to implement software renderer, Kristian Høgsberg (khr) responded that in master branch of weston repo there's a nice abstraction of renderer, so it's possible to implement pixman renderer. So I did :) weston with x11-backend and pixman renderer khr and pq from #wayland were very helpful, and described place of renderer in wayland architecture, here're some points renderer just performs rendering of ...

Back in 2007 I participated in driver development for AuthenTec AES2501 scanner, driver was later merged into libfprint project. I didn't hack much on libfprint, just sent few bugfixes, but recently AuthenTec announced that they're willing to send fingerprint scanners for opensource enthusiasts who wants to develop driver for those scanners. So far, so good... I've wrote a letter to AuthenTec and they proposed to send AES2550 or AES2810 scanner to me. I chose AES2550. Actually, AES2550 and AES2810 are pretty same (AES2550 driver should work with AES2810), the only difference is missing crypto engine on AES2550 (who needs cryptography anyway? :)) So, I've got parcel with scanner in August, but unfortunately had no spare time for hacking, I only coded driver stub and read datasheet from AuthenTec. So, in September/October I've spent few (5-6?) nights hacking on this driver, and finally got it working on my AES2550. Image quality is much better then on my AE...

Recently hit subj issue on 2 PCs, on 2 different distros: ubuntu 12.04 on my sister's nettop current archlinux on my mother's-in-law PC Here're symptoms: PC shutdowns on poweroff command and then immediately turns on. Sounds weird, right? It turned out that cause is forcedeth driver (both PCs are based on nVidia chipset). I suspect it's somehow related to WoL implementation (however there's not WoL packets in my network for sure - local segment contains only router + 1-2 PCs). Solution is to 'rmmod forcedeth' somewhere on shutdown path. Can't investigate this issue more broadly, I've no permanent access to those PCs :) But some forcedeth dev is guilty for sure

It seems that we have no more issues with LCD and backlight management. LCD switches on/off flawlessly, so does LCD backlight :) I've just fixed a problem with backlight not enabling after it was disabled. I've discussed PWM-problems with my friend Ordog (it's his nickname), and he suggested to play with PWM frequency; he described how it can work, and proposed some reasons why it doesn't enable in my case. I decided that backlight needs wormup to switch on properly, I've checked this hypothesis - and it works! Backlight switches on properly after short "warmup". So, thanks to Ordog! Yesterday I've submited my patchset to the linux-arm-kernel maillist. I still have no response about rx1950-related patches, but s3c2440-udc related patch brought up small discussion. You can read it on linux-arm-kernel maillist archive if you're interested in it :)

Finaly! I find out how to disable LCD without leaving garbage on it! It's time to polish my patches and send them upstream :) I've used haret to capture gpio values. Here's code to disable LCD sanely: /* GPC11-GPC15->OUTPUT */ s3c2410_gpio_cfgpin(S3C2410_GPC11, S3C2410_GPIO_OUTPUT); s3c2410_gpio_cfgpin(S3C2410_GPC12, S3C2410_GPIO_OUTPUT); s3c2410_gpio_cfgpin(S3C2410_GPC13, S3C2410_GPIO_OUTPUT); s3c2410_gpio_cfgpin(S3C2410_GPC14, S3C2410_GPIO_OUTPUT); s3c2410_gpio_cfgpin(S3C2410_GPC15, S3C2410_GPIO_OUTPUT); /* GPC11-GPC15->1 */ s3c2410_gpio_setpin(S3C2410_GPC8, 1); s3c2410_gpio_setpin(S3C2410_GPC9, 1); s3c2410_gpio_setpin(S3C2410_GPC10, 1); s3c2410_gpio_setpin(S3C2410_GPC11, 1); s3c2410_gpio_setpin(S3C2410_GPC12, 1); s3c2410_gpio_setpin(S3C2410_GPC13, 1); s3c2410_gpio_setpin(S3C2410_GPC14, 1); s3c2410_gpio_setpin(S3C2410_GPC15, 1); /* Wait a bit here... */ mdelay(100); /* GPD2-GPD7->OUTPUT */ s3c2410_gpio_cfgpin(S3C2410_GPD2, S3C2410_GPIO_OUTPUT); s3c2410_gpio_cfgpi...

I've got 5 minutes of spare time, so I decided to drop couple of lines into my blog. I've started to bring up kernel from linus' tree on rx1950. Basic functional (no battery, no touchscreen, no sound, no wifi) works. I'm going to submit patches to linux-arm-kernel soon. (About touchscreen: I hope guys from openmoko kernel-team will submit their s3c-ts driver. If they don't I'll submit my own version.) If anyone is interested, I can share patches. BTW, I doubt that they will be usefull for someone in current state :)

Sorry for not posting new posts to the blog for a long time, but I was a bit busy. rx1950 port development is suspended for a while. I'll continue porting aproximately in July. In July I'm going to port patches to the latest kernel (2.6.31_rcs?), fix remaining sound driver issues, and then I'll start to submit patches upstream.

Finally got power issues fixed. PDA doesn't consume power in suspend anymore (at least with sound driver unloaded). The thing was in incorrect poweroff sequence (just a small typo in code) for lcd and in mmc power management. Btw, after ~8h of sleep voltage on the battery is the same as before sleep. Also I got s3c24xx pwm driver working flawlessly on rx1950. There were several bugs in it: no resume handler. So after resume timer was not configured. Results: no backlight and lcd flickering wrong configuration sequence. tcmp and tcnt registers were updated before manual_update flag was set. I've fixed these bugs and submitted patches for pwm upstream. Hope to see them in next kernel versions :) One more thing: battery driver was improved to display proper consumption in uA. I've used WM application - BattLog (thanks to its author(s)!) - to monitor battery and at the same time captured ADC values with haret. As result I've got multiplier for current value :) The next step...

It seems that code that puts rx1950 into sleep is not clear: even in sleep mode rx1950 consumes some power. After ~8h in sleep ~20% of battery was eaten :( I suspect one cause of this problem can be sd/mmc card power management - it was not implemented for rx1950. So I implemented rx1950 s3c2410_mmc_def_setpower function that controls sd/mmc card power. When GPJ1 == 0 card is not powered, when GPJ0 == 1 card is powered. Some info about card-related gpios: GPJ1 - controls card power (1 == on) GPH8 - ro sense, (1 == rw, 0 == ro) GPF5 - card detection Latest patch is available here Precompiled kernel and sound modules are available here

Yep, I've just finished rewriting touchscreen and battery drivers to use s3c24xx_adc driver instead using adc directly. It was relatively easy :) No more adc_battery driver (s3c24xx_adc is not adc-class compliant, and I was too lazy to port adc-class to 2.6.28). I rewrote adc_battery to use s3c24xx_adc driver directly, and named it s3c_adc_battery :) And with touchscreen it was much easier: just add some #includes, add adc_client field to device struct, add 2 callback implementations, add some lines about registering as adc_client, and replace some lines that start adc conversion... That's all. Patch is available here P.S. It seems touchscreen driver needs some filtering... I'll look what openmoko guys made to implement touchscreen filtering.

I've spent a day porting old patches to the new kernel, and here's results: 2.6.28-04-jan-2009.tar.bz2 Almost all is working, except wifi (need to port acx100 driver to the 2.6.28 kernel) and battery driver (need to adapt it and touchscreen driver to the new s3c24xx_adc driver) Following tasks are on going: 0. Port touchscreen driver to use s3c24xx_adc 1. Re-implement battery driver 2. Fix sound problems (incorrect sample rate, find out why it doesn't play first time). Problems I've encountered during porting: 1. soft lockup in s3cmci driver in do_pio_write. Thanks to Yaugen Kharuzhy for fix! 2. new fancy (and buggy) gpio lib. No more gpio_to_irq, and gpio_request doesn't work for GPJ, GPGx, where x >=10 P.S. Is there any rx1950-owners who want to help me with porting? :)

One more annoying issue was fixed tonight :) No more LCD flickering after resume! :) Problem was in timer1. rx1950 uses it somehow for clocking LCD (Don't know how :)). After booting from windows, linux reuse windows' timer settings, but these settings were lost after suspend/resume. Solution is simple: reconfigure timer1 in rx1950_lcd_power (some bits of TCON, TCFG0, TCFG1, regs TCNTB1, TCMPB1). Patch will be available as soon as embedded.net.ru get up :) One more hint: To get rid of 270 degrees screen rotation add following lines at the exports section  of /etc/init.d/opie: export QWS_DISPLAY=LinuxFb:Transformed export QWS_SIZE=240x320

Today I've finished first implementation of rx1950 battery driver. It's based on adc-battery driver from hh.org Charging now work correctly (I've tested it, it can charge my battery to 100%, and then disables charging and makes red LED to light solid) Battery level estimated only by battery voltage. It's quite inaqurate and I'm trying to find ways to improve it. Results of my efforts as usually available on hh.org: http://handhelds.org/moin/moin.cgi/HpIpaqRx1950 P.S. Unfortunately, battery driver conflicts with touchscreen driver. I'm working on solution...

At last :) I've managed to get charging work correctly, red led blinks when charging is in progress, and lights solid when charging finished. (Denis reported that his PDA has yellow led, btw, it does not matter :)) Problem was stupid: GPJ2, GPJ3 and GPJ6 (and not GPJ4 as I've reported before!) are affected in battery charging. I'll post patch after some testing ;) Here's short description: when charger connected, GPF2 goes to 0, and EINT2 interrupt occurs. In that case we should: set GPA2 and GPA3 to 1 wait for some time, GPF3 should become 0 (not sure that it's necessary) then we need to set GPJ2, GPJ3 and GPJ6 to 1 when charging is finished, GPF3 becomes 1 (GPF2 still 0!), in that case we should: set GPA2 and GPA3 to 0, set GPA6 and GPA7 to 1 set GPJ2, GPJ3, GPJ6 to 0  when charger is disconnected, GPF2 = 1. Each charger connecting/disconnecting event EINT2 occurs. But it doesn't when charging finished - so we should poll GPF3 periodically to prevent battery o...

Here's some interesting notes about suspend/resume with stock htc-compatible bootloader (rx1950, h1940, rx3000 PDAs) After waking up from suspend bootloader: checks if we really wake up from suspend (not power-on after power-off, etc) performs quick memory check (it calculates simple checksum), if check was successfull jumps to physical address 0x30081000 But haret loads kernel to address 0x30008000. So resume address overlaps kernel space. To avoid kernel code corruption we should load kernel higher :) So, you'll need to patch your kernel to create offset for .text section, and also you'll need to patch haret. Here's patch for haret: diff -Naur haret/src/linboot.cpp haret.offset/src/linboot.cpp --- haret/src/linboot.cpp 2007-04-15 20:13:41.000000000 +0200 +++ haret.offset/src/linboot.cpp 2007-04-26 19:52:13.000000000 +0200 @@ -87,7 +87,7 @@ // Recommended tags placement = RAM start + 256 #define PHYSOFFSET_TAGS 0x100 // Recommended kernel placement = RAM start + 3...

Sooooo, here we go :) Here I'll post history of porting linux to rx1950, info about its hardware, etc. Prehistory: Port was started by Victor Chukhantsev and Denis Grigoriev in the end of 2006. At the early stage modified version of linux-2.6.17 could be booted into console using modified haret. SD card didn't work, usb didn't work... At the beggining of 2007 (when I've joined to the development ;)) many drivers for rx1950 were ported (they were taken from other s3c24xx-based devices): s3c2440mci (sd/mmc driver), backlight driver, usb-device driver. Suspend/battery control/sound still didn't work. Also there were some issues with usb-device driver From may'07 till may'08 development was stalled. Our days: In may'08 I've continued porting. Old patches were adapted to 2.6.25.4 kernel, old s3c2440mci driver was removed, and new s3cmci driver took his place. Also some patches were taken from openmoko repository (s3c2440-usbdevice workaround) I've add...