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.
Hi!
A number of people want to do some long-term evaluation of their cellular
environment and would be interested in an 'app' for OsmocomBB that continuously
scans the spectrum and dumps the cell parameters such as
* ARFCN, Signal Level, SNR
* frequency synch offset
* SCH info (BCC/NCC)
* SI (at least 1-4) from BCCH
I would love to do it, but I simply don't have the time. I thought maybe
somebody on this list is looking for a relatively simple task and has some
time. I think this is a great project to work with OsmocomBB without having
to go into the details.
The algorithm would look something like
STATE 1: Power Scan
* do power measurement over all supported bands
* pick strongest N carriers and iterate over them
STATE 2: FCCH/SCH acquisition
* try to get lock on the carrier
* if not, go back to next carrier from power scan
* if yes, continue with STATE 3
STATE 3: Wait until all relevant SI have been received
* generate GSMTAP output for the SI messages (or timeout)
* go back to STATE 2 for next strongest ARFCN
* after last ARFCN, re-start from STATE 1
This is basically the initial step of the GSM 03.22 cell (re)selection
that we already have as part of the 'mobile' program.
So all the code is there, but what's needed is a separate rady-made app,
not requiring any user interaction. It should also include some e.g. shell
script that automatically generates a new pcap file every N minutes/hours,
and make sure to never overwrite any existing PCAP file.
In the end, having this running for an extended period of time should simply
produce a large number of PCAP files without any manual interaction. Lock-ups
in any state should be detected by timers, singalling a proper L1_RESET
to make sure it continues. Unplugging / re-plugging the phone should also
not require any re-start of the program.
Optional extensions:
* software to aggregate info from the pcap files (remove duplicate
entries, e.g.)
* optional logging of GPS coordinates from a GPS receiver
If anyone has some time to give this some work, I'd most appreciate it. Please
inform the mailing list to ensure no duplicate work is created.
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,
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,
Since a lot of people are asking the same questions and there seems to
be a rush on the C123 on ebay I tought some clarification is needed.
Short version:
- The exact tools I used on stage are _not_ and will _not_ be
released (or sold ... several people asked ...)
- Any one willing to re-code them without any apriori knowledge of
GSM would most likely need months to read/understand both the
specifications and the way the code works. (That's thousands of page
of GSM spec and thousands of line of code)
- Osmocom-BB project is not designed to be a sniffer, it's a baseband
implementation, I just used part of it as a base.
So basically, unless you are really interested in GSM and are willing
to dedicate time to understand it deeply and to contribute the various
projects, there is not much point in you buying phones, or hanging out
in the ml/irc or whatever ...
For those who are still reading and interested here's a little more detail:
* The HLR query step:
-> Go watch the awesome 25C3 talk about it
* The TMSI recovering step
- Won't be published
- If you know how paging works, you know what to do anyway and it's
trivial. Method is in the talk,
there is nothing to it.
* The targeted sniffing application
- Won't be published either
- Some improvements to the layer23 app frame work will be done but
these are generic framework stuff, not app-specific
- Again, if you know how L2 works and have looked at several traces,
it's obvious what to do.
- The 'DSP' part of the sniffer is public for a while with a small
demo app (single phone and doesn't exploit the full potential of the
DSP patch) and it's perfectly sufficient to debug things on your o
wn controlled network. (This is basically what I showed at Deepsec 2010).
* The tool to generate the input to Kraken
- Won't be published either
- Making the guesses is easy for anyone that knows what he's doing.
* The improved Kraken
- No idea about it, see with Karsten / Sacha / Frank, I only got
access to it 1 hour or so before the talk :)
* Conversion from burst to audio
- This was a hacked software mostly with airprobe code.
- The exact app will not be released but I'd like to see the
capability put in some clean library we
can re-use from airprobe and other application without having to
multiply the code each time.
- ... But since I'd like it to support AMR and viterbi softoutput
before that happens, it could take
some time.
- Anyone familiar with GSM, airprobe and C could re-hack the same
thing in an hour ...
As you can see, everything you need to analyze your own network / your
own traffic, even at the burst level is already published and has been
for more than a month.
The other tools have been written only so that we could demonstrate
that what we _say_ is possible for about year, we can now do it
_practically_. It's apparently needed to get people attentions,
"theoretical" attacks are not enough to get the operators / gsma to
react. We'll see if that did it ...
A few advices that are always good:
- Make sure to checkout the a5/1 project ML and airprobe project ML and try
to ask your questions in the proper mailing list as much as possible.
- Check the wiki and mailing list archives toroughly before asking questions.
Cheers,
Sylvain Munaut
PS: I only posted on this list because it seems a lot of people were
pointed here while in fact airprobe would probably be more appropriate
to discuss attack scenarios and such, so make sure to answer / start
new discussion on the right list.
Hi guys,
i just looked at 27c3 talk on
http://27c3.iphoneblog.de/recordings/3952.html (i really wanted to be
there!) and heard about the concept of being able to fake gsm based
position systems.
Which could in theory the distance that could be faked respect to the
knowledge that the BTS can acquire?
I mean, the modified timing information provided by phone running
osmocombb, how many meters distance from BTS could be?
-naif
Hello all.
Just back from the hospital, so I haven't followed the development much
for some time.
Anyway, I've recently stumbled upon an interesting device:
https://www.dealextreme.com/details.dx/sku.50391
I think I'll order that one sometime soon, so that I can look at it in
more detail.
This is a chinese phone with android, but some things make me think that's
MTK inside.
According to desctiption:
ARM926EJ-S rev 5(v5l) BogoMIPS: 207.66
Android 2.2.1 OS system/Wifi(802.11b)/TV/GPS/FM/JAVA
Price - 130 bucks.
Sounds familiar?
Compared to my E1000:
ARM926EJ-S rev 5 (v5l) BogoMIPS: 104.24
Twice more Bogomips. The hardware pretty much seems like a typical MTK,
and for that price I guess there actually is MTK inside, something a
little
better than 2635, so the problem is to find the sources somewhere (And my
bet is, that if they don't make it to the mainline - they'll leak out to
the web) If the chips are pretty much identical, and they are, this might
be a good thing. I think I'll buy one after the holiday madness is over
and, hopefully, provide teardown photos, firmware dump and more details.
Regards,
Andrew.
> Just to avoid any duplicate of work as well: most of this is already
> done by cell_log (layer23/src/misc). It iterates over the whole
spectrum
> and tries to get an Immediate Assignment by sending a RACH to every
cell.
> It stores SI1-4, GPS position and the TA in a logfile, and using the
> gsmmap utility you can create a *.kml map of the calculated cell
> positions for Google Earth.
> So what's missing is really only the PCAP support and a command line
> switch to turn off the "active" scanning by sending no RACHs.
hi steve,
exactly. almost everything is already there. there are some things that
may need to be improved in my opinion:
- deactivating/activating the RACH request
- altering maximum distance (gps) moving off the position of last power
scan, before restarting scanning process.
- multiple radio support for faster scanning and deeper scanning while
moving.
- selecting between the generic text format and PCAP.
- option to wait some more time to receive more system informations than
the mandatory 1..4
regards,
andreas
When running the layer23/mobile host application in combination with layer1
firmware on a c115 (compal_e88 based) I can easily connect with a network
(when using Sylvain's test trunk, which supports the SIM very well!).
However, running the same code on the C155 (compal_e99 based) the phone
refuses to connect to the network and keeps scanning ARFCN's. Is there any
real difference between these phones except for the LCD's? In
rffe_dualband.c I see a remark about the value of SYSTEM_INHERENT_GAIN that
has been measured by Harald on the C123. May that be a different value for
the C155? Is this a problem observed by others, or is there a workaround?
I tried to load the dfu.bin+main.bin (=samba) onto the Olimex SAM7-P64
board. I connected jumper TEST for >10s, disconnected power, reconnected
power. I assume that it is possible now to upload firmware using sam-ba (i
tried both linux and windows) over the USB port. Even trying to connect
through the dbg serial port failed. Is there something wrong with the board
or in the procedure I follow. Should I see a USB-CDC serial port when the
SAM7 is running the SAM-BA bootloader? Any comments would be appreciated.
Hi all,
I have started a GettingStarted[1] page to cover the topics of getting the
code, getting an ARM toolchain and pointing to the osmocon and layer23 pages
for the details. I was also going through the search to update the names of
the firmware binaries.
The CalypsoRomloader[2] page deserves an update as well. It is referring to
the GTA0X but then tries to flash a nonexistent E88 binary. I am not sure what
to turn this page into.
Do we also have a list of Milestones we want to accomplish (besides merging
the sending code to master)? Do we have junior tasks for people that would
like to get started on target and host firmware?
regards
z.
[1] http://bb.osmocom.org/trac/wiki/GettingStarted
[2] http://bb.osmocom.org/trac/wiki/CalypsoRomloader
Hi,
I made a lot of changes to the SIMtrace hardware schema.
Here my v0.5 : https://gsm.tsaitgaist.info/SIMtrace/v0.5/SIMtrace.ps
Some important point that are unclear, where I would like to have some
comments :
- I do not use USB_DP_PUP which I found in several at91sam7s design (and
openPCD). I don't know if it will be useful or required.
- I use npn transistor as switches (2 for I/O because bidirectional).
Maybe (N/P/C)MOS is a better solution.
I already bought most of the parts and would like to start drawing the
PCB. Please tell me if you find some errors or have any advices.
kevin
I ordered a SAM7-P64 board for running Simtrace (received board today, but
still waiting for the REBELSIm connectors). When compiling the code (using
Gnuarm3.4.3) I got two errors:
1) the --g($DEBUGF) option was not understood; omitting this, made the
Makefile (for dfu and main) working
2) in /lib/vsprintf.c I had to add #include <limits.h> in order to prevent
errors related to MAX_INT etc.
Are there any ideas for making a man-in-the-middle SIM device? One master
interface to a real SIM, another slave interface providing a SIM interface
towards a phone with the possibility to filter certain APDU's or to add
files or commands on top of the real SIM. This would need an additional SIM
master interface (to send and receive APDU's to the real SIM) on top of what
already is in SIMtrace and the slave interface should be capable of sending
messaged back to the real SIM master. I will look into it, first starting
with implementing a simple SIM card master on the other UART.
hi,
i want to make a cable for the sciphone g2 that provides serial communication and charging with one connector.
unfortunately the pictures at [1] aren't clear enough for me. i don't want to kill my phone.
actually i count 15 pins in the picture, where mine has only 12.
that's weird. i guess that 2 are just for aligning the case, but that still makes 13 vs. 12.
i tried to ascii draw the connector from the back (soldering) side. the rounded half of the connector on the upper side.
The pins i found described elsewhere on the internet are already marked.
--------------------------
( )
( ) |
( ) |
+-------------------------+ |
| | | | | | | | /
| | | | | | | | /
+-------------------------+/
^ ^ ^ ^
| | | |
| | | +--- GND
| | +----- GND
| +----------- RX (PC -> Phone)
+--------------- TX (Phone -> PC)
could someone please mark the pins that have to be connected for charging ?
i guess one of the two GND pins is involved.
kind regards and
thanks for your time
-Alex
[1] http://en.qi-hardware.com/wiki/Sciphone_Dream_G2
Hello everybody
I want to develop USB Interface USRP Use MTK 6218 chip, But no Firmware Source Code
6218 is ARM Core 'USE it is a GSM Way of USRP .Friends if you Have to know Please contact me
Hello everybody,
last year I stumbled upon a PDF which describes all registers inside the
Qualcomm MSM7200 series chipset. I now got a new mobile phone and
remembered about that document because wanted to play a bit with my old
one (HTC Magic/Sapphire/G2/Ion).
I googled a few hours now and found several documents from Qualcomm, but
I just found a whole svn repository full of Documentation [1].
Those Qualcomm chipsets are particularly interesting, because, due to
Android, there already is a Linux kernel for the ARM11 core available.
The missing part is a free implementation of the ARM9 baseband.
My next goal is, as soon as I managed to solder cables to the JTAG pins
covered in epoxy, to get own code running on the ARM9. I don't know how
hard this will get, because this chipset has several security features
like signature checking of code, fusebits for security configuration
etc., but I will give it a try.
JTAG definitely is still activated, because several people developed a
method to unbrick their phones in case they have a bad ARM11 bootloader.
And even if there is no chance to get own code running right away, I'm
pretty certain that there somewhere is a buffer overflow which is
exploitable. Either inside the baseband itself or in the serial console
command parser of the early bootloaders provided by the OEM (OEMSBL).
Time will tell. I hope I've got something to show you at the 27C3.
My problem is that I don't have enough experience and knowledge about
GSM yet to estimate if all this documentation is sufficient to implement
a real baseband software on this chipset. If it's not, I think it's
pointless to invest several days/nights of work to get own code running.
Maybe somebody of you can have a quick look over the repository and the
documents?
Thanks,
Andy
[1]: http://code.google.com/p/ptwcdma/source/browse/
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
Hi all,
this is just a general request to everyone with git commit access on
the OpenBSC / Osmocom repositories.
I would appreciate to restrict the use of 'git merge' to the absolute
minimum neccessarry, as it makes the commitlog and timeline much harder
to understand.
If you're working on some private branch on a particular feature, please
rebase that private branch on current master before pushing the changes.
Thanks!
--
- 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)
Dear Members,
I incidentally see your development of linux drivers for
MT6235/6140 chipset(the sciphone G2), and wanna share my 50 cents: The
year 2009 released AP+BB monolithic chip MT6156 from mediatek is an
ARM9 AP + ARM7 BB (the old MT6235 is ARM9 AP, MT6140 is ARM7 BB),
considering the timeline of mediatek processors, it should be
conjectured that MT6516 is a combination of these two chips. They
already have Windows mobile 6.5 drivers mature for MT6516, and they
have android drivers (not only driver but the whole system image),
which might be an important referenece for developing MT6235 linux
drivers. So I believe it's a good idea to ask MTK for its MT6516
linux driver and see what can be ported.
Best for all,
Duane
On Tue, Dec 07, 2010 at 08:16:06PM +0200, Alex Badea wrote:
> On 12/07/2010 06:36 PM, Hermann Gausterer wrote:
> >Small typo in the second Serial Number Octet
> >
> >Signed-off-by: Hermann Gausterer<libosmocore-2010(a)mrq1.org>
>
> Good catch, thanks!
>
> You should send this patch to baseband-devel(a)lists.osmocom.org such
> that one of the maintainers can apply it.
>
> Thanks,
> Alex
Hi list,
Last days I was focused on getting self-built code running from NAND memory and finally I got it working.
You can find short demo which actually covers all the functionality which is currently working on Sciphone:
http://www.youtube.com/watch?v=w_Iwsckm7Ko
Here is the list of functionalities which are already working:
* NAND memory driver with HW ECC control and MTK's ECC layout (ECC layout is important for loading SPL, creating dumps of firmware and restoring it).
NAND driver also supports all the NAND memories found so far on Sciphone G2 (small page and large page).
* SD/MMC card support
* LCD driver (automatically detects LCD controller, so far identified two different LCD controllers mounted in G2: ILI9331 and ILI9325)
* tool for creating bootable image from given binary file (should work on all MT62xx chips).
It doesn't need to be SPL (from U-Boot), it can be self-built binary which will be run by IPL on the phone (not bigger than 64kB).
* automatic detection of RAM memory in SPL (two configurations checked) - this will be added by Steve to osmocon loader as well
* BBT and ENV can be saved in NAND (BBT in NAND is disabled by default, as deletes last two NAND blocks, and most people are running from RAM)
I also updated wiki with informations about new features added:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
Open issues:
* LCD controller is using the same data lines as NFI (NAND) controller. Currently it's not possible to use NAND when LCD is enabled.
* vibrator in SPL code - vibrator will be turned on in SPL when it'll start reading NAND and turned off when it'll finish,
thanks to that user will know that SPL code has started (short code which doesn't change SPL size).
* boot process from NAND has been tested only on small page NAND device - I'll create dump of my second phone
and try this process on large page NAND device as well
I recommend to create full NAND dump before playing with new software.
There is already driver for NAND running and you can erase/write NAND easily by mistake.
I turned on define CONFIG_ENV_IS_IN_NAND, which will not erase/write NAND at start, but when you execute "saveenv" command it'll do so.
Please, make NAND dump first.
The problem with NAND dump is that I haven't found built-in functionality in U-Boot that sends dump of RAM memory (where NAND will be read) to PC/SD card.
Dump also has to be created in chunks, as there is less RAM memory than NAND. I'm planning to create dump/restore commands which will save/restore dumps using SD card, but I didn't start it yet.
Currently the easiest way is to create dump in FlashTool.
I checked that restoring of phone using dump created in FlashTool works, so going back to previous firmware is possible.
Unfortunatelly code for LCD driver is not yet in git as my coleague didn't manage to finish it today. Hopefully it'll be available during weekend or beginning next week.
Now I'm going to switch to Linux kernel side and start writing drivers there...
Other good new is that Andrew has reported last week that he successfully run our code on E1000 chinese phone which is also based on MT6235.
There was no need to make any changes.
Here is how E1000 phone looks like:
http://triray.en.made-in-china.com/product/kbYJeomynHhs/China-N97-WiFi-Java…
BR,
Marcin
Hello all,
I'm going to be giving a presentation about free software GSM
implementations at the FSFE's Berlin meeting on December 9th, 2010. It
will be very elementary and newcomer-friendly. I'm planning to go
over OsmocomBB, OpenBTS and OpenBSC, and discuss their security and
practical implications.
The talk will start at 19:30 in Newthinking Store Tucholskystr. 48,
10117 Berlin. You can find more about it on
http://aligunduz.org/blog/free_gsm_talk_next_week.html
Considering I'm not an expert on GSM myself, it would be nice to have
people more familiar with it in attendance.
Ali Gündüz