baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

Constructors
by Harald Welte 29 Jun '10

29 Jun '10

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)

3 3

OsmocomBB Layer1 progress
by Harald Welte 26 Jun '10

26 Jun '10

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)

1 0

Some L1 status updates
by Sylvain Munaut 25 Jun '10

25 Jun '10

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

2 3

AW: Some L1 status updates
by Andreas.Eversberg 24 Jun '10

24 Jun '10

> - 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");

3 2

AW: Some L1 status updates
by Andreas.Eversberg 23 Jun '10

23 Jun '10

> 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.

1 0

l1test without hdlc (sercomm)
by Rust, Marco 23 Jun '10

23 Jun '10

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

2 2

[PATCH] l1ctl.c: add missing ntohs for band_arfcn
by Jan Luebbe 17 Jun '10

17 Jun '10

This fixes mangled ARFCN numbers in gsmtap. --- src/host/layer23/src/l1ctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/host/layer23/src/l1ctl.c b/src/host/layer23/src/l1ctl.c index 051b3d8..5e683d3 100644 --- a/src/host/layer23/src/l1ctl.c +++ b/src/host/layer23/src/l1ctl.c @@ -165,7 +165,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) /* send CCCH data via GSMTAP */ gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, dl->link_id); - gsmtap_sendmsg(dl->band_arfcn, chan_ts, gsmtap_chan_type, chan_ss, + gsmtap_sendmsg(ntohs(dl->band_arfcn), chan_ts, gsmtap_chan_type, chan_ss, tm.fn, dl->rx_level-110, dl->snr, ccch->data, sizeof(ccch->data)); -- 1.7.1

2 1

Thank you
by Zaki Ud Din 17 Jun '10

17 Jun '10

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.

2 1

Fwd: SIM card driver
by Drasko DRASKOVIC 11 Jun '10

11 Jun '10

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

2 2

Re:Trouble building Osmocom
by Zaki Ud Din 10 Jun '10

10 Jun '10

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.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel