Summary of happening in last two weeks or so

I was pretty much silent for last two weeks or so, but that doesn't mean I wasn't hacking on the kernel. More like the opposite is true, I was quite busy actually. Therefore I'm writing a little summary of what I did with some comment about it's usefulness etc.

• Passing platform_data to devices attached to AC97 bus

  This is actually the most revolutionary change. It allows passing platform_data (values like IRQ line, sampling frequency and many others) to devices connected to AC97 bus. This wasn't previously possible and the values were mostly hardcoded into the drivers or were using helper functions to pass the platform_data (which is not nice, but was inevitable). With this change, you can now easily set up a structure containing the parameters for your AC97 device inside your platform definition file and pass it to the AC97 device.

  Also, I converted the wm97xx-battery driver to utilize this change and prepared a patch that converts all platforms using this driver to pass the platform_data properly.

  Another change related to this are cleanups in the wm97xx-battery driver, but also there's a patch queued that adds IRQ-driven charger detection. This means the driver doesn't have to poll the charger state anymore.
  

  Also, I'm planning to convert the Mainstone Accelerated Touch driver to use this patch as it contains hardcoded values.

  There's also one more patch related to the sound part of wm97xx, but this time it's Palm-specific. I converted palm27x-asoc driver to use jack detection api. With this change I could have removed all the buggy GPIO handling code from there and leave the jack detection to the subsystem which is passing it to the userspace as a keypress event. I also used this pxa27x-asoc hacking opportunity to fix a few minor issues in there.

  The above patches are pretty much ready and should hit 2.6.32

• Fix broken pxaficp-ir driver and improve it
  

  This driver wasn't probably tested for a long time, therefore noone noticed the breakage. Since I was tinkering with kbdd and needed IrDA working on the Palm, I noticed this. The fix was fairy simple and is already submitted to kernel mailing list.

  Hand in hand with this goes another patch, a patch that removes redundant code from platform definition files concerning pxaficp-ir. I noticed most of the platforms used very similar initialization, controlling and shutdown routines where often a particular GPIO was requested in the initialization routine, toggled according to IrDA mode in the controlling routine and freed in the shutdown routine. Therefore I took all this, put it into pxaficp-ir, added two more entries (.gpio_pwdown, .gpio_pwdown_inverted) into pxaficp platform_data structure and converted all the platforms in question to use this. This also fixed a few oversights in the code. Though some platforms still has to use the old way (mainstone, lubbock to name a few) since their IrDA routines are much more complicated then toggling a GPIO.

  Actually, this GPIO toggling thing is happening because most of the IrDA transceivers have around 5 pins, those are Vcc, GND, TXD, RXD, PWDOWN. The PWDOWN pin is interesting, since by pulling it high it blocks the transceiver (disconnects the logic) so it can't either transmit or receive anything. This approach is used on pretty much everything (not only PXA board) since it's cheapest and easiest to do.

  Those two will hopefully hit 2.6.32 as well.

