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.
Hi all!
I've merged a number of layer1 related changes that I've been working on
for quite some time.
The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been
replaced by L1CTL_FBSB_REQ. When issuing FBSB_REQ, you can specify what
tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB).
Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP
with result=0xff. This means there is now proper error reporting.
Let's say you want a relatively quick indication if the ARFCN specified
could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return
even more quickly. You will definitely get a response after some 15 TDMA
frames if there was a frequency burst or not.
Furthermore, I have changed some details of the FB/SB acquisition process:
Rather than waiting for a fixed amount (500) TDMA frames before switching from
FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency
delta and SNR. The frequency thresholds can actually be specified by L1CTL,
the SNR thresholds are hardcoded.
One problem with fast scanning was that by erroneous FB0 reports, we tuned our
VCO so far off the desired frequency that it never synced to any cell at all
anymore. I have reduced that problem by simply resetting the AFC-DAC to
its default value every time we start a FBSB acquisition.
Andreas: I think it would make sense to use the S_L1CTL_FBSB_RESP and
S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR,
you can immediately switch to the next ARFCN without wasting further time.
My next API change will be to introduce a separate command, i.e. FBSB_REQ
will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the
application will have to explicitly request that. However, I don't think I'll
find much time throughout the next 10 days or so.. .sorry :/
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,
* Daniel Willmann <daniel(a)totalueberwachung.de> [2010-05-17 11:48]:
> For now just copied over the compal_e88 init.c and adapted the RF
> frontend functions. For osmocon to work with the GSM download cable
> SERCOMM_UART_NR and CONS_UART_NR need to be switched.
[...]
> +/* describe how the RF frontend is wired on the Openmoko GTA0x boards */
> +
> +#define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */
> +#define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */
> +#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */
> +
> +/* All VCn controls are low-active */
> +#define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */
> +#define ASM_VC2 TSPACT(1) /* Antenna switch VC2 */
> +#define ASM_VC3 TSPACT(4) /* Antenna switch VC3 */
> +
> +#define IOTA_STROBE TSPEN0 /* Strobe for the Iota TSP */
> +#define RITA_STROBE TSPEN2 /* Strobe for the Rita TSP */
> +
> +/* switch RF Frontend Mode */
> +void rffe_mode(enum gsm_band band, int tx)
> +{
> + uint16_t tspact = tsp_act_state();
> +
> + /* First we mask off all bits from the state cache */
> + tspact &= ~PA_ENABLE;
> + tspact |= GSM_TXEN; /* low-active */
[...]
I'm not sure what the correct value is in this case but
GSM_TXEN is not defined at this point.
Cheers
Nico
Hello,
these patches enable osmocom to be run on the Openmoko GTA0x devices
(only tested with GTA02). The first patch fixes an issue with baudrate
setting in osmocon.c (termios setting wasn't read prior to writing). The
second patch adds a gta0x board (currently only copied from compal_e88)
and implements the differences in controlling the RF frontend.
Use it as follows (on the device):
kill all processes communicating with the modem (fso, gsm0710muxd)
gta02# echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/download
Then on the PC connect the download cable and start osmocon:
# ./osmocon -m romload -p /dev/ttyUSB0 ../../target/firmware/board/gta0x/l1test.osmoload.bin
To initiate the download toggle baseband power on the phone:
gta02# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on &&
> echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
After the firmware is transferred the app should start.
Regards,
Daniel Willmann
Daniel Willmann (2):
osmocon.c: Fix serial_set_baudrate function
Add new board gta0x (for Openmoko Freerunner devices) and build it
src/host/osmocon/osmocon.c | 5 +
src/target/firmware/Makefile | 4 +-
.../firmware/board/common/rffe_gta0x_triband.c | 88 +++++++++++++
src/target/firmware/board/gta0x/init.c | 131 ++++++++++++++++++++
4 files changed, 227 insertions(+), 1 deletions(-)
create mode 100644 src/target/firmware/board/common/rffe_gta0x_triband.c
create mode 100644 src/target/firmware/board/gta0x/init.c
Hi all,
I wanted to give a short status update on the MTK platform, I spent the
last day implementing a minimal subset of the MTK romloader protocol in
osmocon.
We can now run our own C-code on the MT622x, I started by modifying the
linker script and run proms loader (because it doesn't need interrupts,
the interrupt redirection isn't yet figured out).
When writing something to the UART TX register, I see the output in
osmocon, and writing to the Baseband powerup register works as well
(otherwise you would have to hold down the power-button all the time).
Unfortunately there are no schematics for the Mobistel phone I've been
testing this with, so I haven't found out how to enable e.g. the
backlight, nothing happens when activating PWM1/2.
Today I tried to modify the Calypso UART driver for the MTK UART, but
currently I'm stuck with a strange hang somewhere in the driver, maybe
I'll look after it tomorrow.
That was it for the moment...
Regards,
Steve
Hi,
I've recently got pointed to this project. Haven't dealt with any GSM software since the mid-90ies, so I thought it may be some fun
to look at the software and participate if I find enough time. I've got access to a Racal 6103 and a C123 to start with.
A couple of questions:
1) Do I need attenuators if I wire the C123 to the Racal? Guess not, but I don't want to fry the input of the Racal.
2) External antenna connector on the C123 seems to be a MS-147. I got a couple of HF cables from a WLAN card with
this connector:
http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Cri…
but the inner conductor of the plug seems to be a bit short (may be my fault during assembly).
Does the MS-147 jack on the C123 switch off the internal antenna if anything is plugged in?
3) Does the PA of the C123 survive without any antenna connected (i.e. if it gets most of the HF reflected back) e.g. in continuous transmit mode?
4) A C123 without battery doesn't start the vendor firmware, display is blank, LED are on, flicker from time to time.
Is this a hardware problem or just the vendor firmware missing the battery, i.e. any problem to download osmocom software without any battery?
Thanks for any answers!
Hi,
I converted the X font 5x8 for use in BB and added an goto_xy
routine in case anyone wants to put something entertaining on
the LCD (besides Hello World).
Compared to the old 8x8 font..
- doesn't miss the topmost line of pixels :-)
- needs 475 bytes instead of 4k (only includes characters
ASCII 32 .. 126)
- allows for 19x8 characters on the screen
hello_world.bin prints out all glyphs for testing.
Applies to current "master" (as of 9.4.2010/15:30 MESZ).
Chris
hi,
i like to give a short update:
currently i am testing the processes of selecting a cell and the
network. the processes depend on the coverage, the sim card (network,
inserted or not) and the mode (manual or automatic network selection). i
hope i will finish this week.
to configure mode and sim card and other parameters in the future, i use
the VTY, you already know from the OpenBSC project. there you can get
informations about the subscriber, the mobile station and the received
cells (system informations).
i will move all hacked parameters (test sim) to VTY config file. manual
network selection mode requires reaction of the user, so it will also be
added to the VTY. later the VTY can also command the "call" part to
dial, answer and hangup a call.
my idea: later these VTY command structure may be used for the phone's
menu (up - down - enter - escape), if compiled appropiate. also: if
layer 3 is running on the phone, the serial port could directly connect
to the VTY, so the phone gets a console interface for debugging and
faster configuration.
currently the process (with sim card) ends while trying to do a location
update. if the given channel is not supported, the program exits. to
prevent this, just keep radio TX feature disable. the cell will be
re-selected again and again (hopefully if the process works correct).
sometimes, especially at the first run, the radio process stops. (no
results for measurements, no sync to selected frequency.)
also there is something i am wondering: calibration especially for the
burst signal phase is measured and then stored on the eeprom by the
manufacturer. do we use it? or do we need to do our own calibration?
regards,
andreas
Hi all!
In case you're interested, there seems to be a public project on
code.google.com that contains the build environment and baseband
firmware sdk from mediatek:
svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project
Please note that I don't know about the legality of this. However, it
is distributed on a public server/service without any kind of
authentication...
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!
Right now, one of our many issues in L1 is the frequency stability
(or lack thereof).
What we do right now is very primitive and is mostly based on guesswork,
rather than measurements and good algorithms.
In order to change this, we need some measurements to be done. As I am
currently again travelling a lot, and my time for OsmocomBB is more
limited now, I hope that somebody else will be able to take the
measurements as described below.
There is a big number of people in this project who now have a Racal 6103 (or
similar) measurement device. Also, for those in Berlin, the CCC Berlin has
one in its basement lab.
What needs to be done:
1) Determine the relation between AFCDAC output and actual carrier
frequency.
All that is needed is some manual control over the AFCDAC value (e.g. based on
keypad events) while the AFC is disabled.
Then we continuously transmit bursts (content is unimportant) to the
Racal 6103 and note the measured frequency error by the 6103 for every
AFC value that we input. Those measurements should then be repeated
for each supported band of the phone, preferrably each with a low-frequency
channel, a medium frequency and a high-frequency channel.
This means something like 10 different AFC values for 3 different channels
of each of the 2 bands that the c123/c155 support.
Basd on those measurements (preferrably do that series with 2-3 phones)
we can construct a function that will tell us which AFCDAC value we
should program if we want a given carrier frequency increase/decrease.
2) Determine the temperature related frequency drift and corresponding
temperature ADC reading
Especially when we transmit, the temperature in the RF section of the
phone is assumed to change quite a bit. This means we need to measure
the temperature in the oscillator (using the RITA-internal temperature
sensor connected to one of the ADC channels of IOTA) and compare that
with the frequency drift.
In order to measure this, we first need a temperature-ADC driver. Once
that exists, we can lock onto a BCCH, then make sure the AFC is disabled
and the AFCDAC output value will be stable. Next, one can use e.g. a
hairdryer or ice spray to change the temperature. While doing that, we can
measure the difference in carrier frequency with the Racal 6103.
The absolute temperature in centigrade/kelvin is not actually interesting to
us all. All we want to know is: What is the 6103-measured frequency error at
a given temperature-ADC-reading.
Once again, the measurements should be done for high (1800) and low (900)
band independently, just to be sure.
Based on their relation we can also model a function, table or other
approximation and include that in our AFC code.
I think I'll be able to write the code even while I'm on the road - if
somebody is able to do the measurements and post them to the mailing list.
Thanks in advance,
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,
I checkout the prom/loader AND prom/loader-crc part and merged it
(perhaps I use git wrong way)
When I run the loader with "osmcon -m c123xor" the loader starts but
says "Failed to initialize flash".
I tried to "romload" it with "-m romload" there only beacons but no
valid response from phone.
Sending beacon...
Sending beacon...
got 1 bytes from modem, data looks like: ff
got 1 bytes from modem, data looks like: 00
got 1 bytes from modem, data looks like: ff
Sending beacon...
Sending beacon...
Sending beacon...
Sending beacon...
1. Why the flash initialization fails?
2. Is it (currently) possible to run programs (ex. L1test from
flash)?
I (think I)read all this rom/ram/bootloader stuff.
-------------------------
Marco Rust
FOKUS - Fraunhofer Institute for Open Communication Systems
Kaiserin-Augusta-Allee 31, 10589 Berlin
marco.rust(a)fokus.fraunhofer.de
hi,
tests with layer 3 pointed out a problem. when i select a cell, i get
updates of system informations, paging requests and immediate
assignments. after about half an hour, i get some corrupt frames. i
don't know yet what is wrong.
1. is the communication between the layer 1 and layer 2 (over serial
link) secure?
2. i must be sure that a message between layers always are:
- never get lost (except unit-data or data when connection is aborted)
- never are corrupt
- received in the order they are sent
3. does layer 1 drop (bcch) frames, if they have biterrors? (as it
should do)
andreas
hi,
i like to change some tracked files without committing them. when i do
"git commit -a", every change is comitted.
sometimes i like to play with layer1 code or even change Makefile.inc,
but i don't want to reset my changes before committing.
any idea how to create a list of omitted files?
andreas
Hi!
I think we corrently have the following TODO list.
GSM Layer 1:
* implement transmit power control for transmit
* implement SDCCH/8 on TS1-7 (Sylvain)
* implement frequency hopping
* proper split between synchronous and asynchronous part of L1 (Harald)
* TCH/F support (Dieter, after L3 RR/MM/CC is working)
* A5/1 and A5/2 encryption support
GSM Layer 2:
* implement a real layer2 that deserves the name (full LAPDm implementation)
* properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt
call L1 directly anymore
GSM Layer 3:
* test most of the code that Andreas has written (depends on L1 / L2)
Misc:
* SIM card driver + ISO7816 FS API
* Battery charger driver
* UI framework
* minimal journalling flash file system
* decide which RTOS kernel we want to use (Harald)
* fully support a working firmware build for the openmoko gta01/gta02 GSM modem
using calypso romloader
For people who don't feel like they can take any of this work, there is some
other work, regarding the mid-term port to our next target platform:
* implement host utility for the medaitek MT622x romloader serial protocol
* try to get a minimal hello world codebase to run on the MT622x
* write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x
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 Harald,
On Wed, 28 Apr 2010 20:26:07 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote:
>
> GSM Layer 1:
> * implement transmit power control for transmit
> * implement SDCCH/8 on TS1-7 (Sylvain)
> * implement frequency hopping
> * proper split between synchronous and asynchronous part of L1 (Harald)
> * TCH/F support (Dieter, after L3 RR/MM/CC is working)
> * A5/1 and A5/2 encryption support
I can take care of
* implement frequency hopping
* A5/1 and A5/2 encryption support
in addition to
* TCH/F support
because this would fit together (just different setting on the GSM
testset to do frequency hopping or encryption with a TCH).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
> This is a known problem, but despite working from morning through
night I
> really don't have any time to fix the various layer1 issues at the
moment,
> sorry. In fact, there are some fundamental changes/cleanups required,
and
> I've already literally spent days in coming up with an architecture
that seems
> to make sense to me :/
> I know it must be frustrating for you, but it seems our schedules
didn't match
> very well.
hi harald,
i am currently testing the process of cell selection. when i limit the
number of cells down to 1, i can test some parts of the process.
don't worry about frustrating me. i can wait until these issues are
solved. until then, there is so much more for me todo:
- system information parsing test
- testing location update procedure
- working on incomplete radio ressource process
- maybe start working on some layer 4 application (lcr interface)
regards,
andreas
hi,
while debugging my layer3 code and testing bcch_scan, i got the following problem:
the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system informations are received. subsequently tuning to another channel does not give any rx data. any idea?
andreas
Mit freundlichen Grüßen,
.-.
/'v'\
(/ \)
------------------------------------------------------------------"-"-
|_|
i.A. Andreas Eversberg
Network Operations / 2nd Level Data - KC Internet
Versatel Nord GmbH
Nordstr. 2
D-24937 Flensburg
Fon: +49-461-9099749 | Fax: +49-461-909960749
andreas.eversberg@versatel.de@versatel.de | www.versatel.de
Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL
Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven
> - rslms_recvmsg() frees message if discriminator is not known,
otherwhise it forward it to rslms_rx_rll().
> - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does
not free it when RLL message type is unknown.
it seems that the message is freed by the receiving layer (or function),
but i cannot understand why layer2_read() in main.c does it after
calling l1ctl_recv.
hi,
1) thanx for that info. i can see that you tried running it...
2) i have not checked it. i hope that msg->l3h points to l2 pseudo header.
3) before fixing that, i need to have an issue solved:
two approaches to free a message, if it passes a layer border?
a) the sending layer frees the message after calling the other layer.
b) the receiving layer frees the message.
i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used:
- rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll().
- rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown.
this issue must be solved soon, i think.
thanx for looking at it,
andreas
-----Ursprüngliche Nachricht-----
Von: Sylvain Munaut [mailto:246tnt@gmail.com]
Gesendet: Montag, 26. April 2010 15:22
An: Andreas.Eversberg
Cc: baseband-devel(a)lists.osmocom.org
Betreff: Re: Layer 3 status
Hi,
> i will start testing it tonight and hope to get results soon.
Here's a few bug reports
Sorry, there are no 'proper' fix or patches for them, I just worked
around them with ugly hacks see if I could get up to LOCATION UPDATE
REQUEST, then it was kinda late ... I hope just pointing them out will
help you a bit anyway.
1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn
/* if no PLMN in list */
- if (plmn_first) {
+ if (!plmn_first) {
2) BCCH message don't have the same header.
See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind
struct gsm48_hdr *gh = msgb_l3(msg);
But in BCCH some message don't have this header and have a 'L2 pseudo
length' field ...
3) You do a msgb_free on messages in , but the layer 1 will actually
have freed those message already.
See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd)
l1ctl_recv((struct osmocom_ms *) fd->data, msg);
msgb_free(msg); // <======
Sylvain
hi,
i like to give a short update about the current layer 3 development.
everything compiles, but is not tested and debugged yet. it is divided
into five processes:
- radio ressource
this process is partly complete. it implements functions to establish
radio ressource connection. especially handover and release/abort is not
implemented, but will follow soon. most things here depend on services
of the radio part. as the radio part gets more and more functionality,
the radio ressource can be more and more completed.
- mobility management
this process is complete. it also implements the location update
process.
- call control
this process is complete. the MNCC interface of the call control is
almost identical to the openbsc. therefore i would suggest to merge both
"mncc.h" header files and put them into osmocore. currently there is a
minimal application in mnccms.c which rejects any call. (any MS must at
least do this.) later, a small telephone application could be used.
- cell selection
this process is complete. it does not do any measurements on the radio
part for cell (re-)selection. what it does is taking the results and
storing them in a structure. the structure is then used for selecting a
cell. it also controls the frequency used by the radio part.
- PLMN selection
this process is complete. but the manual cell selection requires a user
interface, which does not yet exist. it uses informations from cell
selection process to select available networks.
the term 'complete' refers only to basic call/data service. there is no
VGCS, VBS, multislot, GPRS, SoSLA support. since there is no interface
to the SIM card process (reading of data / storing data), there is just
a comment in the source code whenever data has to be transferred from/to
the SIM. also some special things, like NCC or cell priorization may be
missing.
i will start testing it tonight and hope to get results soon.
regards,
andreas
Hello Sylvain,
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
>
> When you look deeper into the call, there is the PLL setup that is done
> even earlier, to ensure that it's finished by that 'start' time.
The earlier versions I refer to did no yet switch RX/TX for each burst,
they used to switch after four burst were received/transmitted. In those
versions only the ABB windows was used with the TPU, however we had the
same situation because the code till enabling the TPU took longer than
the "AT" value.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sylvain,
On Sun, 25 Apr 2010 15:16:48 +0000, 246tnt(a)gmail.com wrote:
>
> * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the
> first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo
> 5000 is somewhere around 4944. So when we start executing the TPU scenario
> in the interrupt handler, that first AT command will force to wait almost
> an entire frame and the rx window will be properly placed in the next frame.
To be true, I don't know where the "- 100" in the recent versions come
from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME -
TSP_DELAY - 6). This is about 50 us. However we had the same situation
(actual processing happens in the next frame) because the time to
execute the code after the interrupt occured till the TPU was
enabled took a little bit more than those 50 us. Probably the
code has changed in recent versions so that it tooks less than
those 50 us and "- 100" is needed.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hi all,
as this has been a quite weird bug so far, and Sylvain now seems to have
run into some related problems when trying to make a SDCCH8 on TS1 work,
I'll elaborate a bit more on it.
Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as
follows:
1) The time between the TDMA interrupt happening and starting to execute
l1_sync() and actually being able to configure the TPU window and tell the
DSP what to do was too short for performing the scheduled work in the
very same TDMA frame.
2) As a result, the actions that we thought were performed in the same TDMA
were actually performed one TDMA later. Somehow we must have had another
off-by-one error and thus the two errors compensated themselves in most
cases, particularly for Rx
3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after
which the DSP has to do the FEC, Fire CRC, burst spreading, etc -
before being able to generate the bits for the furst burst. Those
bits then get sent over the TSP to the ABB (into its burst buffer),
from where they are sent based on TPU signals.
So what happened is that the data of the first burst was not in the
burst buffer yet, and the TPU signals triggered sending the last burst
of the previous MAC block, rather than the first burst of the current.
This is why Dieter added the
> tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */
to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one
TDMA frame. At that time, the DSP has by long finished writing the new burst
bits in to the ABB burst buffer, and we can transmit the correct burst data.
I personally believe it would be better to simply move the TDMA interrupt a bit
more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO
in a way that it occurs at a defined point in time still quite a bit into TS7.
In this case we hopefully have enough time for the DSP to be able to transmit
in TS0, making the timing sequence easier to understand.
Hope that helps to explain...
--
- 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 playing for a while with the buzzer & PWT registers and I'm able to
hear 'sound' according to the frequencies supported. The thing I can't
not understand well is the relation between the PWT (pulse width tones)
and the PWL (pulse width light), if exists:
A) After loading some frequency into the PWT, set the volume and hear
the it, if I change PWT to BU in the ASIC_CONF_REG, backlight intensity
changes and sound stops.
B) With LT output selected in the ASIC_CONF_REG instead of PWL, changes
over the PWT registers produce nothing.
Hi,
I was reading the bl_mode_pwl function at backlight.c and found
that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2)
which doesn't map to any known reg. According to the second datasheet
PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at
0xfffe8001.
maybe i'm wrong?
regards,
emerson.
Hi!
As you can see, there is not really that much progress throughout the last 2
weeks or so. Dieter and myself were the only two who actually looked at how
to driver the DSP, TPU and RF hardware, write the drivers for it and the
existing layer1 code. Now we're both busy with other (paid) work, and
the project almost seems stuck.
I would like to see this change. I'm quite sure there are some other folks
on this list who would be interested in diving in those lower layer bits
of the system. However, I also understand there is not all too much that
can be done without running your own non-hopping BTS (as we don't do frequency
hopping at the moment). So a working OpenBTS, OpenBSC setup or something
like a CMD55 or Racal 6103 are a precondition.
Nonetheless, a number of people on this list have access to those devices.
I'd like to encourage some other people to also look at this and remove the
dependence on Dieter and myself in that area.
Furthermore, members of the IRC channel have certainly noticed the growing
interest in a potential port to the Mediatek chipset based devicees. Mediatek
is churning out more than 95 million chipsets every quarter, so there is plenty
of phones around.
The data sheets, reference schematics and other training materials can easily
be found on a lot of chinese developer websites - as is the Mediatek SDK.
However, the critical layer1 and DSP API part is only provided in object code,
and the documentation does not document it.
Still I believe it is feasible. So if you want to stay out of the GSM part,
feel like the Calypso is too boring for you: Why not work on getting a minimal
custom software image for the MT622x running, including bootloader support,
keypad/touchscreen and graphics output? If that is done by the wider
community, the so-called experts can focus on looking at the GSM side of things
once they have time.
Even on the Calypso there are many tasks that still need to be finished,
including battery charging, power management, file system, SIM Card API,
etc.
If you know somebody who understands C development for microcontrollers and
wants to help building the worlds first Free Software GSM baseband chipset
software, please motivate them to join. We can really need every helping hand
we get.
Happy hacking,
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)
