osmocon and boot loader experience
thatsit at gmx.ch
Mon Jan 17 20:38:36 UTC 2011
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!!
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?
More information about the baseband-devel