Eee Note kernel hacking

This SO does not sound like a fail to me. Gosh, you're killing me! Oh the day we'll have Quill on the EA800

Also, I'm going to Taiwan next month. Depending on my satisfaction with the EA800 and the price of the Galaxy Note 10.1, maybe I'll switch to the latter. Not to say that you should stop your amazing work, RomaVis

 

Amazing work RomaVis and certainly not a fail
You might be interested in taking a look at a similar project from Notaz on the openpandora boards Android gingerbread in a pnd? - Beta testing - OpenPandora Boards
He ported cyanogen to the openpandora (600+ MHz OMAP3530 ARM Cortex-A8 (32-bit) and 430 MHz TMS320C64x+ DSP Core, NEON & TRADE SIMD coprocessor[1])
Not sure if the specs of the pandora are a lot better than the eeenote, but Android works quite nice on the pandora.

notaz.gp2x.de Git - android_pandora.git/summary

 

I'm not very knowledgeable in this area so pardon my confusion - does your work allow ea800 to run a newer version of linux os? Would this allow generic linux software applications (e.g. xournal, jarnal) to be installed? I would think this would be useful, even with a rudimentary interface. Thanks for your efforts at expanding ea800.

 

I think that with proper tuning it is possible to run X11 on original kernel (sound is made via ALSA, graphics via generic framebuffer, if, of course, they don't exploit PXA3xx 2D accelerator in Qt-based apps), the main problem can be that original kernel is using palette-based framebuffer, and the colormap used is rather unusual (and for this reason you can't have kernel framebuffer console on original kernel).

I've already run X11 on my custom kernel, and it works OK (both with wacom touchscreen driver and X11 tslib wrapper). However, i must note that:
1) It eats a lot of CPU while processing pen movements (bare tslib eats only 5-15%, what can be seen while running ts_test app, and X11 uses up to 95% both with wacom driver and tslib)
2) I also tried to use Xournal, but it _really_ lags, mainly because of previous problem. You can forget about real-time note-taking with that.
3) Tslib wrapper (xf86-input-tslib) for X11 is buggy (however, its code is simple and can be easily fixed/tuned).

In the other aspects, E17 under X11 looks nice..

 

This is not related to kernel hacking, but.. some screenshots (caught by "fbgrab" directly from framebuffer).
And don't get confused by colorful pictures. In my kernel, framebuffer is configured as 16-bit color! This is because our LCD is connected to PXA like it is generic color 16-bit LCD. And i don't know HOW, but it translates colorful signal to grayscale, and it does this in correct way... In original kernel this was done in software, as i described earlier. Of course, the real image on screen is grayscale.

EeeNote EA-800 pictures by ZoneRR - Photobucket

And again: main cause for not using X11 on EeeNote is huge CPU load while just moving pen over the screen. If I could reduce it from 95% to just 5-10.. it would be great And maybe then Xournal can be used.

 

List of devices: ARMv7, ARMv6, ARMv5 - xda-developers
android ARMv5 device
7" Google Android 2.2 Tablet (ARM V5 349.79MHz / 700Mhz bogoMIPS) - YouTube
video
Android 2.1 Rom - Download
android 2.1 .rom(or .img file)

and i have a question : " can UpdateClient install android .rom into eee note"

 

Probably, yes, UpdateClient can install any image
But, it is much more convenient to "install" it from microSD card by hands (using terminal). This is quite easy to do by standard "dd" tool. Risks of "bricking" EeeNote are equal in both cases..

And you can't just take some foreign ROM and flash it into your device. ROMs are highly hardware-dependent!
Most likely the ROM you pointed contains raw NAND image with YAFFS filesystem (common in pre-Android 3/4 devices), which is completely useless on EeeNote (it uses microSD card).

Regarding Android performance in the video: i am not sure, but that tablet can have graphics accelerator, which is also a common option in Android-based devices..

 

Hi RomaVis,

First of all, I think it's excellent work that you're doing on the EeeNote, and hope that you will continue.

Second, regarding the UpdateClient, I never quite figured out how to generate a valid update image because I couldn't figure out how Asus is generating the checksum. At first, it seemed like a simple sum of DWORDs, but while that creates checksums that are very close, they aren't correct, except for one of the sections.

Finally, I'm sure you've seen it already, but in case you haven't, the Toradex Colibri board is a pxa300 based development board that has a basic android port:
Toradex | Colibri XScale PXA300 208MHz V1.3a Computer on Module

They also have a download section that contains an Android BSP:
Index of /files/toradex-dev/uploads/media/Colibri/Linux/Images/PXA-as-is

There is even a WinCE section:
Index of /files/toradex-dev/uploads/media/Colibri/WinCE

Thanks again for your development efforts.

pb

 

I don't know if it's a silly question or not. What if we recompiled Qte with phonon and other options. Will the Asus apps still work (with eeeserver)?

Etienne

 

2etienne:
I think, they should work as previous. The main headache is to compile Qt Embedded with Phonon And i'm working on that since the last week..
2pbarrette
Ehm, for some unknown reason, i thought that you've revealed checksum computation mechainsm the UpdateClient uses If you hadn't, it's not a great flaw, i think.. Writing image with "dd" from terminal is easier and more reliable (from the developer's point of view) than using UpdateClient. From the user's point of view, pressing "Update Firmware" button is, of course, easier than installing terminal, entering something in command line, and so on.. But I usually prefer to have full control over process while doing something that can accidentally brick my device.

Regarding Colibri's WinCE BSP: in any case, we should adapt drivers and other kernel-related things (especially stupid MMC/SD switching the EeeNote uses). I'm not familiar with Windows' driver development..
As for the Android, I've just given up trying to build Android 2.1.. And I hadn't ever tried to build Android 2.2. These versions probably can work faster than Android 2.3 on our device (because of simpler GUI they use). If it builds successfully, it is quite easy to fully adapt it for EeeNote..
At the moment I'm building cross-compilation environment to compile Qt Embedded with Phonon/SQLite/DBus and so on for EeeNote. After that, I'll probably return to the Android idea and try to build version 2.2.