Linux on your palm

Toradex Colibri Tegra 2 -- first step

2011-06-10T05:21:00.002+02:00

Just a quick post. Thanks to the work of ant micro guys on Toradex Colibri Tegra 250 U-Boot, I was able to use that as a jump start towards Tegra 250 Linux port. I did a very very basic port, the bootlog follows.

I will eventually work on this port more as it seems quite interesting.

U-Boot 2011.03-rc2 (Apr 27 2011 - 21:33:54)

TEGRA2
Board: TORADEX Colibri Tegra2
dynamic ram_size = 268435456
DRAM: 256 MiB
Using default environment

In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Colibri Tegra2 # usb reset ; setenv serverip 10.0.0.1 ; setenv ipaddr 10.0.0.2 ; setenv netmask 255.255.255.0 ; tftpboot 0x01000000 10.0.0.1:uImage ; bootm 0x01000000
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 2 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
scanning bus for ethernet devices... 1 Ethernet Device(s) found
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 10.0.0.1; our IP address is 10.0.0.2
Filename 'uImage'.
Load address: 0x1000000
Loading: EHCI timed out on TD - token=0x8008d80
T #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##
done
Bytes transferred = 2336144 (23a590 hex)
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.0.0-rc1-08421-g4f2e4c1-d
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2336080 Bytes = 2.2 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.0.0-rc1-08421-g4f2e4c1-dirty (root@mashiro) (gcc version 4.4.5 (Debian 4.4.5-8) ) #11 SMP PREEMPT Fri Jun 10 05:18:47 CEST 2011
[ 0.000000] CPU: ARMv7 Processor [411fc090] revision 0 (ARMv7), cr=10c5387f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Toradex Colibri Tegra2
[ 0.000000] Memory policy: ECC disabled, Data cache writealloc
[ 0.000000] Tegra SKU: 8 CPU Process: 0 Core Process: 0
[ 0.000000] L310 cache controller enabled
[ 0.000000] l2x0: 8 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x6e080001, Cache size: 65536 B
[ 0.000000] PERCPU: Embedded 7 pages/cpu @c06ef000 s4960 r8192 d15520 u32768
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: mem=256M@0x0 console=ttyS0,115200
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 256MB = 256MB total
[ 0.000000] Memory: 254776k/254776k available, 7368k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
[ 0.000000] vmalloc : 0xd0800000 - 0xfe000000 ( 728 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .init : 0xc0008000 - 0xc00e3000 ( 876 kB)
[ 0.000000] .text : 0xc00e3000 - 0xc0474ddc (3656 kB)
[ 0.000000] .data : 0xc0476000 - 0xc04a5ce0 ( 192 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:416
[ 0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
[ 0.005600] Calibrating delay loop... 1987.37 BogoMIPS (lpj=9936896)
[ 0.060049] pid_max: default: 32768 minimum: 301
[ 0.060431] Mount-cache hash table entries: 512
[ 0.061121] Initializing cgroup subsys debug
[ 0.061131] Initializing cgroup subsys cpuacct
[ 0.061157] Initializing cgroup subsys freezer
[ 0.061216] CPU: Testing write buffer coherency: ok
[ 0.061406] Calibrating local timer... 249.49MHz.
[ 0.260476] CPU1: Booted secondary processor
[ 0.320055] Brought up 2 CPUs
[ 0.320064] SMP: Total of 2 processors activated (3981.31 BogoMIPS).
[ 0.325413] print_constraints: dummy:
[ 0.325634] NET: Registered protocol family 16
[ 0.333888] bio: create slab at 0
[ 0.334557] vgaarb: loaded
[ 0.335681] Switching to clocksource timer_us
[ 0.337174] NET: Registered protocol family 2
[ 0.337330] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.337807] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 0.337944] TCP bind hash table entries: 8192 (order: 4, 98304 bytes)
[ 0.338055] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.338063] TCP reno registered
[ 0.338072] UDP hash table entries: 128 (order: 0, 4096 bytes)
[ 0.338167] UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
[ 0.338532] NET: Registered protocol family 1
[ 0.339113] RPC: Registered named UNIX socket transport module.
[ 0.339121] RPC: Registered udp transport module.
[ 0.339127] RPC: Registered tcp transport module.
[ 0.339133] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.340005] Switched to NOHz mode on CPU #0
[ 0.340479] Switched to NOHz mode on CPU #1
[ 0.799161] io scheduler noop registered (default)
[ 0.799366] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.145889] ttyS0: detected caps 00001100 should be 00003100
[ 1.145903] serial8250.0: ttyS0 at MMIO 0x70006000 (irq = 68) is a XScale
[ 1.507896] console [ttyS0] enabled
[ 1.628949] loop: module loaded
[ 1.632324] i2c-core: driver [apds9802als] using legacy suspend method
[ 1.638867] i2c-core: driver [apds9802als] using legacy resume method
[ 1.645365] i2c-core: driver [isl29003] using legacy suspend method
[ 1.651637] i2c-core: driver [isl29003] using legacy resume method
[ 1.658610] sdhci: Secure Digital Host Controller Interface driver
[ 1.664775] sdhci: Copyright(c) Pierre Ossman
[ 1.669576] TCP cubic registered
[ 1.672953] NET: Registered protocol family 10
[ 1.678392] Mobile IPv6
[ 1.680831] IPv6 over IPv4 tunneling driver
[ 1.686364] NET: Registered protocol family 17
[ 1.690824] NET: Registered protocol family 15
[ 1.695255] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1
[ 1.702955] Registering SWP/SWPB emulation handler
[ 1.713026] Kernel not built with RTC support, ALARM timers will not wake from suspend
[ 1.721309] Freeing init memory: 876K
(II) mounting sysfs to /sys
(II) mounting procfs to /proc
(II) mounting devpts to /dev/pts
(II) mounting debugfs to /sys/kernel/debug
(II) ifconfig usb0 10.0.0.2 netmask 255.255.255.0
ifconfig: SIOCSIFADDR: No such device
/bin/sh: can't access tty; job control turned off
~ # cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 1987.37

processor : 1
BogoMIPS : 1993.93

Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part : 0xc09
CPU revision : 0

Hardware : Toradex Colibri Tegra2
Revision : 0000
Serial : 0000000000000000

It's been half a year again ...

2011-06-03T22:17:00.002+02:00

It's been more than half a year since I last published here. It's just about time to sum things up again.

Firstly, this whole lag is because there was that Operating Systems class where our team wrote a complete OS for MIPS R4kc, including kernel threads, memory management, disk driver, SMP support, userland support etc.

Then, me and Cyril Hrubis started lecturing class "NSWI075 -- Linux kernel" on the university we both study at, Charles University in Prague, Faculty of Mathematics and Physics. The class was enjoyable, even though it was a lot of work to prepare for each of the lectures. Even through this stuff went on, we even managed to make a 2-and-half day long hack-a-ton for our students.

This actually resulted in us finding there are some very capable people in the class, which already got some patches mainline. This is actually quite positive information. Here we also even got tiny bits of device tree on Intel/Marvell PXA!

In parallel with NSWI075, I got involved in a project where our task was to analyze and potentially improve capabilities of Linux in certain network operation. This is where I got to taste real device tree based thing and also got a taste of PowerPC machine. The device in this case was the completely boring MPC5200-based board.

Other than university projects, firstly, I got Efika Smartbook. The device is actually very nice and interesting and I'm very happy with it. I worked on U-Boot for this thing, which still isn't quite ready. There is still a reset problem on the Smartbook, which I didn't have time to debug yet. Though with a tiny change in Linux or U-Boot, the system works fine.

Hardware-wise, there was another event where I got a new toy. That was, FOSDEM. I bought there the Ben Nanonote MIPS/JZ4740 based handheld. It's an awesome thing, but due to Operating Systems class and stuff, I wasn't able to hack on it at all.

FOSDEM though requires a special paragraph or two here. We called it a school field-trip, since the group of people I went there with were all my students from NSWI106 -- Administration of UNIX class. We met a few other friends on the airport, though the most interesting was the first evening in there. Delirium Cafe, where we had some Belgian beer, made things very interesting. So much we left the hotel the other day sometimes past noon.

When we arrived at FOSDEM, we quickly met with many well-known people. For me, it was a friend I sometimes meet even here in Prague since he's local -- Pavel Machek. As for the foreigners though, it was Hector Oron, Wookey, rtp, Loic Minier and many others from the Debian/ARM team. There were obviously many others. Lastly, I must not forget to mention that for whole that time, I had no other than ARM-based hardware with me. I had no x86 laptop with me and I had no trouble at all. As for FOSDEM, it was really enjoyable and next year I'll likely go with a bigger group of friends, but that's all.

Next important event was my visit of DENX. Meeting Wolfgang Denk, Detlev Zundel and others from that was an awesome experience. Seeing how the company works and how they work with the hardware was something awesome. Here again I saw a lot of interesting hardware and had a great time with those people.

But due to me being too busy with all the stuff happening, I got barely any time to hack on kernel. I got a few fixes in, but most of the stuff I tried pushing down on my students. I really hope I'll be able to bring in a few new kernel hackers soon.

Erratum ENGcm09395 and OpenOCD

2010-10-31T10:21:00.003+01:00

Apparently, the Erratum ENGcm09395 for iMX515 made the OpenOCD problems clear. It states the location of ROM Table is misreported. But still, I wanted to implement the ROM Table location autodetection as Oyvind Harboe hinted me to.

Therefore I added a function for handling quirks as this and did some code shuffling in OpenOCD. The patches for this are already in the OpenOCD mailing list. I'm still a bit uncertain about them, but I hope after one or two iterations, they will land in mainline OpenOCD.

Studies, U-Boot, OpenOCD and CortexA8

2010-10-30T20:44:00.003+02:00

The lack of additions on this blog recently wasn't caused by me disappearing out of the blue. It was caused by me preparing for my degree's exams, then fighting with U-Boot and recently working on a new hardware. Read on.

Studies
In case you're only interested in technical stuff, you can skip this part, which is mostly about gaining my bachelor's degree at the Faculty of Mathematics and Physics Charles University and the OpenBSD thesis.

Due to rather personal than other circumstances, I ended up finishing my first academic degree at the end of the summer rather than at the beginning of it. Well, whatever.

That means, the OpenBSD hacking days are past me since I finished my bachelor's thesis. I believe I wrote about this in some of the previous blogs, but now it's officially past me and sealed away. In the end, the thesis was graded A by both the opponent (Mgr. Martin Decky) and the supervisor (RNDr. Leo Galambos, Ph.D.) so the final grade from the thesis was A as well.