• I put together NAND driver for Palm T|X

  This driver uses the gen_nand driver, therefore all of the controlling routines are implemented in platform definition file. So far so good. The really bad part is Palm hardware engineering squad probably had some issues (better leave it at this since I don't want to insult anyone). They connected the NAND flash in very obscure way. As you can see on the schematic*, the CLE (Command Latch Enable) and ALE (Address Latch Enable) lines of NAND are connected to pretty high MA (memory address) lines of CPU. This makes allocating two memory regions a must to drive those pins. Allocating one continuous region would be unthinkable. Actually, vast majority of hardware manufacturers wire the ALE and CLE pins of NAND flash to low memory addresses. But otherwise the wiring is quite fine.

  * this is available thanks to Ales 'snua12' Snuparek who took apart broken Palm T|X and gave me a board with no components on it so I can trace the connections from CPU to NAND

• I added Palm Universal Wireless Support into kbdd

  This was quite a quick hack. I had to switch the pxaficp-ir off in kernel in the end though, reconfigure the ttyS2 port as STUART and toggle the PWDOWN GPIO using the GPIO API through sysfs since pxaficp-ir is a network device and the keyboard surely doesn't speak ethernet frames, therefore all what the keyboard generated was dropped even before it entered the network stack. I think we might need some middle layer here, between where RAW IrDA frames are unpacked and network layer, from which we can get raw keyboard data, but that's not important now and needs to be properly thought through. Well since I has the port in STUART mode, I had to implement cruncher for IrDA frames. They are pretty simple so it wasn't a problem. Otherwise the keyboard protocol was simple. What the keyboard actually says is 6 byte sequence: [XBOF][BOF][keycode, highest bit (7) is indicating keypress][previous byte, but bit-inverted][probably CRC, no idea][EOF].

  This patch, if wasn't already applied will be applied soon.

• LMS283GF05 LCD SPI controller driver

  This hit mainline through the -mm tree. There's an article about this driver earlier this month.

• The never ending tale of serial port power management hook goes on

  But this time it actually moved somewhere. Russell came up with some vast patch for selectively registering UARTs on PXA from platform definition files. If this patch will be combined with mine, which adds the hook, this tale might actually have a happy ending meaning we will finally be able to switch the level shifters and similar chips attached to UARTs on and off without pain.

• UCB1400 touchscreen shivering

  Today, a friend of mine reported me that ucb1400_ts driver pretty much sucks. I gave it a go and he was right. Therefore we had two absolutely different platforms, but the same problem, the touchscreen was barely usable because of the shivering. The cursor was jumping like crazy even if the touchscreen was properly calibrated and all. He also suggested to check the ADCSYNC pin as it might help. So I started investigating around that. Not too long after that I noticed a kernel parameter which was set to 0 by default and which enables utilization of ADCSYNC pin by the touchscreen driver. Setting that to 1 made the touchscreen calm down and with that it works beautifully. I'm thinking of setting it to 1 be default in kernel and using the kernel parameter to set it to 0 since most platforms, if not all, have that pin connected (it's necessary to sync the touchscreen with LCD as not being in sync is the cause of shivering).

• Updates to Palm Tungsten|C patches

  I also updated to Palm Tungsten|C patchset to incorporate the ucb1400 change as well as a few other fixes.

And that's about it. The article grew unexpectedly long so if you are reading this, I'm happy you didn't get bored and ran away.

PalmLD NOR Flash driver

I sent one more patch to linux-arm-kernel mailing list adding support for AMD Am29LV400BB90VI CMOS NOR Flash memory to Palm LifeDrive Linux port through physmap-flash driver. This flash as used in Palm LifeDrive has 16bit wide data/address bus and total capacity of 4Mbit (512kB).

PalmTX,T5,LD fixes

Today, I sent a few fixes for PalmTX, T5 and LifeDrive to some mailing lists (alsa-devel, linux-input, linux-wireless, linux-arm-kernel). They are addressing the following issues:

• MFP configuration for STUART on T5, TX, LD (fixes not working serial port)
• WiFi channel issue on TX (that is, fix for FWv4 register shift in libertas driver)
• MMC delay on T5, TX, LD (fixes problems with some cards not being detected properly)
• Interrupt driven touchscreen driver for T5, TX, LD (see below)

I also sent RFC patch for pxaficp driver to remove too many copies of similar code for startup/shutdown of the IrDA chip.

Interrupt driven touchscreen driver: I modified the mainstone interrupt driven touchscreen driver and added support for Palm hardware. The benefit from this is that this driver removes some load from the CPU. The main problem with getting this driver work was weird WM1613 chip found in Palms. The chip is some weird crossbred between WM9712 and WM9713 (because WM9712 has AC97_GPIO_STATUS register shifted by one to left, WM9713 doesn't and WM1613 doesn't either, though reports it's ID as WM9712 ; also, reportedly this chip as found in Palm Treo680 reports it's ID to be the one of WM9713).

Further Z2 kernel hacking

As you might have noticed, I was hacking quite a lot on the Z2 recently. I finally got the patches into some releasable form, so here they are (LINK). To apply them, issue the following commands:

• Clone Eric Miao's kernel tree:
  
  • $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
  • $ git checkout -t -b devel origin/devel
• Extract the tarball with patches:
• $ tar -xvjf Z2-patches.tar.bz2
  
