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
