Handhelds.org - Open source for handheld devices

UserPreferences

EtenG500News

Eten G500

News | Home | Status | Hardware | Downloads | Documentation | Howto | Screenshots | Distro

News

Thu Feb 21 20:38:00 CET 2008 :
"It's getting better all the time".
The G500 is not muted anymore : this release include a working sound driver. All is not perfect though, the proper mixer setting for the speaker is currently unknown but headphones are ok. Also the codec initialisation does not work properly and has been disabled since wince does it for us.
This new kernel also includes support for suspend/resume. Making use of this feature is discouraged though.
Get zImage and patches for 2.6.24 at http://www.pierrox.net/G500/20080221/.

Wed Feb 13 20:14:13 CET 2008 :
GPS is connected on the third UART, and NMEA sentences can now be read from Linux. It has always been working, but unfortunately serial parameters were previously wrongly computed, due to misconfiguration in machine init code. It's now fixed in the latest set of patches. The GPS must however be turned on under wince before to boot Linux. Set UART baud rate and read GPS data : 

stty speed 38400 < /dev/s3c2410_serial2
dd if=/dev/s3c2410_serial2 bs=1

Mon Feb 11 22:43:31 CET 2008 :
So it is now certain that the GSM chip can be accessed through the second UART, (configuration 115200,8N1) : turning on the GSM under wince before to boot Linux is required for proper initialization, and the s3c2410 serial driver has to be slightly hacked, but today some bytes have been read from the phone. Calling the device triggers a sequence of "RING: VOICE" mixed with binary data, opening the door for a potential use as a GSM/GPRS modem, if not a real phone :-)

Thu Feb 7 11:43:45 CET 2008 :
Reopening the case of the G500 was needed to determine the audio codec chip reference : it is a Wolfson Micro 9713, with AC97 interface. Work is in progress to make it work, but unfortunately and in spite of good results (s3c2440 ac97 support ok, SoC ALSA available), communication with the codec is not properly working. So currently no sound but perhaps not that far.

Sun Feb 3 19:40:21 CET 2008 :
The patches for the G500 against linux 2.6.24 are now available for download (see EtenG500Downloads). This release benefits from some OpenMoko patches (UDC and touchscreen drivers). The USB network connection works now great and does not require anymore the 'ping -f' workaround. Unfortunately the newer s3c_mci driver doesn't work with s3c2440/linux 2.6.24, so the previous hacked s3c2440mci driver is still in use. However this older driver contains a race condition with short DMA read, and you may experience problems. Use SD cards with care.
Other G500 parts, like buttons and vibrator, have been updated to new interfaces gpio-keys and gpio-leds.
Suspend/resume is currently disabled as it may damage the battery : some components are not turned off, and the battery may be discharged in less than 8 hours when in suspended state, resulting in a deeply discharged state.

Fri Jan 26 17:50:43 CET 2007 :
I have built some packages for the G500 (enough to run Xorg, Matchbox and some GPE apps). Arch is armv4t so they may be used for other devices too. They are available at http://www.pierrox.net/G500/20070126/, and explanations about building these packages can be found here : http://www.pierrox.net/G500/clfs/.

Sun Dec 17 16:21:47 CET 2006 :
A new patch for the G500 against 2.6.19 is available for download, and its associated compiled kernel too. It contains code for suspend/resume and vibrator. In order to have suspend/resume work you need to suspend/resume the device at least once under wince before to boot Linux. Don't know why yet.

Sat Dec 16 19:57:53 CET 2006 :
Work is in progress on power management. Suspend/resume works :-) There are still some glitches but they probably will be fixed soon !

Wed Dec 6 21:15:10 CET 2006 :
Who said "embedded" ???

Not me for sure. So I have built a complete system for the G500 (and other handhelds), based on CLFS 1.0.0. This distribution includes everything needed for compiling C/C++ softwares, and a dropbear SSH server. When I say "compiling" I don't mean "cross-compiling", it is a native arm toolchain (gcc4.1.1, glibc-2.4, binutils-2.17). For the moment the system is not intended for everyday use of course, and actually it does rather few things (no X, no opie, no matchbox, just dropbear). The idea is just to demonstrate several things :

  1. those little machines have a big processing power, really

  2. gnu/linux does not need the "embedded" qualifier. everything is standard, clean and fully working.

  3. the ability to build standard packages out of the box, without further modification for a "constrained" platform, meaning a wider choice of softwares