Note, the grading system in our country is different than in most other countries. Here, it's numeric, but "1" is equal to A, "2" to B, "3" to C and "4" to Failed. I'll hereby stick with the system using letters to make it less confusing.

Then I had to prepare for the exams, which were really thorough so the preparation certainly couldn't be underestimated. That took me about a month where I didn't hack on stuff much, I was just reviewing patches and from time to time I sent some minor fixes. At the exam, I finished with a total grade of B.

Apparently, on the diploma, there is only one grade, not two (one from thesis and one from examination), so the examination committee has to ultimately decide this grade. My final grade was A, which is what will be on my bachelor's diploma, which I'll receive later next month.

U-Boot
Once the exam was past me, I got back to maintaining U-Boot PXA. Apparently, there were a lot of changes going on inside the U-Boot.

Firstly, Wolfgang Denk pushed me to rework pxa-regs.h so the standard accessors can be used to access PXA CPU registers instead of the preprocessor goo that was there before. This was a patch over 6000 lines big as it affected a lot of code in U-Boot, not only pxa-regs.h. Obviously, platform code as well as drivers were affected and had to be patched to use {read[blw],write[bwl]}() accessors. Catching all the damaged code wasn't really easy in some cases, but I think I caught them all.

With that out of the way, I checked pxa-lcd driver and fixed various, mostly coding-style related problems and added a few new LCD definitions. Then, I fixed PXA250 UART problem, where the UART was omitted in U-Boot from the initialization routine on PXA25x and PXA26x.

Also, the Palm LifeDrive, Palm Tungsten|C and Balloon3 support went in, Voipac PXA270 got various bugs fixed and there were also fixes for the memory init code by Mikhail Kshevetskiy. I also got an USB3.0 flash disk, but apparently, it didn't work with USB on PXA in U-Boot, so I submitted a patch for this.

Then though, Heiko Schocher introduced a change in U-Boot, which allows it to relocate in RAM. More into detail, this change allows U-Boot to always sit at the end of RAM, which is useful on systems where there are various models with different size of RAM detected at runtime. This change broke the PXA port of U-Boot altogether.

This was a good enough motivation to completely rework the PXA init code. I rewrote half of the start.S assembler bootstrap from scratch, because the code there was really old, messy and and with the relocation patches in, no longer suitable for the purpose. The start.S can no longer use RAM until certain point, but it needs to use stack. Sure, for stack, SRAM can be used on PXA27x, but there are PXA CPUs older than that which have no SRAM. This set me in front of a challenge -- where should I point stack pointer register is there's no RAM.

The solution is somehow easy, but needs you to understand how the caches on ARMv5/XScale core work. What was the trick? It was easy, the caches allow the user to lock entries in them. That is, they allow the user to write into the cached area, while convince the CPU not to actually write the data into that area, but only keep them in cache. But for using caches, MMU has to be enabled. So the big picture is, I manually generated an 1:1 VA:PA mapping MMU table within the U-Boot binary and at the bootstrap, I point the CPU at this table and enable MMU. Within this table, at the place which indexes RAM start +1MB*, I made a special entry that configures the area as cachable. Then I used the information from the XScale core documentation to lock 4 kb of data to create a tiny, 4 kb in-cache RAM. So writing to that area of RAM behaves as if the RAM was where and was working, even though there's no backing store. The rest was just a matter of pointing a stack pointer there, end of the fairy tale.

This wasn't the only thing about relocation patches though. Because there was no need to init the RAM in assembler code anymore, I could push the RAM init into the C routines which were executed much later. I did this and in current state, most of the hardware initialization takes place much later. This has one very big advantage in the long-term. As the hardware is not initialized in C code, it'll now be easily possible to walk a Flattened Device Tree and do the hardware initialization according to that. So imagine having single U-Boot binary work many CPUs and only supplying a FDT for each board. That's the long-term plan now.

There were other changes related to this relocation stuff, which in the end generated about 30 patches in total. One more thing is interesting though. Because there are boards which have multiple variants and it's not possible to detect which variant is which on the fly, there started to appear a Makefile pollution in U-Boot, which Wolfgang Denk didn't like. We discussed this and came to a conclusion about a solution. I implemented first version, then he improved it and committed it. So now, all of the U-Boot board variant setup should happen in boards.cfg finally and there's no longer need to touch Makefile.

OpenOCD and CortexA8
About a month ago, I received an Genesi USA EfikaMX Smarttop from their developer sponsorship program called Power Developer. My task was to support this device with OpenOCD so common people can JTAG it with those cheap FT2232-based JTAG dongles.

The system contains an Freescale iMX515 CPU, for which apparently there were some previous unsuccessful attempts to make it work. I based my efforts on these, but did a further investigation of the matter. "Sadly", all the support for Cortex A8 was already in place, which spoiled my fun ;-)

And in the end, it turned out the solution of the problem was very simple. The people trying to get iMX515 working with OpenOCD forget, that the Cortex A8 support there was OMAP3-centric. The DAP address was hardcoded for OMAP3, which has it at 0x54011000 address, but for iMX515, the DAP address is at 0x60008000. Adjusting this in the source code made the CPU mostly work.

The problem with this though is, that this stuff should be auto-detectable. So far, I was digging in the CortexA8 stuff for about two days so I have still a lot to learn about this. But I was hinted by Oyvind Harboe and Zack Welch to use the "dap info 1" command and look around that. The command reads the MEM-AP's BASE register to figure out the location of ROM Table. And by parsing the ROM table, it's possible to figure out the location of DAP, which is exactly the address I mentioned in previous paragraph that needs to be autodetected.

The problem is, this command for some reason misdetects the location of ROM Table and returns the ROM Table is empty. By manually adjusting the source code and pointing the command to a proper location of ROM Table, the parsing algoright catches up and correctly dumps the contents. You can keep an eye on further development of this matter for example here (or the OpenOCD mailing list obviously).

There, you can also find preliminary patches with which the iMX515 works, but the autodetection of ROM Table base is still missing. So, if you want to use iMX515 with OpenOCD, you can, but those three patches won't probably make it into mainline OpenOCD until the autodetection problem is solved.

U-Boot: PXA27x Matrix keypad driver

2010-08-16T14:53:00.002+02:00

Today, I hacked together a PXA27x matrix keypad driver for U-Boot bootloader. It behaves as a usual stdin. Then I made ZipitZ2 utilize this new driver. I also implemented support for various modifier keys directly into the driver for convenience's sake. The driver still has a few rough edges and needs some more care, but it does it's job on ZipitZ2 well.

The source code can be found in u-boot-pxa -devel branch.

Last month's hacking report

2010-08-14T18:26:00.004+02:00

Today's blog entry will be a long one as it will span my activities over the last month. I focused more on hacking than on blogging, but the time has come and the FIFO got filled so it's time to empty it.

Voipac PXA270
Firstly, I got a bit involved with Android. Radoslav Deak and me did some kernel and userland hacking on it to get it running on the Voipac PXA270 board. The Android kernel changes didn't make me feel well, but the userland made me cry, no more words needed here I believe. Anyway, the Android does not support 18bpp LCD, therefore I was told they'll send me another board with 16bpp LCD. Though a mistake happened and I got a board with 18bpp LCD again. Luckily enough, I don't have to hack on Android anymore, but it's not only Android that doesn't support 18bpp LCD, it's also X.org.

Here you'll probably already start questioning my sanity when I say I started digging in the X.org to get this fixed. The X.org developers are actually very nice and very helpful people and they helped me with patching the X.org. One thing worth noting is that I compiled the X.org on the other Voipac PXA270 board which is running Debian already. The building took a little bit of time anyway. The patch is already in mainline X.org I believe and it was not all that hard in the end.

The only trouble with this change is that it uses four bits of memory for each pixel and with the 104MHz SDRAM on the Voipac PXA270 and 640x480 LCD, this eats a lot of memory bus bandwidth.

One more thing is worth noting, that is the xserver-xfbdev, which is capable of 18bpp already, but it's not certain whether the apps connecting to this kind of Xserver won't have problems with 18bpp. On the other hand, this kind of problem may happen even with the standard Xserver, but so far, GDM worked well (and probably whole GTK does, I didn't test anything but that).

There were some other minor changes on the Voipac PXA270 front, but these were mostly bugfixes. There were also bootloader related changes and fixes though. The most relevant one was the one adding support for 128MB variant of the module. All these changes can be found either in my kernel tree or in my u-boot tree.

The OpenBSD
Here comes one sad piece of news. Sad, because I had to leave a piece of code unmaintained. I won't disclose the reasons why as I believe interested people will be able to find it themselves. To put it short, I'm not a member of the OpenBSD developer community anymore. I released the rest of the patches for Palm port to their mailing list and I hope jasper@ and drahn@ will at least not let the code bitrot.

On the other hand, it's actually quite a relief as I can now fully focus on Linux kernel hacking and U-Boot bootloader hacking. My opinion of the OpenBSD kernel code is biased and therefore you won't find it here. Though I think drahn@ did a very good job on the ARM code.

Well, at least I managed to finish my thesis and the system actually works quite well on Palm hardware, including Xenocara (the OpenBSD version of X.org), touchscreen etc.

Palm hacking again
A lot of redundant code in the Palm hardware support code and Eric's whining on that matter some time ago motivated me to consider trimming it a bit. Though hacking on the Palm hardware was different from the old Hack&Dev days this time.

I introduced a set of common functions which each registered one piece of hardware on the Palm handheld in question. This allowed me to remove about six copies of redundant data structures and other stuff. While at this, I wrote the common functions modular so in case the support for a particular piece of hardware isn't compiled in kernel, the support structures are removed as well.

I also added a long lost patch for the MAX1586A PMIC into the common code as that's used in all Palms while at that. Further on, I modularized the rest of the non-common code in all the Palm devices in the same fashion. I'm actually quite happy about the code quality now. And Eric did his little Linus-like gag about the number of deletions ;-)

This was not all on the Palm front though. As my Palm Tungsten|C is a nice toy I like quite a bit and I needed a PXA255 testing platform, I updated the U-Boot on this device to mainline version. This can be found in my u-boot tree again. I also modularized the kernel code the same way I did with PXA27x Palms, though I don't use the common code as this platform is quite different. While at that, I added support for LEDs and switched the UDC to gpio-vbus. All these changes can be found in my kernel tree.

U-Boot
I already said this earlier probably, but I'm now the U-Boot-PXA maintainer. Therefore support for some new machines hit mainline and support for a few others is underway. This time, the new ones are surprisingly the Palm LifeDrive, Palm Tungsten|C and Balloon3. The Palm Tungsten|C is no news as the code to support that hardware in U-Boot is about one year old. So this one was only updated, see above.

