yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
Can you confirm whether this only affects colors for the tux logo, the console, probably even X, but not android? If it looks good everywhere, I'm now officially chasing a ghost.

With the 444 kernel that is, not the mdptest. Using different dma config flags makes things worse, unless this was just not the right combination of flags.

Setting the offsets and lengths of fb_info.fb_var_screeninfo.red, .green and .blue does affect how the tux blits and how the X server draws, but not androids renderer. Not to the point where the output _looks_ different anyway.

Now it appears that android does at least know about the RGB packing settings. In its log, it says:

With the original RGB565 settings:

I/SurfaceFlinger( 291): Client API: OpenGL ES
I/EGLDisplaySurface( 291): using (fd=18)
I/EGLDisplaySurface( 291): id = msmfb
I/EGLDisplaySurface( 291): xres = 480 px
I/EGLDisplaySurface( 291): yres = 640 px
I/EGLDisplaySurface( 291): xres_virtual = 480 px
I/EGLDisplaySurface( 291): yres_virtual = 1280 px
I/EGLDisplaySurface( 291): bpp = 16
I/EGLDisplaySurface( 291): r = 11:5
I/EGLDisplaySurface( 291): g = 5:6
I/EGLDisplaySurface( 291): b = 0:5
I/EGLDisplaySurface( 291): width = 51 mm (239.058823 dpi)
I/EGLDisplaySurface( 291): height = 38 mm (427.789459 dpi)
I/EGLDisplaySurface( 291): refresh rate = 60.00 Hz
I/SurfaceFlinger( 291): OpenGL informations:
I/SurfaceFlinger( 291): vendor : Google Inc.
I/SurfaceFlinger( 291): renderer : Android PixelFlinger 1.0
I/SurfaceFlinger( 291): version : OpenGL ES-CM 1.0

With the RGB444 xxRrrrGg-ggxxBbbb packing:

I/SurfaceFlinger( 291): Client API: OpenGL ES
I/EGLDisplaySurface( 291): using (fd=18)
I/EGLDisplaySurface( 291): id = msmfb
I/EGLDisplaySurface( 291): xres = 480 px
I/EGLDisplaySurface( 291): yres = 640 px
I/EGLDisplaySurface( 291): xres_virtual = 480 px
I/EGLDisplaySurface( 291): yres_virtual = 1280 px
I/EGLDisplaySurface( 291): bpp = 16
I/EGLDisplaySurface( 291): r = 10:4
I/EGLDisplaySurface( 291): g = 6:4
I/EGLDisplaySurface( 291): b = 0:4
I/EGLDisplaySurface( 291): width = 51 mm (239.058823 dpi)
I/EGLDisplaySurface( 291): height = 38 mm (427.789459 dpi)
I/EGLDisplaySurface( 291): refresh rate = 60.00 Hz
I/SurfaceFlinger( 291): OpenGL informations:
I/SurfaceFlinger( 291): vendor : Google Inc.
I/SurfaceFlinger( 291): renderer : Android PixelFlinger 1.0
I/SurfaceFlinger( 291): version : OpenGL ES-CM 1.0

..yet when I draw 565 data in the frame buffer it looks normal in both cases, but also it makes no difference to how android draws. :confused: The only thing so far that does affect how android looks is the mdp dma flags but that just looks too ugly. Could it be an android opengl thing rather than a kernel thing?

Will continue to 'investigate' (tinker around)..

-Jobo

BTW: Changing those color settings has weird side effects:

The X server doesn't stay up after boot, like it would with normal settings,

Killing a manually started X server does drop back to or redraw the console, like it would with normal settings,

The server crashes as soon as I kill 1 client, with the normal settings it would stay up.
[Touch Diamond, MDA Compact IV ROM Development] dcordes:
Jobo, I'm excited X works that well on the raphael/diamond. your observations seem to exclude the refresh problem we have on the kaiser and polaris. need to sort out what is the difference between the two framebuffer codes.