This system is not directly intended to be used as a everyday use. It is rather a system to be used as a chrooted environment to build completely standard packages, upon a NFS mount for example, or in an emulator. Of course we don't really need a compiler on the G500, although...
See EtenG500Downloads and EtenG500Distro for immediate use. Stay tuned !

Sat Dec 2 14:12:15 CET 2006 :
Thanks to IDA pro demo and itsme itsutils the vibrator GPIO is now known :-) (GPA06). It will be usefull for power management debugging since this is the only sign that the G500 will be able to give after a resume (usb device and framebuffer are both KO after suspend, I don't even know if the G500 only resumes)
Also it took about 10 hours for the G500 to compile glibc-2.4. Hey, it is not so bad for a so small machine ! It is GCC turn now : a CLFS build may be ready in a few days.
Sat Nov 25 15:52:38 CET 2006 :
At last ! The SD card is now working fine :-) I didn't notice that the s3c2440 controller was slightly different from the s3c2410. The patch will come soon.
Thu Nov 16 20:44:53 CET 2006 :
So Etencorp does not seem to care about the G500/Linux project. They don't even answer to e-mails of their customers. Will avoid them the next time, "tant pis"

Some brainstorming but no new patch for now.
The wince registry is now available for investigations. There are interesting things to learn from some keys : hardware, io ports, driver dll, etc. It appears that bluetooth and GSM are probably used over a serial port. Disassembling some simple dlls will allow to improve the hardware support (led, vibrator, backlight, keypad) : see EtenG500Downloads to get them if you are interested in having a look at them using IDA for example (http://www.datarescue.com/idabase/index.htm). Those dlls have debugging infos, with explicit messages in it... However work on this stuff is kept for later, efforts are focused on this uncooperative SD card. It may be that the card is used with the SPI bus : a registry key refers to GPIO D for card access, but this should be E for SD controller. GPIO D is used for SPI, so...
A simple hint from eten would have save useless efforts.
Mon Nov 6 20:20:39 CET 2006 :
A new patch is available for the G500 ! The Linux version used is now 2.6.18.2 instead of 2.6.16.11. The good thing is that the patch contains support for more hardware. It also uses the official G500 Linux ARM machine type 1178, so update your HaRET configuration file named 'default.txt'. The current patch is configured for :

Also available for download is a GPE filesystem that can be used from NFS. It demonstrates the usability of Linux on a handheld device, despite the temporary lack of persistent storage (SD card or internal flash). Visit EtenG500Downloads to get all this marvelous stuff !

Sun Oct 22 19:51:26 CEST 2006 :
Still no SD card access. But screenshots of the G500 running GPE are here : EtenG500ScreenshotsGpeNfs ! This has been possible thanks to a NFS mount.
I made all sort of investigations on the SDIO controler and it seems it is used for the SD card but for now I couldn't complete the execution of a block read sequence (command timeout).
The Linux NAND driver is working... but not completely : I have only been able to read the first 25MB of the internal flash memory. What is interesting here is that there is the bootloader code in these few MB :-). So if someone has a tool and some hints about how to disassemble arm code, please let me know !!! The bootloader seems to contains test code for hardware like camera, sd, sound, buttons, etc. So there are lots of thing to learn.
Jacques Van Montfort has identified the FM radio chip used on the G500. This is a Philips TEA5764 on the I2C bus. Unfortunately I wasn't able to read or write a single byte on the bus, even if there is a s3c2410/2440 driver in the kernel (the bus remains busy, don't know why). See EtenG500Documentation for the datasheet.
Sat Oct 7 20:35:00 CEST 2006 :
In order to have an idea of what is inside the Eten G500, I decided to disassemble the device. Unfortunately there was covers that I could not remove without possibly damaging the device, so there are still unknown area. Fortunately reassembling the device was straightforward...
See EtenG500Screenschots for pictures.
On Tue Sep 26 21:08:01 CEST 2006 :
It's time for doc.
Since almost two weeks progresses have not been terrific. I faced many stupid and minor problems and the SD card reader is still not working, but :