The Palm LifeDrive is a different thing though. Because I wanted to avoid destroying my unit, I figured out a way how to pseudo-dual-boot PalmOS and U-Boot for testing purposes. This turned out to be quite simple, though without JTAG one has to be very careful. Firstly, the size of flash in Palm LifeDrive is only 512kb -- 0x80000 bytes -- and the last 0x20000 bytes are unused and PalmOS ignores them. That's enough for slightly stripped down U-Boot binary, but there's one more thing missing, that is, in case U-Boot was installed in that part of flash, something must execute it.

Executing it means jumping to it's first instruction. By looking at the disassembly dump of the Palm LifeDrive flash, very close to the beginning, the code clears register "r0" by moving zero into it. By replacing this instruction with a jump at the 0x60000 address, the U-Boot can be executed. But that would make the dual-boot impossible in case there was just pure U-Boot at 0x60000.

The trick is to add code to 0x60000, that checks PSPR register aka. the only register that survives suspend-to-mem. This register always contains value that modulo 4 gives no remainder, ie. is aligned to four bytes in PalmOS. The last two bits are unused though and that's the trick.

The point is to load U-Boot just after this code that checks PSPR. In case these last two bits in PSPR are set, the code will not jump right past the place where the "r0" was zeroed, but instead will just continue executing the code further on, which means CPU will reach U-Boot. Otherwise, the PalmOS loader will just continue execution. I also had to zero the "r0" before jumping back to the PalmOS loader in the later case.

One more thing is important here. To set the PSPR, I adjusted the suspend routine in Linux kernel to store some totally broken number into it and when I then pressed any of the "unsuspend" buttons, the U-Boot came up. Note, the U-Boot I used for this had the wakeup capability disabled, which is very important.

To get the U-Boot wakeup the kernel properly, it's necessary to replace the Palm LifeDrive bootloader altogether. That's what I did and it worked very well for me, until I wanted to test a newly compiled version for Tomas Cech. The battery choked while the system was being updated. Well, that's sad. Luckily, I already have a replacement device.

Cypress EZUSB SX2
Having U-Boot on Palm LifeDrive means it can now be fully used with Linux. That also means need for some kind of connection to the outside world. Most of the people involved with Hack&Dev certainly recall the USB 2.0 chip in Palm LifeDrive. The chip is actually quite simple, but also quite incompatible with Linux's perception of an USB gadget chip.

The SX2 requires the so called Descriptor RAM to be filled with proper USB descriptor in order to enumerate at all. I started writing a driver for the SX2, but it's still very incomplete. In the current state, it can send data from host and to host and is behaving as 4 bulk endpoints. That implies it can be used probably only with g_serial for now. But it's still far from complete. The draft can be found in my kernel tree and anyone willing to hack on it is welcome.

The drinking party
During the Linaro conference in Prague, me and some other people -- Eric Miao, Nicolas Pitre, Daniel Mack, to name a few -- went for a beer. The party turned out into an awesome thing, it was probably the most enjoyable evening and night of the year for me.

Anyway, Eric decided to give up his maintainership of the Sharp Akita and pushed it into me. The current support for Sharp Akita in mainline is kind of poor, but with improving tendencies. The power management code is very broken and there are still a few other issues.

I decided to try fixing the power management issue so I joined efforts with Pavel Machek who started putting together a new battery driver for Sharp Spitz. Actually this also work on Sharp Akita and Sharp Borzoi. The driver currently has more rough edges than I'd love it to have, but it's kind of usable given enough knowledge on the user side. The problem with it is, that it still doesn't check the battery temperature so the user has to be careful not to overcharge the battery. Actually, there should be some GPIO, that prevents the battery from turning the device into a lethal weapon and the driver checks this GPIO, but according to Pavel, this is not safe enough.

I met with Wookey the other day and got a Balloon3 board with some additional peripherals. That obviously ended up in me porting U-Boot to this board and doing some heavy rework on the side of mainline kernel.

The first problem I faced was the FPGA that's on the Balloon3 board. That's used to route various CPU lines to hardware. It also controls NAND, CF and such. The PCMCIA/CF driver had to be slightly fixed on the Balloon3, because in case of FPGA, the only working firmware is version 0.3. For CPLD, which is integrated on some other Balloon3 boards, there is already version 1.0 of the firmware which has a different behaviour. I hope the fix for the FPGA firmware is underway as Hector Oron told me he'd look into it.

The worse thing was the NAND driver. For that, I used the gen_nand driver and implemented various necessary callbacks based on the original out-of-the-tree NAND driver for Balloon3. I heavily reworked this so the driver was used only as a technical documentation. Pretty much all the hardware is implemented on the board I have by now.

When I was hacking on the NAND driver, I noticed a bug in the gen_nand driver where it ignored the number of chips passed to the driver. The gen_nand assumed the number of chips was always one, which was true for all the boards that used the driver so far. But on balloon3, there were four chips in total. I fixed this and even implemented a check for invalid value of number of chips as per David Woodhouse's suggestion.

Toradex Colibri PXA3xx
Recently, there were a few people concerned about the status of Toradex Colibri PXA3xx. I was aware of a fact, that the code needs to be reworked for quite some time already. Just recently, I was motivated enough to go forth and do it. Therefore the code that's now in my tree is the reworked support for the board and the CPU card. I also reworked support for Colibri PXA300/PXA310 while at it. It is done in a very similar fashion to the PXA27x Colibri support. Actually, I used the evalboard code for Colibri PXA27x. Now all the Colibris use the same evalboard code and that's how it should be.

This is not all though. There was some stuff going on in the OpenPXA project about the Colibri PXA320 recently too and I was also pestering the tech support in Toradex. The result is that the E-Boot bootloader supplied by Toradex is not the only one that can update the CPLD firmware on the Colibri PXA320 board anymore.

Toradex provided me with the information on how the CPLD JTAG is connected to the CPU GPIO pins and an xsvf file for the CPLD containing the latest version of the CPLD firmware. And by using an xsvf player that I found is already in U-Boot and used on some PowerPC platforms, I was able to reprogram the CPLD to the latest version v1.7 of the CPLD firmware.

The xsvf player needed some obvious changes to operate the GPIO-emulated JTAG correctly, but the code is well abstracted and I think I'll make it into a generic code soon. Currently there are two copies of the same code in my U-Boot tree, which is no good. Note that the v1.7 of the CPLD firmware is probably some internal testing version from Toradex and I still have to ask them about the license for that file. It'd be best of they just put this xsvf file on their website.

Still, this is not the end. Because I wanted to use CF memory card on the Toradex PXA320 board, I decided to start implementing the PXA320 PCMCIA support. I first had to patch the pxa2xx_base to support different locations of the Static Memory controller registers, the MCIO, MCATT, MCMEM and MECR registers. That was the easier part.

After a bit of struggling with the Toradex CPLD and GPIO pin configuration and muxing, which is doing some obscure stuff to the PCMCIA signals, I managed to get the PCMCIA partly working. Note the struggle means I was stuck with it for more than a two days until I figured out what Toradex actually did. Their tech support on the other hand is very good and helpful even if a little bit slow, I'm happy about this.

The partly working above means, that if I insert a Marvell CF8385 into the CF slot, the card is detected, firmware is downloaded and no problems observed. Once I insert a memory card though, nothing happens. The card insertion GPIO is asserted, but it probably reads zeroes or something from the CIS. This issue can actually be just about anything, starting from wrong timing to misconfigured GPIOs. The more confusing thing here is that if I insert an Emtec or Patriot card, the card insertion is only detected. In case I insert a SanDisk card, the pata_pcmcia driver is loaded, but in the end, the disk is not recognized.

The cluster
You might have noticed the hardware kind of started piling up. That's true, but it's not unused actually. I use the boards that are in good shape software- and hardware-wise as an ARM compile cluster nodes. I run distcc on these and use it to build Debian packages. It's also an awesome stability testing and bug hunting mechanism for these platforms.

The cluster is still growing, but currently there are these machines:

Palm Tungsten|C
- PXA255 400MHz
- 64MB RAM
- 1GB MMC+ card
- USB CDC Ethernet
- Debian SID

Voipac PXA270
- PXA270C5 520MHz
- 128MB RAM
- 2GB SD card
- Ethernet connection
- Debian SID

Voipac PXA270
- PXA270C5 520MHz
- 256MB RAM
- 160GB harddrive
- Ethernet connection
- Debian SID

Balloon3
- PXA270C0 520MHz
- 384MB RAM
- 1GB NAND + 4GB CF card
- USB Ethernet connection
- Debian SID

More devices will be added as they will reach good enough state. I was also thinking of granting access to the cluster to a few fellow developers once it stabilizes well enough.

Other
Just a few days ago, Mike Rapoport aranged it so I received a CM-X300 board. I was still unable to replace the bootloader there as I still don't have JTAG connected to that board.

I also started plumbing into the Debian u-boot package and prepared a patch. The problem is the current maintainer is totally ignoring any requests from me so far. I hope it's just temporary as he was busy with organising the debconf.

I hope you enjoyed reading the text.

Marvell Zylonite PXA300

2010-07-09T03:43:00.002+02:00

Just a quick entry concerning OpenPXA today. In need for some rest, I hacked on the Marvell Zylonite PXA300 board I got some time ago. It is currently supported by the OpenPXA OBM2 as well as U-Boot (u-boot-pxa -openpxa).

I also tested the new SDHC capable PXAMCI driver I recently added to U-Boot on PXA300. It works if I disabled the High-Speed support, which is a new feature on PXA3xx where the card runs at 26 MHz. I think that it's just some really simple problem, maybe miscomputation of the clock speed or something, but I'll analyze that later. For now, I use the old driver on pxa3xx.

I'll also need to sort out the PXA3xx branch of U-Boot (the -openpxa branch), as the mess there starts being bigger and bigger. Once that's done and I have the Zylonite PXA320 fixed, I'll start pushing this stuff into mainline U-Boot.

Not to forget a quick summary of other happenings, I added LCD support to ZipitZ2 U-Boot port. That also implies a SPI interface, which I did using the softspi (GPIO driven SPI) driver. Lastly, I started pushing the PXA2xx fixes and improvements into mainline U-Boot.

U-Boot: PXA SDHC support

2010-06-30T02:27:00.003+02:00

Today, it'll be just a quick entry about a recent achievement in the U-Boot land. I was reported by some people from the Zipit Z2 project that U-Boot doesn't detect their SDHC cards. That was really troublesome and so was the state of the pxa_mmc driver in U-Boot.

