i found this, searching google/codesearch for 'ftm_cmd'
svn co http://hwplatform.googlecode.com/svn/trunk/
about 1.5G of datasheets, sourcecode, and tools
for various phones.
willem
Hi!
I've written an introductory text on GSM mobile phone architecture,
and before officially posting/announcing it, I thought I'd invite
the members of this list to do some review and give feedback!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi Jake (and others),
On Tue, Apr 13, 2010 at 10:09:52AM -0700, Jacob Appelbaum wrote:
> > I've written an introductory text on GSM mobile phone architecture,
> > and before officially posting/announcing it, I thought I'd invite
> > the members of this list to do some review and give feedback!
>
> Do you have the latex available? It's hard to edit and send a diff of a
> pdf...
see attachment.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi everyone,
prom is using the crc16 as implemented in the Linux Kernel for his bootloader
work, and I'm planning to add an optional crc16 check for sercomm. To have
crc16 easily accessible in baseband, this commit adds it to libosmocore.
Chris
Hi,
this patch adds a new DLCI, Numbered 11, which just echoes
whatever it recveices on the mobile back to the PC. It is
very useful for debugging serial port problems.
Chris
Hello Christian,
I had the suspicion that a UART reset in the code is missing,
however I could not verify that because I never had those
problems with wrong bytes.
Out of curiousity, have you tried if just the following line is
enough to fix the problems you noticed ?
> + uart_reg_write(uart, MDR1, 0x07); /* turn off UART */
This should cause the UART to be reset and I would expect that
setting the XON/XOFF characters is not needed as long XON/XOFF
handshake is not turned on.
Thanks and best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've seen a lot of systematic character swaps on the serial port,
especially in the vincinity of 0-bytes. As the XON/XOFF registers
are the only thing in the UART that look like they would consider
the actual data sent, I've added this initialisation to uart.c
This makes the problem go away completely on my C123.
To check for it I've added CRCs to the HDLC protocol and checked
for bad frames, and also compared them in a (patched) osmocon
that just sends random garbate in a special DLCI. The bad
frames I observed always looked like this (number in
parenthesis define number of omitted bytes, for brevity):
<------ good bytes ----------> <-recvd|sent-> <----- identical again ------>
d0 e0 00 00..(107)..f7 ce 17 c4 < 0c 00|00 0c > db 70 ba cb..(67)..d8 6d 3a 1f
31 e1 00 00..(47)..38 ca 2f e5 < 0c 00|00 0c > f8 a3 77 5f..(127)..5b 72 ff 4a
<-- good -> <--- bad -----> <---- good again ------------->
dc e1 00 00 < 0c 00|00 0c > 87 cb 24 83..(178)..2f 69 b3 51
ae e2 00 00..(167)..bd 18 6f a1 < 0c 00|00 0c > 2f 53 d2 b2..(7)..da c7 1b 63
dc e3 00 00..(131)..8e 2c b0 a8 < 0c 00|00 0c > 40 62 56 5f..(43)..f0 3a 47 f7
Formerly I was observing about 10 packets for every 2000 sent (with 192
bytes of payload each). Now, with the added initialisation, I see
(as the time of writing this email) 12000 packets with 192 bytes each
sent, with 0 bytes missing, corrupted, flipped).
Please have a look and tell me if it's helping for you. I'll send the
HDLC/CRC patch in another email.
Chris
Hello Andreas,
On Mon, 5 Apr 2010 17:20:24 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i would like to participate (and others maybe too). what if we have
> somethink like a conference for all the people not in berlin?
>
> in our company we do it this way:
>
> - a conference number is dialed by all members.
> - a phone with hands free option can be used on one place where multiple
> members are.
> - netmeeting is used for presentation. this can also be via VNC remote
> desktop.
A conference call sounds good. If it is done this way, I would participate
too.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
when I tried to read the secure-romloader of an Alcatel VLE5-series
phone, I noticed a small bug in calypso_bootrom(), which prom already
tried to fix, but his fix only worked on targets which have nIBOOT tied
to high (Compal).
I've committed a fix for this to steve-m/pending.
Regards,
Steve
Hi!
Andreas has asked me about this, and it might be interesting to a wider
audience, so I've added the information to the wiki at
https://calypso.gnumonks.org/trac/wiki/libosmocore
Here's a copy of what I wrote there:
== Development Cycle ==
As we are still developing the GSM protocol stacks on the network side
(OpenBSC) and phone side (OsmocomBB),
every so often there is a need to add some new code to libosmocore.
Even worse, we sometimes need to break
the API and ABI of the library.
However, by keeping libosmocore in a separate git repository, we run
into one problem: Checking out an old
version of e.g. OpenBSC or OsmocomBB will result in failed builds, as we
don't remember which old version
of libosmocore was required. This makes debugging and things like git
bisect very hard to impossible.
In order to solve this problem, we use
[http://github.com/apenwarr/git-subtree git-subtree] to import the
full libosmocore.git repository into OsmocomBB.
This way, we ensure that there is always a compatible version of
libosmocore inside the tree if we check out old OsmocomBB versions from
git.
=== Making changes to libosmocore ===
'''NEVER COMMIT CHANGES DIRECTLY TO
osmocom-bb.git:src/shared/libosmocore'''
Instead, use the following process:
1. make your changes to your local copy of libosmocore
1. test them together with OsmocomBB and OpenBSC
1. test if libosmocore still builds for both host and target (ARM)
1. create a ''diff'' of your local libosmocore changes
1. apply that diff to the libosmocore.git repository
1. use the script in osmocom-bb.git/src/shared/update-libosmocore.sh
(uses git-subtree) to import your changes from libosmocore.git
1. test + commit your OsmocomBB changes that depend on the newly
introduced code to libosmocore
It is important that the steps are followed in the order state above to
ensure consistency of our repositories
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
