[projectgus]

So I've taken some early steps with the Linux kernel released by VIA last week. Very early days so far.Up at http://github.com/projectgus/kernel_wm8505My notes so far about the kernel build/install process are on the README on that page.If you're interested in building kernels for WM8505, I suggest cloning this git repository instead of working from VIA's tarball because a few minor things have been cleaned up (and the repository has a copy of kernel config for M001, etc.)Please share anything you discover or improve.I'm hoping VIA will come to the party with the binary parts, otherwise the next step is probably going to be attempting to reverse-engineer and replace all the binary-only video components.

 

[bobobo1618]

I've successfully downloaded it but having difficulty with my arm compiler (two versions of gcc = bad). once get it working though ill do what I can. I really want froyo on this thing...

 

[projectgus]

Good luck bobobo. FWIW, I'm using the emdebian cross-compiler toolchain, has been working without a hitch so far:$ arm-linux-gnueabi-gcc --versionarm-linux-gnueabi-gcc (Debian 4.3.2-1.1) 4.3.2I've been experimenting with "shimming" some of the binary-only .o video object files (renaming function exports in the .o and then compiling my own matching function which then calls the renamed one) and dumping arguments as calls go in and out of the video VPP framebuffer layer. The shimming is working, but I'm not learning much that's useful I don't think.I do have good news, though. I've been told that VIA are going to release the video sources in another week or so. The news comes on good authority.So in the meantime the things to focus on may be getting the kernel's own ac97-bus & wm97xx touch support to work instead of VIA's custom version, and getting ac97 sound to work cleanly without patching in userspace (I think WM's version of Android patches there as well.)- Angus

 

[projectgus]

... do you have a serial console hooked in, as well? If you don't then I don't really recommend messing around with this stuff too much until you do. It's too easy to get into situations that are hard to get out of without serial access.

 

[alienation]

Gus, could you try to give me some help or a hint with a usb cam?I have a Bus 001 Device 003: ID 093a:2468 Pixart Imaging, Inc. SoC PC-CameraThis uses gspca modules. I while ago you built all modules against a vanilla kernel source tree.I've successfully inserted the gspca modules, webcam gets on /dev/video0:gspca: main v2.4.0 registeredgspca: probing 093a:2468pac207: Pixart Sensor ID 0x27 Chips ID 0x00pac207: Pixart PAC207BCA Image Processor and Control Chip detected (vid/pid 0x093A:0x2468)gspca: probe okusbcore: registered new interface driver pac207pac207: registeredBut when i try to do anything with the camera, I get a:gspca: usb_submit_urb [0] err -28I've tracked this to this lauchpad bug:https://bugs.launchpad.net/ubuntu/+source/gspca/+bug/377316Someone suggests to use a new version of the gspca code.Could you be so kind to build this module against the new kernel source? Or maybe just the rebuild against the new kernel will do...btw, my webcam best results is this:I've tried with another camera, but with similar results, so maybe there's some kernel incompatibility?Thanks,

 

[projectgus]

alien, a lot of those discussions describe preloading the lib4vl1compat library to make these work, ie something along these lines:apt-get update && apt-get install libv4l-0export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.socamorama (or whatever app you're using)

 

[alienation]

Thanks Angus! That did it.

I'm now going to try to do the same within Android distro. I will be posting a "how to" get your webcam working soon, to help anyone trying.

 

[projectgus]

We have more source now!!

Harald Welte's blogThat's all of linux kernel sources apart from the MMC driver, and the custom u-boot source as well.

 

[exilaus]

u-boot source = multiboot m001? teoricaly now is possible?

 

[metal03326]

Will this help for bringing Android 2.x to M001?

 

[projectgus]

Will this help for bringing Android 2.x to M001?

Yes it definitely will, but there's a lot of work that needs doing first.

 

[projectgus]

Kernel discussion seems to have running in a few different places concurrently, especially between netbook & tablet people.So I decided to start a Google Group to act as a mailing list for kernel development discussion: VT8500/WM8505 Linux Kernel | Google GroupsPlease join if you're interested in developing the Linux kernel on these devices. For resources on running Linux, you're probably best sticking with this forum & bento-linux for the netbooks.

 

[metal03326]

[quote name='projectgus;39422]It's theoretically possible' date=' someone will need to do quite a bit of work to make a graphical boot selection screen if that's what you're getting at.Multibooting via choice of SD card is probably a more achievable goal. Yes it definitely will, but there's a lot of work that needs doing first.[/QUOTE'] Thanks! I know Android 3.0 will require 512 MB RAM, so maximum possible for M001 will be 2.2 and I'll be very grateful if I can run one on it

I believe in you guys (Y)

 

[Neganur]

[quote name='alienation;32873]I will be posting a "how to" get your webcam working soon' date=' to help anyone trying.[/QUOTE'] I'm interested in this.I think Relax 2.0.1 doesn't have the needed modules to support usb webcams since I can not find any video module.Where would those files be on the tablet itself?scriptdriver (seems this is where most drivers are located)libmodules2.6.29-00236-g4f8dbbb-dirty (empty folder)systemmedia (here's only audio)systemlibmodules (the usb wifi driver is here)I can find gspca in the 2.6.29 source:/Linux/Kernel/v2.6/linux-2.6.29.6.tar.gzlinux-2.6.29.6.tarlinux-2.6.29.6driversmediavideogspcaI just don't know linux/Android well enough to understand where to start looking.Is it possible that whoever compiled the very first (stock) firmware simply omitted all those drivers, since the tablet wasn't intended to support a webcam?

 

[Neganur]

Webcam works I was able to repair a defective M001 yesterday night, it appears to be a stock SDK 1.7.2. It's not rooted and doesn't have anything fancy, chinese market application etc.The pcb was in a terrible condition - worse than what I've seen so far with a badly damaged butt plug (solder joints torn off the board itself).To my surprise, this unit recognises all of my 5 webcam modules running Camera Pro (version 11, 480KB), although the application complains about being outdated and wants me to either visit the market (doesn't exist on the market

) or quit. But I can see the live video in the background.What is different from my new unit which doesn't recognise any of my webcams? Is it the kernel? Is there something that our custom firmware doesn't have?Are there any driver modules in the SPI? (pardon if this is a stupid question - I do hardware stuff, not software)

 

[Neganur]

Is there a way to backup the NAND flash in one go?Similarly, I'd like to backup the SPI flash without having to desolder it all the time.I have an old Nokia CA-42 serial cable hooked up to the serial RvTTL port of one of my boards, if that helps.At the moment I'm interested in figuring out:-Why my SDK 1.9.1 M001 doesn't recognise my webcams while the 1.7.4 does.-How to backup the firmware and SPI since I will mess around with it.-How to build a new kernel with the sourcecode we have (the information is spread out there, I want to write it down in an informative way)-Learn as much as possible about the used ARM9.-Hibernate and sleep.-Write a wiki about the used hardware (working on the battery powermanagement at the moment)My motivation:Use the M001 as a display for a stereo microscope (yay webcams)Use the M001 as logic analyser/oscilloscope/multimeter.PS: I don't have root access on the 1.7.4-board and would like to have those backups done before I change anything. (including root)

 

[mammlouk]

There is no ready made scripts for backing up right now, but what you can do since you're on 1.7.4 is take the scriptcmd file from http://www.slatedroid.com/eken-m001...-new-scriptcmd-file-should-used-all-roms.html and modify it to not flash the kernel or logo. Then create a custom update.sh to tar each nand partition onto your sdcard. I don't know enough about SPI to give any advice on that one.

 

[projectgus]

You might be able to just use dd on the /dev/mtdblock devices. That's partition-table-dependent (and the partition table is hard-coded in the kernel on these) but it'd be pretty close to a full byte-level backup. You can run it from update.sh in a scriptcmd, as suggested by mammlouk.

That is a weird one. Try comparing the output of 'lsmod' and output of 'zcat /proc/config.gz' on each. Also compare 'uname -a' output for the build dates of the two kernels (the version numbers will be probably the same but the dates should be different.)

-How to build a new kernel with the sourcecode we have (the information is spread out there' date=' I want to write it down in an informative way)[/QUOTE']I've tried to put as much info as I can into the README in my clone of VIA's source tree, you can read it on this web page. Plus if you're building to integrate with existing Android kernel modules, there's a tidbit of extra information about forcing the kernel revision. That said, more documentation is awesome! Thanks!

Use the M001 as a display for a stereo microscope (yay webcams)Use the M001 as logic analyser/oscilloscope/multimeter.

Very cool ideas.

.

PS: I don't have root access on the 1.7.4-board and would like to have those backups done before I change anything. (including root)

If you change one thing in the android_fs.tar and reflash then you can get a full root console on your serial port. Change "service console /busybox/bin/login" to "service console /system/bin/sh". This was in the earlier firmwares, before someone ungenerously decided to lock it down again.Bear in mind that pretty much everything gets flashed by the default factory upgrade process anyway, so as long as you don't blow away the SPI flash contents you're more or less always going to be safe to restore.

 

[Neganur]

Thanks a lot for your replies mammlouk and projectgus,1.9.1:

/ $ uname -auname -aLinux localhost 2.6.29-00236-g4f8dbbb-dirty #15 Fri May 21 18:24:36 HKT 2010 armv5tejl GNU/Linux/ $/ $ lsmodlsmodrt3070sta 567880 1 - Live 0xbf035000g_file_storage 26400 0 - Live 0xbf029000sensor_mma7660 14296 0 - Live 0xbf020000wm9715_ts_800_480 11776 1 - Live 0xbf018000wmt_battery 8240 0 - Live 0xbf010000wm9715_api 3952 2 wm9715_ts_800_480,wmt_battery, Live 0xbf00a000wm8505_kpad_md 17584 0 - Live 0xbf000000/ $

here the 1.7.2:

/system/bin # uname -auname -aLinux localhost 2.6.29-00236-g4f8dbbb-dirty #117 Thu Sep 16 22:50:30 EST 2010 armv5tejl GNU/Linux/system/bin #/system/bin # lsmodlsmodrt3070sta 567932 1 - Live 0xbf04d000g_file_storage 26400 0 - Live 0xbf041000asix 29976 0 - Live 0xbf034000usbnet 14090 1 asix, Live 0xbf02b000sensor_mma7660 14500 0 - Live 0xbf022000wm9715_ts_800_480 12180 1 - Live 0xbf01a000wmt_battery 10004 0 - Live 0xbf012000wm9715_api 3952 2 wm9715_ts_800_480,wmt_battery, Live 0xbf00c000wm8505_kpad_md 27964 0 - Live 0xbf000000/system/bin #

the 1.7.2 has the modules asix and usbnet while the 1.9.1 has not. Is that it?The firmware is LfD's Relax 2.0.1, could it be that some modules were removed to save space?I find the dates of the kernels interesting1.9.2: May 2010 Hong Kong Time (flashed with LfD's FW)1.7.2: September 2010 Eastern Standard Time (this unit was bought broken, origin unknown)While I was repairing the older board, I had a strong feeling that the previous owner (some EEng) had been removing the flash in an attempt to revive it, since his soldering skills were terrible:

high resolution here

 

[projectgus]

I don't think so, those modules are both for USB ethernet devices.Can you compare output from 'zcat /proc/config.gz' ? It will be a lot more lines than the others, so you'll want to do something like this:zcat /proc/config.gz | sort > /sdcard/config_172.txtthen once you have both, rundiff /sdcard/config_172.txt /sdcard/config_191.txt... and look at the differences (if any.)[quote name='Neganur;79237]I find the dates of the kernels interesting

That _is_ interesting. If you run 'dmesg | head' then you should be able to see who compiled them (at least a username and a machine name.)

While I was repairing the older board' date=' I had a strong feeling that the previous owner (some EEng) had been removing the flash in an attempt to revive it, since his soldering skills were terrible:[/QUOTE'] Ooh, bridgey! Not that I could do that much better.