Eee Note kernel hacking

[RomaVis]

Not exactly..
On the photo http://img17.imageshack.us/img17/7243/45650128.jpg you can see white ribbon cable connecting main board and sensor board, which is underneath (located between LCD and main board). I'm looking for the sensor board photos.

[Jamie-B]

I've no idea what I'm looking at, but maybe this the sensor board? Sorry again if not.

http://ubuntuone.com/5J9yyw3TY15lWgSl1FBw5s

Resolution is too low to read anything off it, but if it is the right image, we could contact mp035 for a higher quality version of it.

[pbarrette]

Hi RomaVis,

I suspect what you are looking for is this:
http://laoyaoba.com/ss6/html/49/n-174049.html

It suggests that the IC marking is:
LDS6128NQGI

pb

[RomaVis]

Wow! Thanks for the excellent information

However, as i've written in the "Eee Note, the peek within", i've already disassembled it and found that the IC is LDS6128.

Also, i've written to IDT support and they gave me some documentation on this IC..
So, it's time to write a driver (with documentation available it is relatively clear ).

I'll try to do that when i have some free time... The university takes away all the time

[Jamie-B]

Looking forward to any time you get to make improvements, RomaVis you know an incredible amount about this kind of stuff; could I ask what degree you're studying, if that's the source of your relevant knowledge?

[RomaVis]

Hi, guys!

I've got some free time now and just returned to EeeNote kernel hacking.
There IS some progress
-I've moved to the 3.4.2 kernel. It was easy and 3.4.2 fixed some issues I noticed in 3.1.6

-USB client fixed now and works almost flawlessly. It correctly handles cable plug/unplug, system suspends, drives D+ pullup in correct way.
It is possible to enable HOST, but i hadn't tried that yet (and, perhaps, EeeNote can't supply +5V on USB bus in host mode, so external power supply reqired).

-Suspend to mem (S2D3C4, Sleep) and Standby (S0D2C2) power modes work as expected now. I think it was bug in the mainline kernel (it expected that DDR controller MMIO was mapped to the certain virtual address on resume, however, no such mapping was made anywhere), but i've made a workaround (used custom map_io proc in machine description, which maps DDR controller MMIO at correct addresses).
At the moment, wakeup events are: USB cable plug/unplug, power button pressing, debug UART RX pin activity (it is convenient to wake it up by pressing button on my keyboard )

-Finally, system poweroff ("poweroff" / "shutdown -P now") is fixed. I wrote small pm_power_off proc using inline assembly, which just pushes PXA into S3D4C4 mode (DEEPSLEEP, or, in fact, poweroff). Despite it's a bit dirty way, it seems to work good

-WiFi card powerup/powerdown seems to work OK in 3.4.2.
However, I had to patch stock "pxamci" driver to enable MMC runtime PM, which drives WLAN card reset pin..
And it even correctly reacts to the "ifconfig down" & "ifconfig up".

-Also, there is some progress with LDS61xx sensor keyboard. I've written a piece of driver code, which already configures LDS6128, handles interrupts, and prints nice messages like "lds61xx: touched:: 10 13" to the console.
No manual LED control (LED underneath power button is controlled via LDS6128, as i expected), no runtime settings adjustment (thresholds / delays / and so on) and no input subsystem integration yet

Sensor keys work nice, except for the second functional button (button just above the "Home" button). Its center of sensitivity is misaligned a bit (physical defect), so it is common to accidentally press "Home" and "F2" together. Threshold adjustment don't help with this issue, so, I think the button can be disabled in some cases for convenience...


The result of all that work is a small patch
snippet
Patch can be applied directly to the stock (kernel.org) 3.4.2 kernel. If you are interested, i can upload sample .config file too.

Despite some process in getting things working, the kernel can't be used for everyday work (no sound, no sensor keyboard, no touchscreen). So, at the moment, you probably is NOT interested in installing it onto your devices..

[Micha]

Great work, RomaVis! Keep it up; I'm sure something terrific will pop up at one point :-) Plus, you seem to have lots of fun doing that, good for you! As I recall, people were interested in having WPA-EAP support for the device, maybe your work can help in that.

[RomaVis]

As for WPA-EAP... If our Libertas Wi-Fi chip supports it, or maybe encryption is done in software, it should work OK, as with any other linux-based system. Perhaps, it should

Today two new things can be noticed: i've almost complete with sound support, and also i've somewhat polished MMC driver, which gave significant MMC/SD speedup and lowered CPU load from the driver side..

Sound support required developing (however, a part was ported from original ASUS kernel) ALC5611 codec driver for ALSA SoC and writing short machine-specific ASoC driver. Both tasks are completed by 90%.. Today, EeeNote plays mp3s via alsaplayer both to headphones and speaker (or one of them), and all control is done via "standard" alsamixer. Jack insertion also works.
The bad thing is that there are around 25-30 different controls in alsamixer.. And most of them are useless, because many of ALC5611 features are unused in EeeNote. And as I understand, this is ASoC flaw, so nothing can be done there. Just hide unused controls(not in alsamixer) and all is OK

As for MMC, most of overhead and CPU load was introduced by a lot of mmc_cmd processing. Each mmc_request carried at most only 4K of data. Now it can process a lot of DMA segments, each 8191 bytes max, per one request.
So, with the Class 4 SHDC cards (4GB) it showed approx. 5 MB/sec write speed, and 6.5 MB/sec read on one card, 8 MB/sec read on the other. Read-from-first-write-to-second card access showed approx. 2.5 MB/sec speed.

Not the best results, but much higher than previous (700KB/sec write, 2MB/sec read)

[RomaVis]

I've faced the first complete fail with EeeNote

The processor, which EeeNote has, is quite old and sloooow to render beautiful Android 2.3 graphics on such a big LCD. I've managed to run Android 2.3 on it with my custom kernel, but.. it lags heavily. So havily, that it is impossible to work with it.
Also I've found that 2.3 version requires OpenGL ES to be supported by device, otherwise it emulates it softwarely.. Maybe this can explain that behavior.

At the current moment, i'm trying to build an older Android 2.1 (and then maybe 2.2, if I succeed with this effort) but there are some errors during build that I can't resolve at the moment

[eddy]

...requires OpenGL ES to be supported by device...

OpenGL ES is supported by xScale PXA303, well, at least this strange "introductory pdf of marvel pxa3** processors" says it does...