Angstrom uses tslib for the ts input. If you want to mess with the touchscreen in X in the angstrom images, check /etc/ts.conf /etc/profile.d/* . in the conf file play around with the settings - I have no clue what you need for raph ts driver. make sure you set the correct input device env var in the profile.d file.

You can calibrate (produce a /etc/pointercal file) when you have the ts-calibrate. try opkg update; opkg install tslib-calibrate . you could use nfs.

If you need anything special in the image, tell me what and I can produce a few builds. btw everybody is welcome to ask for such images. If you want to roll your own,I detailed on openembedded a few pages earlier.

edit: X init is either /etc/init.d/xserver-nodm or /etc/init.d/gpe-dm

btw venus100 (xperia x1) has the same color problem like raph800, see http://xdaforums.com/showthread.php?t=456595
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
diff (NOT FULLY FUNCTIONAL)

alrighty as you wish ... :) there is a new file clock-7x00.c to be added to the mach-msm/ dir. the mmc-diff.patch is my git index diff (some unrelated files removed), and config.diff are 2 extra debug switches i enabled in the .config file.

<DISCLAIMER: blahblah ... :D>

- lt
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
Thanks for the .diff. I just took a quick look, and looks good. I'm going to take a better look tomorrow... I'll clean out some of the color stuff though. It can be added when there's a working setup for both RAPH800 and RAPH100 (and equally for DIAM*).

To answer your question, the keyboard bit is always '1' on Diamond. So when the kernel boots, it always detects it as being landscape, making the keyboard vertical right away from boot. Makes it a bit annoying for Diamond ;) Would be nice if there's some runtime way to detect if it's a Diamond or a Raphael. Anyway, somewhere in the near future we may need to split Raphael and Diamond anyway, giving the Diamond its own board file and MTYPE.

@lavender.t, thanks for the diff. I'm aware of the disclaimer :p I'm also going to take a look at that tomorrow.

Need sleep.
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
Sure. I would suggest to only pick out the keyboard drag and non-flicker stuff. The colorspace stuff hasn't given any real success yet (not in android anyway).

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
I'd love to, but right now I can't get my phone to boot beyond the rtc clocks message, followed by 4 trout_pwrsink_set lines. As of that point, I can only see the tux logo in color, but that logo is correct. If I can figure out why I don't get to the calibration, then I can try to find out the rest of what you're asking.
[Touch Diamond, MDA Compact IV ROM Development] evilxhwnd:
I am having the same issue on my fuze.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
So, with tmzt_'s help on irc, I stepped through each revision starting with the one known-good revision that I had tried in the past, and found the usb-ether revision to be the offending one that made my phone stop booting. The frustratingly easy fix was to disable USB_FUNCTION_ETHER in .config :eek:

Anyway, I'm able to boot again -- anyone with raph800 having that problem, you can try disabling that, or I'm gonna try another fix now. When I plug USB into my phone, I get a popup asking if I want to connect in activesync mode or in "disk drive" mode. I've been selecting disk drive mode, because it registers as a USB mass storage device, which I can mount and transfer my newly compiled kernel over with. But I think that's part of the problem, since as of when haret takes over, the USB interface might still be in mass storage mode, which the ether driver isn't able to cope with. I'm gonna try it now with that enabled, and with USB set in activesync mode before booting.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
This fixed the problem, btw.

Anyone with a Sprint (or other) raph800 getting the kernel lockups after trout_pwrsink_set lines, make sure you set the phone back to "activesync" mode before starting up haret.

# ping 192.168.2.206
PING 192.168.2.206 (192.168.2.206) 56(84) bytes of data.
64 bytes from 192.168.2.206: icmp_seq=1 ttl=64 time=2.57 ms

Success :)

Jobo, now I think I'll be able to try out android to see how the colors are affected, since this kernel also has your 444 fix for msm_fb.

NetRipper: you should choose a not-so-standard subnet for the phone's IP next time :p my router uses 192.168.0.0 so I had to change the IP on the phone for it to work.
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
Heh, ok. I'll think about that next time. Good job tackling the boot problem. Updated wiki faq with the info.
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
I am now convinced that my earlier hack to draw 444 into the fb fixes everything except android, because android just draws 565 no matter what you tell it.

Color space conversion in android is done in at least a couple of places (opengl/libagl, surfaceflinger/blurfilter, pixelflinger/scanline, ...) but I'm not sure whether it is viable to go in there.. ..if anyone has a setup in place that allows experimenting with that, I would be interested to hear test results.

Does anyone know whether the opengl and related libs in android 1.0 are the same as in 0.8 or whether I can replace the libs in the test initrd with those from 1.0?

Another approach would be that the hardware is capable of working with 565 pixel data but its set to the wrong mode. This must happen during kernel boot as I can't imagine that windows would run in 444 if it could run in 565 mode.

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Using this as inspiration, I dumped the framebuffer memory in haret and used fbgrab with 16 and 15 bpp (doesn't support 12bpp I guess?) to convert it to a PNG, and while I'm not sure why only a portion of the image is visible -- I probably screwed something up somewhere :) -- the difference is quite clear between the 16 (565) and 15 (555) bpp images, and seems to indicate that WM is in fact drawing 565 to the framebuffer.

So if I'm doing things correctly, that should mean that either a) WM is capable of putting the display into a 565 mode that we aren't doing in linux, or b) WM is drawing 565 to the framebuffer, and there's a conversion taking place for every frame draw from 565 to 444. Obviously (b) would be incredibly inefficient and it would make more sense for them to just draw 444 to the framebuffer directly, which makes (a) the more plausible reason. Does my reasoning seem sound?

If I knew how to dump the correct area of memory to see capabilities, it might help explain which of the two it is. Any tips or suggestions?
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
You're right. I tried android.bin, and saw the same thing that hillsdale did (pictured from the wiki). If you're asking for someone to test your changes, let me know -- if you're asking if I've done it myself, nevermind :)
[Touch Diamond, MDA Compact IV ROM Development] computerguru:
I have a question about how the display resolution works with the kernel. Is it a) using the video mode from Windows Mobile, or b) does the kernel set the mode during the boot stage?

If it's (a), I could try writing some code to access the GPE driver from within Windows Mobile to change the color mode (should be able to do it via GetModeInfo and SetMode...if the driver allows it.)

If it's (b), what happens if we skip the kernel-based video mode initialization and use the mode provided by Windows Mobile?...since it may already be in the 565 mapping. If you want, I could write some code to do some visual comparisons between different shades of green...to see if Windows Mobile is doing the conversion. The chipset for the DIAM500 should be able to support it...I mean...the TFT supports 262,144 colors.

http://developer.sprint.com/device/loadDevice.do?id=859d2565-15e1-47ca-aba0-3fcb4d5bc3b2

Sorry if my questions have already been answered...but I don't have time at the moment catch up from page 80 onwards...lol. :)
[Touch Diamond, MDA Compact IV ROM Development] kurgandk:
hah!!

I love the update subject line... :D
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
mmc now works for my diamond, yay !

finally got a clock and timing combination that works for my diamond ! was able to mount my "internal storage":

$ telnet 192.168.0.206
Trying 192.168.0.206...
Connected to 192.168.0.206.
Escape character is '^]'.

BusyBox v1.13.0 (2008-11-28 00:52:00 PST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# dd if=/dev/mmcblk0 count=1 | hd
1+0 records in
1+0 records out
00000000 eb fe 90 4d 53 57 49 4e 34 2e 31 00 02 08 20 00 |...MSWIN4.1... .|
00000010 02 00 00 00 00 f8 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 78 00 00 1e 00 00 00 00 00 00 02 00 00 00 |..x.............|
00000030 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 80 00 29 12 00 43 08 20 20 20 20 20 20 20 20 20 |..)..C. |
00000050 20 20 46 41 54 33 32 20 20 20 00 00 00 00 00 00 | FAT32 ......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
# mkdir mnt
# mount /dev/mmcblk0 /mnt
# ls /mnt
Content/ MSMETADATA/ WMPInfo.xml* android/
EncFiltLog.menc* My Documents/ YouTube/ storage/
Live Search/ VerInfo.txt* album.vol* wmdrm/
# ls /mnt/android/
android-initrd.cpio.gz* haret-big.exe*
default.txt* haret.exe*
default1.txt* initrd-android-raphael.cpio.gz*
default2.txt* initrd-netripper-busybox-usb.cpio.gz*
default3.txt* initrd.cpio.gz*
defaulta.txt* ramdisk.img.gz*
defaulto.txt* zImage*
haret-0.5.2.exe* zImage.old*
#

i'll give a few more tries after i wake up to see how stable it is.

cheers ! :D

- lt
[Touch Diamond, MDA Compact IV ROM Development] beboxed:
WOOOT! Go lavender.t!

btw, is this in DMA mode or PIO?
[Touch Diamond, MDA Compact IV ROM Development] rl2000:
Nice dude! Nice!
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
Awsome. Good job. :)

I'll await a diff ;) Good night for now, well deserved ;)
[Touch Diamond, MDA Compact IV ROM Development] balsat:
I love you man!!! ;)

Can't wait for a diff.
[Touch Diamond, MDA Compact IV ROM Development] nuke1:
Not sure if this is relevant, or even if it's known:

http://www.pocketnow.com/index.php?a=portal_detail&t=news&id=6459
[Touch Diamond, MDA Compact IV ROM Development] liamhere:
glad you liked it.....and the thread is running good again :)
[Touch Diamond, MDA Compact IV ROM Development] holydhaliwal:
Does this mean that we will soon be able to load up android 1.0? or am i missreading?
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
mmc code diff.

if you cant wait to try, here are the diff file and clock-7x00.c. it is not final yet so forgive the code quality. and ... yes i realized the msm_sdcc.c change can be done by the kernel parameters. :)

- lt
[Touch Diamond, MDA Compact IV ROM Development] Willis111:
I'm getting a warm fuzy feeling in my pants right now.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Any tips on what I should look for to see if raph800 is different, and/or how to debug it? Right now it boots with your patch, but there's no /dev/mmcblk*

# cat /sys/kernel/debug/mmc0/ios
clock: 0 Hz
vdd: 0 (invalid)
bus mode: 1 (open drain)
chip select: 0 (don't care)
power mode: 0 (off)
bus width: 0 (1 bits)
timing spec: 0 (legacy)

# dmesg | grep -i slot
[ 1.510183] mmc0: Slot eject status = 0

[ 1.490183] mmc0: Qualcomm MSM SDCC at 0x00000000e1001000 irq 26,0 dma 8
[ 1.500427] mmc0: 4 bit data mode enabled
[ 1.508026] mmc0: MMC clock 2640000 -> 18480000 Hz, PCLK 66000000 Hz
[ 1.510183] mmc0: Slot eject status = 0
[ 1.520061] mmc0: Power save feature enable = 0
[ 1.527598] mmc0: DM non-cached buffer at ffc03000, dma_addr 0x15bc9000
[ 1.530335] mmc0: DM cmd busaddr 364679168, cmdptr busaddr 364679936
[ 1.540122] mmc0: Polling status mode enabled
[Touch Diamond, MDA Compact IV ROM Development] tughi:
on-screen keyboard

I just compiled the cupcake branch... In the emulator you can use now the on-screen keyboard :)

Update: screen shot
[Touch Diamond, MDA Compact IV ROM Development] holydhaliwal:
Awesome, would you be able to post a screenshot of the keyboard? i can't locate one online for some reason...
[Touch Diamond, MDA Compact IV ROM Development] lattiS710:
Hi guys, I dont have time to read all this 114 pages and I am wondering, how does this project goes? Are we going to be able to have Linus/Android on our diamonds soon?

peace
[Touch Diamond, MDA Compact IV ROM Development] jeforce:
Look at the wiki => http://wiki.xda-developers.com/index.php?pagename=RaphaelLinux ;)
[Touch Diamond, MDA Compact IV ROM Development] Black_Angel:
When will somebody update the wiki with the latest version of Android adapted for our HTC Touch Diamond?

Because it seems the on-screen keyboard is functionnaly etc...
[Touch Diamond, MDA Compact IV ROM Development] brumle80:
less than 24 hours since the post about that, hint hint....
[Touch Diamond, MDA Compact IV ROM Development] liamhere:
as title says...." not yet working"....so to keep upto date.. if you don't have time to read all those pages .....please try to read at least the last page....you may get a hint of where the project stands at this moment in time.
[Touch Diamond, MDA Compact IV ROM Development] dcordes:
sorry for adding even more noise on top of the most important mmc topic.

can someboy please try reading and writing from /dev/smd0 on the raph100 raph800 and diam? make sure the radio is turned on in windows mobile and ready to make calls at linux boot time. tia
[Touch Diamond, MDA Compact IV ROM Development] Willis111:
most important mmc topic? screw that someone just got the on-screen keyboard working! Read the wiki, the latest version of android ported to the touch diamond is available there. If you actually read the post that ? made about compiling cupcake and booting it with an EMU ... you'd realise that he didn't boot it using a phone, he did it all on a computer which would make that the latest version of android ported to the touch diamond emulator. I think the holdup is that though there has been a huge breakthrough by my personal hero lavender.t in mounting his sd card in android no one else has been able to duplicate it yet and we're lacking storage space to run android 1.0. If I'm wrong here feel free to correct.
[Touch Diamond, MDA Compact IV ROM Development] sibbor:
Looks great! Hopefully we'll be able to progress further as soon as we get the mmc stuff working out. l.t did a really great job there :D

As most of us here already knows "cupcake" is based on the Linux kernel 2.6.27.

Just to keep the spirit high I'm quoting what they say about the "cupcake" development branch:
[Touch Diamond, MDA Compact IV ROM Development] tughi:
Last time i checked cupcake was still based on 2.6.25... At least this is reported by the emulator's "about phone". But I guess this will change soon.
[Touch Diamond, MDA Compact IV ROM Development] dcordes:
how about a userspace thread and keep this one kernel development only?
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
well actually...

HaRET will load, unpack and boot into an image just over 33M (!! Thirty-three of your Earth megabytes), which would fit a trimmed down android 1.

(I've been (yet unsuccessfully) trying to put together an android 1 image in a single root ramdisk. It boots the kernel, starts android runtime, then complains about not being able to load frameworks. This has more to do with me not knowing what I'm doing than with android 1 requiring internal storage.)

So not mounting the internal storage should not necessarily stop you from running android 1. (You just need to know what you're doing :)) But still, with no access to (persistent) storage, anything you do is just for the sake of it.

Mounting the internal storage makes it possible to run the vogue way, which is with a small initrd that mounts the /system and /data filesystems from 2 files on internal storage. I'm guessing we need to mount at least the data fs read-write for stuff to work.

This boy can. (Sorry ;)) It says:

+CREG: 1,"0460","415B"
+CGREG: 0
@HTCCSQ: 3
+CREG: 1,"11B5","2F2D"
@HTCCSQ: 4
@HTCCSQ: 3
+CREG: 1,"11B5","2F2B"
@HTCCSQ: 4
[... I call my raphael from a landline. The Xs are really numbers .. mine]
+CRING: VOICE
+CLIP: "+315XXXXX15",145,,,""
+CRING: VOICE
+CLIP: "+315XXXXX15",145,,,""
+CREG: 1,"11B5","2F2B"
+CGREG: 0
+CRING: VOICE
+CLIP: "+315XXXXX15",145,,,""
@HTCCSQ: 4
[... I hung up. It goes back to reporting CREGs and HTCCSQs]

..on a GSM raphael. Should I also test with wifi / gps / fm tuner enabled, or is that different radios? What would you like me to write to it?

..and change the title to 'Linux on HTC Diamond & Raphael working to some degree. Android? What android?'

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] balsat:
Android 1.0

I manage to boot into a ext2 partition on /dev/mmcblkp and got android 1.0 running on it... I unpacked http://www.netripper.com/raphael/20081204-01_raph_diam_angstrom_usb/initrd-angstrom-usb.cpio.gz and unpacked data and system from Android image to the sdcard.

But after i rebooted there is problems starting Android... strange.
[Touch Diamond, MDA Compact IV ROM Development] dcordes:
echo AT to it while reading in the background. you should get 0. echo ATV1 and you should get OK

why not
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
smd0

i got similar results as jobo on my diamond when calling in:

# cat /dev/smd0
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
+CRING: VOICE
+CLIP: "+1425xxxxxxx",145,,,""
@HTCDIS: 0013,1

when writing AT or ATV1 cmd to /dev/smd0, no response was seen from the cat side.

- lt
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
a little cleaned up mmc patch

no further news. just cleaned up the code in clock-7x00.c (now support setting clocks for SDC 1 - 4), pulled in the rest of the clock code from clock.c. also temporarily added a kernel option "msmsdcc_id=" (1 - 4, my DIAM100 uses 2) to allow changing the sdc to try without recompiling the kernel.

the diff is attached. i havent seen any one else reported success or failure in diamond yet. i hope this patch could at least workaround diamond's mmc issue.

maejrep and netripper found the patch not working for raphael. i didnt have a clue yet but it appeared to be the clock still not correct for raphael.

i may try if android 1 works in my diamond when i got some time to spare. there are still quite some other significant issues to tackle with so we still need to use some patience ... :(

happy holidays, at least ... :)

- lt
[Touch Diamond, MDA Compact IV ROM Development] dcordes:
ok so obviously AT tx doesn't work. we should fix this in order to talk to the modem from linux. I don't know where the rx/tx offsets from smem base are set in this tree.

lt, did you try adding the clock rate calculation thing cr2 proposed?
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
Does anyone know how to read / interpret the table in /drivers/video/msm/mdp_csc_table.h or for that matter the mdp_default_css[] at the top of mdp.c ?

Thanks,

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] abc12345:
does this mean that you have partial sd support?
[Touch Diamond, MDA Compact IV ROM Development] mdrobnak:
I've read through some of this thread, and I'm happy to see things are moving along. I've got an HTC Fuze. I'd like to know: what can I do to further along development? I'm rusty in C/C++, and have done assembly before on x86...

A few questions:

Are we reverse-engineering from the windows drivers? Are we allowed to do that?

How have we gotten as far as we have in terms of memory locations, IRQs, etc?

Basically, what kind of tools and refrences should I be looking at to try and get this storage & audio stuff (what seems to be the next major stumbling blocks) going...

Thanks,

-Matt