Hi!
I read few pages at http://bb.osmocom.org but didnt find
answer for some little questions.
What this code is based on? Is this a port of some rtos to calypso?
--
wbr, Ilya
ICQ: none, Jabber: ilya.muromec(a)jabber.ru
Hi,
I've noticed that hello_world and compal_dsp_dump now crash pretty
early. I've traced it down to talloc_zero panicing by running out of
free msgb. Augmenting the number to 64 makes the software go a little
further but they still crash in the end.
I'm hoping that the person who wrote this part will see an obvious
place where the problem lies :)
Sylvain
Hi all,
congrats for your awesome research and work, this is truly impressive.
The little ant that I am (compared to you) was interested in helping you
with the SIM aspects of the project. I think I know javacard sufficiently to
implement a basic sim card that can be totally controlled. I already started
to think on how to do that. This will include making host side tools, too.
If javacard is not open enough, we can also look at native cards using PIC,
for example. In our previous discussions, the main problem was the
availability of SIM sized cards, be them javacards or not.
pros and cons
- javacard is an industry standard, coupled with GlobalPlatform specs this
is a portable way to put an application on a card without being locked with
a card manufacturer.
- native PIC cards benefit from a lot of open tools such as the gp* PIC
tools, asm, sdcc for compiler and gpsim for simulation.
- some projects exists already, I don't know them well, maybe they can be
used, forked, improved.
- availability must be checked.
I'd like to request precisions on how the things should be done, what are
the minimal requirements (files, etc) and when the openSim project will be
needed regarding to your progress.
Regards
Sebastien
Hi,
I'm wondering if it's ok or not to put links (and only links
obviously) to schematics of GSM in the Wiki ?
IANAL so I'm not sure exactly what the situation is ... and I'd rather
ask before I start adding too much of them :)
Cheers,
Sylvain
Hi!
After much delibeation I have devoted today to 'fix' the way how we build
the project and how things depend on each other.
We have a couple of challenges:
1) there is (and should be!) a lot of infrastructure code sharing between
OpenBSC and OsmocomBB Layer2/3. I'm referring to stuff like linuxlist.h,
msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc.
2) we want to do the layer2/layer3 development on the PC, while the layer1
resides on the target phone. However, the code should be API compatible
and just compile when we later decide to move (parts of) it into the
phone.
3) there is already some code like "msgb" which is used both in layer2(PC)
and the phone.
4) I don't want to have too many build dependencies as it makes it
unneccesarily difficult to get started with the project. So everything
should build from the git tree we provide
5) we dislike the idea of code duplication or copy+paste. This means
that we need to build some stuff like libosmocore twice; for the
host PC and for ARM
The solution looks like this:
* libosmocore lives in its own git://git.osmocom.org/libosmocore.git
repository. This is where we make changes to it.
* libosmocore is 'squashed' into the osmocom-bb.git repository by means
of git-subtree[1] to make sure challenge '4' is fulfilled. This is
transparent to the user who clones our tree. However, if you want to
make changes, please ensure that a commit either only touches files
within src/shared/libosmocore or outside of that directory. Mixed
commits will require manual action and are tiresome.
* everything is built using autotools, except for the 'firmware'
(what used to be hello_world)
* there's now a top-level Makefile, which
* builds libosmocore for the host
* builds libosmocore for the target
* builds osmocon for the host
* builds layer2 for the host
* builds the target firmware
I understand that this process is quite a bit more complex than what
we used to have, but it is the best option that I could come up with.
I particularly hope that I didn't do something stupid which would break
Cygwin builds... we want to keep Dieter as productive as he currently is,
after all :)
Regards,
Harald
[1] git://github.com/apenwarr/git-subtree.git
--
- 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)
So let me ask a couple of questions about OpenBSC to clarify things for myself.
What are the requirements for running OpenBSC ?
a) a USRP2
b) some kind of computer with gigabit ethernet (recommended hardware?
what kind of load would this be responsible for?)
b) a broadband internet connection
c) anything else? Some kind of VOIP account somewhere?
The reason I'm asking is that I've been doing quite a bit of work with
the USRP2 at university, and have been considering buying one for
myself for quite some time (although as a student, it's hard to
justify the price). My professional / academic / hobby interests
definitely involve hacking mobiles, investigating mobile radio,
hacking various arm devices, even hardware design, etc, and I guess
that OpenBSC would be ideal to for testing out osmocom baseband
firmware (rather than having a commercial provider's black box for a
BS).
I guess another question I could pose to the list would be:
Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc?
I know that the spec sheets say that it's capable of 50 MHz of
instantaneous bandwidth, but I believe that the high data rate 3G (and
further) protocols are using wideband OFDM. From my understanding, I
would imagine that it would be necessary to support much more than 50
MHz of instantaneous bandwidth, or somehow be able to load the
transceiver buffers quickly and sequentially. then push a broad
spectrum in parallel. Perhaps this can be achieved with a MIMO
configuration, or with a specialized daughter card.
Any thoughts?
C
Hi!
I've recycled the old GSMTAP wireshark plugin that I originally wrote
for project airprobe.
Using this patch (now in our git tree as well, applies against current
wireshark svn) and the layer2 host program as well as the l1test.bin target
program, you can watch BCCH messages in realtime.
The architecture is like this:
* DSP forwards decoded normal burst data to layer1/sync.c
* layer1/sync.c generates L1A_L23 protocol message and sends it
via the SERCOMM HDLC layer over RS232
* "osmocon" receives the HDLC frame and relays it to the Unix domain
socket
* "layer2" receives the L1A_L23 protocol message on the Unix domain
socket, adds a GSMTAP header and sends it to the GSMTAP UDP port on
localhost
* wireshark captures on the 'lo' interface and calls the GSMTAP dissector
plugin for everything received on the GSMTAP UDP port number.
Have fun!
--
- 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)
Congratulations to all of the developers that worked on this project -
you must be very proud at this point!
At some point, when I have some free time, I hope to contribute to the
codebase (although I don't have a motorola c123, I'm hacking on some
other handhelds currently).
C
