Hi I also want to share my experience with osmocom and USB-serial cables.. My conclusion is clear that it is not a matter of physics (electrical) but of timing constraints. - both chips (cables) Prolific and FDTI show more or less the same behavior regarding successful firmware loading - after loading the firmware none of the cables ever made any problems (thanks to Harald's HDLC layer:-) - Prolific result in smaller buffer sizes used (768) than FTDI (4096) - Prolific is noisy, that means if the plug is not connected to the phone you will see endless random characters received my osmocom - I made some tests on tree different platforms and 3 different mobiles (C123, C139, C155) and the Prolific cable so far: 1. very smal PC with Ubuntu 10.10 Server 2. Vmware with Ubuntu 10.10 Desktop on older MacBookPro 3. VirtualBox with Ubuntu 10.10 Desktop on a new MacPro (6 cores, 6Gb ram) - Generally I got the best results with the C155 and worst with the C123 - On the MacBookPro/Vmware I never could successfully load any firmware on any phone - On the small PC the very first try after a reboot succeeded most of the time. From then on nearly every try failed - On the new MacPro/VirtualBox nearly every Try succeded! Then I ordered a FTDI cable in the hope that this would solve all my problems.. - It supports none standard baudrates - thats cool - But the firmware loading didn't work better... :-(( For me it was then quite clear that i can only be a problem of the timing.. that means the phone is simply not willing to wait so long for the next character to read.. On my small PC I started killing some of the processes I don't use right now (mysql, apache, ..) ... and oh wonder.. the firmware loading worked already much better:-)) The I commented out all printf's which printed something out during the boot-loading.. .. and wow... from then on it worked nearly 100% of the times!! Conclusion: If you have a powerful machine, you probably won't have any problems.. Else, we should probably think about changing the code in use during boot-load slightly. I think that every time the osmocom executable calls select(), and thats a lot of times, the kernel probably reschedules the processes.. and through this increases the chances that there results a to big pause sending data to the phone.. Does this sound plausible? Best regards Matthias

Hello Tomas, Does common USB->2.5 jack work? I have a USB->2.5 jack cable, but I am not sure if it can be used or not. Best Regards, Weicai ________________________________ From: Tomas Kopsa [mailto:deacon@volny.cz] Sent: 2011年1月17日 11:33 To: list_mailing(a)libero.it; baseband-devel(a)lists.osmocom.org Subject: Re: R: Re: C115 loader.compalram.bin Hi Lia, I have tested another cable (USB <-> 2,5 jack, speacial for Compal phones) - it is the same chip (Prolific) and I am able to load firmware too. Although it is the same chip, there is a difference that this one makes the osmocon printing those messages instantly when phone is not connected: got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: f5 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: fd . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: ea If I connect phone, printing stops. Here is what happened when I tried to load firmware without xor (-m c123) and pressed the button: (This happened every attempt without xor flag) Received PROMPT2 from phone, starting download handle_write(): 1087 bytes (1087/50947) got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 45 E got 1 bytes from modem, data looks like: 53 S got 1 bytes from modem, data looks like: 16 . Received DOWNLOAD NACK from phone, something went wrong :( got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 00 . If you have USB adapter (I guess you have), you dont need to check model, check 'lsusb' [root@amilo osmocon]# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port If you have Prolific, which is very common, I encourage you to use xor flag. You can also try to switch on your phone to check if original firmware boots. I experienced during my early tests, that phone crashed (probably SRAM) and it was unable to boot even original fw. In case phone is crashed, reconnect battery and it will fix itself. Here is the ACK after hello world load: handle_write(): 768 bytes (17919/19787) handle_write(): 768 bytes (18687/19787) handle_write(): 768 bytes (19455/19787) handle_write(): 332 bytes (19787/19787) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 42 B Received DOWNLOAD ACK from phone, your code is running now! OSMOCOM Hello World (revision osmocon_v0.0.0-754-gb5abcb6-modified) ====================================================================== Device ID code: 0xb4fb Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: efce3b1ce1001255 ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ============================================== Looking forward your response, Tomas Hi Tomas, thanks for your feedback. Actually, I've tried both flags (woth/without xor extension), but hte result is the same. So, in your opinioni, the problem could depend on the cable? I don't have the cable model now, but I can send you this information Tuesday. Thanks again. cheers. lia ----Messaggio originale---- Da: deacon@volny.cz<mailto:deacon@volny.cz> Data: 16-gen-2011 4.26 A: <list_mailing@libero.it><mailto:list_mailing@libero.it> ubut Ogg: Re: C115 loader.compalram.bin Hello, I have C115 too and I use '-m c123xor' switch, the phone mostly boots on 1st button push (I never reacher full load with '-m c123'). ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/hello_world.compalram.bin ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/layer1.compalram.bin I have FTDI USB<->RS232 + Calypso serial. When load fails (with xor), I have a feeling that it helps reconnection cable to the phone. (I have also Calypso USB cable which I haven't tested yet, will report later.) - Tomas Hello. I'm trying to load the loader.compalram.bin. The behaviour is very strange because sometimes the download is complete and successfull, sometimes; in particular, in this case, the download is complete, but any ACK is sent back from the mobile phone (see below). ./osmocon -p /dev/ttyUSB0 -m c123 ../.. /target/firmware/board/compal_e99/loader.compalram.bin got 2 bytes from modem, data looks like: 2e c8 .. got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(../../target/firmware/board/compal_e99/loader.compalram.bin): file_size=21752, hdr_len=4, dnload_len=21759 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/21759) handle_write(): 4096 bytes (8192/21759) handle_write(): 4096 bytes (12288/21759) handle_write(): 4096 bytes (16384/21759) handle_write(): 4096 bytes (20480/21759) handle_write(): 1279 bytes (21759/21759) handle_write(): finished The target phone is C115. I tried compal_exx and the result is the same :-( Please, can someone help me to understand the reasons? Thanks in advance.