Hi,
I've hacked something together to quickly test non-combined CCCH.
However, I've hit a problem when trying to receive anything on another
timeslot than 0.
The TX side seems to work fine as the BTS can see my location update
request and answers with a reject, but on the MS side, I never see the
reject and wireshark only shows invalid incohrent data on the RX.
The frames for SDCCH/8 show really nothing valid (looks like random
bytes), things like
09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36
...
while the frames for the associated SAACH show at least something gsm-like :
03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
but that's not quite a SI5/6 ...
To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 *
156.25) when I'm in dedicated channel mode by chaning the 'start' in
l1s_tx_win_ctrl / l1s_rx_win_ctrl
Is there something else that should be done ?
Cheers,
Sylvain
Hi!
Recently we've had the idea of using OsmocomBB with a simple firmware
that synchronizes to an existing GSM networks FCCH and use the resulting
13MHz clock to drive the USRP for airprobe or OpenBTS.
Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to
multiply it up to the required 52 MHz. However, neither the Openmoko
nor the Compal/Motorola phones expose any of the 3 clock output pads :(
So the only choice is to use something along the lines of the
http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html
as a quad clock multiplier and attach it to the CLK13OUT signal of the
phone.
The chip is available for 9 USD in single quantities at digikey, and
possibly cheaper at other sources. Combined with a sub-20EUR phone it
might be a very cheap but still accurate frequency source for OpenBTS -
at least as long as there are any commercial gsm networks available.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi All!
That's true, I managed to run U-Boot on MT6235, but linux kernel is
not fully functional yet (it's fresh stuff as I managed to ran it on
Tuesday and then I was off to conference).
For MT6235 development I chose Sciphone G2, which is pretty cheap.
After some time I managed to download code to SRAM (just 64KB) using
MTK's FlashTool.
MTK FlashTool communicates over UART directly with MT6235 bootloader
and sends its own chunk of code (about 58KB) which is executed in SRAM
and communicates with FlashTool.
I found on pudn.com some pack to customize code loaded by FlashTool,
thanks to which I could download my own code to SRAM (without JTAG).
The problem was that it had to be linked with some security libraries
which occupied about 56KB and not much memory left for my own code.
Then I decided to try find JTAG pins to get all control on MT6235.
That took me sometime, but finally I succeeded.
The other bigger issue was initializing DRAM controller to be able to
download bigger code (linux kernel + uboot) to external RAM. In
sciphone there is problem that all interesting chips are under metal
shield which is pretty havily soldered. In this case I couldn't read
what kind of RAM memory is mounted without destroying the board (I
don't have such soldering machine which could unsolder so big metal
shield). Thanks to JTAG I could attach to target and then dump DRAM
controller registers from processor running MTK's software, but
setting these values after processor start and configuration of PLL
didn't work.
I decided to disassemble bootloader which could show me how DRAM
controller is initialized and how code fron NAND is loaded (to be able
to flash U-Boot and kernel to NAND so MT6235 will start my code
automatically and I will not have to use JTAG). Currently I have
knowledge how internal MT6235 bootloader is loading code from memory
during startup and I also extracted procedure of DRAM controller
initialization. Thanks to that I'm able to run U-Boot from the very
begining of processor startup.
The problem is that I have just one piece of Sciphone G2 and I don't
want to flash it yet to not break existing code in it. Thanks to
running device I'm able to attach with JTAG and check how peripherals
are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm
not 100% sure if I will flash it back, phone will startup. That's why
I bought second piece of Sciphone G2 and should receive it today or on
Tuesday (this Monday is holiday in Poland). In this case I'll flash
U-Boot to NAND and try to make it working. Then we could load the rest
of code from U-Boot (to RAM or NAND over serial).
You can see how my setup looks on attached picture.
The good thing about it is that the same bootloader is used in MT622x,
so it should be fairly easy to do the same on phones based on that
SoCs (but unfortuantely it's just ARM7).
If it comes to code, of course I can share it on "git.osmocom.org".
Currently it's just basic port of U-Boot and not much for linux
kernel, but I'm working on this now so I'll push it when it'll be
ready.
Currently I'm working on driver for NAND memory for U-Boot, so we
could flash linux kernel. When that will be ready I'll push the code.
Then I'll switch to linux kernel and when it'll be functional I also
push the code. At this stage you will not need to have JTAG and you
could load the code over serial in U-Boot.
If it comes to GSM I didn't work with it before. I actualy worked 6
months in L2/3 team for LTE (on RRC) but it's different story.
That could be really outstanding thing if we could run first phone
ever with whole code open (from BB up to APP).
BR,
Marcin
Hi guys,
I dunno if that is the right place for my concern about building the
osmocomBB source. Here is what I already have done:
- downloading the sources for osmocomBB and GNU toolchain for ARM,
- setting the PATH for the arm-elf-* executables,
- calling make in the src directory.
Now, this appears as response of the make command in the terminal:
cd shared/libosmocore/build-host && ../configure
configure: error: cannot find install-sh, install.sh, or shtool in ".."
"../.." "../../.."
make: *** [shared/libosmocore/build-host/Makefile] Error 1.
If you need details about my system, you can look at the following
snippet from the config.log file:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libosmocore configure UNKNOWN, which was
generated by GNU Autoconf 2.65. Invocation command line was
$ ../configure
## --------- ##
## Platform. ##
## --------- ##
hostname = ubuntu-stefan
uname -m = x86_64
uname -r = 2.6.32-24-generic
uname -s = Linux
uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin
## ----------- ##
## Core tests. ##
## ----------- ##
configure:2032: error: cannot find install-sh, install.sh, or shtool in
".." "../.." "../../..".
So, I would be very glad, if someone could give me a hint to solve the
problem. Thank you in advance.
Regards,
begy
Hi All!
At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe,
one of the attendees (Marcin, see Cc) came to me after the talk and told me he
had recently done a u-boot and Linux kernel port to the MT6235 (that's the
ARM926 based chipsets found in the touchscreen MTK phones).
He said he has no understanding of GSM or the existing MTK firmware, but is
interested in working together with us to try to make the GSM part work.
I think that chipset is very intesting, as we could implement the layer1
inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and
layer3 implementations as userspace processes on the Linux system, together
with the user interface.
The performance of those devices should be somewhere between the Openmoko GTA01
and GTA02, and the GSM stack is certainly not going to eat away a lot of the
CPU either.
I have asked Marcin to write mail to the OsmocomBB mailing list on where we can
find the code. He has so far downloaded the code using JTAG. Combining his
code with our ramloader might remove that JTAG dependency...
Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a
separate trac installation for your mtk-linux work, pleaes let me know, I'd be
happy to host that.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
On 06/08/2010 09:41 PM, Huseyin Turan wrote:
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc
> -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc
> bash: ./arm-elf-gcc: cannot execute binary file
> root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a
> Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15
> UTC 2010 i686 GNU/Linux
>
please try b.) again (you miss the file part) and also please reply to
the mailinglist.
Hello,
I try to use the 'host23/mobile' application on a C123 but without
success. I followed Steve's instructions[1] with today's git tree
(d95eddad):
1. osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin
2. ./host/layer23/src/mobile/mobile
3. Power on the phone
(output of theses commands is thereafter)
But I'm not sure it really works: the firmware seems to freeze (not
responding to the power button anymore) and the last output of 'mobile'
is:
<0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE)
Based on the low rxlevel, I guess it is not acquiring any meaningful
signal?
In [2], Steve said the internal antenna was switched off when the cable
is plugged in, is it still true?
I tried to RTFM but I am stuck here.
Thanks for your patience,
Footnotes:
[1] http://baseband-devel.722152.n3.nabble.com/Running-osmocombb-on-a-Motorol-C…
[2] http://lists.osmocom.org/pipermail/baseband-devel/2010-May/000435.html
,----
| % osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin
| ...
| Received DOWNLOAD ACK from phone, your code is running now!
|
| OSMOCOM Layer 1 (revision osmocon_v0.0.0-598-gd95edda)
| ======================================================================
| Device ID code: 0xb4fb
| Device Version code: 0x0000
| ARM ID code: 0xfff3
| cDSP ID code: 0x0128
| Die ID code: ebd8283cba021198
| ======================================================================
| REG_DPLL=0x2413
| CNTL_ARM_CLK=0xf0a1
| CNTL_CLK=0xff91
| CNTL_RST=0xfff3
| CNTL_ARM_DIV=0xfff9
| ======================================================================
|
| THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
| Assert DSP into Reset
| Releasing DSP from Reset
| Setting some dsp_api.ndb values
| Setting API NDB parameters
| DSP Download Status: 0x0001
| DSP API Version: 0x0000 0x0000
| Finishing download phase
| DSP Download Status: 0x0002
| DSP API Version: 0x3606 0x0000
| LOST 7478!
| L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124
| PM MEAS: ARFCN=0, 27 dBm at baseband, -110 dBm at RF
| PM MEAS: ARFCN=0, 26 dBm at baseband, -112 dBm at RF
| PM MEAS: ARFCN=1, 30 dBm at baseband, -107 dBm at RF
| PM MEAS: ARFCN=2, 29 dBm at baseband, -108 dBm at RF
| PM MEAS: ARFCN=3, 43 dBm at baseband, -94 dBm at RF
| PM MEAS: ARFCN=4, 32 dBm at baseband, -105 dBm at RF
| ../..
| PM MEAS: ARFCN=1023, 33 dBm at baseband, -104 dBm at RF
| L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=104, flags=0x7)
| Starting FCCH RecognitionFB0 (1748:10): TOA=11712, Power=-106dBm, Angle=-22058Hz
| FB0 (1775:11): TOA=12528, Power= -65dBm, Angle=-3818Hz
| FB0 (1796:5): TOA= 5280, Power= -68dBm, Angle=-16117Hz
| FB0 (1799:1): TOA= 96, Power=-109dBm, Angle= 7082Hz
`----
,----
| % ./host/layer23/src/mobile/mobile
| ...
| Failed to connect to '/tmp/osmocom_sap'.
| Failed during sap_open(), no SIM reader
| <000e> sim.c:1206 init SIM client
| <0005> gsm48_cc.c:61 init Call Control
| <0001> gsm48_rr.c:5330 init Radio Ressource process
| <0004> gsm48_mm.c:1220 init Mobility Management process
| <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM.
| <0002> gsm322.c:3466 init PLMN process
| <0003> gsm322.c:3467 init Cell Selection process
| <0003> gsm322.c:3521 No stored BA list
| VTY available on port 4247.
| Mobile initialized, please start phone now!
| <0002> gsm322.c:3093 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN selection in state 'A0 null'
| <000d> gsm322.c:1055 SIM is removed
| <0002> gsm322.c:1056 SIM is removed
| <0002> gsm322.c:511 new state 'A0 null' -> 'A6 no SIM inserted'
| <0003> gsm322.c:3313 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in state 'C0 null'
| <0003> gsm322.c:2986 Switch on without SIM.
| <0003> gsm322.c:540 new state 'C0 null' -> 'C6 any cell selection'
| <0003> gsm322.c:2404 Getting PM for frequency 0 twice. Overwriting the first! Please fix prim_pm.c
| <0003> gsm322.c:2415 Found signal (frequency 3 rxlev -94 (16))
| <0003> gsm322.c:2415 Found signal (frequency 8 rxlev -86 (24))
| <0003> gsm322.c:2415 Found signal (frequency 16 rxlev -93 (17))
| ...
| <0003> gsm322.c:2415 Found signal (frequency 819 rxlev -97 (13))
| <0003> gsm322.c:2404 Getting PM for frequency 955 twice. Overwriting the first! Please fix prim_pm.c
| <0003> gsm322.c:2415 Found signal (frequency 982 rxlev -98 (12))
| ...
| <0003> gsm322.c:2415 Found signal (frequency 1004 rxlev -91 (19))
| <0003> gsm322.c:2415 Found signal (frequency 1007 rxlev -89 (21))
| <0003> gsm322.c:2415 Found signal (frequency 1009 rxlev -97 (13))
| <0003> gsm322.c:2415 Found signal (frequency 1010 rxlev -86 (24))
| <0003> gsm322.c:2415 Found signal (frequency 1011 rxlev -67 (43))
| <0003> gsm322.c:2415 Found signal (frequency 1012 rxlev -86 (24))
| <0003> gsm322.c:2415 Found signal (frequency 1013 rxlev -80 (30))
| <0003> gsm322.c:2415 Found signal (frequency 1014 rxlev -87 (23))
| <0003> gsm322.c:2415 Found signal (frequency 1021 rxlev -82 (28))
| <0003> gsm322.c:2415 Found signal (frequency 1022 rxlev -98 (12))
| <0003> gsm322.c:2348 Found 97 frequencies.
| <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE)
`----
Hi mates,
i was thinking to start to work also on Sciphone and starting to learn as much as i can and contribute to the community (even if actually i'm a noob of phone firmwares, i worked only on MIPS router firmwares ).
Have you some usefull books/wiki/etc to start on?
These are the 3 versions identified of Sciphone:
HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM
HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM
TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM
How i could ask to sellers for the best version? (TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM)
Do you know an european shop where i can find it?
Thankyou for attention folks
Regards
Luca
Hello Ton,
On Sun, 28 Nov 2010 23:09:59 +0100, "Ton Slewe" <ton.slewe(a)gmail.com> wrote:
>
> I have tracked down the error to sim.c. I tried to push it to the GIT
> repository which does not seem to work (credentials?). Maybe somebody
> can patch it in their version and then push it. Or otherwise please
> point me in the direction to get it fixed in the repository.
You have take the version from Sylvain's testing branch (Sylvain, please
correct me if the extended SIM driver is no longer there) ?
I ask because there is already a fixed version with several improvments
which is supposed to work in this branch (at least for those SIM task
required to access a real network).
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I have trying the osmocom apps today (firmware). One of the apps,
simtest, did not seem to work well.
I have tracked down the error to sim.c. I tried to push it to the GIT
repository which does not seem to work (credentials?). Maybe somebody
can patch it in their version and then push it. Or otherwise please
point me in the direction to get it fixed in the repository.
Some of the variables on top of the file are not declared as volatile
(they should be because they are modified in an Interrupt Service
Routine). I changed all the variables on top of the file into volatile:
static volatile int sim_rx_character_count = 0; /* How many bytes have
been received by calypso_sim_receive() */
static volatile int sim_tx_character_count = 0; /* How many bytes have
been transmitted by calypso_sim_transmit() */
static volatile int sim_tx_character_length = 0; /* How many bytes have
to be transmitted by calypso_sim_transmit() */
static volatile uint8_t *rx_buffer = 0; /* RX-Buffer that is issued by
calypso_sim_receive() */
static volatile uint8_t *tx_buffer = 0; /* TX-Buffer that is issued by
calypso_sim_transmit() */
Now simtest is working as expected.
Kind regards,
Ton
Hi,
This patch series adds layer23 support for receiving SMSCB messages.
Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and
sending them up to L3. Patch 3/3 is an addition to cell_log for logging
cell-info-display-type SMSCB messages, if available.
This series requires patches[1][2][3] to libosmocore protocol headers.
Cheers,
Alex
[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000827.html
[2] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000830.html
[3] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000831.html
Alex Badea (3):
layer23: introduce SMSCB framework
layer23 smscb: reassemble blocks and pass them up to L3
layer23 cell_log: log CBCH cell info
src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 +
src/host/layer23/include/osmocom/bb/common/smscb.h | 28 +++
src/host/layer23/src/common/Makefile.am | 2 +-
src/host/layer23/src/common/lapdm.c | 7 +
src/host/layer23/src/common/smscb.c | 211 ++++++++++++++++++++
src/host/layer23/src/misc/cell_log.c | 107 ++++++++++-
6 files changed, 354 insertions(+), 3 deletions(-)
create mode 100644 src/host/layer23/include/osmocom/bb/common/smscb.h
create mode 100644 src/host/layer23/src/common/smscb.c
This is particularly useful if a layer23 app exists uncleanly; the next
app would not be able to synchronize at all.
Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com>
---
More to the point, I'd get stuck on the CBCH ;) I'm not sure if this
would negatively impact other FULL reset use-cases, hence the RFC.
Thanks,
Alex
src/target/firmware/layer1/l23_api.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c
index 19838f1..82b86d7 100644
--- a/src/target/firmware/layer1/l23_api.c
+++ b/src/target/firmware/layer1/l23_api.c
@@ -381,6 +381,7 @@ static void l1ctl_rx_reset_req(struct msgb *msg)
switch (reset_req->type) {
case L1CTL_RES_T_FULL:
printf("L1CTL_RESET_REQ: FULL!\n");
+ l1s.dedicated.type = GSM_DCHAN_NONE;
l1s_reset();
l1s_reset_hw();
audio_set_enabled(0);
--
1.7.0.4
Hello, everyone.
I've just stumbled on the post in maillists following a news tip on one
of the linux forums.
I myself have two MTK-based devices - E1000 (MTK6335) and Nokla TV E71
(MTK6225) and have done some research some time ago.
However, from what I heard there was no MMU there (even on 35), so I
didn't study the possibility to start linux there.
To make the story short, I'm now trying to run all the good stuff on my
phone and cannot get past the loader.
While now I cannot get past the osmocon part and upload ramloader:
When I hook up my phone I get
---cut---
~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~
**===================================================**
Main=0x3, Tmp=0x0, Fota=0x0, Bak=0x0
Number of image segments = 4
..[0] Image size = 352Bytes, start addr. =0x428
..[1] Image size = 4516152Bytes, start addr. =0x0
..[2] Image size = 12494144Bytes, start addr. =0x452938
..[3] Image size = 10340676Bytes, start addr. =-0xe000000
Start loading image...
....................................................................NFB
image index: 1...
Bye bye bootloader, jump to=0x0
---cut---
And this comes out at 115200 baud.
Trying osmocon:
osmocon looks like it sends the beacon - but nothing happens - the phone
just turns on. (I do hold the power button, but that just doesn't help)
I altered the sources and changed initial baudrate to 115200, but nothing
still.
I have not yet figured out jtag pins out there, and I guess I will hook my
old atmega-based jtag scanner only if there would be not other way to make
serial method work.
I think I can be of some help, since I have the hardware and some
experience in kernel hacking.
But I guess I cannot be of any use in the gsm part since I just don't know
that stuff.
That's it,
And thanks for starting the porting process.
Hello guys:
In order to participate in OSMOCOM-BB project, I have buy the old
moto C118 and made the T191 cable by myself.
But when I run "make" in ****/src/osmocom-bb/src directory, the error info
is below:
alexander@Foundation:~/src/osmocom-bb/src$ make
cd shared/libosmocore/build-target && ../configure \
--host=arm-elf-linux --disable-vty --enable-panic-infloop \
--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 arm-elf-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for arm-elf-linux-gcc... arm-elf-gcc
checking whether the C compiler works... no
configure: error: in
`/home/alexander/src/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
After my investigating on this issue, I think I must build my own
arm-elf-linux-gcc, am I right?
I want to know how the experienced person handle this scenario? Please
answer my questions!
Thanks!
alexander Xu
Hi all,
I've been looking at receiving CBCH traffic (where I live, 226-01
broadcasts a geographical area name with each cell).
Patches 1/1 and 1/2 are small fixes for the layer23 system information
parser, for storing the required CBCH channel description and mobile
allocation info.
I'll also reply with WIP patches for a small CBCH sniffing l23 app, and
for decoding CBCH in Wireshark. The latter is a quick hack job, as it
only decodes the first block, and it's bodged onto the LAPDm dissector.
Also a question: what would be the best place to integrate CBCH
handling into osmocom-bb? I'm guessing host/layer23/src/common/lapdm.c
would handle block reassembly, then send CBS frames up the stack. Would
any existing messages fit the bill (RSL_MT_UNIT_DATA_IND?) or should we
add a new one?
Cheers,
Alex
Alex Badea (2):
layer23 sysinfo: store chan_nr when decoding CBCH Channel Description
layer23 sysinfo: fix parsing of CBCH Mobile Allocation
src/host/layer23/src/common/sysinfo.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Hi,
Because I'm also deceived by the rebelSIM, I was programming a sim
sniffer using an atmega, by detecting the clock freq. manualy. Until
Harald announced his SIMtrac.
His solution is way easier, and more reliable. This is why I've now done
a hw design for it.
I don't know if it's the right mailing list, but it seemed to be the best.
I'm not a electronic expert, I just follow datasheets and examples. I
used the openPCD schema to do this one.
There is :
- the AT91SAM7SXXX
- 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual
size, as on the rebelSIM
- 1 SC port (IN) to connect the SIM for the phone (I would use the ones
from rebelSIM)
- 1 SC port (OUT) to be able to use the signal using external HW
- the sam-ba port to be able to flash it
here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe
please tell me if there is something wrong, or needs some improvement. I
will design the PCB shortly.
thanks,
tsaitgaist
> As none of my projects is complete without wireshark integration,
> SIMtrace abuses the GSMTAP format to feed messages into wireshark. A
> simplistic wireshark dissector for the GSM TS 11.11 APDUs is included,
> and it is expected to become much more complete in the fuutre (USIM
support,
> parsing of file contents, etc.)
hi laforge,
cool project!
i think it can be usefull to debugging the sim client/reader of
osmocom-bb. as DATA_IND/DATA_REQ is already tapped at
layer23/src/common/l1ctl.c, it would be cool if SIM_IND/SIM_REQ will be
tapped for wireshark too.
regards,
andreas
Hi all!
After what has become much more time than originally anticipated, I'm happy
to announce the first developer version of Osmocom SIMtrace:
http://bb.osmocom.org/trac/wiki/SIMtrace (project page)
git://git.osmocom.org/simtrace.git (host software + wireshark)
git://git.gnumonks.org/openpcd.git (firmware)
You can use it to passively sniff the smart card interface between SIM and
phone. It consists of some firmware for an AT91SAM7S USB-attached
microcontroller, together with a host PC program that receives the APDUs
from USB.
As none of my projects is complete without wireshark integration,
SIMtrace abuses the GSMTAP format to feed messages into wireshark. A
simplistic wireshark dissector for the GSM TS 11.11 APDUs is included,
and it is expected to become much more complete in the fuutre (USIM support,
parsing of file contents, etc.)
What can you use it for?
* Determine what is really going on between phone and sim
* Debugging of SIM Application Toolkit (SAT) programs
Why is it better than existing hardware like Season or the RebelSIM Scanner?
* We do proper auto-bauding and support PPS, i.e. you can automatically
see all communication on any SIM card interface
* We support all clock rates / dividers as per the ISO 7816-3 spec
Future plans:
* In addition to passive tracing, implement SIM-card side interface
in the hardware and have SIM/USIM simulator as host PC software.
* Build custom board for it, with 1.8V SIM support
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,
Finally I have running Linux on Sciphone G2.
Code for U-Boot and Linux kernel can be found here:
http://git.osmocom.org/gitweb?p=uboot-mt623x.git;a=summaryhttp://git.osmocom.org/gitweb?p=linux-mt623x.git;a=summary
To run U-Boot in RAM you can use osmocon loader for MTK.
When U-Boot will start than you can load Linux kernel using serial
port (U-Boot commands: loadb or loady).
Default load address is set to 0x800000, so Linux kernel will be loaded there.
To start executing Linux kernel type in following command: bootm 0x800000
After this command Linux kernel will be relocated, uncompressed and executed.
After short time you should have working console in Linux.
For testing purposes I prepared binaries which you can load and check
that Linux works on your phone:
http://downloads.qi-hardware.com/people/marcin/g2_uboot.binhttp://downloads.qi-hardware.com/people/marcin/g2_uImage.bin
uImage binary has already ramfs image built in, so you don't need any
additional filesystem.
These binaries were also tested by Steve Markgraf and keytwo, so it
should work on most G2s.
Today I was also able to load files from MMC card in U-Boot, so
hopefully this functionality will be available very soon.
Next step will be running UBoot and Linux from NAND, to make
development more convenient.
Recently we discovered that Sciphone G2 phones are sold with different
memory configurations.
So far we identified 3 types of memories:
HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM
(http://hynix.com/datasheet/pdf/flash/HY27US(08_16)12(1_2)B%20Series(Rev0.5)…)
HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM
(http://hynix.com/datasheet/eng/nand/details/small_11_HY27US081G1M.jsp?menu1…)
TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM
(http://www.datasheetcatalog.com/datasheets_pdf/T/C/5/8/TC58NVG0S3AFT.shtml)
This has to be detected in osmocon loader and U-Boot. I write about it
so, you'll be aware of it.
When U-Boot starts it detects your memory configuration and shows you
how much NAND and RAM you have.
If it comes to status of work in progress, following drivers are under
development:
- NAND controller (U-Boot/Linux)
- SD/MMC controller (U-Boot/Linux)
- GPIO (Linux)
- LCD (U-Boot/Linux)
I saw that MT6140 (RF) is connected over I2C bus, so probably this
driver will be next on the list.
BR,
Marcin
Ok, first of all congratulation for this project...
Ok, I understood that it wouldn´t work as USRP.
But would it allow you to tune (or listen - sory don´t know the
tecnical term in english) an especific ARFCN and time slot ?
Hernani
> Hi Harald
>
> Thanks for clarifying this confusion. I bought a motorola C123 on ebay
> with RS232 data cable. When I arrive I'll try this fantastic software.
> Thank you very much for your work, this world needs more people like
> you
>
> On Sat, 6 Nov 2010 08:32:31 +0100, Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/baseband-devel>>
> wrote:
>>* Hi Oscar,
*>>*
*>*> On Sat, Nov 06, 2010 at 03:02:37AM +0100, Oscar Soriano Riera wrote:
*>>*
*>>*> Its posible use
*>>*> OsmocomBB on C123 for do task as a USRP ? or similar scanner ?
*>>*
*>*> No, I think you have some conceptual misunderstanding about radio
*>*> technology in general.
*>>*
*>*> In your subject you ask if OsmocomBB can work as USRP:
*>*> This is wrong, as OsmocomBB is a protocol stack and radio driver, and
*>*> the USRP
*>*> is hardware. How can some software work as hardware?
*>>*
*>*> In the body of your mail you ask if the C123 can act as USRP:
*>*> No. The USRP is a wide-band software defined radio, and the
*>*> Calypso/Iota/Rita
*>*> design implements a more traditional narrow-band zero-if transceiver
*>*> with a DSP
*>*> in the baseband.
*>>*
*>*> Nevertheless, you can use both hardware design to receive and
*>*> transmit GSM
*>*> signals. But this is very far from what you ask by "one device
*>*> working like
*>*> the other"
*
Hi all,
I've been trying to join the party with my OpenMoko GTA02,
and I found that a few tweaks were required.
Patch 1/4 was required to get the romloader to start, otherwise
osmocon would only receive an occasional '\x00' character instead
of the ident_cmd. It works perfectly with the beacon interval
reduced to 13 mS, but I've made it configurable just in case other
targets don't like it.
Patches 2/4 and 3/4 are bugfixes for the calypso uart code. The LCR
register ended up being clobbered, and this rendered the uart on my
board silent.
Finally, I'm using the GTA02 AP as the "host", communicating via
the internal ttySAC0 UART. Patch 4/4 allowed me to cross-compile
osmocon & friends on my x86 box with the AP ARM as the target.
Now I can run,
./osmocon -m romload -p /dev/ttySAC0 -i 13 -d tr firmware/layer1.highram.bin
while toggling power via,
echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on
and get:
OSMOCOM Layer 1 (revision osmocon_v0.0.0-696-ge801cee-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e4942219e4949b52
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
Cheers,
Alex
Alex Badea (4):
osmocon: make beacon interval configurable via cmdline
target uart: fix preservation of LCR
target uart: remove REG_OFFS() macro side-effect
toplevel Makefile: accept arguments for host ./configure calls
src/Makefile | 8 ++++----
src/host/osmocon/osmocon.c | 26 ++++++++++++++++----------
src/target/firmware/calypso/uart.c | 10 +++++-----
3 files changed, 25 insertions(+), 19 deletions(-)
Hi,
Harald Welte wrote:
> bluetooth or FM radio. The GSM RF transceiver is probably possible to
> reverse engineer from the test mode + 3wire protocol sniffing, but wifi e.g. is
> defnitely too complex to do a 100% reverse engineered driver for...
while looking through the component listing on Wolgang's wiki page I
recognized the MediaTek MT5921 WLan-chipset.
This should be the same (or at least similar) chip built into the german
Thalia/Bol/Buch.de Oyo ebook-reader (also released in France). The module is
called mt5921sta_spi.ko and claims to be released under the GPL but until now
no source release happened for any GPL component.
The module is also contained in the firmware of the Booq Avant released in
Spain (http://www.booqreaders.com/en/product_Avant) and possibly many more
ebook-readers as these models seem to share their basic design.
Heiko
Hello All,
I have a question regarding GSMTAP , If it is used for sending messages to
wireshark only or it has some other significant,
like communication between
L2 and L3 or communication with layer1, as the
uint8_t and uint16_t were widely used in source code
Kind regards,
Hello List,
Ii'm facing problem when i'l trying to run ./mobil application i'm getting below error.
if i need some USB or serial SIM reader, or should insert the sim in my MS itself thanks in advance for help.
=========
Failed to connect to '/tmp/osmocom_sap'. <<<<<<<<<
Failed during sap_open(), no SIM reader
<000e> sim.c:1206 init SIM client
<0005> gsm48_cc.c:61 init Call Control
<0001> gsm48_rr.c:4944 init Radio Ressource process
<0004> gsm48_mm.c:1220 init Mobility Management process
<0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:3471 init PLMN process
<0003> gsm322.c:3472 init Cell Selection process
<0003> gsm322.c:3526 No stored BA list
Failed to parse the config file: '/etc/osmocom/osmocom.cfg'
Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg' <<<<<<<<
What Is the solution for this how i can do this
==========
Regards,
Dev
Hi everyone from Spain
I have one question:
Its posible use
OsmocomBB on C123 for do task as a USRP ? or similar scanner ?
Thanks
for your BIG work ¡¡¡¡ congratulations
Hi All,
I now have a V171 phone and cable so I thought I might get started with
this.
I checked out the code and started make. Osmocon built with no problem, but
I got this error next:
cd shared/libosmocore/build-target && ../configure \
--host=arm-elf-linux --disable-vty
--enable-panic-infloop \
--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... /bin/install -c
checking whether build environment is sane... yes
checking for arm-elf-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for arm-elf-linux-gcc... arm-elf-gcc
checking whether the C compiler works... no
configure: error: in
`/mnt/site/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
Checking config.log I can see it chokes here:
/usr/bin/arm-elf-ld: this linker was not configured to use sysroots
collect2: ld returned 1 exit status
I am running Arch Linux and have the packages cross-arm-elf-binutils
and cross-arm-elf-gcc-base installed. Does anyone have any suggestions to
fix this?
Thanks!
:D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I)
--- On Thu, 10/21/10, Holger Hans Peter Freyther <holger(a)freyther.de> wrote:
From: Holger Hans Peter Freyther <holger(a)freyther.de>
Subject: Re: osmocom on windows
To: baseband-devel(a)lists.osmocom.org
Date: Thursday, October 21, 2010, 8:09 PM
On 10/21/2010 07:00 PM, eisencah eisenach wrote:
> Here's another one. Regarding the select mechanism (the one in select.c).
> Other then the serial port and sockets is anything else registered there?
> Cause I
would like to keep sockets for communication after all (but the select
> function will not work on windows for serial ports handles). So I would use a
> different mechanism only for serial port scheduling.
> Cheers,
> Mihai.
well.. we handle the timers with it too.
