| 00:02.23 | lamikr | If you want to get our sources use command: svn export svn://fuzzyneural.net/h6300/omap-linux/trunk WLAN stuff is under drivers/net/wireless/tiacx |
| 00:04.17 | cp15 | the acx100.sf.net is what my driver is based on |
| 00:04.38 | cp15 | Thanks for the svn trunk |
| 00:05.50 | lamikr | Yes, husam is also based on to that. Actually he told that the acx100 developers have promised to help. But then he got his work things... Husam told that he may be able to get back to h6300 work in next week. |
| 00:06.33 | lamikr | It may be best if you make the diff between acx100 driver and husams driver to find out differences. |
| 00:19.09 | cp15 | Looks quite different... I will try it tomorrow |
| 00:19.37 | lamikr | Ok... Do you still have couple of minutes time with my sms problem? |
| 00:19.56 | cp15 | Sure |
| 00:20.35 | cp15 | BTW: How did you get around yesterdays error? |
| 00:20.39 | lamikr | Btw, if you want to ask from husam, his email is: husamsenussi@hotmail.com |
| 00:23.07 | cp15 | Thanks for the mail, but please only post addresses of people which you don't like in the channel. The channel is logged in a web page, and spambots will find the address soon |
| 00:26.03 | lamikr | ... did not realized...:-( |
| 00:26.14 | lamikr | Ok... Here is my latest test. |
| 00:26.16 | lamikr | message "hello" to 407542928 |
| 00:26.18 | lamikr | printf("sendSMS(), SMS PDU = %s\n", pdu); |
| 00:26.19 | lamikr | --> pdu: 0025000A814070459282010005E8329BFD06 |
| 00:26.21 | lamikr | sprintf(phoneBuffer,"AT+CMGS=%d%c%s%c", strlen(sms_pdu)/2, 0x0d, "0025000C91534870459282010005E8329BFD06", 0x1a); |
| 00:26.22 | lamikr | phoneGetOK_slow(phoneBuffer, TRUE); |
| 00:26.24 | lamikr | --> processReadLine('+CMGS: 89',9) |
| 00:26.25 | lamikr | --> processReadLine('OK',2) |
| 00:26.27 | lamikr | --> tryReadphone return |
| 00:26.28 | lamikr | sprintf(phoneBuffer,"AT+CMGS=%d%c%s%c", strlen(sms_pdu)/2, 0x0d, pdu, 0x1a); |
| 00:26.30 | lamikr | phoneGetOK_slow(phoneBuffer, TRUE); |
| 00:26.31 | lamikr | --> processReadLine('>',1) |
| 00:26.33 | lamikr | --> Unknown Reply '>' |
| 00:26.34 | lamikr | --> processReadLine('+CMS ERROR: 304',15) |
| 00:26.36 | lamikr | --> tryReadphone return |
| 00:27.00 | cp15 | And the pdu is the same? |
| 00:27.36 | lamikr | Ok, let me explain. I modified sendSMD message so that it sends the SMS message twice. |
| 00:28.05 | cp15 | Ah, I see |
| 00:28.42 | cp15 | Have you already tried to swap the two? |
| 00:29.20 | lamikr | Yes, I have tried them many times so that another one is remmed. |
| 00:29.45 | lamikr | So first it printed out the pdu. (pdu: 0025000A814070459282010005E8329BFD06) |
| 00:30.10 | lamikr | Then it prepared the phoneBuffer with sprintf(phoneBuffer,"AT+CMGS=%d%c%s%c", strlen(sms_pdu)/2, 0x0d, "0025000C91534870459282010005E8329BFD06", 0x1a); |
| 00:30.33 | lamikr | and called phoneGetOk --> message went in nicely. |
| 00:31.42 | lamikr | put when phoneBuffer is prepared with the sprintf(phoneBuffer,"AT+CMGS=%d%c%s%c", strlen(sms_pdu)/2, 0x0d, pdu, 0x1a); |
| 00:31.42 | lamikr | phoneGetOK_slow(phoneBuffer, TRUE); |
| 00:32.17 | lamikr | It return +CMS ERROR: 304',15 |
| 00:33.00 | lamikr | (You can ignore the "unknown reply line..." it is there by accident.) |
| 00:33.50 | cp15 | Wait a moment... Try strlen(sms_pdu)/2-1 for the second one... It is shorter |
| 00:35.01 | lamikr | Do you mean that "pdu" has "enter char" in the end or? |
| 00:36.02 | cp15 | I have read something that the length isn't correct on some devices |
| 00:36.45 | cp15 | No, it has one byte less. But the length in AT+CMGS is still the same |
| 00:41.09 | lamikr | Did not work. For some reason the printf of phoeBuffer does not work ok, maybe the <cr> and <ctrl-z> chars are confusing it. |
| 00:42.00 | cp15 | I think it is the different content. Set pdu to the same string you used in sprintf |
| 00:43.26 | lamikr | But before setting sprintf() I use printf("sendSMS(), SMS PDU = %s\n", pdu); method to print the content to screen. When I copy paste that it works... |
| 00:44.19 | cp15 | You mean even if you enter the first string in the sprintf command they behave different? |
| 00:47.45 | lamikr | The first sprintf() contains same pdu that is printed in "--> pdu: 0025000A814070459282010005E8329BFD06" line... (result of printf("sendSMS(), SMS PDU = %s\n", pdu); |
| 00:48.55 | cp15 | No, it doesn't |
| 00:49.26 | cp15 | There is no 4070 in the sprintf pdu |
| 00:52.06 | lamikr | !!! You are correct in this! Btw, I now remmed the first attempt and left only this |
| 00:52.12 | lamikr | sprintf(phoneBuffer,"AT+CMGS=%d%c%s%c", strlen(sms_pdu)/2 - 1, 0x0d, pdu, 0x1a); |
| 00:52.15 | lamikr | and it worked! |
| 00:52.42 | lamikr | Need to test one more time with some other messages than this "hello" |
| 00:53.05 | cp15 | Ok, I will test tomorrow if it works with -1 for me too |
| 00:53.15 | cp15 | But now I go to bed |
| 00:53.18 | cp15 | Good night |
| 00:53.54 | lamikr | Yes, "hello world" worked also. Thanks, I am blind! |
| 00:55.22 | lamikr | I will tomorrow try to clean my mess so that there are minimum changes compared to current cvs code. Maybe we can find something that works for both devices. |
| 00:55.36 | cp15 | Yes, that would be good |
| 00:56.04 | lamikr | One difference I know is the AT command frames... But lets think that tomorrow. goodnight! |
| 00:56.16 | cp15 | Good night |
| 00:57.21 | iclem | llange, i've just booted kernel including your last diff |
| 00:57.45 | llange | cool great piece of news ! |
| 00:58.37 | llange | I'm trying to build a full-featured kernel, however I can't seem to compiled himalaya_ts3 built-in ; it can(t find a symbol (tsc2200_sem). However building as a module is fine. strange... |
| 00:58.42 | iclem | do you have a white stripe on the lcd too with fb? |
| 01:00.19 | llange | no white stripe at all. However I once had an offset, and there was a few values to tweak in himalaya_lcd.c ( himalaya_w100_modes_6 ) |
| 01:01.19 | llange | does it look like an offset ? Or is this white strip in the middle of the screen ? Does it fade ? |
| 01:03.49 | iclem | it is on the right, so i guess it is an offset ? |
| 01:06.04 | iclem | looks like : http://xda-fr.iclem.net/images/hima_linux_1.jpg |
| 01:08.30 | llange | nice but strange. |
| 01:08.49 | llange | perharps there is, like the blueangel, different LCD manufacturers. |
| 01:09.13 | llange | We may have to check the board ID. Is your platform a Qtek 2020 or a 2020i ? |
| 01:09.31 | iclem | Qtek 2020, bard ID 0x20 |
| 01:12.46 | llange | Where do you read such a board id ? |
| 01:14.04 | iclem | in a dmesg with a blueangel kernel |
| 01:15.29 | llange | ok. it's not the same for Himalaya. I don't think the kernel prints it. I'll dig into it. |
| 01:18.42 | llange | I'm trying to print it. I'll send you a patch in a few minutes... |
| 01:21.26 | iclem | ok, you are porting blueangel_board_id() function ? |
| 01:21.59 | llange | yes. |
| 01:44.22 | llange | not as easy as it seems... the board id is on the ASIC3 GPIO, and it needs the ASIC3 to be initialized before reading the IDs... |
| 01:51.59 | iclem | how do it work on BA ? can't we just paste the code and change GPIO IDs ? |
| 01:54.43 | llange | On BA they are using 'standard' GPIO, that are managed by the CPU. On Himalaya, these are Extended GPIO, managed by the ASIC3. |
| 01:54.45 | llange | But I'm nearly finished =) |
| 01:58.22 | llange | Here it is : |
| 01:58.37 | llange | in himalaya.c, add the following function somewhere : |
| 01:58.53 | llange | int himalaya_boardid; |
| 01:58.55 | llange | EXPORT_SYMBOL(himalaya_boardid); |
| 01:58.56 | llange | #define H3900_ASIC3_VIRT 0xf3800000 |
| 01:58.58 | llange | static void |
| 01:58.59 | llange | himalaya_get_boardid(void) |
| 01:59.01 | llange | { |
| 01:59.02 | llange | unsigned int *ptr = (H3900_ASIC3_VIRT + _IPAQ_ASIC3_GPIO_C_Base + _IPAQ_ASIC3_GPIO_Out ); |
| 01:59.04 | llange | int gpioc = *ptr; |
| 01:59.05 | llange | himalaya_boardid=0; |
| 01:59.07 | llange | if( gpioc & GPIOC_BOARDID0 ) { |
| 01:59.08 | llange | himalaya_boardid |= 1; |
| 01:59.10 | llange | } |
| 01:59.12 | llange | if( gpioc & GPIOC_BOARDID1 ) { |
| 01:59.13 | llange | himalaya_boardid |= 2; |
| 01:59.15 | llange | } |
| 01:59.16 | llange | if( gpioc & GPIOC_BOARDID2 ) { |
| 01:59.18 | llange | himalaya_boardid |= 4; |
| 01:59.19 | llange | } |
| 01:59.21 | llange | printk("Himalaya Board ID 0x%x\n", himalaya_boardid); |
| 01:59.23 | llange | } |
| 01:59.24 | llange | And add a call to it, for example like this : |
| 01:59.26 | llange | /* |
| 01:59.28 | llange | <PROTECTED> |
| 01:59.30 | llange | <PROTECTED> |
| 01:59.32 | llange | static void __init himalaya_map_io(void) |
| 01:59.34 | llange | { |
| 01:59.36 | llange | int i; |
| 01:59.38 | llange | pxa_map_io(); |
| 01:59.40 | llange | iotable_init(himalaya_io_desc, ARRAY_SIZE(himalaya_io_desc)); |
| 01:59.42 | llange | himalaya_get_boardid(); |
| 02:00.03 | llange | You must also modify the include file include/asm/arch/himalaya_asic.h : |
| 02:00.09 | llange | #defineGPIOC_BOARDID0(1 << 3) |
| 02:00.11 | llange | #defineGPIOC_BOARDID1(1 << 4) |
| 02:00.13 | llange | #defineGPIOC_BOARDID2(1 << 5) |
| 02:03.47 | llange | But I have a board ID of 4, which seems reasonable : http://wiki.xda-developers.com/index.php?pagename=HimalayaBoardIDs |
| 02:03.49 | llange | PVT means Production, DVT means Development, EVT means Engineering.... So I have a production board. very nice. =) |
| 02:05.17 | llange | I'm afraid this won't give us a clue for your LCD problem. |
| 02:05.18 | llange | Did you have the same white stripe when booting previous kernels ? blueangel for example ? |
| 02:06.31 | iclem | yes, btw the photo is made booting the last blueangel kernel |
| 02:08.47 | llange | ok |
| 02:08.58 | iclem | how have you found the correct modes when you had this offset problem ? |
| 02:10.41 | llange | The blueangel had 2 modes settings, I tried both. And I modified the settings using this page http://wiki.xda-developers.com/index.php?pagename=HimalayaLCD , the initialisation values that were reverse-engineered from WinCE. Perharps I missed some values, I'm going to double-check. |
| 02:28.11 | iclem | wow this kernel is really verbose :) |
| 02:28.24 | *** join/#htc-blueangel idiot (n=idiot@c-24-62-188-126.hsd1.ma.comcast.net) |
| 02:29.55 | llange | try this : himalaya_lcd, around line 265 (in struct himalaya_w100_modes_6), change the value of crtc_dclk from 0xa1700030 to 0x81700030 ? |
| 02:30.53 | iclem | no danger ? :P |
| 02:31.39 | iclem | which option should I turn off in order to have time to read dmesg before it is overloaded ? |
| 02:33.15 | llange | I don't know about danger or not... but it works here ;-) |
| 02:33.16 | *** part/#htc-blueangel idiot (n=idiot@c-24-62-188-126.hsd1.ma.comcast.net) |
| 02:33.17 | llange | concerning dmesg, I'm not sure I understand... your kernel is verbose on the LCD or on the USB-serial ? |
| 02:39.44 | llange | I think I'm gonna go to sleep now... |
| 02:41.05 | iclem | Ok so am i |
| 02:41.38 | llange | cu. bye everybody. |
| 02:41.51 | iclem | bye |
| 02:43.36 | *** part/#htc-blueangel iclem (n=iclem@iclem.net) |
| 05:59.25 | *** join/#htc-blueangel magnet (n=magnet@vsg94-1-82-234-118-20.fbx.proxad.net) [NETSPLIT VICTIM] |
| 05:59.25 | *** join/#htc-blueangel Funklord (n=cow@c-cbd572d5.014-46-73746f28.cust.bredbandsbolaget.se) [NETSPLIT VICTIM] |
| 05:59.25 | *** join/#htc-blueangel collin_away (n=collin@shadow.cs.ucsb.edu) [NETSPLIT VICTIM] |
