[DEV] Blackstone Linux / Android Development - Touch HD Windows Mobile ROM Development

This thread is for development discussion only. If you are not actively working on the project, please go to the discussion thread where your contribution will be more valuable. By keeping this thread clean, we can hope to get Android working on our devices much quicker.​
Project Status:
We now have a 2.6.27 kernel which is capable of booting Angstrom and Android. Android looks good and is responsive, but most core functions are not there yet. Work is focused on kernel development to provide us with a stable base with working hardware. You can find test files in the second post.
We have a Wiki page where the project gets documented in some detail.
History
The development had a slow start while Orux worked out how to make the mdp talk to mddi to get a working display. We hope that progress will be faster now as there has been considerable work on the Diamond and Raphael hardware, which is quite similar to the Blackstone.
23Feb09
Screen problems fixed at last - many weeks work from Orux got the mdp talking to mddi and give us a working display.
03Mar09
Wow! So much progress in just a week! We now have working SD (some issues with brands of cards - under investigation), allowing booting direct from the SD card; working hardware buttons, and some GSM functionality (the network connects and reports of sending SMS successfully). Credit to Orux, Pichurri, Cybersalsero, Jonlar (and have I missed anyone out - not me, I have been spectating!). Pichurri has posted a full install package on teh wiki, go try it and give feedback in the testing thread.
(to be continued!)
Current tasks
Debugging SD card problems many ppl having
Getting our own version of Android (currently using builds optimised for Raph/Diam
More GSM functions - who will be first to make a call???
What can I do?
You tell us! First thing would be to get yourself set up with a development environment. You need Linux on your PC - either installed as the main OS or if you use Windows, in a virtual machine (eg Virtualbox). Then follow the instructions on the wiki to get the sources and latest diff.

Reserved for files
Here you will find the up to date files related to the project.
Pichurri's full 2.6.27 install package is on the wiki here

You should correct the posts: 2.6.26 and 2.6.27 is the kernels used. More info: www.kernel.org

brumbrum said:
You should correct the posts: 2.6.26 and 2.6.27 is the kernels used. More info: www.kernel.org
Click to expand...
Click to collapse
We are using 2 kernels:
2.6.25 --> htc-msm-2.6.25 branch in git.linuxtogo.org. This is the kernel that we are testing in our machines these days.
2.6.27 --> htc-msm-2.6.27 branch in git.linuxtogo.org. Where we will stay in a few days. Better kernel, more improvements. Here is where people from other projects are working now.

orux said:
We are using 2 kernels:
2.6.25 --> htc-msm-2.6.25 branch in git.linuxtogo.org. This is the kernel that we are testing in our machines these days.
2.6.27 --> htc-msm-2.6.27 branch in git.linuxtogo.org. Where we will stay in a few days. Better kernel, more improvements. Here is where people from other projects are working now.
Click to expand...
Click to collapse
Sorry, my mistake. Typed the message above late in the night.
But in the first and second post in this thread it says 2.2.65 and 2.2.67.

Thanks, was posted in a rush, just pm me if you see more errors. We use the odd numbered dev kernels, they will always have the most recent stuff.

A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.

orux said:
A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.
Click to expand...
Click to collapse
Do you mean things like picture-in-picture? Would be good later on in the gui - multiple desktops, that kind of thing. Also I noticed the Epson controller handles TV-out. Do we know if the out-connection exists for this, or have they just not connected it up?
Another thing to consider maybe USB on-the-go - the MSM72xx supports it; if (big if) the usb port has the right connections, it would be possible to mount external storage.
But I think it's more for later on - core functionality would be about making calls, sms, GPRS/3G. Let's see what we get from the latest kernel. Orux have you talked to the RAPH/DIAM guys on irc about merging?

orux said:
A challenge for someone who likes graphic drivers:
I think linux is using ~10% of epson controller capabilities.
We have a lot of information about this controller, and open source code from epson.
Perhaps someone would like to work with this stuff.
Click to expand...
Click to collapse
what makes you believe that?
whatever makes you believe it, share it!
if you have anything like docs,etc to share or point to lets have it !

Blackstone has got 2 graphic processors:
--->mdp, inside the chip. We have drivers in the kernel (mdp.c, mdp_ppp.c ...) I am not sure what capabilities are being used in current kernel. There are not good docs about mdp processor (I haven't got any useful).
--->epson controller. It can do:
• Picture in Picture, Transparency, Alpha Blending
• Image Rotation (90°, 180°, 270°) and Mirroring
• Scroll Assist
• AME (Auto Movie Enhancement)
• Supports up to three layers
• Image Doubling
• Bi-Cubic Scaling (1/2x ~ 8x)
• Over/Down Sampling Scaling (1/8x ~ 8x)
• Edge Enhancement
We don't have driver support in current kernel, but we have docs and source code from epson (link posted in discussion thread).
Htc Touch Pro has a tvout usb cable adapter, and seems to work in linux! I don't know if this cable works with our device.
USB on-the-go: interesting TODO.
patp said:
Orux have you talked to the RAPH/DIAM guys on irc about merging?
Click to expand...
Click to collapse
Not yet; perhaps your (or pichurri, ...) task when we have a good .27 diff. I have too much language limitations for an on-line discussion

p3ngwin said:
what makes you believe that?
whatever makes you believe it, share it!
if you have anything like docs,etc to share or point to lets have it !
Click to expand...
Click to collapse
OK, OK! These things take time - we all have other jobs I guess. We plan to get any open source docs online in a systematic way, we just need to figure out a reliable way - ie not RS etc. And we have to be careful of proprietry materials - we don't want copyright lawyers after us...
If anyone wants to offer us some rock solid webspace, that would be awesome.

TODO: Investigate instability of screen
I think that problems with screen are caused by onscreen keyboard. This keyboard is an excellent hack, but it is not 100% integrated with android.
We need to test a kernel without it.

orux said:
I think that problems with screen are caused by onscreen keyboard. This keyboard is an excellent hack, but it is not 100% integrated with android.
We need to test a kernel without it.
Click to expand...
Click to collapse
Or use the cup cake version with the keyboard in android it self.

Full doc of the epson controler : http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=278&Itemid=40
Link is at the bottom of the wiki, add yours
I don't think we need to put all the docs at the same place, just add links at the bottom of the wiki, either hosted or link to website.
I can provide hosting if you need, just pm me.

repository
what do you guys think about creating some kind of repository(git or svn) to upload and share our blackstone kernel? i think it would make development much easier if you could see changes of other people immediately. we could use github or sourceforge.

I also think the On-Screen Keyboard is a problem.
Earlyer today I was goofing around in Android and every time I moved the keyboard, the graphics started acting very weird.(scrolling, not updating etc.)
When I hit F5 on the OSK, it would refresh Android and go back to the home page and the screen would be normal again.
Maybe route the OSK to a pip on the epson?

It's git for kernel dev, anyways svn sucks (inc troll)
If we set up a git, we'll need a guy working as a maintainer and pulling from everyone. This may become usefull when people start working in many different areas of the kernel, but for now diffs are better as they can be easily shared, and there's a howto in the wiki.

patp said:
OK, OK! These things take time - we all have other jobs I guess. We plan to get any open source docs online in a systematic way, we just need to figure out a reliable way - ie not RS etc. And we have to be careful of proprietry materials - we don't want copyright lawyers after us...
If anyone wants to offer us some rock solid webspace, that would be awesome.
Click to expand...
Click to collapse
hey i have a servage account that i hardly use which has massive space and bandwidth i could give you a ftp account to and any sql servers you may need. let me know

Rewpparo said:
Full doc of the epson controler : http://vdc.epson.com/index.php?option=com_docman&task=cat_view&gid=278&Itemid=40
Link is at the bottom of the wiki, add yours
I don't think we need to put all the docs at the same place, just add links at the bottom of the wiki, either hosted or link to website.
I can provide hosting if you need, just pm me.
Click to expand...
Click to collapse
Agreed, the wiki is the best place for this. Would you be happy for me to mention your hosting offer on the front page (which will quite soon need a better structure I'm sure).

JanSchotsmans said:
I also think the On-Screen Keyboard is a problem.
Earlyer today I was goofing around in Android and every time I moved the keyboard, the graphics started acting very weird.(scrolling, not updating etc.)
When I hit F5 on the OSK, it would refresh Android and go back to the home page and the screen would be normal again.
Maybe route the OSK to a pip on the epson?
Click to expand...
Click to collapse
Now that my friend, is a stunning idea (if it can be done simply). How does it relate to the Android OSK mentioned by xmoo? I guess the linux one is low level whereas the Android one is basically an app in the gui. Advantages to both, but if it works out of the box, the android one would mean we could essentially get rid of the linux one. We have ssh if we want to type in a console (or maybe android terminal app?).

Related

Progress of linux --- any flavour

Hi Just a quick query ------ any ideas if there is a beta nix for trinity in the pipline soon or do we just put that aside and come idea to see how it all is in 12 months
no info???????? no pulse?
Just might be helpful as an general update for myself and the others who desperatly await a decent operating system for their Trinity.......
Thanks all
http://wiki.xda-developers.com/index.php?pagename=Xanadux
when there is news that page would prob be the place it would be shown
looks like they need people maybe it could be you?
can't program can test
well i can't program but I would test it till the cows come home ------ I will wait
Cheers for the funny signature ---- I also come from a long line of jedi's ----- jedi taxi drivers
andytof47 said:
Hi Just a quick query ------ any ideas if there is a beta nix for trinity in the pipline soon or do we just put that aside and come idea to see how it all is in 12 months
Click to expand...
Click to collapse
I started working on a linux port for trinity. I nearly got the kernel running but there was some problems with the uart driver (if I remember correctly) that prevented it from loading completely.
I had to stop working on it due to lack of sparetime to use on this project.
I will weep uncontrollably
That hurts more than you will ever know
but I will let anyone know that any effort that is spent towards this is appreciated and time very well spent... I'm sure your work wasn't in vain
cheers
Needing linux, feeling WM6 is limiting
check out news on ubuntu mobile - they are hoping to release a distrib later this year working on as many smartphones as possible
kimusan said:
I started working on a linux port for trinity. I nearly got the kernel running but there was some problems with the uart driver (if I remember correctly) that prevented it from loading completely.
I had to stop working on it due to lack of sparetime to use on this project.
Click to expand...
Click to collapse
Hi,
Your work is quite intersting !
Would it be possible you publish the kernel version, the patches and the .config you used in the wiki ?
Thanks ^^
I've checkedout the linux kernel sources and installed the ARM toolchain from handhelds.org.
The kernel compile fines:
Code:
make htctrinity_defconfig
make
After copying the zImage file created, I tryed to launch it with Haret (also recompiled from latest sources). Since the Trinity seems to be not supported "out of the box", I had to set set the RAM start address and the mahchine type:
Code:
set RAMADDR 0xa0000000
set MTYPE 0x000004C9
set KERNEL zImage
bootlinux
The result is the screen gets black as soon as Haret jumps to the kernel... (see attached Haret's log).
Any hints on how to have more debug from the kernel ?
Where the console is supposed to be displayed ?
A big problem appears to be the fact that our device and the hermes use the SD driver in the ATI chip, not the friendly PXA27x drivers most others use. This is causing all sorts of headaches for the guys working on it and as I understand it they really need someone who can write a driver from scratch for it.
I personally thought about working on this and almost started (got a haret patch at least) and then decided that without a hardware keyboard this is gonna utterly SUCK for debugging and testing. As much as I hate to say it, I'm gonna wait for the kaiser to play with getting linux fulling running on the device. Then again, that's gonna suck since it uses a wacked cpu compared to any other...
bump ... . ..

Android 2.2 "Froyo" porting project | discontinued

Xdandroid port for XPERIA
I am working to port the main Android distribution for HTC devices, xdandroid to the XPERIA. The fix for the screen flip is now present in their source repository and hopefully the kernels will merge soon.
LATEST RELEASE: 27th September - mic mute fix
Fixes the mute mic in calls. Turns out I pulled the latest kernel sources at the wrong time
Complete package (72MiB)
Without system.ext2 (27MiB)
Thanks to Jonny4911 for the touchscreen calibration file
Known issues: Battery charging won't work if charger is not active at boot.
22nd September - kernel revision (page 147 onwards)
I am no longer distributing the system image as I no longer need to modify it.
* Get the kernel+haret etc. from here and then get the latest XDANDROID system image from the official thread
* Rename the system image you downloaded to system.ext2 and put it on your sdcard along with the kernel package
* As noted in the xdandroid thread, you will need to throw out your data.img this time around, due to having a signed release.
Changes:
Seems to crash less!
Known issue: Voice calls are not working properly (mic not turned on)
21st August - Kernel update (page 117 onwards)
Kernel from kovsky-battery-driver branch - standalone battery meter driver, migrated to official HTC touchscreen driver, BT turns on but may not work, kb backlight thanks to ultrashot+vdelf
Clean system image from xdandroid 19/8 There is no LauncherPro in this image!
Known bugs: Not as stable.
Important: delete ts-calibration on your SDcard. You will be asked to calibrate the touchscreen on startup. Follow the onscreen instructions and not the squares as the calibration program does not know the screen is upside down
Important: Back up your data.img as there is a very real chance you could lose it due to crash
Download: US West
US East
with working ts-calibration and haret.exe (oops) thanks loco
Next release will be near the end of September, mkay? I've been busy elsewhere
9th August - System image update page 103 onwards
Based on xdandroid RC2.1
Removed Gallery3D and Music Mod, replaced with 2D Gallery and stock Music. (You can d/l Music Mod without screen size issues from the Market)
Wireless tether now included (warning: burns more power than charger puts in)
powertop now included for power usage debugging
sdcard powersave fix now in default.txt
fsck files purged on startup.
Previous releases are available from this page.
FAQs
Is there a Chinese language version?
Not yet. xdandroid has not built their images for non-latin locales it seems
Will there be a ROM?
Not yet. Requires more work for the kernel and that is not my area.
Will battery life be 'fixed'?
Possibly.
Will Camera be fixed?
Unlikely.
Charging does not work
If your phone is very warm then it is probably consuming more power than the charger delivers. Otherwise, reboot and try again
Market does not connect
Reboot, connect WiFi immediately (if you have it), try again
<Android feature X> does not work
Look in the Rapahael, Blackstone and Diamond forums to see if this issue affects other devices first. It is a very low priority for me.
If it involves Google accounts (i.e sync) I won't investigate.. we are lucky it works in the first place.
Speaker still seems to be on
Fixed in development, but I haven't released an updated kernel yet.
<I have a power saving idea involving speakers, GPS or something>
The cause of our battery life crapness is some driver bugs preventing the use of a proper sleep mode. Nothing else.
Cool! looking forward to follow development.
Nice job
With enough documentation, I might join in the development! I have skills in C++, PHP and Java, so this interests me a lot.
Aw, you beat me to it haha.
Very nice Gentoo work too!
nice.. im in. im not a dev but this kinda stuffs been a hobby for years..
ill try to help with whatever i can
i heard froyo a lot more flexible with its hardware compatibility, might be easier to fix radio, wifi, gps, etc
thought i doubt with x1's hardware can run froyo well but still appreciate if have it
I have very little experience with linux or any coding, but i need to get the most out of my xperia till February next year. New hobby coming my way!!
Thanks for taking the effort to explain what we all needed to know!
Will be following your thread and google-blogish type thing.
So glad to see that people are still confident in android + our xperias!
thought i doubt with x1's hardware can run froyo well but still appreciate if have it
Click to expand...
Click to collapse
From doing the Gentoo work with X and now Android, I think a proper graphics driver might help, you can see that while the CPU isn't being taxed much there is low fps on the display.
If we can get that extra 56MB of RAM currently not available that would help as well. Android is very RAM hungry..
Tremere said:
From doing the Gentoo work with X and now Android, I think a proper graphics driver might help, you can see that while the CPU isn't being taxed much there is low fps on the display.
If we can get that extra 56MB of RAM currently not available that would help as well. Android is very RAM hungry..
Click to expand...
Click to collapse
Wow that's cool somebody is working on this, and what about a 128mb swap partion to make up for for 56mb of ram currently not available? Also for graphic driver what do you mean exactly? Graphic driver for Android on xperia or do you need one from windows to port into android? I have a collection of graphic driver's that I use for the Xperia.
I tried using swap on my other Linux experiment but these days Linux seems to prefer not to use swap at all.
Android uses the Linux framebuffer to draw stuff, and there is a binary 3D driver for OpenGL stuff - i think the xdandroid guys use it and run the Nexus One gallery 3d app with it.
The issue is that the speed of drawing on the screen is very choppy, its like when you use Windows or Linux with a generic VESA driver - you can't see windows while your moving them, or if you do its very slow. Maybe its something to do with the vsync messages I get in dmesg.. I'll let someone more experienced answer
It's great to see this development! Following this topic.
Keep up the good work
Tremere said:
The issue is that the speed of drawing on the screen is very choppy, its like when you use Windows or Linux with a generic VESA driver - you can't see windows while your moving them, or if you do its very slow. Maybe its something to do with the vsync messages I get in dmesg.. I'll let someone more experienced answer
Click to expand...
Click to collapse
Could this be reason why android takes so much cpu power and battery?
i.e. if you take out the battery in winmo while connected to the charger you'll still be able to do everything on the phone.
I've done the same thing in android. Pull out the battery... but when I slide the homescreen the phone turns off.
So this is also a benefit for the most important thing.. improving battery life?
Thank you!!I think the Android ROM is not far away from X1...I will close attention to your update!Thank you again!!
Can you tell me when the Android ROM will finish??Thank you ....
I think you can do it !!
@yinjianweizxc Ever heard of edit function?
Anyway, i hope this project evolves. Can you make RSS feed for your progress? I want to be on track
EDIT: wait, you got usb to work? That is great, i hope other devs see this.
USB has always worked - but you need to have a USB cable plugged in and connected to a computer before starting HaRET. Its one of those things they don't fully know how to do under Linux yet.
It got me too when I was first playing around with Linux on the Xperia
We should talk to some of the original developers to see how they got started and if they would be willing to help.
matejdro said:
@yinjianweizxc Ever heard of edit function?
Anyway, i hope this project evolves. Can you make RSS feed for your progress? I want to be on track
EDIT: wait, you got usb to work? That is great, i hope other devs see this.
Click to expand...
Click to collapse
Transplant system in this regard I know nothing, and I greatly admire your technology,haha...

[PRJ] SYS Builds: What's the Difference?

I'm putting up this thread because there is a good bit of questions that get asked about the difference between the SYS builds. While Microsoft and its partners don't give us a real breakdown of them, we can at least get results on which one is faster than the other. That is the purpose of this thread. If you have any relevant information for me to add to this, let me know. If I add your suggestion, I will, of course, credit you. This is relevant to pretty much all WM6 devices, but I'm making this specific to the Rhodium as that is the only device I plan to support with benchmark results. I'm following the same pattern from the benchmark thread that was started HERE by daeron.be.
To start off, Da_G, a1d2catz, and Cotulla originally posted about the different builds. OndraSter posted to elaborate on a couple of the builds.
Branches of WM Development: Here is what all these different version numbers relate to, and a summary of their features.
212xx = AKU1, all builds leading up to and including WM 6.5
213xx = MOT motorola
214xx = ???
215xx = SAM samsung
216xx = HTC htc
217xx = COM1, continuing dev of 6.5.0.1 - 6.5.0.40
218xx = COM2, continuing dev of 6.5.0.50
219xx = MD, feature test branch, pretty much dead now. (unstable features are added here, this tree is based on COM1, so older base OS code, but the UI/UX code is newer)
22xxx = SEMC sony ericsson
*230xx = COM3, continuing development
*234xx = COM4, appears to be abandoned.
*235xx = COM5, more GUI changes here. New Outlook Interface.
*236xx = LG Electronics Branch
*24xxx = Possible HTC branch
*25xxx = SEMC - Sony Ericsson
*280xx, 282xx = WMD. This is a continuation of com3 from 23090. Most of the changes appear to be with IE
235xx is the only branch that has threaded email natively
290xx = Unknown branch
There was 219xx about half year ago, with numbers ending about 21936 (or maybe 45 or about that). It was test branch, where new features (like... supernew, something like previous 230xx where appeared huge softkeybar etc) were added. This branch was dead, just as looks 234xx now.
But, there was also COM2, with numbers 218xx. Well it reached its maximum, 21899. But instead of making new number line, MS/HTC chose to use already used 219xx. Here is where the mess comes from
The WM version numbers are as follows:
216xx = 6.5.3
219xx = 6.5.0
220xx = 6.5.3
231xx = 6.5.3
235xx = 6.5.5
236xx = 6.5.3
246xx = 6.5.3
250xx = 6.5.3
282xx = 6.5.3
290xx = 6.5.3
Click to expand...
Click to collapse
Updates:
14 March 2011: Finished benchmarks on 21689, 28245, 29011, 29013.
09 March 2011: New builds have begun rolling out. Testing begins tonight on 21687, 29008, and 29009.
...trimmed every month...
Results
I based these blank uncompressed ROMs on the latest shipped T-Mobile 6.5 ROM (1.91.531.4), disabled all ext packages, and swapped builds. I've listed all of the builds that I currently have. If you have one for me to test that's not on the list, send it my way as long as it's WVGA.
SYS builds tested:
216xx: 21659, 21661, 21663, 21665, 21671, 21674, 21677, 21679, 21680, 21681, 21682, 21683, 21684, 21685, 21686, 21687
219xx: 21904, 21905, 21907, 21908, 21909, 21911, 21914, 21916
220xx: 22013, 22018, 22019, 22021, 22022, 22024, 22027, 22031, 22036, 22037, 22038, 22040, 22041, 22042, 22044, 22046, 22047
231xx: 23120, 23121, 23129, 23130, 23132, 23133, 23134, 23135, 23136, 23138, 23139, 23140, 23142, 23144, 23145, 23146, 23148, 23149, 23150, 23151, 23152
235xx: 23569
236xx: 23651, 23654, 23656, 23658, 23659, 23662, 23664, 23667, 23670, 23676, 23678, 23680, 23683, 23686, 23688, 23689, 23690, 23691, 23694, 23697, 23698, 23699
246xx: 24609, 24610, 24611, 24614, 24618, 24619, 24620, 24626, 24627, 24628, 24630, 24631, 24635
250xx: 25018, 25024, 25026, 25027, 25028
282xx: 28233, 28236, 28237, 28238, 28240, 28242, 28243, 28244
290xx: 29002, 29003, 29005, 29007, 29008, 29009
Custom ROMs tested so far:
NRGZ28 Energy: 21916, 21684, 28244, 23148, 23699 - Update coming soon!
Ondraster LBFAR: 21899, 23569
dotcompt DeepShining: Coming soon!
Problem builds:
These are builds I was either unable to import into my kitchen, or cook for various reasons:
22016, 21664, 23123, 23125, 23126, 23127, 23566, 23694
Method and relevant information
If you are planning to send me results or anything, be sure to include the version numbers of the programs you used. SPBBenchmark and Test OpenGL are both freeware. Coreplayer Mobile costs around $30.
Benchmark programs used:
1. SPBBenchmark 1.6
2. Test OpenGL 18.01.2010
3. CorePlayer Mobile 1.2.5
Test Method for blank builds:
1. task29 then flash the ROM without the SIM card.
2. The storage card is left in to install the benchmark cabs.
3. Go into airplane mode.
4. Disable switching screen off and turning the device off.
5. Install benchmarking apps
6. Soft Reset
7. Run SPBbenchmark and disable the following:
Built-in applications (whole category)
Arkaball frames per second
Copy 1 MB using memcpy
8. Run TestOpenGL for about 3 cycles of benchmarks (each cycle is 4 benchmarks) and then turn it off
9. Run three Avatar trailers, note down the results (%). Use default Coreplayer settings and run benchmark immediately after files are loaded.
Trailer found HERE. Note that trailers ARE copyrighted material and are NOT subject to fair use. The link provided is to show what I am using. I own the BluRay disk and ripped it from there. The link is also 720p. My original clip was 1080p. Each exported trailer was set to 800x480 resolution.
One trailer was converted to 25fps, 768 kbps - XHQ
One trailer was converted to 23.976fps, 512 kbps - HQ
One trailer was converted to 20fps, 384 kbps -MED
I wasn't able to determine the original qualities from daeron.be's thread, so I made my own. If you know more about it, please let me know for more accurate results.
10. Run Video Flash benchmark with PIE using a downloaded version of the animation found HERE. If you plan on doing this yourself, download it to your device and run it with IE. Just put it in a root dictionary (\) and then input \benchmark.swf address in IE. On some ROMs you might have to wait a while before the flash starts (there won't be any signs of loading). Run the benchmark (if you want your result to be compatible with mine you MUST run it with flash file in full screen).
11. Collect results
Test Method for Custom ROMs:
Same as above with three exceptions.
1. Run SPB Benchmark with ONLY "Built-in applications (whole category)" test disabled. Leave everything else on.
2. Connect the device to the PC after running the SPB Benchmark test. You may have to go to Start > Settings > Connections > USBtoPC and untick the "Enable faster data synchronization" box to get it to work.
3. Copy the "Spb Benchmark Results.xml" from \My Documents to the PC and grab the results from there with the decimals. I use every decimal in the file. I then trim the trailing zeros in the Excel results file.
I figure since some people will probably use this as a guide of which ROMs are "best" or "fastest," that the results should be as accurate as possible, which is why I'm including the decimals in the custom ROM results, but not in the blank builds.
FAQ
When posting to this thread, please use proper English only, and do not use profanity.
You should not type like a high school girl, either. Leave the "plz," "sum1," and "u" back on the playground.
Ask for help like an adult and be treated like one.
1. What are these benchmarks for?
Basically this is just a measure of performance on different SYS builds to see which one is the fastest. These tests do not indicate which build is really “the best.” It is a measurement of speed on the process of copying files, reading directories, and playing video. To truly “test” a ROM, you need to spend a few days with it.
2. Which radio version are you using?
To the best of my knowledge, this has no affect on the results. However, my current radio version can be found in my sig. I do not change it for these tests.
3. Does a task29 before each flashing affect the results?
There are problems with "ghosting" in ROMs where residual data is left over from a previous ROM. To avoid this, I perform a task29 first. If you want to know more about task29, then visit that thread.
4. Are those benchmarks accurate?
I test the ROMs with SPBBenchmark once as it averages the results of 13 tests each. I use three rounds of OpenGL and use those results as it takes the highest result from there, which is what we want. An average in that category is useless as we want to know what the best result is for this, not the average. I run each Avatar trailer three times and take that average. Flash is pretty straightforward and kind of just for fun, so I only do one test. All of this means that the results may vary by a very small margin. If you don't believe my findings, you are always welcome to test yourself. Anything within a 1% margin of error is acceptable.
5. Why do you disable "Built-in applications (whole category)," "Arkaball frames per second," and "Copy 1 MB using memcpy" for SPB Benchmark on the blank builds?
They don't make a noticeable difference in the results. I could grab the *.xml results file from \My Documents, but it's not that big of a deal in the blank builds as they are just a stepping stone for chefs to see what they like and don't like. If you want to see the results, test them. I use them for custom ROMs because it makes sense to do so. People will interpret these results loosely, and it is better to be more accurate with them.
6. Why aren't you using Linpack?
Great question! I would if this were Android as there are current programs for it. The only one available for use on the WinCE platform is almost three years old at this point. Also, SPBBenchmark measures MFlops, so I don't really need it, do I?
7. Why don't you test battery life?
Battery life testing takes too long, plain and simple. When you flash a new ROM, getting the battery set properly takes about two or three cycles (drained to 10% and then charged to 100%) before it "settles." Even if I did nothing but play movies with the backlight and sound at max while downloading files via wifi and using Bluetooth file transfer, it would still take about an hour or so to drain the battery enough to charge it back again. You would need to drain and then charge AT LEAST once, preferably twice, before running a battery meter to test. This means I would be stuck on one ROM for hours before moving to the next one. My current set up allows for about 30-45 minutes per ROM to test. This is much more reasonable than 4 hours each, don't you think? If you decide to do test it yourself and want to share, then be my guest.
8. I didn't see you use xxxxx version of a build. Why is that?
I either don't have access to that build, or it isn't a WVGA build. If it is a WVGA build and I don't have it listed, send me a link, and I'll test it out.
9. Can I test the ROMs too?
Sure, why not? I won't use your results, though. There was a massive flame war in the aforementioned original thread that was partly fueled by other users posting results. I don't plan to start any nonsense here.
10. Would you mind testing a custom ROM for me?
YOU MUST GET THE CHEF'S PERMISSION FOR THEIR ROM'S RESULTS TO BE POSTED. I need them to PM me with an ok. I basically want it in writing. NOTE: Once a chef says it's ok to test, I will not remove them from the tests; make sure they understand this.
11. Why am I getting different results?
There are several little nuances that can influence the results in minor ways. If you're getting significantly different results than I am, then I'll look into it again. Keep in mind that using a different device than I am may affect the results as well. However, I will not use any other users' results without verifying them myself.
12. Some of this material looks familiar. Did you steal this?
Yes, basically I did. I figured I'd restart something similar for reasons I've mentioned as well as making it more Rhodium specific. Besides, the original poster, daeron.be, hasn't even logged on in a long time. His thread hasn't been updated since September of 2009 as well. I'm going to use most of their formatting and previous material to build on. If someone has a legitimate problem with this, then PM me.
13. I don't believe that you got "X" results with "X" ROM! I think it's WAY better than all the rest!
I don't care what you think. That isn't a question anyhow. I'm doing this for myself and sharing with you all. Either take it for what it's worth or do it yourself.
14. You didn't respond to my post. What gives?!
I have a life. I'm on XDA way more than I should be as it is. I will generally respond to questions and the like. If you just post to say "Good job" or "Thanks, man," don't expect me to respond. I might, just don't expect it. Just consider this answer here as a general "Thanks" and "You're welcome."
15. You're from New Orleans? What's it like?
People are wonderful; food is amazing; Mardi Gras rocks. Let's keep the thread on topic, please.
Requests
If someone wants to change the BG colors of the spreadsheet to something they like better, be my guest. If I like the colors, I'll keep it.
Please take the poll at the top of the page. If enough people use this thread with other devices, then I will consider moving it to the Chef's Central forum.
I am slowly adding custom ROMs to the results. I need a few people to notify me when the ROMs you're using are updated. This includes Energy, Simplicity, DeepShining, Core Cell, and other popular ROMs.
Custom ROM testing
Ask your chef if he/she would mind having their ROM(s) tested and compared in my results. See below for rules:
All custom ROMs would be separate of the clean builds, but compared all together.
Understand that once permission is given, it cannot be taken away. (I don't want anyone trying to revoke permission after results are posted to take advantage of my system.)
Have the chef PM me with the green light if they want it included.
All results will either be performed by me, or verified by me.
I will not measure battery performance. See FAQ.
These results are not conclusive to picking a "good" ROM. It's a jumping off point. Test yourself and see which one works for you. This tests certain factors of the ROMs. This doesn't test for stability or feel of the ROM. Do that yourself.
Chefs are allowed to "pick and choose" which ROMs they want tested. If they cook multiple flavors or builds, they can decline to have certain ones excluded from results.
If you have a problem with my methods, you are welcome to do them yourself. I am doing my best to ensure that this is as objective as possible.
Contact
If you feel like contacting me or need to request info or whatever, you may PM, e-mail, or message me on Twitter.
Donate
Coffee keeps me cranking out results. DONATE to keep the caffeine flowing. If I see that you've donated, I will probably take a bit more care in listening to your problem/suggestion/comment. Make sure that you include your XDA user name so I can give you credit.
beautiful... cant wait to see results
Subscribed.
Imho you should test blank WM builds. Or at last be sure that the EXT/XIP packages are same. However the idea of testing different builds fits me.
Shame that usually the fastest builds leak memory like hell.
Jackos said:
Subscribed.
Imho you should test blank WM builds. Or at last be sure that the EXT/XIP packages are same. However the idea of testing different builds fits me.
Shame that usually the fastest builds leak memory like hell.
Click to expand...
Click to collapse
I used to believe that until we started seeing the 21680 and 21681 builds come out. They really are quite faster than most of the others. When NRG was using the 23xxx builds, that was the case where the faster they ran the more memory was "spirited away," so to speak. I'm finding a much more stable experience with the 21680 and 21681 builds than most that I've seen.
In any case, the results will speak for themselves. The first three should be posted in a few hours or so.
For anyone who missed it, I've posted the first test file. I only did a single test for each one. In the future I will do an average of three results per test. I only did a single one due to time constraints mostly. That being said, this first file is just a test both for me and for anyone viewing to get a feel for what it's going to look like.
Any questions; let me know.
cajunflavoredbob said:
Requests
The first thing I could use help with to speed up my testing is for someone to point me to the reg key that disables Sense. This would make it easier for me to just drop it into XDA_UC to have the changes made automatically.
[..]
Click to expand...
Click to collapse
This isn't a reg key, but I think there are mortscripts that disable Sense. Maybe this might help?
http://forum.xda-developers.com/showthread.php?p=8684203
I think JVH3 talked about scripts that disable sense too, so perhaps he might be able to help you out there too?
Great work, this is really interesting!
Using mortscript you can do this:
Code:
RegWriteDword("HKLM","\Software\Microsoft\Today\Items\" & ManilaName,"Enabled","0")
RedrawToday
Sleep(5000)
ManilaName is usually HTC Sense, I think. The sleep can probably be shortened. Nice thread!
why not just build a rom free of all ext packages?
just sys and oem packages.
that way it is a better comparsion of sys builds.
no?
sh4d0w86.
cajunflavoredbob said:
The first thing I could use help with to speed up my testing is for someone to point me to the reg key that disables Sense. This would make it easier for me to just drop it into XDA_UC to have the changes made automatically.
I could also use the reg key that sets the device into flight mode for the same reasons.
Click to expand...
Click to collapse
Disable Sense:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Today\Items\HTC Sense]
"Enabled"=dword:0
Flight mode on boot:
Code:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\State]
"Phone"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\RIL]
"LastEquipmentState"=dword:00000001
[HKEY_LOCAL_MACHINE\System\State\Phone]
"Status"=dword:00400030
"Radio Ready State"=dword:00000000
Random offtopic: I believe that all roms should have the radio turned off by default.
Jackos said:
Random offtopic: I believe that all roms should have the radio turned off by default.
Click to expand...
Click to collapse
I'm curious, why?
seeM_ZA said:
I'm curious, why?
Click to expand...
Click to collapse
Because not anyone wants to run the Connection setup after rom upgrade? Not anyone wants to get all those sms messages right after flash. It's just more convenient then taking the sim card out and putting it back into the device when you're ready (not healthy for the card too).
Not to mention the CDMA phones without simcard, having the radio enabled by default in ROM must be a pain in the ass if you flash several times or hardreset to test different software!
Excellent work on this, cajunflavoredbob!
I look forward to reviewing the results that you come up with on your comparisons.
I am already interested in some of the results that you found in the first tests and will watch that pretty closely.
One thing that I noticed - when I first opened the spreadsheet the colors pretty much come on like a freight train - can those be toned down a tad? These old eyes finally adjusted to them but a lighter shade of colors may be more aesthetic...
Thanks for this contribution!
sh4d0w86 said:
why not just build a rom free of all ext packages?
just sys and oem packages.
that way it is a better comparsion of sys builds.
no?
sh4d0w86.
Click to expand...
Click to collapse
If you read the first two posts, I addressed this twice. That's what I plan to do. I need to get a feel for this myself and find ways of doing it quickly before I move on to the kitchen.
Jackos said:
Disable Sense:
Code:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Today\Items\HTC Sense]
"Enabled"=dword:0
Flight mode on boot:
Code:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\State]
"Phone"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\RIL]
"LastEquipmentState"=dword:00000001
[HKEY_LOCAL_MACHINE\System\State\Phone]
"Status"=dword:00400030
"Radio Ready State"=dword:00000000
Random offtopic: I believe that all roms should have the radio turned off by default.
Click to expand...
Click to collapse
Wonderful! Thanks. This will save some time! I agree with you on the radio being off by default. With the number of times I flash my device during the week, it would really help not to hear the alerts going off twenty times when I start up. I use NRG's ROMs by day, backup with Sprite Backup, and then toy with my personal ROM at night normally. Now, of course, I'm going to be flashing even more than that with this new project.
toucan said:
Excellent work on this, cajunflavoredbob!
I look forward to reviewing the results that you come up with on your comparisons.
I am already interested in some of the results that you found in the first tests and will watch that pretty closely.
One thing that I noticed - when I first opened the spreadsheet the colors pretty much come on like a freight train - can those be toned down a tad? These old eyes finally adjusted to them but a lighter shade of colors may be more aesthetic...
Thanks for this contribution!
Click to expand...
Click to collapse
I can't promise you that I'll get to it, but I'll put it on my to-do list. I basically stole the formatted speadsheet from the other thread. I was about 2/3 of the way through with making my own, when it dawned on me that there was probably one already made. Their formulas covered some things I hadn't yet thought of, so I'm going to be using this for a while.
In other news, I'll be working on this again today, so check for updates tonight. I'll post any updates in the second post.
cajunflavoredbob said:
To-Do List
Change crazy background colors on spreadsheet.
Build clean ROM based on latest T-Mobile shipped ROM
Clean up first post.
Finish learning Italian.
Click to expand...
Click to collapse
One down (see attached).
piaqt said:
One down (see attached).
Click to expand...
Click to collapse
Thanks, but I still need the backgrounds. It helps me find the fields more easily. I'm going to experiment with different colors soon. This isn't my top priority, though. I think, lighter, not brighter colors would do better. We'll see what happens. I'm working on cooking the new ROM right now. Well, not right now, but I'll be starting soon. Hopefully I can get this completed within the week. I can only flash/work at night on this as I need a functioning device during the day.
cajunflavoredbob said:
Thanks, but I still need the backgrounds. It helps me find the fields more easily. I'm going to experiment with different colors soon. This isn't my top priority, though. I think, lighter, not brighter colors would do better. We'll see what happens. I'm working on cooking the new ROM right now. Well, not right now, but I'll be starting soon. Hopefully I can get this completed within the week. I can only flash/work at night on this as I need a functioning device during the day.
Click to expand...
Click to collapse
Haha... I wholeheartedly agree - it is absolutely necessary to have the colors - but perhaps not so bright!

mobile view on webtop

ok as you are aware motorola have a closed source app called mobile view,
My aim is to reverse engineer it to see if we can port it to other distros i.e like gentop / debian.
PROGRESS:
i have already somewhat worked out and have (with errors) a fully working debian wheezy running with some of the webtop apps working and a few errors, I.e sound not working
i have so far got the fact of the program is called aiw it is launched via aiw -d on boot of webtop, In the start-webtop-1.sh script .
i've located all the files it uses to run i can also see the fact it is wrote in c (c assembly to be precise) .
TO DO:
I should have some what of a base code of it by the end of next week. I've learnt alot about the webtop in the last month and i am continuing to learn it till i know it inside and out.
Also i will be started a git repo later for some of my other work
I.e the full debian wheezzy with gnome and gnome panel working on boot
i don't know how to make it into an easy install so help would be nice on that
If any of you wish to help with this then please let me know its not for the faint hearted also mods if you have a problem with this then please let me know / remove the post.
MOD EDIT:
This dude is looking for folks to help him reverse engineer mobile view, a closed source application on the Atrix, for porting it to gentoo or debian. Hopefully he will edit his thread and use some commas or bullets!
MY EDIT:
I Have re-edited it with commas and full stops and capital letters i'm sorry if some of you were unable to read / understand this
MOD EDIT:
I added some badly needed formatting Good luck!
First step is find a keyboard with punctuation symbols on it so you can communicate with the rest of the development community. After that all things are possible.
sorry i do personally suck at grammer
Trying to read this made me mad. :/
Sent from my MB860 using XDA App
Op has serious development intent. Let's try to keep it on topic now that things have been edited.
there we go edited
I'd very much love to see this happen for a couple reasons
1. I imagine this could be used with a linux based PC to run AIW?
2. We could **** all dependency holding like we do in the current ubuntu setups and have a no-break upgradable linux OS.
Little side bit, though might provide incite as to why some apps have issues
Been looking into VNC server on web-top on my How Too in the general section and as I was working on it I noticed that the ported moto applications such as firfox aiw awn and a few others only function only in the adas hdmi environment such as DISPLAY=:0 as set up by a few scripts in /etc/init.d I was wondering as you mess with your development on this if you manage to find out how to set X to share for Xvnc to utilize or can point me in the right set of files to look at I would appreciate it.
-DjAzin
Djazin said:
Little side bit, though might provide incite as to why some apps have issues
Been looking into VNC server on web-top on my How Too in the general section and as I was working on it I noticed that the ported moto applications such as firfox aiw awn and a few others only function only in the adas hdmi environment such as DISPLAY=:0 as set up by a few scripts in /etc/init.d I was wondering as you mess with your development on this if you manage to find out how to set X to share for Xvnc to utilize or can point me in the right set of files to look at I would appreciate it.
-DjAzin
Click to expand...
Click to collapse
aiw and firefox will run in any enviroment there is some security policy's that were set by motorola that only allow certain process to run / access certain files and would autokill things that it it didnt think should be running and shouldnt be running by a certain user ie adas is the only user allowed to start awn and firefox if you try starting it from root it will kill it straight away i will find out the commnds i used to disable this amd post it up later i,m currently out and about atm and not near my computer

Windows 10 preview

Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
gsmyth said:
Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
Click to expand...
Click to collapse
Nope, have no use for it...
I've looked into interfacing with GPIO in C# but found it to be lacking in many ways, the most important being speed. It also appears to be impossible to repurpose pins with ALT functions which Microsoft have fixed to SPI/I2C etc- you can't use them as basic GPIO pins which makes it impossible to use Windows 10 with many, many Pi accessories. I have successfully tested I2C, however, and SPI to an LCD display is next on my list.
As for straight up GPIO twiddling, my litmus test was multiplexing a 7 segment, 4 digit display - not exactly an uncommon or complex activity. I couldn't get a stable timing resolution any smaller than 500 microseconds, and at this point you're plugging decimal numbers into DotNet's TimeSpan.FromMilliseconds and things are getting silly.
I'll have to try it with a straight up loop to see what overhead the threaded timer introduces, but right now Visual Studio is refusing to deploy code at all- probably because I've got a shoddy networking setup to bridge the Windows IOT ethernet-only connection to my PC.
One thing is abundantly clear; if you're not a DotNet/C# developer then it isn't for you.
It's Microsoft, just saying.
gsmyth said:
Anyone gave this a try yet?
http://gizmodo.com/you-can-download..._source=gizmodo_twitter&utm_medium=socialflow
Click to expand...
Click to collapse
It is just for developers. No desktop only app testing. Total waste of time.
gsmyth said:
Anyone gave this a try yet?
I'm also interested in finding out. Haven't tried it myself yet.
Anyone got it running?
How does it compare to 8.1?
Click to expand...
Click to collapse
@wodeh: what do you recommend to use in place of Windows 10 ? How does it compare to linux+python (with RPi-gpio) ?
I never used my RPi for this kind of things, I'm just curious.
@davcri91 it depends what you're familiar with- if you already know C#, use Windows and are familiar with Visual Studio then it will certainly get you off to a good start. Right now, though, support for Pi add-ons in Windows 10 is going to be all but non-existent so it's not the best all-round experience.
Raspbian, the official OS, grants you much more flexibility- you can choose to use Python, Ruby, Node JS, PHP, C, Go or really whatever you fancy. All the current documentation and software support is focussed on this OS, so Pi add-ons- especially more complicated things like our Unicorn HAT or the Pi DAC+- will work.
As for performance, I've yet to try a better test since I couldn't get Visual Studio to upload code to my Pi anymore and didn't want to waste any more time with it. My initial experimentation suggested that C# is tremendously slow at toggling an IO pin though, I couldn't even reasonably multiplex a 4-digit, 7-segment display whereas in Raspbian I can clock out serial data to a 128x64 pixel LCD at 200FPS.
Someone with a more recent working knowledge of C# ( mine is about 10 years out of date ) could probably do somewhat better... I'd hope.
The GUI "Universal App" stuff seems to be a talking point for Windows IoT but this has absolutely no utility in any setup that doesn't have a screen. My preferred setup for Raspberry Pi UIs is HTML/CSS with a RESTful or Web Sockets API- that way I can use my phone, my laptop, or whatever screen/device is handy.
So to summarise:
Windows IoT:
* Targeted at existing C# developers
* Dev-environment with step debugging and all the trimmings
* GUI framework... I think... for better or worse
* Slow to build and deploy
* Slow IO, it seems
* Impossible to use pins reserved for I2C/SPI as general purpose IO, breaking any add-ons that rely on this
Raspbian:
* Complete and total free for all- could probably even use C# with Mono
* Whatever Dev environment you can cobble together.. it'll probably be Sublime Text on your computer plus SCP or VIM/NANO/IDLE
* No standard framework for doing anything, which is a shame- there needs to be an official stance + docs on App/Game dev for the Pi
* You can just run Interactive Python and toggle GPIO pins on and off instantly with commands- fast deployment/test/fail cycle since you're already *on* the device
* IO pins will toggle at 20 Megahertz using C, although the resulting signal will be useless mush
* You can re-assign IO pins as you see fit- SPI and I2C can be regular GPIO, and you can use ALT functions to move some things around
This is a totally top-of-my-head summary of the strengths/weaknesses of each. It's an apples to oranges comparison, though!
You made a really great post, thank you wodeh
For now I think I'll stick to linux because I'm used to Python.

Categories

Resources