Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
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)
On 06/08/2010 09:41 PM, Huseyin Turan wrote:
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc
> -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a
> Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15
> UTC 2010 i686 GNU/Linux
>
please try b.) again (you miss the file part) and also please reply to
the mailinglist.
Hi!
I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/)
which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin
from August 21/22 this year.
Before sending a response, I would like to inquire whom of you would actually
have any intention of visiting this conference and spending time in the
developer room to work on OpenBSC or OsmocomBB ?
I think the idea is great to meet some of you guys [again], not only at the
annual CCC congress in winter. But there is little point for me to go there if
there is no interest from the wider project community.
Please provide your feedback ASAP.
--
- 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 have been looking for sometime at OsmocomBB project, but haven't tied it yet.
I have seen that software supports a number of Compal phones :
Supported Phone hardware
Information specific to certain Calypso based phones that we support
Designed + Manufactured by Compal, OEM by Motorola
MotorolaC115/C117 (E87)
MotorolaC123/C121/C118 (E88) -- our primary target
MotorolaC140/C139 (E86)
MotorolaC155 (E99) -- our secondary target
MotorolaV171 (E68/E69)
SonyEricssonJ100i
So, I was wondering:
1) Which would be best to have to start with, as the most supported target ?
2) Where I can get this phone quickly and easily ?
3) What additional equipment is needed (how do you flash the software
and how do you debug) ?
4) Is there some software simulator in which I could see what is
happening and how the SW works without actual HW equipment ?
Best regards,
Drasko
hi,
i like to do extensions to the RSLms layer of osmocom. before that i
like to ask and discuss if this would be the correct way:
instead directly of calling l1ctl_* functions of l1ctl.c, i would like
to use RSL messages between layer 2 and layer 3. the lapdm.c would then
convert these messages and call l1ctl_* functions. (maybe i could split
up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an
RSL request could be made at layer2.c, as well as selecting the right
handler for the frames received from layer1. only the lapdm part could
be handled in lapdm.c. )
the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could
be the same message type, but i prefer to invent a new one: 0x18, but
using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the
RACH request, could tell the layer 1 about usage of power and TA (which
is normally 0 for RACH request).
the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if
omitted, the stored value from the last message with
RSL_IE_MS_POWER_PARAMS could used.
the (UNIT) DATA indication and request of SACCH may include
RSL_IE_L1_INFO IE to receive power and timing control as well as send
the actual power and timing advance. i could handle these IE at layer 3
(radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM)
depending on the supported radio power and on special VTY settings to
mess with power and fake timing advance.
regards,
andreas
Hi!
As indicated in other mails, we now have support for gcc-style constructors
in OsmocomBB. The way to use them is relatively easy: Simply put
"__attribute__((constructor))" at the function that you want to be
called during initialization.
The way how this works is like this:
* gcc and the linker create a table of function pointers to all the
functions with that attribute
* the code in compal_ramload_start.S takes care of calling
lib/ctors.s:do_global_ctors() which iterates over the list
and calls each constructor
This concept is now used for things like prim_fbsb_init() in layer1,
but I have also started to use it for board_init(). This means that
board_init() no longer needs to be called from the main() function
of each app.
We can probably put more stuff into constructors, but we should also
be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus
there is no explicit way to control the ordering in case of dependencies.
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 all!
JFYI: The AGC control in L1 is now active. At least it didn't make things
worse for me. Maybe people who have had problems acquiring weak cells
should give it a try again.
I've also fixed some compile problems due to a missing header file,
and there is now a L1CTL_DM_REL_REQ where Layer23 can explicitly release
the dedicated mode and return to idle mode.
Right now the 'mobile' program (specifically gsm322/gsm48_rr) issue another
L1CTL_PM_REQ after a location update reject hap[pens, i.e. layer1 is still
in dedicated mode but it gets some power measurements. This results in
L1 trying to do Transmit in parallel with power measurements and it
crashes at some point.
I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose
it should avoid that problem.
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,
The good news, is that hopping and ts[0:4] work just fine and were
surprisingly easy to implement. The bugs I thought I had were in fact
not related to these and just prior bugs that were never noticed
before. (see my sylvain/testing branch).
Only L1 is changed, so you'll need to tweak l23 (either the mobile app
or layer23 for quick tests) if you want to try them out somehow.
Current limitations:
- SDCCH8 subchannel 4,5,6,7 won't work.
For those, we need to TX and RX in the same frame ... which just
isn't possible with the way the primitives work right now. (each
assume to have the full frame for themselve).
- TS >= 4 may not work
When using TS>=4 we should also change the interrupt alignment so
that the DSP still has time to do it's job. Switching 'forward' is
easy, but when switching 'back', we need to be conscious that we need
to skip 1 frame at the very least ...
IMHO to solve both those issue, we need a better scheduler/primitives
that possibly have some knowledge of the 'span' (in terms of qbit) of
each operation. Because if we do a TX on TS=5 for instance, there is
no way we can do a RX on TS=0 on the next frame, the tpu window
overlap.
- No ciphering.
That should be trivial to add. Just setup the fn and the kc and set
the flag ... the 'l1s.next_time' contains the godd time of the frame
TX/RX frame during the primitive execution, so that's the FN to use.
Once that's done, the few bits missing from mobile app could be
added (and from a quick look, not much is missing ... just the l1ctl_*
calls because they don't exists yet) and a full location update with
auth and ciphering could be done.
The need for a SIM interface grows quickly :)
Some 'gotchas' you might encounter that are not fixed yet:
- The L1 completion handler crashes.
In target/firmware/layer1/prim_tx_nb.c ,
l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's
never called. So you need to comment out
l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until
a proper fix.
- Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is
just plain wrong. (source code uses % 0x38 instead of & 0x38), need to
send a patch for this
- layer23 doesn't currently filter much the IMM.ASS it receives so
you may end up on a channel that's not yours ... beware.
Sylvain
> - layer23 doesn't currently filter much the IMM.ASS it receives so
> you may end up on a channel that's not yours ... beware.
hi sylvain,
what do you mean with "much"? i filter the channel with the channel
request number (includes random number) in the IMM.ASS message. maybe in
the future we can filter the time slot where it was sent (RACH confirm)
and compare it also. but this requires RACH confirm with GSM time where
it was sent.
andreas
@harald: is there any time stamp in the RACH confirm? what format would
it be?
.... from the IMM.ASS parsing:
/* 3.3.1.1.2: ignore assignment while idle */
if (rr->state != GSM48_RR_ST_CONN_PEND || !rr->wait_assign) {
LOGP(DRR, LOGL_INFO, "Not for us, no request.\n");
return 0;
}
/* request ref */
if (gsm48_match_ra(ms, &ia->req_ref)) {
/* channel description */
memcpy(&rr->cd_now, &cd, sizeof(rr->cd_now));
/* timing advance */
rr->cd_now.ta = ia->timing_advance;
/* mobile allocation */
memcpy(&rr->cd_now.mob_alloc_lv, &ia->mob_alloc_len,
ia->mob_alloc_len + 1);
rr->wait_assign = 0;
return gsm48_rr_dl_est(ms);
}
LOGP(DRR, LOGL_INFO, "Request, but not for us.\n");
> I was refering to "layer23" the quick & dirty test app if you want to
> play with the layer1.
oops. sorry, but anyway i need to improve the IMM.ASS. check against
timestamp.
i will test all the new features soon and also check the time stamps if
they match.
Hello,
I want to use the power measurements from the l1test in the phone. Therefore I modified the program so only the PM is done and additional some averaging and so on.
Finally the information should be sent to an microcontroller over UART. There is the problem: I don't know how to use this HDLC sercomm stuff because I don't have time to understand AND implement it for my thesis in the µc-part. I need a quick dirty hack to deactivate this HDLC. I don't find it in code and tried some hours.
I tried "uart_putchar_wait()" and hterm shows me that the bytes are sent with a lot other stuff.
What is the easiest way working for me?
Thanks a lot.
Marco
Hello,
I am just writing this email to thank everyone who helped me with all the
trouble I had while Osmocom. Though I didn't succeed in my objective but it
was just a part of my project that I started quite late and was always
fighting against time to complete it.
Thank you :),
Zaki.
Hi all,
can anybody point be to the SIM card driver sources ?
I looked at src/target/firmware/calypso but did not find it...
Is there some other sources that you know for SCI (Smart Card
Interface) that I can look at ?
Best regards,
Drasko
---------- Forwarded message ----------
From: Wolfgang Draxinger <wdraxinger.maillist(a)draxit.de>
Date: Wed, Jun 9, 2010 at 10:08 AM
Subject: Re: SIM card driver
To: hardware(a)lists.openmoko.org, Al Johnson <openmoko(a)mazikeen.demon.co.uk>
On Wed, 9 Jun 2010 00:04:07 +0200
Drasko DRASKOVIC <drasko.draskovic(a)gmail.com> wrote:
> Very uncool :(.
>
> I need to write a driver for ARM PrimeCell Smart Card Interface PL131
> in order to init/read/write SIM card for 4G mobile device. Does
> anybody knows where I can get hold of some implementation of (any) SIM
> interface driver ?
>
> Thanks and BR,
> Drasko
SIMs, like any other SmartCard communicate over an interface very
similar to I2C, with the notable difference, that the terminal always
is the "bus" master.
Building your very own SmartCard terminal is very easy. Or you just use
one of the ready to use ones (from Towitoko, Reiner SCT, etc.).
Also have a look in the Open Baseband project
http://bb.osmocom.org/trac/
Which b nature also must deal with SIM cards.
Wolfgang
_______________________________________________
hardware mailing list
hardware(a)lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/hardware
Hello,
Thank you for your reply. I have downloaded the toolchain that I should have
done at the first place. I am not getting those errors any more but I am
stuck at some new ones. I am pasting them below
.................
calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_irq_handler_sercomm+0x0):
undefined reference to `__aeabi_unwind_cpp_pr1'
calypso/libcalypso.a(uart.o):(.ARM.exidx.text.uart_init+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_pull+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
lib/libmini.a(console.o):(.ARM.exidx.text.__cons_rb_append+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_append+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
lib/libmini.a(console.o):(.ARM.exidx.text.cons_puts+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
lib/libmini.a(console.o):(.ARM.exidx.text.cons_rb_flush+0x0): more undefined
references to `__aeabi_unwind_cpp_pr0' follow
make[1]: *** [board/compal_e88/hello_world.ramload.elf] Error 1
make[1]: Leaving directory `/home/zaki/osmocom-bb/src/target/firmware'
make: *** [firmware] Error 2
Another thing that I had to ask was that basically my work is at the layer1
and all the c files present in that folder of firmware have got built, the
error that is coming above is in some other folder. Would I be able to load
the layer1 files through osmocon without completing the installation of the
rest of the firmware.
Awaiting your response,
Zaki.
Hi,
I would like to get started with osmocon for openmoko devices.
I have checked out the project and setup the gnuarm but it doesnt seem to
compile.
I am running ubuntu karmic.
Please do help me with the steps of getting it running on this device.
-------------Error--------------
configure error could not find install.sh, or sh-tool
make [shared/libosmocore/build-host/Makefile]
-------------Error--------------
Regards
Saravanan.L
Hello,
I never thought I would become such a popular figure on your mailing lists,
be it for the wrong reasons. I am sorry to have emailed you that question,
but honestly I am new to Ubuntu. I have done quite a lot of programming on
Windows, but this seems to be quite a different world, and that is why I
email you even my seemingly childish questions for you to you, as I am sure
you wont have any trouble solving them although it does takes some seconds
of yours.
Regards,
Zaki.
On Wed, Jun 9, 2010 at 9:47 AM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Re: Trouble building Osmocom (Sylvain Munaut)
> 2. Re: Trouble building Osmocom (Zaki Ud Din)
> 3. Re: Trouble building Osmocom (Huseyin Turan)
> 4. Re: Trouble building Osmocom (Nordin)
> 5. Re: Trouble building Osmocom (Huseyin Turan)
> 6. Re: Trouble building Osmocom (Nordin)
> 7. Re: Trouble building Osmocom (Nordin)
> 8. Re: Trouble building Osmocom (Sylvain Munaut)
> 9. Re: Trouble building Osmocom (Holger Hans Peter Freyther)
>
>
> ---------- Forwarded message ----------
> From: Sylvain Munaut <246tnt(a)gmail.com>
> To:
> Date: Tue, 8 Jun 2010 15:57:22 +0200
> Subject: Re: Trouble building Osmocom
> Looking at gnuarm.com, it looks like you have a x86_64 toolchain and
> try to run it on i686.
> Honestly I don't want to be mean but if you can't see what's wrong
> with that, osmocom-bb might not be for you quite just yet.
>
>
>
>
> ---------- Forwarded message ----------
> From: Zaki Ud Din <fyproject14(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 8 Jun 2010 19:00:20 +0500
> Subject: Re: Trouble building Osmocom
> Hello,
>
> Thank you for your reply. I am really sorry I did not get your point in the
> mail where you asked me to perform the different checks. Though I have
> written those commands and have pasted their output below.
>
>
> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc
> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a
> Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC
> 2009 i686 GNU/Linux
>
> Awaiting your response,
>
> Zaki.
>
>
> ---------- Forwarded message ----------
> From: Huseyin Turan <huseyinturan(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 8 Jun 2010 16:51:06 +0300
> Subject: Re: Trouble building Osmocom
> Sorry;
>
> file ./arm-elf-gcc
> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
>
>
>
> ---------- Forwarded message ----------
> From: Nordin <bouchtaoui(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 08 Jun 2010 16:26:08 +0200
> Subject: Re: Trouble building Osmocom
> On 8-6-2010 15:57, Sylvain Munaut wrote:
>
>> Honestly I don't want to be mean but if you can't see what's wrong
>> with that, osmocom-bb might not be for you quite just yet.
>>
>>
>
> Maybe he's good in programming embedded stuff, this has purely to do with
> Linux specific builds and nothing to do with coding/decoding gsm stuff.
> By the way, he can always learn...
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Huseyin Turan <huseyinturan(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 8 Jun 2010 18:16:50 +0300
> Subject: Re: Trouble building Osmocom
> Thank you very much.
>
> I have succeded to compile. I will try to deploy on C118.
>
>
> ---------- Forwarded message ----------
> From: Nordin <bouchtaoui(a)gmail.com>
> To: Sylvain Munaut <246tnt(a)gmail.com>
> Date: Tue, 08 Jun 2010 17:24:35 +0200
> Subject: Re: Trouble building Osmocom
> Silvain,
>
> Yes I agree with you, but I just want to note that we have to encourage
> beginners to keep trying and learning.
> Especially when one comes from the Windows world like me, where everything
> builds magically in Visual Studio (debugging is a joy in there ;-)
> Never programmed in Linux, never used git, gdb, vim, etc... and now, I
> begin to rock a little bit, thnx to OpenBSC and you guys ;-)
>
>
>
> On 8-6-2010 17:07, Sylvain Munaut wrote:
>
>> Maybe he's good in programming embedded stuff, this has purely to do with
>>> Linux specific builds and nothing to do with coding/decoding gsm stuff.
>>>
>>>
>> I never meant otherwise in my previous message. But basic knowledge /
>> problem solving of the build system is a requirement IMHO, especially
>> in this project (that includes both host and target code with even
>> some shared code between the two).
>>
>> I also looked up his history on the various mailing lists before
>> posting this and this is not the first build problem with GSM related
>> projects so I would expect him to learn from previous experience.
>>
>>
>> Also, when I see a message with :
>>
>> ----
>> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc
>> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
>> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
>> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a
>> Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
>> 01:57:59 UTC 2009 i686 GNU/Linux
>> ----
>>
>> And he still asks what's wrong ? An embedded programmer that doesn't
>> know he can't just run binaries from one architecture onto another
>> architecture ...
>>
>>
>>
>>
>>
>>> By the way, he can always learn...
>>>
>>>
>> I know, that's why there is a "quite just yet" at the end. That's
>> exactly what I implied: that he learns that first and then come back.
>>
>>
>> Cheers,
>>
>> Sylvain
>>
>>
>>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Nordin <bouchtaoui(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 08 Jun 2010 17:27:53 +0200
> Subject: Re: Trouble building Osmocom
> Congratulations! :)
>
>
>
> On 8-6-2010 17:16, Huseyin Turan wrote:
>
>> Thank you very much.
>>
>> I have succeded to compile. I will try to deploy on C118.
>>
>>
>>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Sylvain Munaut <246tnt(a)gmail.com>
> To: Nordin <bouchtaoui(a)gmail.com>
> Date: Tue, 8 Jun 2010 17:07:42 +0200
> Subject: Re: Trouble building Osmocom
> > Maybe he's good in programming embedded stuff, this has purely to do with
> > Linux specific builds and nothing to do with coding/decoding gsm stuff.
>
> I never meant otherwise in my previous message. But basic knowledge /
> problem solving of the build system is a requirement IMHO, especially
> in this project (that includes both host and target code with even
> some shared code between the two).
>
> I also looked up his history on the various mailing lists before
> posting this and this is not the first build problem with GSM related
> projects so I would expect him to learn from previous experience.
>
>
> Also, when I see a message with :
>
> ----
> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc
> ./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
> dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
> zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a
> Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
> 01:57:59 UTC 2009 i686 GNU/Linux
> ----
>
> And he still asks what's wrong ? An embedded programmer that doesn't
> know he can't just run binaries from one architecture onto another
> architecture ...
>
>
>
> > By the way, he can always learn...
>
> I know, that's why there is a "quite just yet" at the end. That's
> exactly what I implied: that he learns that first and then come back.
>
>
> Cheers,
>
> Sylvain
>
>
>
>
> ---------- Forwarded message ----------
> From: Holger Hans Peter Freyther <holger(a)freyther.de>
> To: baseband-devel(a)lists.osmocom.org
> Date: Wed, 09 Jun 2010 12:31:46 +0800
> Subject: Re: Trouble building Osmocom
> On 06/08/2010 11:24 PM, Nordin wrote:
> > Silvain,
> >
> > Yes I agree with you, but I just want to note that we have to encourage
> > beginners to keep trying and learning.
> > Especially when one comes from the Windows world like me, where
> > everything builds magically in Visual Studio (debugging is a joy in
> > there ;-)
> > Never programmed in Linux, never used git, gdb, vim, etc... and now, I
> > begin to rock a little bit, thnx to OpenBSC and you guys ;-)
>
> Hi Nordin,
>
> I wouldn't have the skills I have now if it wouldn't be due to others
> help. And of course I know file and uname and it is new to others. The
> biggest problem I have is judging is someone is just lazy, or if there
> is someone who is slow to start but eager to learn.
>
> how would you figure that out?
>
> z.
>
> PS: Would you be willing to help me to go through the documentation and
> provide some more getting started information? At least two have
> downloaded a wrong toolchain, I am pretty sure this will happen again.
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
Hello,
Thank you for your reply. I am really sorry I did not get your point in the
mail where you asked me to perform the different checks. Though I have
written those commands and have pasted their output below.
zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ file ./arm-elf-gcc
./arm-elf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.4.1, stripped
zaki@zaki-desktop:~/gnuarm-4.0.2/bin$ uname -a
Linux zaki-desktop 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC
2009 i686 GNU/Linux
Awaiting your response,
Zaki.
Hello,
Thank you very much for your reply. When i give the path to arm-elf-gcc
"export PATH=$PATH:/home/zaki/gnuarm-4.0.2/bin/" , and run "make firmware",
I get errors. I have pasted some of the errors that i get in config.log
below and have also attached that file.
configure:2559: checking for arm-elf-linux-gcc
configure:2586: result: arm-elf-gcc
configure:2858: checking for C compiler version
configure:2866: arm-elf-gcc --version >&5
../configure: line 2868: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot
execute binary file
configure:2870: $? = 126
configure:2877: arm-elf-gcc -v >&5
../configure: line 2879: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot
execute binary file
configure:2881: $? = 126
configure:2888: arm-elf-gcc -V >&5
../configure: line 2890: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot
execute binary file
configure:2892: $? = 126
configure:2915: checking for C compiler default output file name
configure:2937: arm-elf-gcc -Os -ffunction-sections
-I../../../../target/firmware/include conftest.c >&5
../configure: line 2939: /home/zaki/gnuarm-4.0.2/bin/arm-elf-gcc: cannot
execute binary file
configure:2941: $? = 126
configure:2979: result:
configure: failed program was:
Awaiting your response,
Zaki.
On Tue, Jun 8, 2010 at 6:12 PM, <baseband-devel-request(a)lists.osmocom.org>wrote:
> Send baseband-devel mailing list submissions to
> baseband-devel(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
> baseband-devel-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> baseband-devel-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
> 1. Re: Trouble building Osmocom (Adrian-Ken Rueegsegger)
> 2. Re: Trouble building Osmocom (Sylvain Munaut)
> 3. AW: Trouble building Osmocom (Riemer, Bjoern)
> 4. Re: Trouble building Osmocom (Holger Freyther)
> 5. Trouble building Osmocom (Zaki Ud Din)
> 6. Re: Trouble building Osmocom (Holger Freyther)
>
>
> ---------- Forwarded message ----------
> From: Adrian-Ken Rueegsegger <ken(a)codelabs.ch>
> To: Zaki Ud Din <fyproject14(a)gmail.com>
> Date: Tue, 08 Jun 2010 12:44:56 +0200
> Subject: Re: Trouble building Osmocom
> Hi,
>
> Zaki Ud Din schrieb:
> > Hello,
> >
> > Thank you very much for your reply. No my config.log file seems to be
> > different. I am pasting a portion of config.log file below and am also
> > attaching the complete file with this email.
>
> [snip]
>
> > configure:2866: arm-elf-gcc --version >&5
> > ../configure: line 2868: arm-elf-gcc: command not found
> > configure:2870: $? = 127
> > configure:2877: arm-elf-gcc -v >&5
> > ../configure: line 2879: arm-elf-gcc: command not found
> > configure:2881: $? = 127
> > configure:2888: arm-elf-gcc -V >&5
> > ../configure: line 2890: arm-elf-gcc: command not found
> > configure:2892: $? = 127
> > configure:2915: checking for C compiler default output file name
> > configure:2937: arm-elf-gcc -Os -ffunction-sections
> > -I../../../../target/firmware/include conftest.c >&5
> > ../configure: line 2939: arm-elf-gcc: command not found
>
> It does not find the toolchain/cross-compiler. Where did you
> install/unpack the toolchain? Please check that it is really in
> "/gnuarm-4.0.2/arm-elf/bin". Otherwise you have to export the proper path.
>
> -Adrian
>
>
>
>
> ---------- Forwarded message ----------
> From: Sylvain Munaut <246tnt(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 8 Jun 2010 12:43:19 +0200
> Subject: Re: Trouble building Osmocom
> This seems pretty clear :
>
> > ../configure: line 2939: arm-elf-gcc: command not found
>
> Make sure you have a good ARM toolchain installed ... (look it up on
> google, plenty of doc on how to install one).
>
> Sylvain
>
>
>
>
> ---------- Forwarded message ----------
> From: "Riemer, Bjoern" <bjoern.riemer(a)fokus.fraunhofer.de>
> To: "Zaki Ud Din" <fyproject14(a)gmail.com>, <
> baseband-devel(a)lists.osmocom.org>
> Date: Tue, 8 Jun 2010 13:07:30 +0200
> Subject: AW: Trouble building Osmocom
>
> Hi
>
>
>
> You say that you unpacked the gcc compiler to your home directory and then
> set you path to PATH=/gnuarm-4.0.2/arm-elf/bin:$PATH ..
>
> Unless your home directory is set to / the path to the gcc compiler is
> wrong.
>
>
>
> bjoern
>
>
>
> *Von:* baseband-devel-bounces(a)lists.osmocom.org [mailto:
> baseband-devel-bounces(a)lists.osmocom.org] *Im Auftrag von *Zaki Ud Din
> *Gesendet:* Sonntag, 6. Juni 2010 22:21
> *An:* baseband-devel(a)lists.osmocom.org
> *Betreff:* Trouble building Osmocom
>
>
>
> Hello,
>
> I have been trying to build osmocom but have been getting errors in doing
> so.
>
> Firstly, I downloaded the following file,"* binutils-2.16.1,
> gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under
> GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home
> folder.
>
> Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/
>
> bin:$PATH" in terminal window. Afterwards when I entered "make" under
> "/osmosom-bb/src", I got the following errors
>
>
> zaki@zaki-desktop:~/osmocom-bb/src$ make
>
> cd shared/libosmocore/build-host && make
> make[1]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> make all-recursive
> make[2]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> Making all in include
> make[3]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
> Making all in osmocore
> make[4]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
> Making all in protocol
> make[5]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol'
> make[5]: Nothing to be done for `all'.
> make[5]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol'
> make[5]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
> make[5]: Nothing to be done for `all-am'.
> make[5]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
> make[4]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
> make[4]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
> make[4]: Nothing to be done for `all-am'.
> make[4]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
> make[3]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
> Making all in src
> make[3]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src'
> Making all in tests
> make[3]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
> Making all in timer
> make[4]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer'
> make[4]: Nothing to be done for `all'.
> make[4]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer'
> Making all in sms
> make[4]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms'
> make[4]: Nothing to be done for `all'.
> make[4]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms'
> make[4]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
> make[4]: Nothing to be done for `all-am'.
> make[4]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
> make[3]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
> make[3]: Entering directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> make[3]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> make[2]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> make[1]: Leaving directory
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
> cd shared/libosmocore/build-target && ../configure \
> --host=arm-elf-linux --disable-shared --disable-talloc
> --disable-tests \
> CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections
> -I../../../../target/firmware/include"
> configure: WARNING: If you wanted to set the --build type, don't use
> --host.
> If a cross compiler is detected then cross compile mode will be used.
>
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
>
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking for arm-elf-linux-strip... no
> checking for strip... strip
> checking whether make sets $(MAKE)... (cached) yes
>
>
> checking for arm-elf-linux-gcc... arm-elf-gcc
> checking for C compiler default output file name...
> configure: error: in
> `/home/zaki/osmocom-bb/src/shared/libosmocore/build-target':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> make: *** [shared/libosmocore/build-target/Makefile] Error 77
>
> I shall be grateful to you if you could help me on this.
>
> Awaiting your Response,
>
> Zaki.
>
>
> ---------- Forwarded message ----------
> From: Holger Freyther <zecke(a)selfish.org>
> To:
> Date: Tue, 08 Jun 2010 20:05:45 +0800
> Subject: Re: Trouble building Osmocom
> On 06/08/2010 07:59 PM, Zaki Ud Din wrote:
> > Hello,
>
> > I did export the path using the following line "export
> > PATH=$PATH:/home/zaki/gnuarm-
> > 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got
> > the errors I told you.
> >
> > Awaiting your response,
>
> Well,
> it claims to not find arm-elf-gcc. Have you considered checking that
> this application exists? e.g. does which arm-elf-gcc lead to anything?
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Zaki Ud Din <fyproject14(a)gmail.com>
> To: baseband-devel(a)lists.osmocom.org, Holger Freyther <zecke(a)selfish.org>
> Date: Tue, 8 Jun 2010 16:59:23 +0500
> Subject: Trouble building Osmocom
> Hello,
>
> Thank you very much for your reply.
>
> I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0,
> insight-6.4, TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from
> www.gnuarm.com. I then extracted to the folder named "Zaki".
>
> I did export the path using the following line "export
> PATH=$PATH:/home/zaki/gnuarm-
> 4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got
> the errors I told you.
>
> Awaiting your response,
>
> Zaki.
>
> ---------- Forwarded message ----------
> From: Holger Freyther <zecke(a)selfish.org>
> To: baseband-devel(a)lists.osmocom.org
> Date: Tue, 08 Jun 2010 21:12:05 +0800
> Subject: Re: Trouble building Osmocom
> On 06/08/2010 09:01 PM, Huseyin Turan wrote:
>
> > checking for gcc... gcc
> > checking for C compiler default output file name...
> > configure: error: in
> > `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host':
> > configure: error: C compiler cannot create executables
> > See `config.log' for more details.
>
> Looking at the log file is always a good idea. It might have an eye
> opening effect....
>
>
> >
> > That is; in gnuarm-4.0.2/arm-elf/bin there are executables like
> > gcc,g++,etc. which can be executed.
> > in gnuarm-4.0.2/bin there are executables like
> > arm-elf-gcc,arm-elf-g++,etc. which can not be executed.
> >
> > Which path is true?
>
> You want to use your normal gcc and such, so putting
> gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the
> issue with arm-elf-gcc? What happens when you try to execute it?
>
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel(a)lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
On 06/08/2010 09:24 PM, Huseyin Turan wrote:
> name1@name1-desktop:~/osmocom/gnuarm-4.0.2/bin$ ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
Why is that the case? The basic checks are
a.) did the +x bit go missing on that file?
b.) file ./arm-elf-gcc tells you what architecture is that?
uname -a tells you what architecture are you running on?
c.) when the above fails, we will talk about it...
On 06/08/2010 09:01 PM, Huseyin Turan wrote:
> checking for gcc... gcc
> checking for C compiler default output file name...
> configure: error: in
> `/home/name1/osmocom/osmocom-bb/src/shared/libosmocore/build-host':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
Looking at the log file is always a good idea. It might have an eye
opening effect....
>
> That is; in gnuarm-4.0.2/arm-elf/bin there are executables like
> gcc,g++,etc. which can be executed.
> in gnuarm-4.0.2/bin there are executables like
> arm-elf-gcc,arm-elf-g++,etc. which can not be executed.
>
> Which path is true?
You want to use your normal gcc and such, so putting
gnuarm-4.0.2/arm-elf/bin in your path is not that clever. What is the
issue with arm-elf-gcc? What happens when you try to execute it?
Hello,
Thank you very much for your reply.
I am using ,"* binutils-2.16.1, gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4,
TAR BZ2 [65.5MB]*" under GCC-4.0 toolchain from www.gnuarm.com. I then
extracted to the folder named "Zaki".
I did export the path using the following line "export
PATH=$PATH:/home/zaki/gnuarm-
4.0.2/arm-elf/bin/ " and afterwards I typed "make firmware" and then got the
errors I told you.
Awaiting your response,
Zaki.
Hello,
I have been trying to build osmocom but have been getting errors in doing
so.
Firstly, I downloaded the following file,"* binutils-2.16.1,
gcc-4.0.2-c-c++, newlib-1.14.0, insight-6.4, TAR BZ2 [65.5MB]*" under
GCC-4.0 toolchain from www.gnuarm.com and extracted this to my home folder.
Secondly, I gave the following path "export PATH=/gnuarm-4.0.2/arm-elf/
bin:$PATH" in terminal window. Afterwards when I entered "make" under
"/osmosom-bb/src", I got the following errors
zaki@zaki-desktop:~/osmocom-bb/src$ make
cd shared/libosmocore/build-host && make
make[1]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
make all-recursive
make[2]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
Making all in include
make[3]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
Making all in osmocore
make[4]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
Making all in protocol
make[5]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore/protocol'
make[5]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
make[4]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include/osmocore'
make[4]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
make[3]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/include'
Making all in src
make[3]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/src'
Making all in tests
make[3]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
Making all in timer
make[4]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/timer'
Making all in sms
make[4]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests/sms'
make[4]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
make[3]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host/tests'
make[3]: Entering directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
make[3]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
make[2]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
make[1]: Leaving directory
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-host'
cd shared/libosmocore/build-target && ../configure \
--host=arm-elf-linux --disable-shared --disable-talloc
--disable-tests \
CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections
-I../../../../target/firmware/include"
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for arm-elf-linux-strip... no
checking for strip... strip
checking whether make sets $(MAKE)... (cached) yes
checking for arm-elf-linux-gcc... arm-elf-gcc
checking for C compiler default output file name...
configure: error: in
`/home/zaki/osmocom-bb/src/shared/libosmocore/build-target':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [shared/libosmocore/build-target/Makefile] Error 77
I shall be grateful to you if you could help me on this.
Awaiting your Response,
Zaki.
This seems pretty clear :
> ../configure: line 2939: arm-elf-gcc: command not found
Make sure you have a good ARM toolchain installed ... (look it up on
google, plenty of doc on how to install one).
Sylvain
hi,
if you pull the git, you will notice that i submitted the lapdm code i
was working on. location update with app_mobile works now. (at least for
the combined BCCH+CCCH+SDCCH4) the best way to test the location update
is to setup a mobile test card to manual network selection, and to set
the registered PLMN to the tester's network. see VTY interface for more.
what happens:
- the previously store ba-list of frequencies is used to search for the
registered PLMN. since there is only one frequency on a tester, the
power measurement is done on this frequency only.
- the power measurement result is positive, so a sync request is made to
that channel.
- the sync is indicated by layer 1.
- the BCCH data is received. the cell is "suitable and allowable".
- a sync request is done again, because this cell is the one to "camp
on".
- a sync request is done again, because the mobility management process
makes a location update and requests a channel from the radio ressource.
- the sync is confirmed by layer 1.
- after syncing to the channel the layer 2 is activated by the BTS.
- the location updating request is sent and messages are exchanged until
the location update is complete.
- the layer 2 is de-activated by the BTS.
- the release of layer 2 is currently not processed by RR, so the timout
aborts the radio link. (but this is fixed soon)
but there are problem:
1. the layer 1 sometimes crashes when sending frames. i guess there is
no queue inside... i currently don't care about any confirm of a frame,
so i send all frames i need to send. i would like to get a confirm when
a frame is sent, so i can send the next frame without making layer 1
overflow. this confirm would also be handy for RACH requests when they
are sent. since there are only few message during a location update or a
call, i think this is not much overhead. when requesting sync/rach
again,
all pending frames (RACH request / transmit data) shall be removed
inside
layer 1.
2. when sending two sync requests to layer 1 without a delay, the layer
1 crashes. i expect to do a sync request at any time. also when sending
a sync request before i got a response, i do not know to which the
response belongs to which request. (delayed on the serial line) a
confirm of every sync request would be handy, so i can wait for this
confirm until i make another sync request to a different channel. this
confirm just tells me that the layer 1 has received the sync request and
is able to receive another sync request. also when syncing to a
different channel, i skip any sync result or received frames until i get
the confirm, so i can skip any data from the last channel i was synced
to.
andreas
Hello,
I am a little new to ubuntu and am trying to build osmocom-bb but i am
facing some problems in doing so. I found your emial address in the .c files
present in the Osmocom-bb folder. I have downloaded the GNU toolchain for
ARM which is the first step in building Osmocom. But I am not able to
understand the second step in which I have to set a path to include the
arm-elf-* executables of the toolchain. Would you please help me on this?
Awaiting your response,
Zaki.