Actually, pxa_mmc was probably the last SD/MMC driver in U-Boot that used the old driver interface there. I decided it needs a rewrite. I based the new code on the Linux version of pxa_mmc driver. The resulting pxa_mmc_gen.c now uses the generic SD/MMC framework in U-Boot and the code is much more cleaner. It also supports SDHC well. And one more benefit is that the timing issues that were observed with the old driver are gone now.

The code wasn't merged mainline yet and is currently held as a separate driver to make the transition from the old driver to the new one as smooth as possible. Also, I'd like the driver to get some testing before some other boards are converted to use it.

The code is currently available in the u-boot-pxa.git -devel branch. Also, it was submitted to the u-boot mailing list. To enable the new driver, you'll have to replace

#define CONFIG_PXA_MMC

with
#define CONFIG_GENERIC_MMC
#define CONFIG_PXA_MMC_GENERIC
And recompile the U-Boot.

To use the new driver, you can use commands like:
$ mmcinfo
$ fatls mmc 0
etc. Note, that the "mmcinfo" command is new and the old "mmc" command class is gone. So no "mmc init" anymore.

OpenPXA: first release

2010-06-21T19:48:00.003+02:00

The OpenPXA project proudly released first beta version of the bootloader package for PXA3xx. The package supports the following boards:

Toradex Colibri PXA300
Toradex Colibri PXA310
Toradex Colibri PXA320
Marvell Littleton PXA310

The software is labeled "beta" because there still might appear problems that we are unaware of.

The package contains the OpenPXA OBM2 and U-Boot bootloader binaries for the boards as well as installation instructions. The package can be downloaded from the OpenPXA website.

Zaurus hacking

2010-06-21T19:26:00.002+02:00

Just a quick update on the problems I described on Zaurus. I've been hacking a little bit further into it and figured there's a problem in PCMCIA. Actually, there was always a warning in the pxa2xx_base.c stating that the timing recomputation for the PCMCIA devices is based off the CPU core frequency and that's probably wrong. I changed this and based the timing off the CPU bus frequency, which fixed one of the problems with Zaurus. It fixed the problem where at 312MHz the harddrive died. The other problem with weird lines on the LCD still persists, though not in such a big scale.

On the other hand, the LCD problem now appears even on 416 MHz which makes me think the PCMCIA timing recomputation has some other bug. Maybe, the timing is now too tight so the PCMCIA device takes too much bus bandwidth, triggering the LCDs FIFOs underruns.

There is one more thing that brings me to that conclusion, that is, when I ran a hdpart -T /dev/sda on the harddrive attached to PCMCIA, I got the following results:

Frequency	Read speed without fix	Read speed with fix
416 MHz	8 MB/s	12 MB/s
208 MHz	2 MB/s	4 MB/s

Recent XScale hacking

2010-06-17T02:17:00.002+02:00

About a month passed since my last post so it's probably time for a recap. The last month was again very busy and the number of platforms that undercame changes overgrew the size of the header for this entry. For starters, let's just say that even the always so popular and beloved Zaurus got some cosmetic changes. There were also some changes in the PXA3xx land and the ZipitZ2 land wasn't left intact either.

ZipitZ2
The first turning point on this platform was a release of the U-Boot bootloader update kit for public testing. Some people installed this and reported me various bugs. There was for example a grave typo in the new U-Boot macros for pxa2xx which made wake-up from suspend-to-mem impossible. That was easily located and fixed right away. The new version of update kit was obviously uploaded very fast. Actually, there were no more bugs reported since then.

The only drawback is that U-Boot doesn't support booting from SDHC cards, only SD and MMC are supported. This can be easily worked around by flashing the kernel into the NOR to an address 0x60000. In case the U-Boot bootloader is unable to either detect a card or find a script on the card, it boots the kernel from the 0x60000 location.

The other changes related to ZipitZ2 happened within the Linux kernel. Firstly, the NOR flash layout was standardized. It is incompatible with the old layout, though on the other hand, now there are strict rules on how the NOR flash layout will look and no more anarchy will take place. The final layout is like this:

0x0-0x40000 -- U-Boot bootloader
0x40000-0x60000 -- U-Boot environment
0x60000-END -- Linux kernel or possibly some small filesystem

I was also reported a bug in the screen blanking on ZipitZ2. Not long ago, Alberto Panizzo wrote a driver for his LCD based on my LMS283GF05 driver (the LCD in ZipitZ2). Though back when I wrote this driver, I made a mistake and screen blanking wasn't working correctly. Sadly, the same mistake got into the new driver by Alberto as well. I therefore sent a patch for both of the drivers.

In the end, I must not forget to mention, that the WM8750 codec is now finally registered in the platform definition file for both ZipitZ2 and Sharp Zaurus/Spitz. This brings the conversion of the WM8750 codec which I started before the 2.6.34 was out to an end.

Income SBC
In one of the older entries here, I mentioned I got my hands on the Income SBC and that my patch started some discussion in the Linux-ARM kernel mailing list. Just to explain what this Income SBC device is, it is a custom-made board with a LCD which is powered by the Toradex Colibri PXA270 module. The conclusion of the discussion was so that we need to separate the board support code from the module support code.

A friend of mine, Daniel Mack, took the Income SBC patch and the Colibri PXA270 code and did the split, which was very helpful. Before the split, I sent a pile of patches which added support for various devices on the Toradex Colibri PXA270 module/baseboard as the support was quite incomplete in mainline.

Sharp Zaurus
Just recently, a friend of mine, Metan, was complaining that the LCD screen on his Sharp Zaurus goes crazy when he uses the mainline Linux kernel and changes frequency of the CPU with CPUfreq to just about anything but 416MHz. He also complained, that if he changes the frequency to 312MHz, the harddrive in the machine fails. He lent me the machine for a while with an explanation on how to boot kernel on it.

It didn't take long and I came up with a first patch. That was actually just a cleanup. The Zaurus support code in mainline Linux kernel was in a terrible state. The first patch therefore only improved the readability of the code. Actually, there was also a minor revamp of the CF/SD power control function. All in all, the patch was pretty much a complete rewrite of the file.

Then, there was another patch. The Zaurus contains an Intersil ISL6271A PMIC for the CPU. Even before I got my hands on the Zaurus device, I implemented a driver for it and asked Metan if he can test it. Well in the end, he lent me the Zaurus instead. The initial version of the ISL6271A driver contained bugs, but after about three revisions of the patch, the driver was clean and was applied to the regulator tree.

There was still the LCD going crazy though. I discussed this with Eric Miao and he explained to me, that the CPU bus probably isn't capable of transferring so many data and therefore the LCD FIFOs underrun. I checked this by enabling the Input and Output FIFO Underrun interrupt in the PXAFB driver. And bingo, the underruns really happened. This means there is either something, that consumes the bus bandwidth or the bus is simply slow. I also tested some other kernels which supported CPUfreq and noticed the issues was there as well. Sadly, I wasn't able to get CPUfreq working with a stock Zaurus ROM.

Also there is still a lingering issue with the harddrive and 312MHz CPU speed. This will need further investigation. It'll probably involve the Sharp SCOOP chip and PCMCIA drivers undergoing a rewrite.

Marvell
Apparently, the popularity of the OpenPXA project is rising. I assume this from a fact that I get more requests for help and bug reports. There were some that helped the project greatly, even if there was no patch included with them. What's even better is the project actually gets testers and that really helps.

The first important bug report that arrived was from some person from HCLTech. He had issues with saving the U-Boot environment into the NAND on the Marvell Littleton PXA310 board. The whole problem was that the size of the environment sector differed from the size of NAND block and the U-Boot MTD subsystem can only write whole blocks. Also, the environment position wasn't aligned to block boundary. That was quickly solved and a patch was applied on top of u-boot-pxa, openpxa branch.

Though he then wanted to do a TFTP boot and figured out the ethernet chip doesn't work in U-Boot. This took some further investigation. I figured out, that if I flash a Marvell BBU into the board and execute U-Boot from it, the ethernet magically works. I dumped various interesting registers from this setup and bisected the one which caused the problems with ethernet. The most funny part that the problem was caused by a bit marked as "SETALWAYS" not being set. Apparently, these bits marked as "SETALWAYS" mean something Marvell doesn't want other people to know. Obviously, armed with this knowledge, I fixed the ethernet and applied a patch.

The other batch of problems came from a guy owning a Colibri PXA320 board. He complained that he can't even boot a kernel from U-Boot. I figured this issue was only there if the kernel was compiled with a built-in initramfs. In the end, it was fixed by a quick patch. The problem was a mess in the RAM base addresses. It's an agreement in Linux-ARM, that the RAM on XScale starts at 0xa0000000. On PXA3xx though, the RAM is mirrored from 0x80000000 to 0xa0000000 by default for compatibility reasons. The U-Boot contained mess in this and both of these 0x80000000 and 0xa0000000 addresses were used. Unifying these addresses to 0xa0000000 fixed the problem.

Furthermore, this person complained, that the Colibri PXA320 board doesn't support USB device mode in Linux. A quick hack fixed that and patch already hit LAKML. With this guy happy and not considering buying a very expensive BSP from a certain corporation, I could have taken a rest. Though, I noticed some things worth fixing in U-Boot for this board along the way. I fixed the ethernet support on the Colibri PXA320 board in U-Boot and added USB host support.

This is still not all though. I mentioned in one of the older entries, that I got those Marvell Zylonites. I decided to take a look at those, particularly on the one with PXA320 C0 CPU. Firstly, I figured the CPU contains BootROM v3.38. This was a big surprise as this implies the CPU supports the NTIM header. Furthermore U-Boot apparently supported this board, but with the ongoing changes in the U-Boot bootloader, the platform was broken. I therefore took it and rewrote it from scratch, reusing just some of the static memory controller configuration values from it. The U-Boot works just fine. There is still a problem with this board though.

With the Zylonite320, I decided to try a new approach. I pushed all of the low-level init into the OpenPXA OBM2. I also implemented a DDR DRAM initialization code in the OBM2. This should in the end allow me, to totally skip and remove lowlevel_init.S in U-Boot. With just a few tweaks in the OpenPXA OBM2 and the NTIM header, I managed to get this working on the Zylonite320 as well.

And now to the problem. The expected behavior would be that if a power supply is attached to the device, it'd power up and U-Boot will come up. For some unknown reason, this doesn't happen on the Zylonite320. The only way I was able to get the Zylonite320 boot from NAND was to issue a "reset run" in the OpenOCD shell over JTAG. Then the board booted, no problem. I was slightly investigating this with a Marvell XDB and figured the NFC is maybe misconfigured in a way the NAND is detected as x16 instead of x8 by the BootROM. Though maybe there are just some switches that toggle the boot-up behaviour of the CPU.

