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…
