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.