Other
This month was quite rich in finishing conversions. Not only was the WM8750 conversion finished, but also the final removal of wm97xx_batt.h happened. The file was lingering in the kernel tree for about a year now, to be accurate ever since it was possible to pass platform data through the AC97 bus. So now the file is gone and all the platforms that used this file are now fixed.

In the end, I must not forget I got into a little fight with Russell King. We exchanged a few rough mails etc. Also, if I mention Pavel Machek was involved, I believe no further explanation is necessary. Actually, I was only teasing Russell a bit, but he probably took it personally.

I hope you enjoyed the reading, it was quite a lot of boring text as always.

Today's OpenPXA progress

2010-05-14T19:48:00.004+02:00

I got to hacking on OpenPXA today. This brought some noticable progress. For some time already, there was a bothersome issue where one had to prepare a NTIM and IPL binary for the PXA300/PXA310 and a special combined IPLNTIM for PXA320.

Knowing it's most probably no use trying to get NTIM working on PXA320, I used a horrible hack. Firstly, lets recapitulate the facts. The first important fact is, that the first four bytes of the NTIM contain minimal version of BootROM this image will run on. The second important fact is that the four bytes at offset 0xc contain a date when the NTIM was created and is ignored by the BootROM.

On PXA300 and PXA310 which have BootROM v3.xx, the version string is compared to the BootROM version and if it's lower, the NTIM header is used to further control the boot process. On PXA320 on the other side, the code at 0x0 is copied to SRAM and normally executed. So the trick with unified NTIM now seems simple. It has a problem though.

Firstly I thought placing a branch instruction at offset 0x0 which would just jump past the NTIM should do the trick. How mistaken I was. The branch instruction was encoded as 0xea000028, if converted to LE it is 0x280000ea, whereas the version string in LE is 0x00030102 for BootROM v3.12, so this can't possibly work. Though there is a solution.

Branch which jumps eight bytes forward is encoded as 0xea000000, in LE 0x000000ea, which is lower than the version string. With this trick, I used the date entry and inserted an instruction which branches right past the NTIM header. You probably noticed by now, that the branch jumps 8 bytes forward, but the date entry is at 0xc. This is no problem as the entry at 0x8 is the HMIT section offset, which is zero and zero means nop.

This change has one more advantage. The IPL is now stored in block 0 of NAND just past the NTIM. It was necessary to patch the linker command so it'd correctly adjust the location of built in variables. But the result now is, one more block is free and can contain U-Boot most likely and there's no need to explicitly choose which CPU will the NTIM run at. As of today, the CPU parameter is dropped and only file called iplntim.bin is generated, holding the contents of NAND block 0.

Besides this crucial change, I moved the stack setup into a self standing function which then calls the main function of the IPL. This allows the main function to have it's variables on the stack and correctly allocated.

Marvell, Voipac, U-Boot and insomnia

2010-05-13T16:31:00.000+02:00

Again the time has come to push out a summary of things that I worked on recently. Mostly, I worked on the Voipac Technologies a.s. hardware, but there are some great news from Marvell as well.

Voipac
In the last entry, I mentioned adding support for the Voipac PXA270 SBC. Most of the support for this device hit mainline and will be available in 2.6.35 probably. The rest will hopefully hit 2.6.36. That's not all, I estabilished cooperation with the corporation itself and they sent me a baseboard and a CPU card equipped with OneNAND memory. This made me busy for a few days until I figured how to properly prepare the OneNAND IPL that is in U-Boot.

Voipac also sent me their JTAG adapter, which I'm very grateful for as it helped me a lot. Support for this JTAG adapter as well as for the Voipac board with NOR flash hit mainline OpenOCD already. It's currently impossible to flash OneNAND directly from OpenOCD, but one can load U-Boot into SRAM using OpenOCD and execute it from there. Then one can simply reflash the board from that U-Boot.

I then hacked on the SparseMEM support for the board a little more. There was a bug in kernel which caused the kernel to crash in very early stages with SparseMEM enabled. The bug was caused by a recent patch that was applied to the tree. Though, Catalin proposed a fix a few days before I finished debugging it, the fix was pending until someone tests it. Giving my ACK for that, the fix was applied and I submitted a SparseMEM support patch. The SparseMEM support is still unapplied though.

Besides, the company told me they have a DMA capable driver for the ParallelATA disk attached to the board. I only used the pata-platform driver which was only PIO capable and giving about 3800 kB/s reads. This was a no-go. The company didn't send me the harddrive extension for that board, so I had to fix myself a hardware hack, which allowed me to connect a CDROM drive. But ATAPI has specific needs when it comes to DMA and I was unable to get the DMA working with CDROM drive. So I made another hardware hack, even worse this time and connected a PATA 2.5" harddrive. Hacking on this driver for a while resulted in a generic pata-pxa driver, which uses the PXA DMA controller and is capable of getting over 11084 kB/s reads, but only for harddrive. For CDROM the driver falls back to PIO, but it's unlikely anyone will connect a CDROM to this SBC.

Hacking on the Voipac platform was great because the hardware is very well documented and the design is very clean.

U-Boot
I prepared a few macros that drop the need for copying so many code between PXA2xx boards in their lowlevel_init.S files. Those macros allow easy GPIO configuration, SDRAM configuration, clock and interrupt configuration as well as wakeup procedure. When using these macros, the lowlevel_init.S file consist of about 6 lines. This is a great achivement in cleaning up the u-boot-pxa. The ZipitZ2 platform was converted to use these new macros and works well.

Besides these macros, I added support for some new platforms. Namely the Voipac PXA270 with OneNAND flash and a Toradex Colibri PXA270. All of this new stuff is available in the u-boot-pxa devel branch. The branches were also recently rebased to bring the newest code from mainline u-boot.

