I'm using an Overo FE on a chestnut board.  The stock install (in NAND) uses linux kernel 2.6.32, and the touch screen appears to be work correctly.
 
I pulled the latest overo branch of org.openembedded.dev and used bitbake with a stripped down console image recipe to make a custom load.  This new load uses linux kernel 2.6.36.  The touchscreen appears to have very poor resolution in that as I move my finger across the screen the cursor will jump 5-10mm at a time, as if there was a very coarse grid of usable points.
 
To debug, I used:
 
  cat /dev/input/touchscreen0 | xxd | grep "0300 0000"
 
to examine the raw X-coordinate data.  With the 2.6.32 kernel, the X values appear to be 12-bit little endian data.  For example as I dragged my finger from left to right:
 
 
        |<--- Time stamp -->|Type|Code|<-Value->|
00009a0: 436c 454b b210 0400 0300 0000 f600 0000  ClEK............
00009d0: 436c 454b 5827 0400 0300 0000 f400 0000  ClEKX'..........
0000a10: 436c 454b 473d 0400 0300 0000 f800 0000  ClEKG=..........
0000a50: 436c 454b 7453 0400 0300 0000 fa00 0000  ClEKtS..........
0000a90: 436c 454b fc69 0400 0300 0000 0201 0000  ClEK.i..........
0000ad0: 436c 454b 2880 0400 0300 0000 0501 0000  ClEK(...........
0000af0: 436c 454b da95 0400 0300 0000 0601 0000  ClEK............
0000b30: 436c 454b 38ad 0400 0300 0000 1401 0000  ClEK8...........
0000b70: 436c 454b 58c4 0400 0300 0000 1301 0000  ClEKX...........
0000ba0: 436c 454b 47da 0400 0300 0000 1d01 0000  ClEKG...........
0000be0: 436c 454b 92f0 0400 0300 0000 2201 0000  ClEK........"...
0000c20: 436c 454b 7507 0500 0300 0000 2e01 0000  ClEKu...........
0000c60: 436c 454b df1d 0500 0300 0000 3b01 0000  ClEK........;...
0000ca0: 436c 454b 1e35 0500 0300 0000 4101 0000  ClEK.5......A...
0000ce0: 436c 454b 6a62 0500 0300 0000 4e01 0000  ClEKjb......N...
0000d20: 436c 454b 9678 0500 0300 0000 5501 0000  ClEK.x......U...
0000d60: 436c 454b a48e 0500 0300 0000 5b01 0000  ClEK........[...
0000da0: 436c 454b 2ca5 0500 0300 0000 5c01 0000  ClEK,.......\...
0000de0: 436c 454b 95bb 0500 0300 0000 6501 0000  ClEK........e...
0000e50: 436c 454b cfe7 0500 0300 0000 6901 0000  ClEK........i...
Where Type=0300 indicates an "Absolute event", and Code=0000 indicates "Absolute X" axes.  If we read the value field as a little-endian value, we see that it (mostly) increases in value from 0x00f6 to 0x0169.  Dragging my finger all the way across the screen yields a range of 0x00da-0x0ea2.
 
When I run the same test with the 2.6.26 kernel, I get results similar the following:
 
00001b0: f46a 454b 3028 0400 0300 0000 0010 0000  .jEK0(..........
00001d0: f46a 454b 1f3e 0400 0300 0000 0110 0000  .jEK.>..........
00001f0: f46a 454b 0e54 0400 0300 0000 0111 0000  .jEK.T..........
0000240: f46a 454b ddf7 0a00 0300 0000 0212 0000  .jEK............
0000270: f56a 454b 6827 0100 0300 0000 0313 0000  .jEKh'..........
0000360: f56a 454b daee 0500 0300 0000 0414 0000  .jEK............
00004f0: f56a 454b 9adf 0900 0300 0000 0515 0000  .jEK............
00005e0: f56a 454b e15f 0e00 0300 0000 0616 0000  .jEK._..........
0000610: f66a 454b a642 0200 0300 0000 0716 0000  .jEK.B..........
0000630: f66a 454b 9558 0200 0300 0000 0616 0000  .jEK.X..........
0000650: f66a 454b 449a 0200 0300 0000 0717 0000  .jEKD...........
0000780: f66a 454b 555b 0600 0300 0000 0818 0000  .jEKU[..........
00007b0: f66a 454b e69c 0600 0300 0000 0817 0000  .jEK............
00007e0: f66a 454b b6b2 0600 0300 0000 0818 0000  .jEK............
0000810: f66a 454b 87c8 0600 0300 0000 0817 0000  .jEK............
0000840: f66a 454b 4cdf 0600 0300 0000 0818 0000  .jEKL...........
0000910: f66a 454b cdca 0a00 0300 0000 0918 0000  .jEK............
0000930: f66a 454b 42e0 0a00 0300 0000 0818 0000  .jEKB...........
0000950: f66a 454b 31f6 0a00 0300 0000 0918 0000  .jEK1...........
0000970: f66a 454b 3f0c 0b00 0300 0000 0919 0000  .jEK?...........
0000a40: f66a 454b c5e2 0e00 0300 0000 0a1a 0000  .jEK............
0000a70: f76a 454b f9e1 0300 0300 0000 0b1b 0000  .jEK............
                                      |<-Value->|
These values look suspiciously big-endian.  Has anyone else noticed this, and more importantly, has anyone fixed the problem?
 
Patrick