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
Hello,
I couldn't find any possibility to register for a trac-account. I assume
it is intentional that only the maintainers may change content (I could
see reasons for that)? If so, is there a chance to keep the todo-list
updated? I know by now that there is already work ongoing for the
C155-display driver. I just became unsure which other topics may already
been worked on.
Kind regards,
Wolfram
PS: One for the news section maybe?
http://www.pro-linux.de/NB3/news/1/15336/1,osmocombb-will-mobilfunk-mit-fre…
hi!
we now have a 'struct timer_list' API, its use is similar to that of
the linux kernel (and openbsc).
The caller (e.g. your driver/app) allocates a 'struct timer_list', sets
the 'cb' function pointer to a callback function, and then schedules the
timer with 'schedule_timer(&my_struct_tm, 600) for expiration in e.g. 600ms
from now.
Once the timer expires, it will call the callback. There's also an
'unsigned long' argument that you can pass along.
Calling the timer expiration routines happens by calling update_timers() from
the while (1) loop in the main program. This will of course change once
we have a scheduler and tasks.
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)
> L3 sends RSL RLL ESTABLISH REQUEST with LOC UPD REQ as L3_INFO
> L2 converts this in SABM with LOC UPD REQ as payload
> L1 sends the packet to the GSM network
> L1 receives response from the GSM network
> L2 generates RSL RLL ESTABLISH CONFIRM to L3
hi,
just to see if i understand it right, here is my view of how it should
work:
(for reference, see Fig. A.4 in GSM 04.07 in the appendix A.)
mobility management layer requires to send an location update, so it
does the following things happen:
- a msgb is created with payload, large enough for LOC UPD REQ, and a
headroom to encapsulate it into other messages...
- LOC UPD REQ is assembled by mobility management layer
- the msbg is "pushed" to add radio ressource header in front of it
- the radio ressource primitive RR EST REQ is written to radio ressource
header
- the msgb is now transferred using a function call to radio ressource
layer
- the radio ressource routes the message according to the state and the
primitive to the appropiate handler of this message. (state machine)
- there the msgb is "pulled" to remove that header
- the handler of "RR EST REQ message in IDLE mode" stores the msbg until
an IMM ASS is received, and starts channel request procedure...
...
- when handling the IMM ASS, the radio ressource layer takes the stored
msgb and pushes the RSL RLL header in front of it
- the RSL RLL header gets informations about channel to establish, and
the RSL EST REQ primitive is set
- the msgb is sent down from radio ressource layer to layer 2, in this
case the RSLms layer, using a function call.
(RSL EST REQ represents the DL-ESTABLISH REQUEST primitive)
while the message is walking from radio ressource layer down to layer 1,
the primitives for inter-layer communication are added by the sending
layer and removed by the receiving layer.
is this procedure correct? (of course, more things are done at radio
ressource and mobility management layers in the procedure above, but i
just wanted to explain what happens to the msgb.
regards,
andreas
hi,
my last mail was written yesterday and somehow sent today.
meanwhile i decided to work with GIT for the following reasons:
- working with others parallel on L3
- faster solving of issues. solving before finishing the code.
- backup (even loss of one weekend's work would be a great loss of
motivation)
i will try the GIT tonight...
anyway here is my first issue:
the messages between layer 3 (radio ressource) and layer 2 have
primitives starting with DL_*.
e.g. DL_RANDOM_ACCESS_REQ is used to send a CHANNEL REQUEST on the RACH.
and DL_ESTABLISH_REQ is used to establish a layer 2 link on SDCCH or
TCH.
both messages carry layer 3 messages, like CHANNEL REQUEST or LOCATION
UPDATE REQUEST. using msgb between layer 2 and 3 is not enough, because
i need to exchange additional informations with layer 2. these are the
primitives themselves, and in case of DL_ESTABLISH_REQ the channel
information for frequency, channel type, slot, ect.
my current solution is to use a structure with primitive type and all
additional informations and a pointer to the attached layer 3 message,
if there is actually one message. (not yet immplemented, but already
implemented at mncc interface in openbsc.)
to prevent function call loops, i use a queue in the upward direction,
so the structure with the message is copied into a msbg and added to the
queue. (remember that this message may carry another layer 3 message)
is there a better (simpler) way?
regards,
andreas
hi harald,
as i am still working on RR MM and CC layer, it seems to be more complicated as i thought. remember all the messages in 04.08? but most problem is that i must first understand it all. i get more and more knowledge about it while reading it. i started implementing some parts, but most parts i do not understand yet. as i know from earlier project, it requires exact knowledge of every bit to do it right.
when i am finished, i will tell you as soon as possible, but i think it takes some more weeks. anyway, there will be many issues then. as i can see, there the layer 2 and layer 1 will also be not that easy too. e.g. layer 2 must process channel descriptions to connect to the right channel and the right configurations and mode. also when i am finished, i will need to solve some coding issues, like message flow, queueing (to prevent message loops), and structures for subscriber data, telephone settings and system informations. as soon i am finished, i will make a list of remaining unsolved issues.
and finally gsm 03.22 (selecting and changing cells) must also wants to be implemented.
if you like to be aware of what i am doing, just watch my code base. it is live, so every time i do a write, it will be available at: http://home.eversberg.eu/alpha3/
regards,
andreas
Hi!
Today, there have been quite a number of possibly intrusive changes in
the repository. A quick summary:
* prom's new makefile voodoo has been merged for the 'firmware' directory,
this means we now have proper dependency tracking in our builds, as well
as support for multiple board builds
* the compiled elf/map/bin/... files are now in board/compal_{e88,e99},
rather than in the main directory.
* the firmware now uses the real libosmocore (and its linuxlist, msgb,...)
code. No more code duplication, and one step closer to easy migration
of the layer23 code into the firmware at some later day.
* lots of minor changes here and there have been introduced to reduce number
of compiler warnings.
* l1ctl messages (L1 <-> L2/L3) communication has changed a little bit,
it now includes only the frame number and not a full 'struct gsm_time'.
This is important for anyone who has his own ocde to talk to the L1!
I hope this was the last time we've had such an amount of changes, especially
to the build system.
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 Steve,
I have now partially merged your C155 display driver. Partial, since
I only merged those parts that didn't break the build for C123.
So what needs to be done soon:
* support multipe 'boards' in our Makefile magic, producing NR_BOARDS * NR_APPS
images as a result.
* merge those parts that are identical between board_e88 and board_e99
and create something like a calypso_init() function, keeping only board
specific bits in the board_init()
* introduce some "lcd_puts()" macro that is defined to either of the two
display drivers, depending on the board that we're building for.
If anyone is posting patches (or a git branch) for that, I'd be happy to merge
them.
Later on, I want a LCD abstraction layer that hides the details from
the apps. The app should not have to care about color/monochrome, or the
fact that the X/Y coordinates seem to be inverted between the displays.
I personally have no interest in doing that, as GSM related work has much
higher priority to me. I hope somebody in the community will take care of the
task. Thanks in advance!
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 Andreas,
I'm going to pick up your questions as found in your preliminary
http://home.eversberg.eu/alpha3/ code.
I took the liberty of posting to the ML, as other people will definitely
be interested in this, too.
1) why is layer2 a socket client?
because we want to develop layer2 + layer3 + everything above on the PC first,
while keeping the L1 on the phone. This makes debugging much easier. Later
we will simply move the code to the phone and run it in one or multiple
tasks of the operating system, replacing sercomm + unix socket with message
queues.
2) where is layer3 to go?
I think we can directly put it into the layer2 program, but try to keep a clean
seperation between l2 and l3, using the REQUEST/RESPONSE/INDICATION primitives.
3) where should the app (layer4) go? library or console?
it should live on top of the l23 stack, preferrably as its own program.
There is a lot of sense for having the application (UI) as its own
process/thread, and the stack in its process/thread.
4) Is the TLV parser buffer-overflow safe?
TLV parser (libosmocore) is not buffer-overflow safe, patches are appreciated.
5) classmark1 lsb/msb twisted:
I have no idea :)
6) lchan/ms mapping.
I don't have a clear idea on this either. I'm not so sure if the 'lchan'
concept makes much sense in a phone at all. A phone typically only uses one
dedicated channel at any given point - with corner cases in the event of a
handover, where we 'switch back' to the old channel if establishing the new
channel fails.
7) ms instantiation for multiple devices
I think this is not really an important issue at the moment. If there are
multiple phones, there should be multiple instances (processes) of the layer23
stack. A normal application would also exist 1:1 for each stack instance.
If you think of some PBX application, than I also think it is easier to have
one instance (process or thread) of the stack for each phone.
After all, the primary target for us is to make layer2+3 work in a phone,
and there it will definitely be one instance for one phone.
One additional comment:
Please make sure that the common/shared code between OpenBSC and your Layer3
does get moved into libosmocore. I'm thinking particularly abotu code for
parsing and generating the various IE's. We don't want to keep multiple
implementations around...
Thanks again for all your help,
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!
There will be an informal meeting of OsmocomBB hackers at the Berlin CCC
(http://berlin.ccc.de/) on Saturday, 2010-03-06 at 8pm local time.
Prom and myself will be there, most likely also dexter and tec. If you're
local, feel free to join.
There's no formal agenda, we just like to meet one more time before I'll
disappear to Taiwan for quite some time.
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've improved the layer23 gsmtap support to add support for
* uplink frames, sent by layer23 to L1
* properly support dedicated channels with LAPDm
* allow the user to specify the GSMTAP destination IP address
In order to use the new features, you need to
1) use the new gsmtap.patch for wireshark
2) use the '-i dstip' option of layer23, as the default is now to NOT
generate GSMTAP UDP Packets
I'm attaching a screen-shot showing the wireshark decode of the LOC UPD REQ
generated by layer23. As you can see from the packet list, the BTS responds
with the UA packet containing the same LOC UPD REQ as part of the contention
resolution in LAPDm, just as expected.
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)
All,
I found some low-hanging fruit. :-) Attached is an updated patch against the latest wireshark trunk svn. It incorporates all of the requested changes in the bug comments [1].
Hopefully I'll be able to pitch in more once my C123 arrives...
hth,
Jason.
[1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4508
Hello Chekov,
On Mon, 01 Mar 2010 15:32:53 +0100, "chekov" <chekov(a)riseup.net> wrote:
>
> still, this info differs from the wiki:
> the last section is missing and the second last section is printed twice
What you receive as output is OK, the current version of "hello_world"
prints the same clock configuration twice and doesn't start the DSP.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I'm pleased to report that the current master branch in osmocom-bb.git
has initial support for bi-directional communication, and handles
messages all the way up from L1 to L3 and back.
The architecture is as follows:
L1 events (such as received 23byte mac blocks) are encapsulated in L1CTL
messages, which are sent over HDLC/rs232 to the PC. 'osmocon' then
demultiplexes the L1CTL from the console messages and sends it via unix
domain socket to the layer23 program.
Inside layer23, L1CTL is decapsulated and passed into the LAPDm code, from
where the data is encapsulated in RSLms (RSL for mobil station, my invention)
and handed off to L3.
Messages from L3 take the opposite way L3->RSLms->LAPDm->L1CTL->HDLC->L1
So far, we still only support IMMEDIATE ASSIGNments to SDCCH/4 on a
combined CCCH. But if you are on a BTS with that channel configuration,
layer23 will now happily send a LOCATION UPDATE REQUEST to the BTS :)
Dieter has indicated he will be looking into supporting TCH/F as well as
frequency hopping during the next week(s).
I myself desperately need to get some real work done at this point,
so don't expect any major developments for some time.
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)
Hello. First of all:
You can get here extremely cheap the defenetly correct cable(i buy it
with hope it could be the right one and had luck. Now everybothy can
get a cheap one):
http://www.dealextreme.com/details.dx/sku.14664
You could add/change that in the wiki.
How it is connected:
GND: next to the cable and COM-Port-Pin nr 5
Rx: in the middle and COM-Port-Pin nr 2
Tx: at the smal end and COM-Port-Pin nr 3
And now my problem:
I use ARM binary from here:
http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X
Everything compiled fine so far. I doesnt use any converter. Just use
a real com Port from a older Notebook.
I run:
./osmocon -m c123 -p /dev/ttyS0 ../where_the_firmware_is/hello_world.bin
And get the result you see in the attachment.
Phone: It is an C118 with Firmware 1.0.75 and it is locked to Vodafone DE.
I tried today nearly 5 hours all tools for windows i could find to
unlock the phone. There was no tool that worked(some also worked with
pressing on-button shortly in off-modus). Maybe the problem is in the
computer i used (also older one with real com-port.notebook is
linux-only). Maybe the phone.
Did i understand right, that when i get the output like here:
http://bb.osmocom.org/trac/wiki/osmocon
I also could get somehow the unlock key? Can you tell me then how? The
Unlock Code is always 8 Numbers.
After 5 hours i also know that it could be in A:0x7FC300 or A:0x7FC600
Thanks so far
hi everyone,
could the strange problem be related to the cheap cable...?
still waiting for usb data cable from akku-king (supply issue...
related to osmocomBB project ?), i'm also experiencing unstable serial
communications with this cable :
http://www.multi-unlock.com/images/mot-t191.jpg
some related questions :
does someone here use this cable ? :
http://gsmserver.com/newshop/images/large/COM_cable_for_Motorola_T191.jpg
can we use direct connection to PC serial port (UART or usb serial
adapter) safely ? i mean without any ttl level conversion (like
max-232) ?
which exact FTDI usb to serial chipset (ie FT232R) is most
recommended, with :
- good linux driver support
- support for a possible future use of higher non-standard baud rates ?
is there any serial port configuration trick or driver tweak to get
better serial communications with osmocon ?
thanks
nico
Hi!
I have decided to merge the uplink branch as master didn't even build and
wasn't receiving any attention from my side.
In order to avoid any accidents, the default builds of the master branch
will not include any Tx functionality. If you want to enable it, you have
to use "CONFIG_TX_ENABLE" while compiling (by enabling it in Makefile.inc).
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 all,
This weekend I had my first try with a C123, and everything seemed to
work great from the start.
But suddenly when uploading l1test.bin to the phone, it seems to hang
after the first three ARFCN's found, like so:
Hello World from apps/l1test/main.c program code
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Dropping sample '~'
=============
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: 0x975b 0xadac
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
Performing power measurement over GSM900
LOST!ARFCN Top 10 Rx Level
ARFCN 7: -102 dBm
ARFCN 10: -103 dBm
ARFCN 14: -103 dBm
When I press any button of the phone it continues by showing the
remaining ARFCNs, but nothing else:
ARFCN 43: -103 dBm
ARFCN 85: -103 dBm
ARFCN 87: -103 dBm
ARFCN 105: -103 dBm
ARFCN 115: -103 dBm
ARFCN 123: -103 dBm
ARFCN 96: -104 dBm
Starting FCCH Recognition
key=12 pressed
key=12 released
I also noticed the dBm values, all channels are barely above the
noise floor, right?
Does anybody have tips on how to get running again?
Thanks,
Hessel
Hello Thomas,
On Mon, 01 Mar 2010 23:45:43 +0100, "Thomas Kindler" <mail+gsm(a)t-kindler.de> wrote:
> What do I do wrong?
There is probably something wrong with your cable or configuration.
I have marked the lines below in your log, the marked bytes are the
"download command" sent by osmocon. Those bytes are never echoed back
by the bootloader and you should not see them. So you should first check
why you see those bytes.
> got 2 bytes from modem, data looks like: 04 81
> 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/hello_world.bin): file_size=16676,
> hdr_len=4, dnload_len=16683
> got 1 bytes from modem, data looks like: 1b <<- should not be there
> got 1 bytes from modem, data looks like: f6 <<- should not be there
> got 1 bytes from modem, data looks like: 02 <<- should not be there
> got 1 bytes from modem, data looks like: 00 <<- should not be there
> got 1 bytes from modem, data looks like: 52 <<- should not be there
> got 1 bytes from modem, data looks like: 01 <<- should not be there
> got 1 bytes from modem, data looks like: 53 <<- should not be there
> got 1 bytes from modem, data looks like: 66
> got 1 bytes from modem, data looks like: 74
> got 1 bytes from modem, data looks like: 6d
> ...
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
After quite a bit of hacking on libosmocore as well as the various
parts of Osmocom-BB, I've now committed the latest state to the 'uplink'
branch of osmocom-bb.git.
I have decided to introduce RSL/RLL as the interface between Layer2(LAPDm)
and Layer3(04.08), as it is a clean protocol that we already understand
from the OpenBSC side.
You can see in src/host/layer2/src/osmocom_rslms.c how we receive
e.g. the 04.08 PAGING REQUEST and 04.08 IMMEDIATE ASSIGNMENT on the
PCH/AGCH inside RSL UNIT DATA INDICATION messages.
Please note the layer2/src/lapdm.c implementation is extremely incomplete,
particularly when it comes to ABM (asynchronous balanced mode) and I-frames.
It's full of FIXME's that I'll be working on as soon as possible.
However, the infrastructure now seems to be coming together and we basically
have everything in place for bi-directional transmission of data for SAPI0 and
SAPI3 for both DCCH and ACCH (limited to SDCCH/4 on combined CCCH on C0T0)
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'm just getting started with GSM and Osmocom and received my C123 from
eBay last week. I got everything to compile under Ubuntu 9.10, using
the arm-elf toolchain from
http://embdev.net/articles/ARM_GCC_toolchain_for_Linux_and_Mac_OS_X
Will that be usable at all?
As I'm still waiting for my official cable to arrive, I built one myself
using an old CP2102 USB-Serial development board.. unfortunately,
osmocon fails to upload programs:
$ ./osmocon -p /dev/ttyUSB0 -m c123../../target/firmware/hello_world.bin
got 2 bytes from modem, data looks like: 04 81
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/hello_world.bin): file_size=16676,
hdr_len=4, dnload_len=16683
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: 52
got 1 bytes from modem, data looks like: 01
got 1 bytes from modem, data looks like: 53
got 1 bytes from modem, data looks like: 66
got 1 bytes from modem, data looks like: 74
got 1 bytes from modem, data looks like: 6d
got 1 bytes from modem, data looks like: 74
got 1 bytes from modem, data looks like: 6f
got 1 bytes from modem, data looks like: 6f
got 1 bytes from modem, data looks like: 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
What do I do wrong?
best regards,
--
Thomas Kindler <mail+gsm(a)t-kindler.de>
I have ordered a C139+cable and I am waiting for it to arrive. I guess
the helloworld and other binaries will run on it but the peripherals
that differ from the C123 will not work. Is that correct?
At work we used ARM7TDMI, now an ARM9, and we looked at FreeRTOS
before going for a custom non-RTOS event-based os. We use the gnu
toolchain and OpenOCD.
So far, I have only used GSM/GPRS from the AT-command level, but it
looks interesting to see more.
While waiting for the hardware I did some trivial patches for osmocon
that are attached. Hope that form (as well as the content :) is
acceptable.
/Erik
Hello Chekov,
On Mon, 01 Mar 2010 02:04:13 +0100, "chekov" <chekov(a)riseup.net> wrote:
> but now i'm stuck, because i get no feedback from the phone, except that
> the display lights up blue.
I think the problem is related to this:
> Received PROMPT2 from phone, starting download
> handle_write(): 4096 bytes (4096/16503)
> handle_write(): 4096 bytes (8192/16503)
> handle_write(): 4096 bytes (12288/16503)
> handle_write(): 4096 bytes (16384/16503)
> handle_write(): 119 bytes (16503/16503)
> handle_write(): finished
> handle_write(): 4096 bytes (4096/16503) <<<<----- this should not happen
> got 1 bytes from modem, data looks like: 1b
This probably means that the downloader does not receive a reply in time
and continues to download the code. You can try to fix it with this
modification:
--- ./src/host/osmocon/osmocon.c Tue Feb 23 18:38:39 2010
+++ /src/host/osmocon/osmocon.c Mon Mar 01 07:59:22 2010
@@ -275,6 +275,7 @@
usleep(1);
} else if (dnload.write_ptr >= dnload.data + dnload.data_len) {
printf("finished\n");
+ dnload.serial_fd.when = BSC_FD_READ;
dnload.write_ptr = dnload.data;
return 1;
}
As a consequence of still sending data to the phone, the firmware
could crash because there was a bug which is already fixed in the
latest GIT version. You can check if you already have the latest
version:
--- ./src/target/firmware/comm/msgb.c Tue Feb 23 18:38:39 2010
+++ /src/target/firmware/comm/msgb.c Sun Feb 28 11:22:57 2010
@@ -35,7 +35,11 @@
#ifdef NO_TALLOC
/* This is a poor mans static allocator for msgb objects */
-#define MSGB_DATA_SIZE 256
+#define MSGB_DATA_SIZE 256+4
#define MSGB_NUM 16
struct supermsg {
uint8_t allocated;
Maybe the above helps to solve the problem.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi!
I'm currently working on getting the integration between l1, l2 and l3
running.
As it seems to me, using at least the RLL part of RSL as an interface
between l2 and l3 seems to make a lot of sense. After all, it contains
all information we need, such as timeslot/subslot/sapi/... and supports
all the various {data,unit_data,establish}{{request,indication} messages.
So my idea is to generate a RSL RLL message in L2 and send ot to L3 and
vice versa.
I'll commit it to the 'uplink' branch as soon as I have something useful.
--
- 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'm trying to follow this projects developement with my revived Motorola
C118. The wiki helped me making the phone downloading the
hello_world.bin file.
but now i'm stuck, because i get no feedback from the phone, except that
the display lights up blue.
here is what osmocon prints when i make the phone downloading the
hello_world.bin:
$ ./host/osmocon/osmocon -m c118 -p /dev/ttyUSB0
target/firmware/hello_world.bin
got 2 bytes from modem, data looks like: 04 81
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/hello_world.bin): file_size=16500, hdr_len=0,
dnload_len=16503
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/16503)
handle_write(): 4096 bytes (8192/16503)
handle_write(): 4096 bytes (12288/16503)
handle_write(): 4096 bytes (16384/16503)
handle_write(): 119 bytes (16503/16503)
handle_write(): finished
handle_write(): 4096 bytes (4096/16503)
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!
this also works with -m c118xor
maybe you can create something like a user mailinglist if this kind of
questions produces to much volume.
Hello Joachim,
On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh(a)hyte.de> wrote:
>
> ps: according the the schem the vibra should be controlled by the auxdac
> of iota. i poked it and some enable bit few minutes, but couldnt get it
> doing anything.
Have you turned the Auxiliary DAC on ? It has its own power control
bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC
on. I just did a quick test with a C123, and the following seems to
work:
twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on
twl3025_reg_write(AUXDAC, 1000);
delay_ms(1500);
twl3025_reg_write(AUXDAC, 0);
twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
sorry for not writing anything earlier, but i'm currently moving so i'm
a bit short of time.
i have been working on the bci and madc block already, so if you are not
already done, i'd like to do that.
its a bit tricky since one needs to do quite a lot to charge the battery
correctly, but in the end we could even charge nimh and i guess small
lead batterys also if we want to (with different code).
i have done the irq handlers, the charger plug in detection and the
async madc stuff is already working.
it just needs some cleanup before commit.
about the bci stuff: i'm now done reading and understanding the iota
datasheets and appnotes (the latter one having invaluable information
not in the datasheets).
'just' need to get it written down in code and debug it. ;)
summary: if you can live with charging your batteries for another week
or 2, just try figuring out the ringer and or vibra for example
ps: according the the schem the vibra should be controlled by the auxdac
of iota. i poked it and some enable bit few minutes, but couldnt get it
doing anything.
so there is still a mystery or 2 left.
kind regards
--
roh
Hi everyone
Without further introduction and in a similar manner to laforge's last
mail I would like to note that I am working on a bootloader that will
allow for larger binaries in RAM and flexible flashing.
To avoid troublesome interaction between the Calypso bootrom (which we
use for interrupt redirection) and CFI support, I have decided to go for
an interrupt-less approach. So don't be surprised to see me committing a
polling mode to fundamental drivers (keypad, uart) sometime soon.
Luckily, the required changes are trivial.
I'll push my branch sometime soon, just dropping a line to keep everyone
informed. Feel free to drop a line in case you are interested in other
flash-based tasks like hammering out linkage details and implementing
some kind of filesystem.
Greetings
prom
Hi!
Just to avoid any possible duplicate work: A member of this list already has a
working C155 color display driver. So if you were thinking of working on
this: Please rather do another TODO item.
I'm supposed to be merging that driver during the next couple of days.
Cheers,
Harald
p.s.: I'm back in Berlin now, will be working with zecke of getting layer2
(bi-directional) up and running.
--
- 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)