Marvell
Recently, a friend of mine in Marvell arranged it so I was able receive two Marvell Zylonite units, one with Marvell PXA320 CPU and one with Intel PXA300 (the CPU was apparently made in Intel factory and is possibly even a prototype, though I'm unsure). This will be a great help for the OpenPXA project and he deserves a big thanks.

Also, I was told that PXA320 does not support NTIM header because the CPU is old (and has BootROM v2.22), which means I don't have to RE the BootROM anymore probably and I'd better focus on implementing a single NTIM header for both PXA320 and PXA310/300 (BootROM v3.xx). This is very likely doable through some a little non-standard alternations to the NTIM header. Though it's also likely I'll still continue to RE the BootROM just for curiousity's sake. For example I found out that WTM registers are mapped at 0x43000000 (this is undocumented in PXA3xx manual).

Others
I got my hands on one more platform -- the smarthouse.cz SH-Dmaster. It's a platform based on Toradex Colibri PXA270 module, but uses it's own baseboard. The patch for this platform is pending and is uncertain to be applied as it started a discussion about splitting development platforms to hardware that's on the mainboard and hardware that's on the CPU card.

I must not forget one more thing, I added support for the Guillemot Jet Leader Force Feedback joystick into the iforce driver. I had the patch lying around from the times of 2.6.16 or so, but never got around to sending it. Now it's already applied in linux-input. As I didn't want to reboot my PC to test the driver, I debugged it on the Voipac board.

Conclusion
Well, it's getting pretty busy recently, but I'm happy with the direction things are taking. Also, most of the hardware I have available now works well.

Recent happening -- OpenPXA, U-Boot, Marvell, Voipac, Zipit,...

2010-04-14T19:46:00.005+02:00

Quite a lot happened in recent weeks. Now the time has come to sum this stuff up so expect quite long entry. I divided this entry into some subsections for the sake of readability.

Marvell and OpenPXA
The most important thing first. The OpenPXA project undercame quite big changes. The most significant one being OBM2, which I'll describe further. Besides this, the websites were updated and the u-boot patches were also updated to match the latest GIT HEAD.

As for the OBM, the original OpenPXA OBM turned out to be too less scalable and modular and it was also very hard adding new platforms. Besides understanding the assembly there was not for everyone. Also, this version of OBM didn't use stack and there were no function calls, it was a linear program and everything that looked like functions were macros. This made the work with this OBM even more complicated and basically made the possibility to extend the OBM in some way impossible.

To quench the need for a better OBM, an OBM2 was born. Written completely from scratch in the C language with little bits of inline assembly. Also, this new OBM2 has a very modular design and uses normal function calls which puts no more limitations on developers wanting to work on this. Besides this, new platforms can be easily added through an unified interface where the developer only has to fill in about three easy functions. Moreover, the OBM2 already carries a library of hardware drivers for the PXA3xx CPUs, like driver for UART and driver for NAND flash. Actually, the NAND flash driver is fundamental of course. But enough praise, even this OBM2 has it's draws. Let's take a better look at those now.

Before we take a look at the problems of OBM2, we better describe the boot procedure of a PXA3xx CPU. The CPU loads the first page of NAND into SRAM location 0x5c008000. In case there is a so called NTIM header, which is generated by a program called mkntim (included with the OBM2), the BootROM within the PXA3xx CPU copies the portions of memory according to the NTIM header. In the NTIM header, there is a configuration section called HMIT, a section describing the NTIM header called OBMI and a section with the OBM2 called BOOT. And the BOOT section is executed.

Now to the problem with OBM2. It's actually not really a problem with OBM2 but more with the PXA320 CPU BootROM. The BootROM in the PXA320 is older (v 2.22 in RTPXA320B2) than in the PXA310 I have available (v 3.33 in PXA310 A2). With the newer BootROM in PXA310, there is no problem with the NTIM header, it works fine, but with the PXA320 the NTIM header does not work at all. That's why I dumped the BootROM, started disassembling it and tracing the instruction flow. Not much luck yet though. But the fact the NTIM headers doesn't work on PXA320 doesn't render it unusable with OpenPXA OBM2. There is a way to boot the PXA320 CPU without an NTIM header by putting 8 zero bytes before the OBM2. Interestingly enough, the CPU drops the first two instructions, copies the rest to 0x5c014000 and executes it.

I introduced a variable CPU which determines which kind of image should be generated at compile time. Setting it to PXA320 generates file called 'iplntim.bin' which goes to 0x00 of NAND and is actually the OBM2 prefixed with those 8 zero bytes. Setting it to something else produces normal NTIM header and a OBM2 binary. In both cases, the compile process ends with a small help describing which file should be flashed where.

As for the hardware support on the OpenPXA OBM2 side, currently supported platforms are the Marvell Littleton PXA310 and the Toradex Colibri PXA320. Both of those platforms boot well with the OBM2.

U-Boot
I became the maintainer of U-Boot/PXA. This means fixes will hopefully flow in faster in this area. I'm looking forward to your patches and cooperation. There are a few fixes pending already. The GIT repository is here.

Some time ago, I wrote about a strange bug in U-Boot that caused printf() and NAND driver malfunction when VSPRINTF64 (simply 64bit support for printf()) was enabled. I hit this bug on my first PXA3xx platform, but was unable to debug it. This ended up with various weird workarounds which were in the OpenPXA "U-Boot patches" tree for some time. Just recently, I thought I'd be better if I took another look at the issue as those patches had side effects (like NAND was read-only etc.).

After a few hours of debugging a redeeming thought arrived. I took a look at the stack alignment, stupid me I didn't thought of this earlier. The LDRD and STRD instructions, which do a data movement between 64bit memory area and 2 following ARM registers need the memory area aligned to 8 bytes. Looking at the address of the variables, they were aligned to four bytes even with GCC attribute for variables __attribute__ ((aligned(8))). It turned out the aligned(8) does not mean it's aligned to 8 bytes from start of memory, but from the top of the stack. Therefore the final patch was simple, it was just a question of aligning the stack to 8 bytes.

Also, there was one more patch that caused problems to users on the PXA CPUs and not only the PXA3xx was affected. It was the PXAMCI driver for the MMC card. The first attempt to detect the card in most cases timed out. It was because the card had different delays for PXA27x than for PXA25x. Removing this shorter loops for PXA27x fixed this problem.

Voipac
I established cooperation with Voipac Technologies a.s.. This was actually started by a friend of mine who lent me their hardware and said it's a pretty interesting box. The software was too limited though, meaning the preinstalled u-boot only allowed TFTP boot, there were no patches for VPAC270 board in the mainline kernel etc.

So I prepared a patchset for the VPAC270 and pushed it mainline. The only patch remaining outside mainline is for the SparseMEM support on this board. This one needs to be properly reworked probably before merging. And this needs some further thought. The patches that made it in add pretty much all the functionality for the VPAC270 board.

Zipit Z2
I also prepared a patchset for the Aeronix Zipit Z2. The patchset made it into mainline, though it was a slow process because it spanned across multiple kernel trees. There were drivers for various peripherals, that is battery driver and ASoC audio driver.

As for the ASoC driver, Mark Brown pointed out the WM8750 codec still wasn't turned to the new API. I therefore converted it over and then pushed both the conversion patch and a vastly reworked Z2 ASoC audio driver.

Conclusion
And this is it. That's all. I guess I should update this place more often rather than creating such a huge pieces of text once in a few weeks.

ZipitZ2 U-Boot update

2010-04-05T03:19:00.003+02:00

I was recently asked by Magon if I could fix an u-boot for his Z2 that'd be able to be operated without a serial console. It took a little bit of investigation to figure out u-boot can run scripts from memory card. Though there still was a problem with the memory card.

The PXAMCI is known to be crappy. Though fixing this bug with the PXAMCI was simple. The problem was the mmc init command had to be called twice (or multiple times as some people reported) before the card was detected. It was just that the card was not fast enough to respond to commands so increasing the delays in the initialization routine fixed the problem.

Next was the scripting. I fixed a small conditional statement into the u-boot bootcmd variable which tries starting the MMC card and in case the card is there, starts a script called uboot.script from it. If the card is not present, it tries to start kernel from 0x60000.

The script for u-boot has to be compiled in a little special way. For that, there's a utility called mkimage. This utility takes input files, adds CRC and various other goodies and spits out an image that u-boot can use. To compile uboot.script, run the command like this (this is a one-liner):

mkimage -A arm -O u-boot -T script -C none -a 0 -e 0 -n uboot.script -d SOURCEFILE uboot.script

where SOURCEFILE is the file with the script and uboot.script is the result that goes onto the memory card. For example, my script that only boots the kernel looks like this:

if fatload mmc 0 0xa0000000 uImage ; then
bootm 0xa0000000 ;
fi

As for the updated u-boot, the patches and a binary are available here:

Compiling and flashing (start from pt. 5) instructions:

Apply all three patches in correct order (use git am)
make CROSS_COMPILE=arm-crosscc- clean mrproper
make CROSS_COMPILE=arm-crosscc- zipitz2_config
make CROSS_COMPILE=arm-crosscc- -j9
Flash u-boot.bin
to 0x00 and erase 0x40000 (for environment) in your flash. In old u-boot, run:
1. loady 0xa0000000 (here send the u-boot.bin over Ymodem)
2. protect off all
3. erase 0x00 +0x20000
4. erase 0x40000 +0x20000
5. cp.b 0xa0000000 0x0 0x1ea88
6. reset

OpenOCD: PXA3xx NAND flash driver

2009-12-13T05:37:00.002+01:00

Just a quick entry today. Recently, I was hacking on a PXA3xx NAND flash support for OpenOCD. It's finally ready, though it has a few limitations. The preliminary version is available in the OpenPXA GIT as always, though the patches are being pushed into mainline OpenOCD. The limitations mentioned before are that you can't erase multiple blocks as once, you have to do it one after another for now. Also, this driver for now works only for large block devices, but adding support for small block ones should be easy. And the driver is quite slow too, so it's probably only useful for flashing in the bootloader.

A quick howto on reflashing the bootloader using the NAND code in OpenOCD follows:

run OpenOCD with the following command: openocd -s tcl -f board/colibri_pxa320.cfg -f interface/jtagkey.cfg (for Colibri/PXA3xx board and Amontec JTAGkey)
connect to OpenOCD using telnet: telnet localhost 4444
Issue the following commands, one after another:
- reset halt
- nand probe 0
- nand erase 0 0x0 0x20000 ; nand erase 0x20000 0x20000 (erase first two blocks)
- nand write 0 bootloader.img 0x0
To read data from NAND, use: nand dump 0 dump.img 0x0 0x800 (0x0 is base address, 0x800 is amount of bytes)

Colibri/PXA320 meets OpenOCD, becomes free

2009-11-29T03:54:00.002+01:00

In the last blog entry, I mentioned getting a development kit. It's cool and all, but as the Colibri/PXA320 and other PXA3xx boards, it has one really bad flaw -- all of the flashing tools for PXA3xx are for certain proprietary OS only. Moreover this particular overly proprietary debugger/flasher I got with the board was so choosy about adapters it supported it really went on my nerves badly especially since the adapter I got was not working properly and I couldn't use any other of those I had. So there was no way to reflash PXA3xx boards from Linux ... until recently.

I took a look at OpenOCD project, which is a Free Software JTAG Debugger, and figured it'd be actually quite simple to update it to support PXA3xx by looking into the PXA3xx documentation and comparing it with PXA2xx one. Apparently, the only differences there were the Instruction Length (which was 7 for PXA2xx and 11 for PXA3xx) and - the more weird change - that PXA3xx has the instruction codes shifted by 4 to the left in some cases. After fixing these, I was able to connect to the CPU using my FTDI FT2232 based fake-amontec JTAG cable and operate with it normally. The patches are available in the OpenPXA GIT.

Maybe someone would like to see a howto for loading new software into the board using the OpenOCD, so here it is. Firstly, download the OpenOCD patches from OpenPXA GIT and do:

git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd # download OpenOCD sources
cd openocd # enter the OpenOCD directory
apply OpenPXA patches for OpenOCD
./bootstrap # prepare files necessary for OpenOCD compilation
./configure --enable-maintainer-mode --enable-ft2232_libftdi # the first option is necessary (dunno why), the other one enables support for the ft2232-based cables
make # compiles OpenOCD
./src/openocd -s tcl -f board/colibri_pxa320.cfg -f interface/jtagkey.cfg # executes the OpenOCD debugger; tells it to search for configuration scripts in directory tcl, to use colibri_pxa320.cfg board support file and jtagkey.cfg cable support file
telnet localhost 4444 # connect to the OpenOCD

Once connected using the telnet, we can start issuing commands. We'll want to load a program to a particular location in SRAM:

reset halt # reset the CPU and stop executing instructions
fast_load_image /path/to/file 0x5c080000 bin # prepare to load binary file to address 0x5c080000 (NOTE: 0x5c080000 is valid SRAM only for PXA320, for other CPUs use 0x5c000000 or something)
fast_load # actually upload the file
resume 0x5c080000 # continue instruction execution at address 0x5c080000 (about the address used, see previous note)

And now that you can load a file into SRAM and execute it, you can use this technique to load a bootloader there and control it over UART or something. Once you succeed in running the bootloader, you can do whatever you want with the hardware (for example flash the bootloader into NAND).

Colibri/PXA320 Ethernet, OpenPXA IPL v2.0 and UCB1400

2009-11-10T19:59:00.003+01:00

Just a quick summary to keep possibly interested people in the loop today. I got the ethernet working on the Colibri/PXA320 board in u-boot. The problem was with the way the ax88796 driver was accessing the registers of the ethernet chip. It was actually accessing them in some weird 16bit mode, which caused two registers to be read at one time and the contents of the upper one was sometimes lost, caused malfunction of the driver. So I supplied my own access functions the same way as some Renesas board did and that eventually fixed the issues. Now the ethernet controller is working happily.

I recently started working on making the OpenPXA IPL more generic in preparation for supporting more devices. As I explained in an earlier post, the NAND is configured to some sane defaults and some of it's characteristics are determined by the BootROM already when the IPL is being executed. So I make use of this information and don't reconfigure the NAND, but just reset the chip and do READ0 and READYREAD commands. Also, I'm working on cleaning up the code and fixing some of it's possible issues.

Moreover, I plan to add debugging functionality into the IPL, which would probably allow the user to load some code into SRAM through serial console (XMODEM possibly or something) instead of NAND as it's now. Such thing will eventually allow the user to restore pretty much any system without NAND page number 0 being wiped out.

And the last thing today is about the UCB1400. I sent a patch upstream, that allows the UCB1400 to accept touchscreen IRQ GPIO through platform data. I also explained the reason for this in the previous post so read it there.

Recent happening - PXA3xx, u-boot etc.

2009-11-07T19:22:00.004+01:00

I just want to write some sum of what happened since last time I posted something here as stuff actually pretty piled up and I'm overly busy now. Expect somehow longer entry as quite a bit happened actually.

All this machinery started back in late September, when I got a Toradex Colibri carrier board with a PXA320 CPU card from INCOME s.r.o. and was instructed to prepare a decent bootloader for it and possibly make Linux kernel run smoothly on it. Sure, sounds easy, it's a Marvell CPU afterall and U-Boot already has some support for a few boards with PXA3xx too. Moreover, it's not too different from PXA2xx series, right? Yes sure, it's not, but there are a few changes.

I was suffering for some time, trying to make use of the preinstalled EBOOT bootloader to load Linux and even wrote some wrapper so it loads the kernel correctly at least, but I gave up on this idea as it turned out EBOOT is a worthless piece of crap. Not to mention, EBOOT is a proprietary goo. So I figured I need to replace it. U-Boot was the only choice here of course, but here came the first difference between PXA2xx and PXA3xx. The PXA3xx CPU does not need a NOR flash to boot from, it can boot directly from the NAND flash. Actually, there is something called BootROM buried in the CPU as I figured out later, but it's not possible to read it's contents without electron microscopy I think. Well this BootROM apparently configures the NAND properly, copies it's first sector to SRAM and executes it. But here popped in another problem, I managed to overwrite the first sector with not working code rendering the board unusable. Sadly, there is no utility for Linux that can flash the PXA3xx board so I had to use their proprietary one to reflash the board.

After numerous reflashes and testing, digging through the bootloader images Toradex released publicly and analyzing them, I managed to put together an open source GPLed IPL (initial program loader) that can be stored in the first sector of NAND with a sole purpose of loading further sectors from NAND, copying them to SRAM and then jumping to the beginning of these copied data. For this IPL, I established the OpenPXA project hosted on SourceForge as the plan is to extend it's support to other boards as you'll figure out later. Well, the data I mentioned a while ago that are being copied and executed are actually U-Boot. Maybe you are asking -- why is it so complicated. That's because the BootROM can apparently load only the first sector from NAND, the rest has to be done by the IPL, that's how the chip is.

Back to the U-Boot. There was one more obstacle I had to fight, it was the RAM. The PXA3xx supports DDR DRAM besides some other types of DRAM and the hardware I have has the DDR DRAM. That's why I had to write the initialization routine, which soon turned out to be one hell of a hard work to be done properly. As a side story, I made a decision to stick most of the hardware initialization into the U-Boot and keep the IPL size to the minimum. That's also why the IPL is loading the U-Boot into SRAM, to avoid initializing the DRAM controller.

After all this suffering, the current status of U-Boot for the Colibri/PXA320 is such that it's usable to boot Linux from MMC or NAND, the CPU is properly configured, DRAM works just fine. There are still a few problems though. The most noticable one is that the NAND can't be written from U-Boot, but I suspect that's because of a GCC bug that produces wrong code causing the U-Boot to hang. The other problem is that the ethernet adapter doesn't work in U-Boot, but that's being worked on now. It actually works from Linux so that's not much of a problem. Just as a side note, I sometimes update the patches for U-Boot in the OpenPXA git so if you are interested, you can find them there.

Mentioning GCC bugs, let me warn you that you should not even try compiling U-Boot with >= GCC4.3. It produces weird code and makes the U-Boot not work properly, like unexpectedly hang and such. I tried fixing some of those issues in U-Boot, but there are still many so stick with GCC4.2 for the time being. The exceptionally nasty one was with 64bit division. In the end, I ripped the code for 64bit division from Linux kernel and stick it into U-Boot, but that's more like a workaround.

Before I disclose my future plans with U-Boot on PXA3xx, I first need to explain why I'm so into it probably. That's because somewhere along the process of fixing U-Boot, I made some negotiations with a certain corporation that makes CPUs and such (I'm not sure if I can disclose anything more here, sorry) and was supplied some hardware to hack on. So that's why I'm sticking very closely to this and why I'm investing such a load of my time to this low-level stuff. Also I have to say, the people I communicated with so far are awesome and I like it the way it is.

So to the plans I have with the IPL and U-Boot. Firstly, I'll have to hack on the IPL a bit to make it support PXA310, Monahans LV CPU. Then there was an idea to use the values from BootROM to auto-configure the NAND in the IPL and possibly even later in U-Boot and Linux, which is awesome as the NAND will be technically auto-detected and we won't have to care for it much. Next of course will be fixing of the ethernet on the Colibri/PXA320, ok, maybe this will be first as I'm getting close here. What I'd also like to have working is the USB host in U-Boot so the thing can also boot from an USB thumb-drive or something.

Besides these plans with IPL and U-Boot, I have an idea that there needs to be an improvement made in the Linux kernel concerning the UCB1400 chip driver which is integrated on the Colibri/PXA320 module. This improvement would make use of the recently merged possibility of passing platform data through the AC97 bus. Let me explain properly. I recently got an email from someone that the pseudo-auto-detection routine which somehow should detect the proper touchscreen IRQ GPIO for UCB1400 doesn't work on his hardware. Well that sucks and it was unavoidable anyway I think. So this patch would pertain to removal of this routine altogether and modifying all the platforms that use the UCB1400 driver to supply the touchscreen IRQ GPIO as AC97 bus platform data. There are just two or three such platforms so it's not much of a problem anyway.

Well this is about it, life was pretty busy recently and the article actually grew quite long, sorry to hold you here for so long. I hope you enjoyed your stay at least.

OmniVision OV9640 hacking - part IV

2009-08-22T05:35:00.002+02:00

I recently had some talk with Guennadi Liakhovetski (aka. the soc-camera maintainer and v4l2 guru) about this driver. He pointed out that there will certainly be a large amount of changes going into 2.6.32 affecting the soc-camera API and advised me to prepare the driver for those. Besides that, we found out there are certain differences between OV9640 and OV9650, so support for the later one was dropped (it was never tested anyway). For that model there's another driver scheduled for merge written by Stefan Herbrechtsmeier. Subsequent changes are mostly because of the API change. There are also some minor cleanups and changes in logic of the driver.

The patch got split into three separate patches, but prior to applying those, you need to apply a patchset available here (LINK) on top of linux-next (in case you run into merge issues, git reset --hard to commit hash in 0000-base) . The OV9640 patches are then available here:

Patch adding support for RGB555X and RGB565X formats into pxa-camera (LINK)
OV9640 support adding patch (LINK)
Patch adding support for the camera into PalmZ72 platform file (LINK)

Marvell Libertas CF8305 partly supported

2009-08-21T04:48:00.002+02:00

So after my own private hackathon I held for last two weeks and where OpenBSD gained support for Palm hardware to some extent, I felt the urge to fix some hardware to work with Linux. And there was a perfect candidate for that, the WiFi card in Palm LifeDrive. That damn little piece of silicon bothered me for more than two years already, but just a few hours ago, I cracked the nut there at least.

The Marvell Libertas CF8305 is actually a very ancient piece of silicon and runs Marvell proprietary firmware version 3.0 . Being this old, the card has various issues which later models (like CF8381 and CF8385) do not have. The first difference from the later models is that this card runs only an one-stage firmware, but that's luckily loaded the same way as a helper firmware on the later models. The second-stage firmware isn't loaded at all on this card.

Next issue on the list happens when accessing registers of the card. It seems the card can not do an unaligned accesses to it's registers which means the driver has to access only odd addresses. Accesses to even addresses doesn't work - in case of reading the returned value is the one of the nearest lower odd address. But luckily, there is only one such unaligned access happening in the whole if_cs.c part of the driver and that is when reading the SCRATCH_PAD register which has address 0x3F . And this can be easily worked around by doing a 16bit read of address 0x3E and bit-shifting the result by 8 to the right.

This was the easy part, but the horrible bugs are still waiting. Apparently, with the first problem fixed, the firmware can be loaded and the card seem to respond to some commands, so far so good. What the card really does not like though is a command with code 0x0006 aka. CMD_802_11_SCAN. Once that command is sent to the card, the card plain hangs and all you can do is remove the driver, eject the card and reinsert it (there's no hardware eject so use 'pccardctl eject' and 'pccardctl insert'). The real problem here is, once the card is brought up (for instance by 'ifconfig eth0 up', the driver itself issues the SCAN command - or at least that's what it does when configured into Ad-Hoc mode. This can be worked around by editing 'drivers/net/wireless/libertas/scan.c' and commenting out 'ret = __lbs_cmd(priv, CMD_802_11_SCAN...);' at around line 333.

With the hack above, it's possible at least for the card to serve as a node in an Ad-Hoc network. But that's not the last limitation it has. It's impossible for now to reconfigure the card once brought up. Since in case you do that, the command 0x002b aka. CMD_802_11_AD_HOC_START will fail and again hanging the whole card.

Other than that, if the card is configured by 'iwconfig' and then brought up by 'ifconfig', it seems to be possible to establish at least the Ad-Hoc network. Well there are still some very hard limitations, but at least there are some signs of life from the card and it can't get any worse now.

Here's the patch for the if_cs.c file: LINK
And here's a picture of a working WiFi on Palm LifeDrive:

OmniVision OV9640 hacking - part ]|[

2009-08-07T23:03:00.002+02:00

I spent the last few days tracking down some really weird issues with the OV9640 driver. The major problem was a bright stripe, exactly 90px from the top of the photo. But it only occurred on photos in 640x480 and lower resolution. Also, there were other problems like brightness too dim in certain resolutions, swapped colors, i2c glitches etc. Interestingly enough, I haven't met such issues at the 1280x960 resolution.

The bright stripe was in the end caused by the camera not being ready right after reconfiguration. A little delay pretty much solved it, but it might need some further investigation still. Tinkering some more with the chips' registers, I also managed to eliminate most of the color-swap related problem as well as improve overall image quality.

But then there was that i2c problem. It was pretty hard to even notice it since writing the chip registers worked. The problem popped up when I tried reading the registers back though. It returned total nonsense. Further investigation came up with the chip not being able to communicate in SMBUS-mode so I switched to i2c-mode and it worked like a charm.

Anyway, with the problems listed above solved, the driver reached something that can be called a beta-state. It can now do capture in both RGB565X and VYUY (though it could be better in the RGB565X, the VYUY is fine). Sadly, the RGB555X is still not there, but I wonder if anyone will actually be missing it since there are those two higher-quality formats.

The patch is available here. Actually, I upload a new version of the patch from time to time and the old version of the patch gets overwritten so there might pop up a new version of the driver between blog entries announcing it. Though the changes are often very minor.

OmniVision OV9640 hacking - part ][

2009-08-03T11:53:00.002+02:00

So once the i2c problem was partly solved, I started putting together a driver for the camera chip. It's in an alpha-state currently, which means some things are still missing/doesn't work/are untested etc., but it can already make photos! Some examples follow.

This is a RGB565 photo of a monoscope.

This is a VYUY photo of a monoscope.

Here comes a list of the problems so far:

The image quality is still a little bad in case of VYUY, more bad in case of RGB565 and it doesn't work for RGB555 yet. This needs some further work.
Some of the advanced features of the OV96xx are missing altogether.

If you still haven't lost your interest, here are the patches:

OV96xx support for Linux 2.6.31-rc (includes PalmZ72 platform changes)
VYUY and RGB565X support for fswebcam

OmniVision OV9640 hacking

2009-08-01T10:15:00.003+02:00

I've been hacking on this camera module in last three days or so. Whew, it gave me quite a pain especially because of the SCCB interface (which is renamed i2c), but I finally defeated it. This chip can be found for example in Palm Zire72. I made some hardware research to figure out what GPIOs drive it. the results are:

GPIO56 - PWDN
GPIO57 - RESET
GPIO91 - DVDD

Ok, with this knowledge, it's simple to setup PXA QCI and read some data from the chip. With a little effort I was able to make a photo using the fswebcam tool. Though the colours were totally off and messed up because the camera chip wasn't configured at all. And here came the main problem.

The problem was, when I tried to communicate with the chip using i2c-pxa driver (the native PXA I2C driver), it didn't work. The i2c driver complained about timeouts etc. Just a while ago, I got quite crazy idea to give the i2c-gpio driver (this one toggles GPIOs to emulate i2c behaviour) a go. To my surprise, it worked. I was able to read registers of the chip and all. So this is it, the whole solution was to use the i2c-gpio driver instead of i2c-pxa.

But here comes another question - why ... why does it work with i2c-gpio and doesn't with i2c-pxa ? I think the problem might be with I2C and QCI clocks supplied to the module (speed, sychro, ... who knows). But interestingly enough, PalmOS seems to use the PXA I2C. So this makes the whole situation even more confusing. So in the end, this will need some further investigation, but at least the camera is working somehow and I can start writing a proper driver for it.

Summary of happening in last two weeks or so

2009-07-26T23:00:00.005+02:00

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

2009-07-17T20:21:00.002+02:00

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

2009-07-17T18:02:00.005+02:00

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

2009-07-17T17:48:00.002+02:00

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

2009-07-11T00:17:00.003+02:00

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

2009-07-09T06:04:00.004+02:00

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

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

2009-07-07T01:08:00.006+02:00

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 ]|[

2009-07-03T02:19:00.003+02:00

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 ][

2009-07-02T21:50:00.002+02:00

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

2009-07-02T21:35:00.003+02:00

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

2009-07-02T21:32:00.003+02:00

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

Palm Wireless Keyboard

2007-09-23T17:33:00.000+02:00

I recently borrowed Palm Wireless Keyboard from |miska| to write a driver for it. First of all, it's not a good idea to polute kernel sources with more and more keyboard driver modules. Moreover when there already is a nice and clean solution called kbdd for handling all those serial/bluetooth/irda keyboards too, so I decided to use it. The following patch adds palmwk support to kbdd.

Patch: http://marex.hackndev.com/01-add-palmwk.patch

To use it just compile kernel with CONFIG_SERIAL_PXA_IR=y and run "kbdd -p /dev/ttyS2 -t palmwk". If you configure kbdd using kbdd.conf, it's even easier since at least in angstrom it's started automagically every time you boot and you wont have to type that command at all. There are just minor changes in the original palmwk keymap, that is "Green FN" + Numbers works as Fx keys (convenient eg. in mc) instead of special characters.

Opie-borderapplet 0.2

2007-09-02T17:50:00.000+02:00

I added PalmTX support to borderapplet, you can download it here:
http://marex.hackndev.com/borderapplet-0.2.tar.bz2
SHA1: 6bf2ec837b49f6d07e770b01f9640f2b7bc739ee

For further information about borderapplet, refer to this article:
http://marex-hnd.blogspot.com/2007/07/lifedrive-borderapplet-for-opie.html

PalmTX: PCMCIA

2007-08-14T15:18:00.000+02:00

That's one small hack for Marex, one giant leap for PalmTX port ;-) . Yup, I finally finished the PCMCIA driver for Palm T|X. Now the WiFi card is detectable by pccardctl and friends. See following results ...

root@palmtx:~$ pccardctl info
PRODID_1="SyChip"
PRODID_2="Cheetah6064 802 11b Module"
PRODID_3="WLAN6100"
PRODID_4="01"
MANFID=02db,6064
FUNCID=6

root@palmtx:~$ pccardctl ident
Socket 0:
product info: "SyChip", "Cheetah6064 802 11b Module", "WLAN6100", "01"
manfid: 0x02db, 0x6064
function: 6 (network)

root@palmtx:~$ pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) [unbound]

Opie: CPUFreq applet

2007-07-30T00:02:00.000+02:00

I put together one more applet today. This time it's CPUFreq control applet. All it does is that it allows you to change CPU speed from GUI. Currently supported CPUs are PXA25x/26x and PXA27x.

Sources: http://marex.hackndev.com/cpufreqapplet.tar.bz2
SHA1: http://marex.hackndev.com/cpufreqapplet.tar.bz2.sha1

And of course screenshot. In the menu header you can see current CPU speed. To select different speed, use menu items below.

LifeDrive: BorderApplet for Opie

2007-07-29T15:26:00.000+02:00

Since I found out two GPIOs that control LCD border power and put together small driver to turn on/off the border, there became need for GUI to control this driver. So I hacked together simple applet for Opie to turn the border on/off.

Sources: http://marex.hackndev.com/borderapplet.tar.bz2
SHA1: http://marex.hackndev.com/borderapplet.tar.bz2.sha1

The screenshot is slightly edited in GIMP, but its enough to see how it looks I think. BorderApplet is that changing blue thing in applet dock. You just tap on it to enable/disable border, thats all.

Today's Konqueror/Embedded hacking ][

2007-07-20T18:56:00.000+02:00

So in the end, Konqueror/Embedded seems to be fairy stable and usable. Font problem was just that my fonts were taken from qt/e3 and I needed those from qt/e2. Even javascript now works and konqueror embedded even compiles with RTTI ... time to celebrate ;-) I will make someone merge this in OE right after I make some fine tuning. Btw. this konqueror uses KHTML 3.5.7 ;-)

