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(-)
