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
i managed to get hello_world working on my c121, connected through a
pl2303 usb/serial cable to my macbookpro.
but found that the connection is extremely noisy.
often the movement of me putting down the phone on the table is enough
to break the upload.
is that a common problem with these headphone/serial cable plugs?
for the serial device i can use /dev/cu.PL2303-0000201A
or /dev/tty.PL2303-0000201A
but when using the '/dev/tty...' variant, i have to add this to osmocon.c
diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
index f934dd7..b361eb1 100644
--- a/src/host/osmocon/osmocon.c
+++ b/src/host/osmocon/osmocon.c
@@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev)
/* hardware flow control off */
options.c_cflag &= ~CRTSCTS;
+ /* ignore modem status lines */
+ options.c_cflag |= CLOCAL;
+
/* software flow control off */
options.c_iflag &= ~(IXON | IXOFF | IXANY);
=============================
willem
Hi,
First off, thank the community--OsmocomBB for launching and then sharing the
development of mobile protocol stack first.
As we can understand, the current mailing list has been acting as the
primary way of communicating between one another on the project basis.
For these quick questions as well as immediate discussions, however, most
likely there should be yet another way to complement, like irc on the
freenode.
Or, for the above issue you guys out there have other ways to solve, eh? If
so, please take me into the circle as well, just because I have too many
questions to ask. :)
Thanks.
Best Regards,
Samuel
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
i had a similar problem with an unconnected input pin which caused a
reset of a microcontroller, just by moving some centimeters in a
distance of one meter. check if you have left unconnected input pins on
your USB converter. what about hardware flow control input? (RTS/CTR)
andreas
hi harald,
>> must random value in chan_request change on every resend or only on
>> every RR establishment? (currently it changes on every RR
>> establishment only.)
>
>as far as I know, it has to change on every retransmission. Dieter is
>probably the person who knows all RACH aspects in detail, maybe he can
>comment on this.
from the specs it is quite clear that every access burst has different
random number when resending. but how does the network know if the burst
is from the same phone but retransmitted? in case of poor uplink many
bursts may be resent. will the network allocate a channel for every
burst received and waits for timeout? (if this is the case, emergency
calls could quickly 'evacuate' the cell.)
>> OpenBSC: if tx-msg fails during process, the msg must be freed to
>> avoid memory leak.
>
>I don't understand, can you please explain this further?
it is something to remind me that there are memory leak problems. in
some functions of gsm_04_08.c there are messages allocated at the
beginning and sent at the end. sometimes during processing, the function
returns due to error conditions, but the message is not freed before
return. i will check that later together with my new code.
as far as i can see right now, it just happens in gsm48_cc_tx_setup().
regards,
andreas
Hello Andreas,
On Mon, 29 Mar 2010 13:39:21 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> from the specs it is quite clear that every access burst has different
> random number when resending. but how does the network know if the burst
> is from the same phone but retransmitted? in case of poor uplink many
> bursts may be resent. will the network allocate a channel for every
> burst received and waits for timeout? (if this is the case, emergency
> calls could quickly 'evacuate' the cell.)
It does not even need a poor uplink. I experience this behaviour for example
with OpenBSC and the nanoBTS. If the "Immediate Assignment" is not sent
fast enough, a retransmitted RACH burst will allocate another channel
(the timeout for releasing an unused channel is around 2 to 5 seconds in
"real" GSM networks). The maximum number of the retransmitted RACH burst
is controlled by a parameter in the SYSTEM INFORMATION messages (there
are several parameters which control the RACH transmission behaviour).
Of course a "bad phone" can ignore those parameters and a DoS attack
with continuous RACH bursts works quite well because the BTS or
network does not know from which phone the burst come from.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Christian,
On Mon, 29 Mar 2010 13:27:31 +0200, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> I'm using a self-made cable consisting of a known good FT232R
> converter @ 3.3V and a cut off headset cable (that also worked
> flawlessly without any noise on another mobile phone before). My C123
> also looks pristine. I manage to upload and run hello world
> successfully in maybe one out of ten attempts, often have to remove
> the battery because the phone just gets stuck. So I have ordered a new
> cable from Akku-King as suggested on the Wiki.
My experience: I work under Windows with Cygwin so the OS internals
how the serial port is handled are (totally) different than Linux.
With the non-blocking variant of "osmocon" it was nearly impossible
to download the code to the phone in a reliable way. So I had to apply
an ugly hack to my version which basically switches the serial connection
to "blocking mode" during the download phase. This way it works rather
reliable here (regardless of using a "real" RS232 port or an USB to serial
converter).
So you might experience the same problem instead of a bad cable. You
can try the attached patch to "osmocom.c". The patch is not for the
latest GIT version, however it should be quite easy to apply it to
the current on. Again, its an ugly hack, but it works for me.
Best regards,
Dieter
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Willem,
On Mon, 29 Mar 2010 12:39:35 +0200, "willem" <itsme(a)xs4all.nl> wrote:
>
> but found that the connection is extremely noisy.
> often the movement of me putting down the phone on the table is enough
> to break the upload.
> is that a common problem with these headphone/serial cable plugs?
Hello Harald,
On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> as far as I know, it has to change on every retransmission. Dieter is
> probably the person who knows all RACH aspects in detail, maybe he can
> comment on this.
According to the specification the random value has to change on every
transmission:
a random reference which is drawn randomly from a uniform probability
distribution for every new transmission.
In the TSM30 firmware this is done by having a table with random values
and an index into the table which is initialised to a random value when
the Immediate Assignment Procedure is started and incremented with every
random number taken for a retransmission. The table has 32 values because
the random reference is not larger than 5 bits.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi Andreas,
some comments regarding your issues.txt:
> must random value in chan_request change on every resend or only on
> every RR establishment? (currently it changes on every RR
> establishment only.)
as far as I know, it has to change on every retransmission. Dieter is
probably the person who knows all RACH aspects in detail, maybe he can
comment on this.
> must be expanded: struct osmocom_ms:
no problem here, expand it how you see fit. I just generally prefer
caller-allocated structures to callee-allocated ones, and I'd like to
use static allocation whenever possible. So if there's only one 'struct
rrlayer' per ms, then we should simply include 'struct rrlayer' as
sub-structure of 'struct osmocom_ms', rather than having two structures
and pointers between them.
> OpenBSC: if tx-msg fails during process, the msg must be freed to
> avoid memory leak.
I don't understand, can you please explain this further?
> random acces via RSL?
I think we simply add some new / non-standard primitives, as it does not
have any notion of RACH bursts.
It might also be possible to encode it as UNIT DATA REQUEST for channel
(chan_nr) RACH (CCCH uplink), but then we still cannot specify details
like at which frame number, etc. From what I can see, your
RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement
we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom
RSLms message and nothing specified in the original RSLms spec.
Cheers,
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)
Hi,
I started to play around with osmocon, but unfortunately my serial
cable (a FTDI232RL module from Sparkfun connected to the 2.5mm plug,
this one is set to 3v3 and worked flawlessly for several projects!)
seems to be quite unreliable in the host -> handset direction.
But to not procrastinate, I did some cleanup in osmocon to escape
non-printable output and added new "-c" option to start straight into
HDLC-mode without uploading any firmware to the mobile.
Are those kinds of mostly cosmetic patches appreciated or considered
unnecessary?
Chris
Hi,
what's currently the recommended toolchain for bb-osmocom?
The wiki says on http://bb.osmocom.org/trac/wiki/AreasOfWork
that most people are using gcc 4.0.2 from http://gnuarm.com/
but the binary there is only for x86_64 which I don't use.
So, as I've got to build from source, I'm going to download
the latest binutils/gcc/newlib(?) for that. Is it a good idea,
or are there known problems with gcc binutils 2.20.1/gcc 4.4.3?
Greetings,
Chris
Hi!
It seems we're loosing serial characters on their way from the (Linux)
PC to the phone.
I think I've seen this at some point in the past, but now I'm seeing it
constantly.
Let's assume we're trying to send the following sequence of bytes from
the PC side to the phone in one of the HLDC connections:
> send_to_phone(dlci=5): 0a 00 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
> 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
> 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
what we actually get from the sercomm callback on the phone is:
> l1a_l23_rx_cb: 0a 00 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12
> 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a
> 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d
as you can see, there is a '00 01' missing between the '00' and the '02'.
Interestingly, putting a usleep(10000) after every serial write does not
solve the problem, so it is not timing related. We don't get any UART
overflows on the calypso, either.
If I change the data pattern, then the first bytes are transmitted fine,
but as soon as there is one 00 bytes, two characters are missing from
the stream.
If I strace osmocon, it is clear that we write every character,
including the null-bytes, and all of the writes are successfully.
I've again looked at (and played with) the termios settings, but could
not find any problem (nor solution).
It's also not the sercomm layer that is loosing bytes, as I the
characters appear already lost when printing them from within the
calypso UART driver, as you can see here:
getchar_nb(1) = 7e // flag character
getchar_nb(1) = 05 // hdlc
getchar_nb(1) = 03 // hdlc
getchar_nb(1) = 0a // l1ctl_hdr (undefined msg_type 10)
getchar_nb(1) = 00 // padding
getchar_nb(1) = 02 // here should be 00, 01, 02...
getchar_nb(1) = 03
getchar_nb(1) = 04
getchar_nb(1) = 05
[...]
Any ideas? It's really strange and I don't really know what else to do.
I'm quite sure our binaries contain multiple successive null-bytes and
their download is working great...
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)
Hi *,
i have an Motorola C123 without a battery and without a charger.
Can someone told me pinout of the battery Connector so that I can connect a nokia battery?
Or can I use a 5v power supply and connect it to the charger port and the phone boots without a main battery?
Bjoern
-----
#- Björn Riemer
#- FOKUS - Fraunhofer Institute for Open Communication Systems
#- -Sensor Applications and Networks -
#- Kaiserin-Augusta-Allee 31
#- 10589 Berlin, Germany
#- phone: +49 30 3463-7747
#- fax: +49 30 3463-8000
#- email: bjoern.riemer(a)fokus.fraunhofer.de <mailto:bjoern.riemer@fokus.fraunhofer.de>
#- http://www.fokus.fraunhofer.de <http://www.fokus.fraunhofer.de>
attached is a patch with several minor fixes:
added missing param in call to gsm48_rx_bcch.
added 'extern' in .h files for declarations of rsl_rlm_cause_strs and
target_board.
added several 'const' for strings.
removed useless 'bufptr,' from hexdump.
willem
Hello,
I'm very new here and I wanted to ask if you already choose an OS? On
the website I read that you don't want to use FreeRTOS. Is this
information still up to date? Which RTOS u want to use instead? I have
found a small summary of potential candidates at wikipedia:
http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
the best candidate seems to be BeRTOS, but i think it could be a little
bit too much (e.g. it has a complete graphics subsystem).
Regards
Arne
This is a Mailman mailing list bounce action notice:
List: baseband-devel
Member: osmocon(a)ngolde.de
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
mailman(a)lists.osmocom.org.
Hello Erik,
On Fri, 19 Mar 2010 09:51:48 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote:
>
> Yes. Mine has special US Tracfone firmware which seems to have a
> particularly evil unlock scheme. Cutting one of the balls in the BGA
> seems the way to do it..
I had a quick look at the bootloader from a dumped Tracfone C139
firmware. Its nearly the same the Osmocom loader supports, however
this special bootloader checks a flag in flash memory to decide wether
to allow RAM download or not. If it is disabled, only the FTMTOOL
check is done and no RAM download at the boot stage is possible.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
today my serial cable finally arrived. As in the meantime a driver for
the C155 display was added I am searching for new things I might be able
to do.
The AreasOfWork lists under Build System
"we need a clean/known base as a compiler"
As a LFS user I'm used to compiling my own software and as I did for the
toolchain which currently consists of
binutils-2.19.1
gcc-4.3.4
newlib-1.18.0
and as I now have the cable, I can confirm that it works.
The instructions in the support section of gnuarm.com work well if you
have the needed libs (gmp, mpfr, ...) and not picked a broken version of
binutils or others.
So my questions are:
(1) Is this still a todo or did someone work on it?
(2) What needs to be done?
Thanks for all your work, this is amazing,
Florian Tobias Schandinat
Hello Erik,
On Fri, 19 Mar 2010 07:42:06 +0100, "Erik Ekman" <yarrick(a)kryo.se> wrote:
>
> I did some more research and it seems even the unlocking people are
> having the same problems here. So I will just wait for my other phone.
I do have one C139 here, it works with the "board/compal_e88/hello_world.bin"
firmware and the "-m c123xor" option for "osmocon", however without the
display working (its a different display). If I boot the normal phone
firmware, I also see some output and have the same "AT" behaviour you
reported.
But maybe there are different versions of the C139 so that some work and
others don't.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi
I just got my cable and am trying to download any code into a C139
(tracfone software, bought from usa on ebay).
This is what I get:
$ ./osmocon -m c123 -p /dev/ttyS2 compal_dump.bin
waiting for data
got 7 bytes from modem, data looks like: 66 74 6d 74 6f 6f 6c
Received FTMTOOL from phone, ramolader has aborted
got 1 bytes from modem, data looks like: 65
got 1 bytes from modem, data looks like: 72
got 1 bytes from modem, data looks like: 72
got 1 bytes from modem, data looks like: 6f
got 1 bytes from modem, data looks like: 72
^C
Hello Andreas,
On Thu, 18 Mar 2010 10:41:32 +0100, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote:
>
> i prefer the CNC machine solution. it looks pretty easy to me. in my
> example white = fully cut out. black = no cut, light gray = more
> deep , dark gray = less deep.
Looks good, do you have access to a CNC machine and what costs would
you expect for a prototype ?
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi,
I've been slowly working on the DSP code for some time now and I
tought I'd post a status here in case other people are interested.
The ultimate point of this is to add support for things the DSP isn't
supposed to do. Like receiving the raw demodulated data without the
deciphering / fire code / whatever. Or dealing with raw speech data
... sending other type of burts like SCH / FCCH, or receiving other
type of bursts like RACH, ...
The DSP ROM dumper has been present for a while but there was no way
to really use the output efficiently.
For that, I've written a parser that takes the console log output and
converts it into a COFF file that you can load in your favorite
disassembler.
I've been working with IDA 5.6 mostly and I made several enhancement
to it to support the calypso better (the tms320c54 module is part of
the SDK and can be modded and recompiled) :
- Add support for memory mappings so that the same memory zone can
'appear' at several place in the address space (to handle data & code
overlay)
- Fix the section handling when loading a file:
. to set XPC properly,
. to not override section name
. to support more than 2 sections
- Fix a bug in cross reference detection when dealing with section
having selectors != 0
- Add stub support for the type system. This allows loading of a .h
header file with the NDB structure definition
- Add definition for the IO ports so that they are symbolically displayed
Here's a sample results of what it looks like now (without much manual
fixups, just loading the files and declaring a couple addresses as
being structures) :
http://www.246tnt.com/files/calypso_dsp_ida_sample.png
It becomes clear what function does what :)
I'll try to push a maximum in my dsp branch tomorrow. I can't put the
IDA processor module modification because even just the patch contains
some hex-rays code, so I guess I'll have to ask them permission on a
case by case basis to distribute it. (just ask me privately and we'll
work it out)
Cheers,
Sylvain
Hello,
Just a note about the RS-232 cable from Dealextreme:
http://www.dealextreme.com/details.dx/sku.14664
This is a direct connection cable, this means that there is no
level-converter between the phone and the RS-232 port from the
PC. Despending on the RS-232 port of the PC, I would expect that
this can/will damage the phone. I have one of those cables here
and can confirm that there is no level-converter in between.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Thu, 18 Mar 2010 12:17:18 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> The SIM obviously relies on a filesystem. Some files are defined as
> mandatory in TS11.11, so I will include them, but their size is not always
> fixed. I'm opening this thread to define this kind of information.
Maybe useful:
https://sites.google.com/site/savolabs/Home/tools
Its about a tool (SIMbrush) to extract all EFs from a SIM. Besides the
source code there is also a PDF file with the results from scanning a
standard SIM, it contains the file size for the EFs of the scanned SIM.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
I'm making progress on the SIM/Filesystem applet. Data access commands are
working, I'm now working on writing commands that send replies formatted as
defined in TS 11.11 instead of FCI responses.
I need input from you: I'm only a "smart card" guy, I can do "whatever is
needed", but I need to define *what* is needed with you. I know especially
nothing about GSM itself except that the MS talks with the SIM to manage
cryptography, store SMS and phonebooks entries, etc.
The SIM obviously relies on a filesystem. Some files are defined as
mandatory in TS11.11, so I will include them, but their size is not always
fixed. I'm opening this thread to define this kind of information.
-what should be the N value for files whose size is defined by "3*N, N>=4"?
-what optional files will be needed when the layer 2-3 will be ready to talk
with the SIM?
I let you read the TS11.11 spec to make your choice.
Thanks,
Sebastien
hi,
i prefer the CNC machine solution. it looks pretty easy to me. in my example white = fully cut out. black = no cut, light gray = more deep , dark gray = less deep.
two thick metal peaces are cut from a metal band. the left one has partly cut out path for the frame to cut from the card. the right one has partly cut out area to carry the card. the frame is lower than the border, so the card will be positioned before it is cut out.
hole in the left plate (white dots) will help to remove the plastic inside the frame path.
andreas
Hello Chris,
On Thu, 18 Mar 2010 08:34:18 +0100, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> Maxim alone has about a dozen variations of the MAX232 (max3232 for 3v3, e.g).
>
> It's much easier to directly go from USB to TTL/3v3 serial ports, the
> basic breakout boards from Sparkfun (e.g.
> http://www.watterott.com/de/FTDI-Basic-Breakout-33V) seem to be fine
> and sell for ?12. Haven't used them on a C123-phone, though.
Thanks for the info. I am a bit old-fashioned when it comes to
serial communication, I prefer to use "real" RS-232 because its
much more predictable with regards to timing. For the USB serial
adpaters it depends on the used interface chip. Of course for
"standard" serial communication where the timing is not critical
an USB serial adapter is just fine.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Thu, 18 Mar 2010 08:07:23 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> You can now be sure: the 3.3v part is the MAX 3232.
> Other parts exists that need smaller capacitors (100nF) instead of 1-10uF
> required by the "grand father" MAX232 :)
Thanks for the update.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Lubomir,
On Thu, 18 Mar 2010 01:00:44 +0100, "Lubomir Schmidt" <gentoo.lubomir(a)googlemail.com> wrote:
>
> How can i change the cable to get it working? What is a
> level-converter and where can i get such?
The level of the RS-232 interface is specified to be -3V..-15V for a
logic one and +3V..+15V for a logic zero, typically -12V and +12V is
used. The phone uses 0V and 3.2V. So you need a level-converter between
the RS-232 port of a PC and the phone.
The simple solution is to use a ready-made data cable with a built-in
level-converter, they cost around 9.00 EUR on ebay Germany including
shipping, either as USB or RS-232 variant. If you really want to build
your own level-converter, you can for example use the MAX232 IC. The
MAX232 is for TTL level (0V and 5V), I think there is a variant for
3.2V available, however I am not 100% sure.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Tue, 16 Mar 2010 10:04:07 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> I know that smart card EEPROMS are rated for 100k writes, but I would not
> rely on that. In fact, this depends on how often is the EF.Kc file written,
> which was my original question. Every 30 seconds or every day? Every day is
> of course OK.
It is only written if an AUTHENTICATION REQUEST from the network is
performed. This usually happens when the phone is turned on and
does a location update. The network can also perform an AUTHENTICATION
REQUEST when doing a call or similar things, however usually this is
not done every time and the previous Kc stored on the SIM is reused
as Sylvain explained it. For OpenBSC and OpenBTS the default is that
there is no AUTHENTICATION REQUEST at all, so no Kc is written (I am
not 100% sure if this is true for OpenBTS, but I guess so).
> Additionally, how often are these other files written (LOCI, BCCH) ?
They are written when a location update is done or the cell changes.
However it depends on the phone if the data is really written to the
SIM every time, sometimes the phone caches those data and writes them
to the SIM only when the phone is turned off. For OpenBSC and OpenBTS
writing should not happen that often because there is usually only one
cell with fixed parameters. And I guess you will probably not actually
write to the EEPROM if the same data is already stored (or a least
the Card OS should do it this way).
> SmartCardFocus has a ID0 cutting service, that can turn any card into a SIM
> sized module:
> http://www.smartcardfocus.com/shop/ilp/id~82/p/index.shtml
> This is the best option I know so far.
Thanks, I did not know that. It would be interesting to know what tool
they use and if it is available for a reasonable price.
> However for devel purposes, as layer 2-3 will be developed on a PC, most
> people will need/use a PCSC reader and a normal sized card. Any javacard
> will do, even dual interface cards such as JCOP31 or Cosmo or older
> Cyberflex. my applet will have no specific requirement on javacard support,
> JC 2.1.x or 2.2.x will do.
Yes, sure.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I'm trying to run the layer1 firmware and the layer23 program
with an C123, however as soon as the firmware reports a layer 1
reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone,
it appears to crash and sends a new PROMPT1, causing an endless
cycle of firmware uploads and following crashes.
Bisection failed due to compiler errors, using trial-and-error
I found that the last instructions successfully executed are in
l1a_l23_rx_cb(), case L1CTL_NEW_CCCH_REQ, just before the
tpu_end_scenario() call. tpu_end_scenario() is what appears to
be triggering the crash, more specifically its the tpu_enable()
call in tpu_end_scenario().
Any hints how to debug this further?
For reference, this is the output of osmocon:
$ ./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/layer1.bin
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
handle_write(): finished
Received DOWNLOAD ACK from phone, your code is running now!
Hello World from apps/layer1/main.c program code
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Dropping sample '~'
===
THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
hdlc_send_to_phone(dlci=5): 01 00 00 00 00 00 14 00
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
Received PROMPT2 from phone, starting download
and so on.
Hello Sebastien,
On Tue, 16 Mar 2010 00:09:46 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> Sylvain, if I evolve your algorithm, then I think we don't need to store
> anything in EEPROM. Just keep that in RAM and force a renegociation at MS
> boot. What do you think of that?
Just a question: Why do you want to avoid writing Kc to the EEPROM ? The
cards I know have a quite huge number of EPPROM write cycles, e.g. for a
certain MULTOS card the number is specified to be 500.000. I don't know
the number for the card you use, but I expect it to be at least 100.000.
For our purpose this should be really good enough, I would expect more
writes to EF LOCI and EF BCCH than to EF KC.
A question to the list: does anyone know where to get a tool to
cut out a SIM from a standard smart card ? I don't prefer doing this
with a knife or similar, this might only be OK for one or two pieces
and the result also does not look too good.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
(sorry dexter , this was intended for the list - someone has to fix the
reply-to address of this group)
Hi all,
Tonight I worked on the sim implementation with javacard. I will update this
thread with my progress.
A few minutes ago, I completed the most important parts selection and
creation code, that allows me to create any directory structure on the card.
There is no security yet, only the highway to what is necessary. Side roads
will be added later.
My implementation has a Master File (MF) and the possibility to create
directories (Dedicated Files, DF) like in any unix file system. File
identifiers are 2 bytes long (Long identifier or LID). The MF is the tree
root, with LID 0x3F00, and DFs can be nested to "any" level.
I have a command to select directories, then create directories inside. this
is the equivalence of :
cd / (select MF)
cd .. (select parent DF)
cd <dir> (select a file with its LID, be it the parent, a brother or a
child)
mkdir <dir> (create DF)
Everything related to this is described in ISO7816-4 (creation in
ISO7816-9).
You'll be happy (or not) to find BER-TLV encoded data here, too.
I'm now focusing on having a ISO7816-4 compliant card applet whose code is
separated from the filesystem implementation. This way, I'll be able to
quickly switch from the ISO7816-4 commands to the TS 11.11 apdu commands.
This is only a matter of what information is returned from the SELECT FILE
apdu, and what selection modes are supported.
In the coming day I'll focus on data file (EF) implementation, along with
the READ and UPDATE commands.
Select commands allowing content browsing are planned too (select first/next
child)
The current code is not in the global git yet, I prefer keeping it in my
personal SVN until the first release. However if anyone is interested in
looking at the code, I can provide access to it.
Let me say this is quite specific code that will not be usable by everyone.
You need skills in javacard, globalplatform and smart cards in general.
Regards
Sebastien
PS: Guess the format of the current "Card FAT" :-)
idx ty sf lid fch nxt par
0000: 01 00 3F00 0001 FFFF FFFF
0001: 01 00 2000 0002 0003 0000
0002: 01 00 3000 FFFF 0004 0001
0003: 01 00 4000 FFFF FFFF 0000
0004: 01 00 5000 FFFF FFFF 0001
OK, that was easy, just a list of entries forming a tree with "next" "child"
and "parent" links. data files have a corresponding data block at the same
index in another list.
I can nest just everything I want, and create any number of files (well, atm
256, that is configurable, and the max file size is 32kB, that is fixed by
the max array size in javacard - signed short ) until the card is full.
tree corresponding to the list (index:file id):
0000:3F00
+--- 0001:2000
| +--- 0002:3000
| +--- 0004:5000
+--- 0003:4000
Hello Nathan,
On Sun, 14 Mar 2010 17:54:29 +0000, "Nathan Fain" <nat(a)fains.com> wrote:
>
> because i was on the python route I went ahead and wrote code all the way
> through uploading. I was expecting I would get a NACK but instead I get
> neither a NACK nor ACK but the following response after uploading hello
> world. Just curious if anyone has ever seen this before:
What you see looks like the strings inside the binary you send
to the phone. So your download code either echoes back what you
send or there is a problem with the cable (e.g. shortcut between
RX and TX). The phone usually does not echo back what it receives,
at least I never saw that.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I'm running into a problem with sercomm. oscmocon is unable to write()
the CMD after PROMPT1 is received. I've attached a quick python client
that checks from PROMPT1 and then sends CMD to confirm that it responds and
its not something with the local system (OSX).
Relevant code with some added debugging:
static int handle_read(void)
{
if (!memcmp(buffer, phone_prompt1, sizeof(phone_prompt1))) {
printf("Received PROMPT1 from phone, responding with CMD\n");
dnload.print_hdlc = 0;
dnload.state = WAITING_PROMPT2;
rc = write(dnload.serial_fd.fd, dnload_cmd, sizeof(dnload_cmd));
/* not in src, added for debugging: */
if (rc <= 0) {
printf("error writing CMD to serial\n");
exit(1);
}
...
$ ./osmocon -m c155 -p /dev/tty.usbserial \
../../target/firmware/board/compal_e99/hello_world.bin
got 1 bytes from modem, data looks like: 1b
got 6 bytes from modem, data looks like: f6 02 00 41 01 40
Received PROMPT1 from phone, responding with CMD
could not write CMD to serial
Output from python script:
(if you try this, be sure to set your serial port and change the python2.5
call on line 1)
$ ./compalserialtest.py 115200
got byte(s) from phone: 1b
got byte(s) from phone: f6
got byte(s) from phone: 02
got byte(s) from phone: 00
got byte(s) from phone: 41
got byte(s) from phone: 01
recieved PROMPT1 from phone. Writing CMD
got byte(s) from phone: 1b
got byte(s) from phone: f6
got byte(s) from phone: 02
got byte(s) from phone: 00
got byte(s) from phone: 41
got byte(s) from phone: 02
got byte(s) from phone: 43
--
cyphunk://cypherpoet.comnathan://squimp.comfain://deadhacker.com
hi,
here is one issue that stopped me today:
sometimes l3 message headers includes protocol header: see struct
gsm48_imm_ass
and sometimes it is just the information element part: see struct
gsm48_loc_upd_req
since i work with layer 3 messages, i need a uniform way to define these
headers. i will add new headers for messages i implement to gsm_04_08.h.
therefore i need a decision. i prefer that the headers (like
gsm48_imm_ass or gsm48_loc_upd_req) consists of the information elements
parts only. i must put gsm48_hdr in front of it whenever i create a l3
message. when parsing that message, i must skip the information element
part in the decoding function. when creating the message, i always add
the l3 header (with it's content) and the information elements.
creation would look like this
struct msgb *msg = gsm48_msgb_alloc();
struct gsm48_hdr *gh = (struct gsm48_hdr *) msgb_put(msg,
sizeof(*gh));
struct gsm48_imm_ass *ia = (struct gsm48_imm_ass *)
msgb_put(msg, sizeof(*ia));
gh->protocol = ....
gh->msg_type = ....
parsing would look like this:
struct gsm48_hdr *gh = msgb_l3(msg);
struct gsm48_imm_ass *ia = gh->data;
unsigned int payload_len = msgb_l3len(msg) - sizeof(*gh) -
sizeof(ia);
tlv_parse(&tp, &rsl_att_tlvdef, ia->data, payload_len, 0, 0);
note: payload_len is where the TLV part of the information elements
start.
any suggestions?
andreas
first build, grabbed repository today. ran into some issues running make
from src.
ERROR 1 (snippits):
cd host/layer23 && autoreconf -i
cd host/layer23 &&
LIBOSMOCORE_LIBS=/osmocom-bb/src/shared/libosmocore/build-host/src/.libs/libosmocore.a
LIBOSMOCORE_CFLAGS=-I/osmocom-bb/src/shared/libosmocore/include
./configure
./configure: line 3361: syntax error near unexpected token `LIBOSMOCORE,'
./configure: line 3461: `PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore)'
SOLUTION:
i do have pkg-config installed, as well as aclocal 1.10. Commenting out
line 3461 continues. Perhaps the errors that happen thereafter are a
result of this.
ERROR 2:
cd host/osmocon && autoreconf -i
cd host/osmocon &&
LIBOSMOCORE_LIBS=/osmocom-bb/src/shared/libosmocore/build-host/src/.libs/libosmocore.a
LIBOSMOCORE_CFLAGS=-I/osmocom-bb/src/shared/libosmocore/include
./configure
./configure: line 3364: syntax error near unexpected token `LIBOSMOCORE,'
./configure: line 3364: `PKG_CHECK_MODULES(LIBOSMOCORE, libosmocore)'
SOLUTION:
same
ERROR 3:
arm-elf-ld -nostartfiles -nostdlib -nodefaultlibs --gc-sections -T
board/common/compal_ramload.lds -Bstatic -Map
board/compal_e88/hello_world.map -o board/compal_e88/hello_world.elf
--start-group apps/hello_world/main.o board/common/compal_ramload_start.o
abb/twl3025.o rf/trf6151.o display/font_r8x8.o display/font_r8x8_horiz.o
display/st7558.o display/ssd1783.o display/display.o flash/cfi_flash.o
calypso/libcalypso.a layer1/liblayer1.a lib/libmini.a comm/libcomm.a
../../shared/libosmocore/build-target/src/.libs/libosmocore.a
board/common/rffe_compal_dualband.o board/compal_e88/init.o
board/compal_e88/board.o --end-group
calypso/libcalypso.a: could not read symbols: Archive has no index; run
ranlib to add one
make[1]: *** [board/compal_e88/hello_world.elf] Error 1
make: *** [firmware] Error 2
$ cd target/firmware/calypso/
$ ranlib libcalypso.a
ranlib: warning for library: libcalypso.a the table of contents is empty
(no object file members in the library define global symbols)
Any clues?
thanks
--
cyphunk://cypherpoet.comnathan://squimp.comfain://deadhacker.com
Hi,
I've noticed there is no detailed info on the C140 in the wiki as the
shielding is soldered on this model. I opened that one on my C140 today
by force (ripping it apart, more or less), dunno yet if the phone survived
but at least I got some nice photos of it now :-)
I put the relevant info and photos up at my wiki:
http://randomprojects.org/wiki/Motorola_C140
I don't think I have access to the bb.osmocom.org wiki, but feel free to
merge any of the info or photos you like, all my C140 photos are in the
public domain.
Most of the hardware is very similar to the C123 as far as I can see.
The display may be a small problem as it's a Toppoly TD014THEA3 for
which I haven't yet found a datasheet. It probably has an integrated
controller, or at least I didn't find an external controller on the PCB.
I'll try to figure out some of the connections of the test pads on the
PCB in the next few days, will report back when I know more.
Uwe.
--
http://www.hermann-uwe.de | http://www.randomprojects.orghttp://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Hi,
I've played a bit with osmocom on a C155 here, but there seems to be an
issue with the UART/puts/printf code somewhere. I'm using latest git as
of today.
$ src/host/osmocon > ./osmocon -m c155 -p /dev/ttyUSB0 ../../target/firmware/board/compal_e99/hello_world.bin
got 2 bytes from modem, data looks like: 00 00
got 5 bytes from modem, data looks like: 1b f6 02 00 41
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/hello_world.bin):
file_size=18560, hdr_len=4, dnload_len=18567
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
got 1 bytes from modem, data looks like: 02
got 1 bytes from modem, data looks like: 43
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/18567)
handle_write(): 4096 bytes (8192/18567)
handle_write(): 4096 bytes (12288/18567)
handle_write(): 4096 bytes (16384/18567)
handle_write(): 2183 bytes (18567/18567)
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
got 1 bytes from modem, data looks like: 03
got 1 bytes from modem, data looks like: 42
Received DOWNLOAD ACK from phone, your code is running now!
Hello World from apps/hello_world/main.c program code
At this point there seems to be a hang. However, it looks like the LCD
is being partially initialized (?), at least the backlight is enabled
and there's a white screen (no "Hello world" on it though). I assume
this is because the display driver for C155 is not yet fully merged?
Also, the wiki says "The LCD controller inside the display is a
Ultrachip UC1682", is this really correct? The code has "ssd1783"
as display driver name.
Anyway, after removing a newline and some print functions I see some
more output (see attached patch for what I changed), which is why I
expect a problem in puts/printf, the UART, or the \n handling etc:
$ src/host/osmocon > ./osmocon -m c155 -p /dev/ttyUSB0 ../../target/firmware/board/compal_e99/hello_world.bin
got 7 bytes from modem, data looks like: 1b f6 02 00 41 01 40
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e99/hello_world.bin):
file_size=18404, hdr_len=4, dnload_len=18411
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
got 1 bytes from modem, data looks like: 02
got 1 bytes from modem, data looks like: 43
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/18411)
handle_write(): 4096 bytes (8192/18411)
handle_write(): 4096 bytes (12288/18411)
handle_write(): 4096 bytes (16384/18411)
handle_write(): 2027 bytes (18411/18411)
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
got 1 bytes from modem, data looks like: 03
got 1 bytes from modem, data looks like: 42
Received DOWNLOAD ACK from phone, your code is running now!
Device ID code: 0xb4fbDevice Version code: 0x0000
Here it hangs after the newline in the "Device Version code" line.
Any ideas what the problem could be?
Thanks, Uwe.
--
http://www.hermann-uwe.de | http://www.randomprojects.orghttp://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Hello Sylvain,
On Thu, 11 Mar 2010 01:18:06 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote:
>
> I've been slowly working on the DSP code for some time now and I
> tought I'd post a status here in case other people are interested.
Great that you work on the DSP part. I am working with the DSP code
for a while, mainly to look up things for my Layer1 experiments
if the meaning of API RAM fields are not clear from the header
files only. I also use the latest IDA Pro version (I am a Hex-Rays
customer too), however without much dealing with the Data ROM
till now, the Code ROM was good enough so far.
> The ultimate point of this is to add support for things the DSP isn't
> supposed to do. Like receiving the raw demodulated data without the
> deciphering / fire code / whatever.
I already found the location in the internal DSP RAM where the raw
bits of a frame from four normal bursts are stored. They are stored
as "soft" bits (16-bit value) and are already deinterleaved. It
should not be too hard to patch the appropriate functions and move
the raw bits to some unused location in the API RAM so that they can
be accessed from the ARM. So getting the raw bits of one timeslot
is probably rather easy, however getting the raw bits of all timeslots
is a different thing. I did not look at this in more detail because
there are currently other more important things to do in Layer1.
> Here's a sample results of what it looks like now (without much manual
> fixups, just loading the files and declaring a couple addresses as
> being structures) :
> http://www.246tnt.com/files/calypso_dsp_ida_sample.png
> It becomes clear what function does what :)
Yes, I have seen this code ;-).
> I'll try to push a maximum in my dsp branch tomorrow. I can't put the
> IDA processor module modification because even just the patch contains
> some hex-rays code, so I guess I'll have to ask them permission on a
> case by case basis to distribute it. (just ask me privately and we'll
> work it out)
Great. I am interested in your modification to IDA Pro (feel free
to ask Hex-Rays of course, they should know me).
As a side note: IDA Pro is an extraordinary tool and the support from
Hex-Rays is great. So if one use IDA Pro regulary, Hex-Rays really
deserves it that a licensed copy of IDA Pro is used and not a pirated
one. I am not related to Hex-Rays, just a happy customer for a long time.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
hi,
after a break of one week, the firmware doesn't seem to be built.
when typing make clean followed by make or make firmware in ./src/
here is the tail of the output:
make -C target/firmware CROSS_COMPILE=arm-elf-
make[1]: Betrete Verzeichnis '<snip>/src/target/firmware'
make[1]: Für das Ziel »default« ist nichts zu tun.
make[1]: Verlasse Verzeichnis '<snip>/src/target/firmware'
what am i doing wrong?
I was preparsing the TS M30g smStack a bit and
came out with something like this:
http://netplugin.sourceforge.net/ ++append+next++
htmltag/CC/cc_act.c.pinfo.main.php
(please concat the two url parts).
I wondered weather I could support this project a
bit by processing some more of the TS M30 files.
However somebody has to tell me which ones are the
relevant files to take into account. (Another limitation is
the sourceforge mysql db limit...) Description on how
to navigate:
- Press on macros to expand
- Press on expanded macro names for "definition"/place+view
- "[<]" shrink macro expansion
Also some hint:
Isnt there a software only way to run the stack:
Put even Layer1 on the PC ? Then connect
directly to BTC software? Kind off skip the messy
embedded thing altogether for development.
-- Gruesse HopsingK