Today's Konqueror/Embedded hacking

2007-07-20T07:45:00.000+02:00

Being without a webbrowser is pretty inconvenient on mobile device, thats for sure. So I decided to take a look at Konqueror/Embedded once more. I grabbed new sources from Basyskom and started hacking on them. I configured it so that everything is enabled and only disabled javascript stuff, ported Paul Eggleton's Konq/E 2007 patch (available here) on it, added bunch of mine patches, added a few horrible hacks and voila. See the screenshots. It is being worked on so dont worry about those distorted fonts.

LCCRman

2007-07-13T21:10:00.000+02:00

I recently noticed that some of our devices still use static LCCR0 and LCCR3 values in device files. This is not quite correct so I put together really stupid and bloated tool called LCCRman. You just give it the LCCR0 and LCCR3 values and it returns the correct .lccr0 and .lccr3 section of pxa_mach_info structure.

Download here:
http://builds.hackndev.com/builds/Marex/LCCRman-0.1.tar.bz2
http://builds.hackndev.com/builds/Marex/LCCRman-0.1.tar.bz2.sha1

Cpufreq

2007-07-13T01:07:00.000+02:00

I just slightly diverged from my holiday hacking plan. Since some people were asking me about frequency scaling on pxa27x palms I took a look at it. First attempt - LCD got "milky". I continued in experiments and in the end I obviously killed my device :) Disassembling and repluging the battery fixed it of course. I was experimenting further on ... now with device taken apart... and in the end I managed to make cpufreq working without the milky display effect. It is still sort of weird hack, but it is fine for the time being. So enjoy the frequency scaling. Cool about it is that you can eg. play mp3s in xmms-embedded and have cpu running at 1/4 of working speed (104MHz) and it works perfectly well. You can also disable LCD backlight and this is what I call power conservation ;-) I also tried to overclock my device - Palm LifeDrive with 416MHz PXA270-C0 - to 520MHz ... this seemed to work so I moved further - 624MHz ... the device lasted alive for about 5 seconds and then freezed, but the reset button worked. This overclocking stability differs from chip to chip though so it may work for you as well as it doesnt have to work for me.

