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.