I spent enormous time to solve Linux random behaviour : HaRET discovers 128M of memory on the PocketPC, but this is the NAND size, not the SDRAM size, which is only 64M. So Linux was poking some memory far beyond the physical memory end, and of course results were not really predictable... Fortunately HaRET has an option to fix the real memory size and now Linux is booting and working great :-)
Another thing is that the USB device does not work with FastFPE. I spent also many time on this...
Maybe somebody have already encounter these problems.

On Thu Sep 14 21:13:21 CEST 2006 :
Thanks to the work on rx3715, the touchscreen input driver and the usb connection now work ! I was even able to do a telnet on the pocket pc :-)
I now work on having the SD card reader ok : for this I use the s3c2410mci driver from the h1940 linux patch. No good result for now.
The usb link seems to be unstable. After several minutes of use (or several seconds) it becames slow then it stop to work. Work has to be done on this area.
On Fri Sep 8 18:58:39 CEST 2006 :
The framebuffer display is now OK and shows a very nice penguin !
This was possible thanks to HaRET (once again) : I simply took the values of the LCD registers from wm5 and put them in the smdk2440 init infos. A G500 implementation should be created instead of modifyng the existing smdk2440.
Since now it possible to compile and run userspace program, and we see what happens, I think running Linux on Eten phones is going to be near from us...
On Thu Sep 7 13:40:54 CEST 2006 :
First program running in userspace !
Before to run init or something more complex, I make some tests with a simple program that outputs hello in a loop, with 1 second between each line.
Although it may seem to be a (almost) easy thing, I had some trouble running something outside the kernel. For an unknown reason yet the kernel does not mount the initrd I tried to build. On the screen I can guess that it is written something like unable to mount root, unknow bloc (1,0), etc. As bloc device 1,0 is ram0 I suppose that there is a problem when initialising this driver, but actually don't know what.
So I now use ramfs, but my first try was not sucessful neither : the init binary (my test program) causes the kernel oops (lots of line scrolling, something like the content of registers...).
I switched from the codesourcery toolchain using glibc to a brand new compiled toolchain with uClibc (thanks to [WWW]buildroot). In the meantime I also come back to OABI instead of EABI. Rebuilded the kernel and it runs !
I now hope to be able to establish a link between the PDA and the PC.
On Sun Sep 3 13:31:05 CEST 2006 :
HURRAH ! My first Linux boot !
See it [WWW]here !!!
Well... there are still some minor problems, but at last Linux boots. After almost a billion device hard reset I finally found where the problem was (or at least what started the problem...). There is a call in HaRET to "(cpu->setup_load)()", which initializez the UART. It does not fail in itself but removing this line let the code continue execution after disabling the MMU. I wonder what's happens but I will have a look later, now the things to do are :
On Sat Sep 2 09:14:58 CEST 2006 :
I located the precise point where the device hangs : just after disabling the MMU. However code is executed after that. If I put code that fills screen with colors after that point, it is sometimes (partially) executed.
On Fri Sep 1 12:57:24 CEST 2006 :
The Eten G500 runs under wm5. Currently HaRET does not work out of the box with wm5 because the default physical RAM address 0xa000000 seems to be wrong. I don't know whether it depends on wm5 or on the hardware implementation, but the CP 15,2 register (MMU base table address) reports 0x302f0000. So it seems that the start of physical RAM is rather around 0x3000000. As a consequence HaRET is unable to allocate memory for the kernel bundle (preloader, kernel and initrd) so that it does not get overwritten when copying it from virtual addressed pages to the beginning of the physical memory.
HaRET patched with this value, I have tried again to boot Linux. This time the preparation of the boot seems to go further : the thermometer is filled and the penguin eyes went bloody :-). However the screen became dark and I had to hard reset the device. I compiled Linux with framebuffer console but :

In order to see if code execution jumps to Linux I am in the process of writing a small binary blob of binary instructions that fills screen with colors. This is an idea of Andrew Zabolotny, the author of HaRET. As I am completely new to ARM it may take some times ;-)