Hello world!

2007-06-27T01:35:00.000+02:00

Hi, I started this blog to let others keep track of my research done on embedded devices and porting linux to them. The ToDo chunk for my holiday (20070601-20070831) follows:

1) Full opie support for palm/pxa and palm/omap devices in mainstream - DONE
All stuff was merged to opie cvs, there are also some nice pictures of various palm models upstream. I also sent a patch that fixes device/model detection. That patch was prepared in cooperation with Paul -bluelightning- Eggleton, since it turned out to be deeper problem. The devices in libopie had to be renumerated etc. Nevertheless, it will all be in Opie 1.2.3
2) WiFi support for palmld - W.I.P.
Thanks to Holger Schurig's efforts, there is now a driver for 88W8385 WiFi chipset. It is not the same as in palmld, but it is quite similar. We have 88W8305 which is much older. This doesnt matter though, it can be also handled by that driver (with some modifications). The currect status is I can communicate with the card, load firmware and get the MAC address out of it. I still cant work with the wireless part though, but this will probably be just a matter of implementing some stuff since the card is so old.
3) WiFi support for palmtx - ToDo
The chip is similar as in palmld, but newer, refer to point [2]
4) USB2 support for palmld - ToDo
I began doing research some time ago on this stuff and the result was I found out the wiring ... well ... most of it. The currect status is that I know where that chip has power and reset GPIOs, so I can turn it on and off and I also know where it has it's registers mmaped. I also managed to write testing driver that makes the chip enumerate with usb bus, but it is more of an example and proof that it somehow works.
5) Angstrom/iWMMXt - W.I.P.
Try compiling angstrom with iwmmxt optimalizations. This will be harder nut, since qemu has still some problems with running iwmmxt compiled localedef from glibc and so I cant generate binary locales. After that is fixed, I think it will be all ok. I believe that iwmmxt will give the device some speedboost. Moreover opie2 and mplayer can use it.
6) Update PalmZ71 and PalmTT - ToDo
Since last release for those two devices was half year ago and the code in omap KT is getting stinky, I think I should update those. Also there are good news for palmtt/palmtt2 because Paul Sokolovsky bought palmtt2 and he will probably work on it. This may as well result in much better mmc driver and faster running linux port for palmtt/palmtt2.
7) Release bootpacks for devices I have - ToDo
This really needs to be done, but it depends on all previous points.
8) Support for BCM2033 (PalmTT/T2) - ToDo
This would be handy afterall. Since there is support for BCM2035 and I know how to get both firmwares for this chip from palmos resource file, it may be fun to hack on this.