• Apply the patches:
• $ git am Z2-patches-clean/*.patch

The current version still has some issues, but that's being worked on (mostly usability issues, hardware seems to work well). Beware, this version of kernel doesn't work with BLOB bootloader. You'll need U-Boot flashed into your Z2 in order to run this kernel.

Z2 LCD problem solved

As I wrote in the previous entry, the LCD wasn't working if BLOB was replaced with U-Boot on Z2. This is not true anymore. A member of Z2 hacking community called 'g1powermac' supplied me with a datasheet to the LCD module which clearly stated the LCD needs initialization over SPI bus. I took a quick glance at the BLOB sources and found out it's really true, the LCD needs to be initialized as there was something very similar to the stuff in datasheet. I put together a simple driver (patch available here) to do the initialization and it really turned out to be the problem why LCD stood blanked. Therefore the way to replacing BLOB with U-Boot is now open.

Zipit Z2 bootloader hacking

Some time ago, I got quite nice device called Aeronix Zipit Z2 from Martin 'Magon' Kupec. The configuration is pretty normal - 32MB of RAM, 8MB of Flash, 312MHz PXA270C5. Moreover, the device is Linux-based, but running some proprietary userspace application.

Actually, the maker of the Z2 was kind enough and provided some patches and some hardware information (can be found here). I'm a little suspicious whether the patches and what's in the device correspond, but whatever. Unlike Palm Inc. (whose behavior towards Linux community is very disgusting and rude), the Z2 maker is very open to cooperation with Linux community and very supportive.

Anyway, just recently, I started hacking on a new bootloader for Z2 as the one the device is shipping with is total crap (details left out for the sake of mentally weaker readers). The bootloader of choice was u-boot again. In it's current state, the only problem with replacing BLOB (the original bootloader) with u-boot is that with u-boot, the LCD doesn't work even later in Linux, it just stays blank white. The rest of the hardware works (you can even boot kernel from MMC card, serial console is OK, Flash memory is supported etc.). I suspect the problem with LCD is some GPIO setup problem or PMIC setup problem and will need further investigation. Here's a simple howto to get an u-boot binary for your Z2:

• Clone U-Boot-ARM sources: git clone git://git.denx.de/u-boot-arm.git
• Download patch here and apply it to the sources
• Run the following commands to compile U-Boot for Z2:
• make CROSS_COMPILE=arm-linux-gnueabi- clean
• make CROSS_COMPILE=arm-linux-gnueabi- zipitz2_config
• make CROSS_COMPILE=arm-linux-gnueabi-

The above procedure will produce file called u-boot.bin. You'll need a serial port attached to Z2 to replace the BLOB bootloader. In case you happen to fail the process of replacing the bootloader, you'll have to attach JTAG adapter to the Z2 and reflash using JTAG.

BEWARE: THIS PROCEDURE IS DANGEROUS AND MAY PUT YOUR DEVICE TO UNUSABLE STATE (BRICK IT)! THE AUTHOR IS NOT LIABLE FOR ANY DAMAGE CAUSED BY APPLYING THE FOLLOWING PROCEDURE!

Ok, so if you are still brave enough, here's the procedure.

• Run minicom terminal emulator on your PC, set serial port configuration to 115200Bd 8N1 (^A-o).
• Power up Z2, press Enter repeatedly to interrupt autoboot ... you will get bootloader prompt (blob>).
• On your PC, prepare two files from u-boot.bin by issuing the following commands:
• dd if=u-boot.bin of=u-boot.bin.1 bs=64k count=1
• dd if=u-boot.bin of=u-boot.bin.2 bs=64k skip=1
The first file should be exactly 65536 bytes long, the second one should be a little shorter.
• Now you have to send the files to the device. In the BLOB command prompt type "xdownload blob" without quotes and press ^A-s, select xmodem and navigate to the u-boot.bin.1 file. Send that one.
• Once the above procedure succeeded, continue to sending second part of u-boot. In the BLOB prompt, type "xdownload kernel", do the same sequence as before, that is ^A-s, select xmodem, but this time send u-boot.bin.2 file.
• Now finally you can flash the u-boot into the device. That is done by issuing the following two commands in BLOB prompt (this is the unsafe part, anything to this point was safe): "flash kernel" "flash blob". Once those complete, type "reboot" and you should get an u-boot prompt.

If the above worked, congratulations to your new Z2 with u-boot.

Just a final note to this patch, it needs cleaning up and fixing the LCD problem.

A way to PalmOS-less device IV

This being probably the last article of the series, I decided to sum things up a little. But firstly, I have to admit there's still a minor issue. The system sometimes refuses to suspend and hangs instead. That is being worked on. I made some chart of support available here. As of now, the device is pretty much usable. My current setup looks like the following:

• xfce4 on debian-based rootfs running from 2Gb class-4 SD card
• Flash containing UBoot bootloader and basic recovery system (fits well in 16Mb)

Even though I think this kind of full-blown setup might be a little too heavy on a device PalmTC is, it copes with it well.

Now to the kernel stuff, as you might have found out in the previous posts, there are some files available, here's the list:

• Kernel config: .config
• Patches: Available here, apply on the following kernel tree
• U-Boot patch: available here

To compile kernel, do the following:

• Copy the downloaded .config to kernel source directory, apply all patches (use git am).
  
• make ARCH=arm CROSS_COMPILE=arm-something- menuconfig # this is not needed in case you don't want to modify the kernel configuration
  
• make ARCH=arm CROSS_COMPILE=arm-something- # this will get you arch/arm/boot/zImage (suitable for Cocoboot)
  
• make ARCH=arm CROSS_COMPILE=arm-something- uImage # this will get you arch/arm/boot/uImage (suitable for U-Boot)
  
• INSTALL_MOD_PATH=/somewhere/safe make ARCH=arm CROSS_COMPILE=arm-something- modules_install # this will install modules to /somewhere/safe/lib/modules/... You really don't want to mix them with your systems' modules

To compile U-Boot, do the following:

• Apply all patches (again, git am is your friend)
• make CROSS_COMPILE=arm-something- clean
• make CROSS_COMPILE=arm-something- palmtc_config
• make CROSS_COMPILE=arm-something- # this will get you u-boot.bin, the bootloader binary

You can use busybox to prepare some initramfs for your kernel if needed.

A way to PalmOS-less device ]|[

So after some more tinkering with linux kernel, I got a decent, cleaned up version of the sources ready. Without further ado, get the sources here:

http://marex.hackndev.com/palmtc/

What still has issues is the keypad, I'll have to talk about it with Eric Miao since he made some changes to the original driver. The WiFi works, sadly, the module was faulty so I replaced it with another one. Also, sound is now fixed as well. I'll prepare some kind of linux installer soon.

A way to PalmOS-less device ][

And here comes one more entry today. Once I have a nice uboot on PalmTC now, why not give linux a go, right? Actually, collecting all the ancient patches for PalmTC I produced last year, I managed to compile a kernel from them and load it on PalmTC. Many things work, though there are some that do not. Here's the list of those that need fixing:

• Keyboard (needs to be replaced by gpio-matrix-keypad that will land in mainline soon ... I hope)
• WiFi (this might be caused by the highly suspicious state of the WiFi module, I need to test with another one)

Sound has one issue as well, the palmtc-asoc driver doesn't work, but with the native PXA driver, the UCB1400 chip is properly detected and touchscreen works as well. Therefore it'll be an easy fix.

U-Boot on PalmTC, way to PalmOS-less device

About a month ago, I made initial port of u-boot bootloader to Palm Tungsten|C. Back then it was bootable from PalmOS and pretty safe to tinker with. But just recently I gave it a go on real hardware. The hardware of choice was an old PalmTC I had lying around here for some time, covered with dust since I thought it was somehow damaged. To my surprise, after a few hours with JTAG ( more info on JTAG with Palm hardware ) and openwince-jtag tool, I managed to get serial console ( for that I used FTDI-based RS-232/USB converter from asix.cz ). Tinkering with it further got me a proper LCD support and MMC support (therefore it's even safe to damage kernel in flash as it still can boot from MMC card if inserted).

The patch is here: http://marex.hackndev.com/uboot/0001-Hacky-PalmTC-support-for-uboot.patch

Just apply it on top of uboot sources, compile and you should be ready to test it, but be careful, writing to flash can damage your device and the only way out is to solder JTAG to the board and reflash using that (the way I did the initial revival process for my PalmTC unit).

Blog revived

After a few years of silence on this blog, I decided to revive it. I prepared a ToDo list for this summer holiday and I'd like to make it all in time.

Here it is: http://marex.hackndev.com/ToDo.txt