yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV ROM Development] Arktronic:
An excellent first post, dblanchard! There are certainly many ways to contact Google devs. What do you think the best one is? Perhaps we should look through the Dream forums, there may be Google devs lurking in them.
[Touch Diamond, MDA Compact IV ROM Development] COCOViper:
There are a couple Android devs here:

http://groups.google.com/group/andr...read/thread/ab553116dbc960da/750968267c31ed58

The first one I can think of is named Brian Swetland
[Touch Diamond, MDA Compact IV ROM Development] jamesd256:
Google and HTC want you to buy the G1, not put Android on you Raphael, so maybe it's not so much of a lack of support, as a veto on supporting the project.

Personally, I would take a fully functional android touch pro over the G1 every time and I'm sure I'm not the only one.
[Touch Diamond, MDA Compact IV ROM Development] Marcellus_pnz:
Totally agree. Plus, I think Google developers doesn't know anything about diamonds hardware, it's HTCs prerogative.
[Touch Diamond, MDA Compact IV ROM Development] hachiroku:
you know honestly...i would PAY to have android on my phone. there is of course a limit, but I WOULD PAY!!! to get this stuipd microsoft junk off my phone.

i do not use direct push for enterprise email anyway. sure its open source, but if we got enough developers together that actually wanted to do this it could work out.
[Touch Diamond, MDA Compact IV ROM Development] NikPraskaton:
Enough talking, make me proud and get this workin` :D hihi
[Touch Diamond, MDA Compact IV ROM Development] jamesd256:
I can imagine all the contributors are dropping everything now and their main motivation in life has become to 'make you proud'.

I know if I could 'make you proud' I would do anything, as my life would be complete and I could die happy.
[Touch Diamond, MDA Compact IV ROM Development] Sig. Gargiulo:
Hi to all,

this project is great !!! :cool:

What is the project's progress?

Bye :)
[Touch Diamond, MDA Compact IV ROM Development] skiwithpete:
Here's a link to the wiki

http://wiki.xda-developers.com/index.php?pagename=RaphaelLinux
[Touch Diamond, MDA Compact IV ROM Development] NikPraskaton:
OMG. I was just tryin to express my gratitude to all the contributors working on this project. And tell ppl on a nice way to stop flooding this thread. (Just like you did now)
[Touch Diamond, MDA Compact IV ROM Development] Arktronic:
Calm down, everyone. No need to start insulting people. This is an Android development thread. Let's try to get back on topic please.
[Touch Diamond, MDA Compact IV ROM Development] jamesd256:
Make me proud

So you're saying 1+1=3?
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
In the FCC documentation for the Sprint Touch Pro, there's a document with internal photos, and it lists the LCD as part number 60H00129-00M (Hitachi). Might be useful to either get the part number for the GSM version and see how they differ, and/or see if there's any documentation online about writing drivers for it.
[Touch Diamond, MDA Compact IV ROM Development] hdzsound:
forget Android GUI I just want a Linux Shell on my phone. A phone with only command prompt gonna be the best thing ever
[Touch Diamond, MDA Compact IV ROM Development] _wizo_:
Do do what with it? Browse the web with lynx?

Diamond is a phone and should remain a phone even after a OS switch
[Touch Diamond, MDA Compact IV ROM Development] Seifer:
well for a start it should be nice. a linux shell that supports most hardware natively. After that Android won't be much of a problem.
[Touch Diamond, MDA Compact IV ROM Development] rl2000:
You should really read this thread before writing statements like that.
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
I don't think the LCD itself is the issue - there is a bridge chip between the qualcomm and the lcd which I think is causing the trouble. Google for "toshiba mddi bridge", and take a look at the google-provided (heh) driver in drivers/video/msm/mddi_client_toshiba.c, and some comments about toshiba in mddi.c. I think this is the component that is either different in the cdma phones, or maybe just isn't getting initialized correctly.

FWIW, it does seem to be returning valid-looking data, but with a different manufacturer id and somewhat different settings that the gsm one. This is what leads me to think the hardware might be a different chip. Or I could just be barking completely up the wrong tree...
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
Seeing as how the display does correctly read from the framebuffer memory area and the screen is correctly updated (which requires interaction with the panel), it seems to me the important part is working.

As only the colors are wrong, I'd say try to look into the palette, color map or what Jobo mentioned earlier, the RGB565/RGB555.

Might be worth to try to dump the framebuffer area in WinCE using HaRET and to see if you can open it in a paint program (i.e. Photoshop) and determine if it's RGB555 or RGB565.
[Touch Diamond, MDA Compact IV ROM Development] brusell:
Let him be Bro.

He is from another world ;o/

He need rather pocket toy then phone....
[Touch Diamond, MDA Compact IV ROM Development] losttrack:
fantastic effort everyone,

at a point i was checking this page 3-4 times a day for updates!!!!

I really wish everyone the best with the developments for this - and it would be fantastic to get it working.

Keep up the hard graft everyone.

warm regards,

Tom
[Touch Diamond, MDA Compact IV ROM Development] jamesd256:
forget Linux Shell I just want a bootloader on my phone. A phone with only a hex editor gonna be the best thing ever
[Touch Diamond, MDA Compact IV ROM Development] chasist:
haha that was funny
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
bars

GSM Raphael is RGB565:

I put a zImage here that draws 16 bars with 1 bit high each when you hit KEY_F1. There is some other stuff fin there that may be unpredictable on diamond (it turns the vkeyb -90deg when you slide the hardware keyboard out), so if you want to build from your own set, you can just put this:

if (key == KEY_F1) {
for (i = 0;i < 16;i++) {
msm_vkeyb_rect(40,80 + i * 32,400,28,0xFFFF - (1 << i),1 << i);
msm_vkeyb_putc('0' + i / 10,232,90 + i * 32,0xFFFF - (1 << i));
msm_vkeyb_putc('0' + i % 10,240,90 + i * 32,0xFFFF - (1 << i));
}
}

..in msm_vkeyb_handle_ts_event() after posting the input events, around line 400.

But let's say you know how the components fit (like RGB555, big endian), do you then know what to put in which fields of the mddi_client_caps structure?

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Jobo - awesome, thanks! I'm heading out of town for a few days, but I'll try this as soon as I can and report back.

The problem that I see with the code is that at least some of it is hardcoded for 565, though it seems to be mostly around loading the logo and images. If it turns out the device really is in 555 mode, I don't think any change to the client_caps structure will make a difference without substantial further code changes. OTOH, if the device really is in a 555 mode, we'd probably be more productive trying to figure out how to tell it to run in 565, which it would presumably support. (obligatory big long chain of conjecture here)... :)
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Ok, definitely different. Bar 03 is the brightest blue, then bar 09 is the brightest green, then bar 13 is the brightest red. 14 and 15 look black.

(00, 04, 05, maybe 06, and 10 also look black, but I assume that some of them are just very dark).

That doesn't even sound like 555? 464? Color me even more confused...
[Touch Diamond, MDA Compact IV ROM Development] fireweed:
Forget the bootloader. I'm going to make my own phone with hookers and blackjack.

In fact, forget the phone.
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
Which ones are the next brightest R, G and B? 12, 08 and 02? If so, it looks like 444 or 454 (does that exist?), in 13:10, 9:6(or 5) and 3:0

I put a new zImage under the same link that draws a couple of different bit patterns on F8,F9,F10,F11. Hopefully that helps figuring it out..

'Confused' .. that would be 0x9E54 on GSM or 0x4F16 on CDMA?

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] mp.goldfinger:
hey guy.....nice work so far......I was reading this forum at the begining and the problem now is SD......yesterday I was playing with my regs and just find a driver dll for SD card I am not sure but maybe that will help us to something. I dont know maybe we can write our own driver from that just an idea.......let me know if that help.....I can put some time on this but need some guides
[Touch Diamond, MDA Compact IV ROM Development] skiwithpete:
Me too, but it seems Druidu has disappeared and Netripper doesn't have the time to really get this going.

Most of the other participants in this forum (like me) are keen to test, but don't have the requisite skills to code the thing. Which is a real shame since Android seems to be where most of the mobile phone innovation is happening.

Not sure where that leaves this us, except patiently sitting on our thumbs.

SWP
[Touch Diamond, MDA Compact IV ROM Development] nashmage:
Ive been in the wait and see category for awhile because id really like to see android in all its glory on my diamond but i also have a sprint diamond so i dont think it will be happening anytime this year. Im a computer science major in college and know a few languages pretty well so now that things are lightening up in class a bit im gonna try and start to look into things and see if i can help
[Touch Diamond, MDA Compact IV ROM Development] -jordann:
Android sounds good but tbh the user interface is plain and ugly, i much prefer touchflo3D...

But it would be good to have the ability to download free applications from the android market. :p
[Touch Diamond, MDA Compact IV ROM Development] fredfredburger123:
Diamond

Hi

just got a diamond and am keen to try android on it as wm6 is really annoying me

am willing to test if anybody wants to develop as am a noob am afraid

Thanks
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Hi Jobo!

Could you post a diff or source like before? The stock kernel doesn't load the gui at all on sprint phones, so I pretty much have to recompile with my changes in place. If you prefer to roll a binary, my original hack patch at http://pastebin.com/m7aefaeb8 should be good enough to let it boot.

Thanks again for all the debugging help - I really appreciate it!

-Hillsdale

BTW, next brightest is 12, 8, 2. I have to think that the phone is doing better than 12 or 13 color in windows, though...
[Touch Diamond, MDA Compact IV ROM Development] ecker2008:
just curious.. has the wiki page been abandoned or at a new location?? (Linux on Raphael).. i'm wondering becuase the last progress update was on 11-7.. and the updates were almost coming daily before that.. thanks!
[Touch Diamond, MDA Compact IV ROM Development] ermin15:
no, there just hasn't been any new progress
[Touch Diamond, MDA Compact IV ROM Development] freakolowsky:
Still no NAND drivers? Any threads with some more information on that front?

I just wish i had time to help ...
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
I took a couple pictures with 1) the code Jobo provided on the previous page, and 2-4) similar code, using RGB( ... 1<<(i+1)-1 ... ) putting that value into each of the r,g,b arguments. Though I think the RGB part is misleading, as the defines in the code say:

#define COLOR_BLACK RGB(0x00, 0x00, 0x00)
#define COLOR_WHITE RGB(0xFF, 0xFF, 0xFF)
// ^ both look appropriate
#define COLOR_RED RGB(0xFF, 0x00, 0x00)
#define COLOR_GREEN RGB(0x00, 0xFF, 0xFF)
// ^ green is not what I would expect...

Unfortunately, i can't find an SD card reader, so it's kind of difficult to grab the pictures :/ I'll get those up soon though. The results are kind of strange. But then I don't know what the difference between RGB565, RGB555, RGB444, etc are.. so it's probably just me being naive :)
[Touch Diamond, MDA Compact IV ROM Development] freakolowsky:
#define COLOR_GREEN RGB(0x00, 0xFF, 0xFF)

?? Red-Yellow-Blue ??
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
I made a different debugging loop and found an interesting result. Does this mean anything to anyone else?

else if ( key == KEY_F5)
{
for( i=0; i<32; i+=2)
{
msm_vkeyb_rect(20,80 + i * 16,120,14, COLOR_WHITE, i);
msm_vkeyb_rect(160,80 + i * 16,120,14, COLOR_WHITE, i << 5);
msm_vkeyb_rect(300,80 + i * 16,120,14, COLOR_WHITE, i << 11);
}
}

This code shows that the red and blue columns get bright to a certain point, then it overflows back to black. But this code makes all 3 colors increment at what seems to be the same amount, so that the first row is all black, and the last row is close to full intensity of the color:

else if ( key == KEY_F6)
{
for( i=0; i<32; i+=2)
{
msm_vkeyb_rect(20,80 + i * 16,120,14, COLOR_WHITE, i/2);
msm_vkeyb_rect(160,80 + i * 16,120,14, COLOR_WHITE, i << 5);
msm_vkeyb_rect(300,80 + i * 16,120,14, COLOR_WHITE, (i/2) << 10);
}
}

Notice the R and B values are halved, and the B value was shifted right 1 bit. Curious to see what the result is for the GSM version.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Finally got the images from my camera (Sorry for the bluriness :/) This one shows the result from the code Jobo provided:

http://privatepaste.com/6103Voc0D8

The result of the first code snippet above:

http://privatepaste.com/88TcbqK8cT

And the second snippet:

http://privatepaste.com/e70FX05ukX

Does that mean anything to anyone?
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Maejrep, thanks for the pictures - definitely something weird. I'm assuming at this point that the hardware needs to be initialized in a way that just isn't happening - I think we've got to figure out how to learn more about the internals. I wish I understand how the memory map and locations were generated (the ones on the wiki).

In other news, some extremely interesting code just hit the android repository, donated by qualcomm for the qualcomm surf (guessing a tablet from the code?). Does a lot of low level hardware initialization, shows exactly how the init the toshiba mddi chip, flash, etc. Actually has support for two mddi manufacturer ids, but neither is the 4ca3 I'm hoping for. :) Worth a look for anyone hacking qualcomm hardware, though.

http://android.git.kernel.org/?p=pl...it;h=90c46cfadcc58a8d9d514bb7eed20db0b0be4310
[Touch Diamond, MDA Compact IV ROM Development] touch of jobo:
Yes. I put it here. Its a bit big because it has a couple of different unrelated changes in it.

- It uses msm_vkeyb_plot(x,y,c) in stead of FBRAM(x,y) = c so that I can more easily experiment with plotting in multiple buffers.

- a static global in msm_vkeyb.c 'vkeyb_landscape' holds whether the hardware keyboard is out.

=> The test for this is !!(readl(MSM_GPIO2_BASE + 0xC20) & 0x00400000)

- The msm_vkeyb_plot() function and the sm_ts_handler() use this global to draw the vkeyb rotated (in plot) and interpret the coords as rotated (in the ts_handler)

- next to the vkeyb is a 'toggle button' to switch the vkeyb on/off. (so that you either click through the vkeyb and into the android gui without posting a input event, or the click gets eaten by the vkeyb and generates an input event..) The vkeyb only gets drawn when active, but doesnt get un-drawn when switched from on to off.

- the msm_ts_handler_t is now int (was void) so as to return whether a click was processed and should be eaten.

- It dumps some mddi related data on startup.

The code I use to draw different kinds of bars is:

for (i = 0;i < 16;i++) {
switch (pat) {
default:
case KEY_F8: /* one bit high at a time, LSB to MSB*/
col = 1 << i;
break;
case KEY_F9: /* all but one bit high at a time, LBS to MSB */
col = 0xFFFF - (1 << i);
break;
case KEY_F10: /* all bits high one by one, LSB to MSB*/
col = (1 << (i + 1)) - 1;
break;
case KEY_F11: /* all bits high one by one, MSB to LSB*/
col = 0x10000 - (1 << (15 - i));
break;
}
sprintf(txt,"%02d %04X",i,col);
msm_vkeyb_rect(40,80 + i * 32,400,28,COLOR_WHITE,col);
msm_vkeyb_rect(200,81 + i * 32,80,26,COLOR_BLACK,0);
msm_vkeyb_rect(64,82 + i * 32,24,24,0xFFFF,0xFFFF);
msm_vkeyb_rect(392,82 + i * 32,24,24,0xFFFF,0xFFFF);
msm_vkeyb_puts(txt,208,90 + i * 32,COLOR_WHITE);
}

COLOR_GREEN shows up as cyan, which makes sense for 00,FF,FF. Only the _name_ is wrong.

I think the most interesting thing is that the sticky keys in the vkeyb in your picture are light green. In the picture on the wiki, they are light red.

This can mean one or both of two things:

1 - we have more than 2 flavors of LCD

2 - rgb-caps of mddi-client-caps really doesn't get initialized and ends up containing what happened to sit in those bits.

(Do those sticky keys (Cap, Shift, Ctrl, Alt) have the same color every time?)

-Jobo
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Mine seem to be always red. One difference is that I'm booting into the android image, and it looks like maejrep is booting to a shell prompt. OTOH, my sticky keys look red even in console mode before the android red blinky loads...

Maejrep, do you have a pointer to the linux shell initrd you are using?
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Are we talking memory address pointers, or ... ;) I'm using NetRipper's busybox initrd, initrd-netripper-busybox-usb.cpio.gz at http://netripper.nl/raphael/

Jobo, yes it is always that light green color. Would my default.txt affect that? I am using "set RAMADDR 0x10000000".. Only thing I can think of that would affect it. I think the haret default for raphael is 0x20000000 (?)

Interestingly, the calibration dots in the UL/BR corners are red, and the pixels where I tap on the screen are yellow (or could have a very slight tint of green)... So if it's just a colormap issue, wouldn't the red calibration dots also appear light green like the sticky keys? I agree it's strange that NetRipper's screen shows the sticky keys gray, both hillsdale and I are getting different colors.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Another thing that seems odd to me, and I don't see this on NetRipper's or hillsdale's pictures, is that my framebuffer seems to get shifted vertically starting at a random point horizontally. You can see it in all three of my images above, but all the images on http://wiki.xda-developers.com/index.php?pagename=RaphaelLinux look correct (minus hillsdale's colors).
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
FYI, the sticky keys should be gray when not pressed and red when pressed.

Also, I'm using RAMADDR 0x1* in default.txt instead of 0x2 because it seems to be more stable. At 0x1* is a 128M memory module, but you can only use about 96M because the part at the end is used as shared memory. At 0x2* is another 128M memory module, which could be used to its full extend I guess, but I have had less stable results (i.e. after soft reset to windows, some apps misbehave until I do a second soft-reset). Not sure why.

I indeed don't have this behaviour. It's always the same making full use of the screen.

(P.S. Would be sweet if everyone could include their device name in their signatures. Would make it easier to see what device they're playing on. Just a suggestion. :))
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
FWIW, just took another look at your images, and the first one has red stickies.

I haven't seen the vertical screen tearing on mine, and bertramt didn't mention it either.
[Touch Diamond, MDA Compact IV ROM Development] maejrep:
Ah, so it is... That's odd. So maybe the framebuffer is getting corrupted at some point, or as mentioned above, getting initialized with a corrupted buffer of some sort. I guess that might explain both the randomly colored sticky keys, and the vertical tearing. But other things aren't that random -- like the red calibration dots after booting, and the results of the F* colored bar tests, and (for the most part) the tux logo. The colors on the logo look to be what I would expect given hillsdale's picture of android. I've not had a chance to boot into android yet. Hillsdale, are you just using the android.bin that NetRipper has on his site?
[Touch Diamond, MDA Compact IV ROM Development] hillsdale:
Yes, but I think I'm using a somewhat different set of kernel patches - I've still got the old invisible calibration, for instance.
[Touch Diamond, MDA Compact IV ROM Development] cibs:
Hi everybody,

let me start of by saying i enjoy reading up, in this thread. the development is has been staggering.

but now i see progress is slowing down. I can't help with development, i don't have the knowledge.

But can somebody tell me what people like me can do to help progress, besides testing? what is the information we need to get things going again?

should i contact HTC for technical specs or something?they would probably not give it, but i could try anyway.

let me know

ps. i mean this in the most positive way!
[Touch Diamond, MDA Compact IV ROM Development] skiwithpete:
I know this will sound obvious, but at the same time... because I'm in your boat.

Start, by finding a problem. For example, the speaker and mic don't work when making a voice call.

So, Find out how to make the speaker and mic work... Find other projects on Android that have changed code - or least what tags lines or variables are needed - to make it work.

Find out what chip maker makes the mic and speaker... see if that info leads anywhere.

... Of course it doesn't have to be speaker and mic - it can be any detail you find interesting.

// I mean this in a most positive way. The beauty of open source is that people share. If I've missed detail, or you can help our friend and help us: share.
[Touch Diamond, MDA Compact IV ROM Development] druidu:
Well, I admit it... it was late when I coded the touchscreen and keyboard drivers, some things might have slipped :D

Also, I'm not even sure if I got the macros for the rgb565 conversion right (and there were many ways to do that anyway). I just wanted to make it work asap so I can get to booting Android & stuff.

Netripper: the only thing my console driver does different from msm_fb is that it skips *all* initialization code (gpios & proc_comm stuff to initialize mddi, mdp, the panel, etc) is skipped. It just maps some area of physical memory to virtual memory, draws to that memory area and uses mddi dma code (same as in msm_fb) to transfer the buffer from the physical address we mapped in the init to the lcd. So, if we use the dummy panel (as in trout board, it has no init code) and disable all the init code from msm_fb (except the one that initializes internal structures, maybe hardcore stuff as lcd size) it should work perfectly.

I've been very busy with work and school (and it's not over yet) so couldn't work on Diamond lately. Hope to get back on track soon!
[Touch Diamond, MDA Compact IV ROM Development] NetRipper:
@druidu

Thanks for the info. Let us know when you're ready to rock again! :)

@Any RAPH800 owners

Could you please test this kernel? http://www.netripper.com/raphael/zImage-raph800-01

It should give the same results as hillsdale original patch. I applied the same patch, but in a different way. I just need to know if this works like hillsdale patch does. Thanks.
[Touch Diamond, MDA Compact IV ROM Development] lavender.t:
USB problem & fix in branch htc-msm-2.6.25

folks,

i tried git out the head of htc-msm-2.6.25, built for my diamond and found the USB doesnt work at all. after adding a few printk()s here and there in msm_hsusb.c, i was able to nail that it was indeed CONFIG_USB_FUNCTION_ETHER isnt enabled in htcraphael_defconfig (and today htcdiamond_defconfig) too.

first time working on this so i wonder how i could check in the change or who could do that for me.

thanks !

- lt