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
The SIM and the SIM reader in the phone and the mechanical contact
between them are definitely working because the SIM can be accessed from
the motorola firmware, from another phone and from a PC smartcard reader
with no PIN or anything.
However, under simtest firmware no data is received by the phone, even
the ATR is zero bytes...
Anybody had this problem?
Also, is l1CTL SIM APDU command not implemented in the layer1 firmware?
How are people making calls without a SIM? :P
Gianni
----------------SIMTEST----8<-----------------
Initializing driver:
SIM: Registering interrupt handler for simcard-interface
====================== CALYPSO SIM REGISTER DUMP =====================
Reg_sim_cmd register (R/W) - FFFE:0000
|-REG_SIM_CMD = 0000
| |-REG_SIM_CMD_CMDCARDRST = 0 ==> SIM card reset sequence disabled.
| |-REG_SIM_CMD_CMDIFRST = 0
| |-REG_SIM_CMD_CMDSTOP = 0
| |-REG_SIM_CMD_CMDSTART = 0
| |-REG_SIM_CMD_MODULE_CLK_EN = 0 ==> Clock of the module disabled.
|-REG_SIM_STAT = 000b
| |-REG_SIM_STAT_STATNOCARD = 1 ==> No card!
| |-REG_SIM_STAT_STATTXPAR = 1 ==> Parity ok!
| |-REG_SIM_STAT_STATFIFOFULL = 0
| |-REG_SIM_STAT_STATFIFOEMPTY = 1 ==> Fifo empty!
|-REG_SIM_CONF1 = 000c
| |-REG_SIM_CONF1_CONFCHKPAR = 0 ==> Parity check on reception disabled.
| |-REG_SIM_CONF1_CONFCODCONV = 0 ==> Coding convention is direct (normal).
| |-REG_SIM_CONF1_CONFTXRX = 1 ==> SIO line direction is in transmit mode.
| |-REG_SIM_CONF1_CONFSCLKEN = 1 ==> SIM clock in normal mode.
| |-REG_SIM_CONF1_reserved = 0 ==> ETU period is CONFETUPERIOD.
| |-REG_SIM_CONF1_CONFSCLKDIV = 0 ==> SIM clock frequency is 13/4 Mhz.
| |-REG_SIM_CONF1_CONFSCLKLEV = 0 ==> SIM clock idle level is low.
| |-REG_SIM_CONF1_CONFETUPERIOD = 0 ==> ETU period is 372/8*1/Fsclk.
| |-REG_SIM_CONF1_CONFBYPASS = 0 ==> Hardware timers and start and stop sequences are normal.
| |-REG_SIM_CONF1_CONFSVCCLEV = 0 ==> SVCC Level is low (Only valid when CONFBYPASS = 1).
| |-REG_SIM_CONF1_CONFSRSTLEV = 0 ==> SRST Level is low (Only valid when CONFBYPASS = 1).
| |-REG_SIM_CONF1_CONFTRIG = 0x0 (FIFO trigger level)
| |-REG_SIM_CONF1_CONFSIOLOW = 0
|-REG_SIM_CONF2 = 0940
| |-REG_SIM_CONF2_CONFTFSIM = 0x0 (time delay for filtering of SIM_CD)
| |-REG_SIM_CONF2_CONFTDSIM = 0x4 (time delay for contact activation/deactivation)
| |-REG_SIM_CONF2_CONFWAITI = 0x9 (CONFWAITI overflow wait time between two received chars)
|-REG_SIM_IT = 0000
| |-REG_SIM_IT_SIM_NATR = 0 ==> On read access to REG_SIM_IT.
| |-REG_SIM_IT_SIM_WT = 0 ==> On read access to REG_SIM_IT.
| |-REG_SIM_IT_SIM_OV = 0 ==> On read access to REG_SIM_IT.
| |-REG_SIM_IT_SIM_TX = 0 ==> On write access to REG_SIM_DTX or on switching
| | from transmit to receive mode (CONFTXRX bit)
| |-REG_SIM_IT_SIM_RX = 0 ==> On read access to REG_SIM_DRX.
|-REG_SIM_DRX = 0100
| |-REG_SIM_DRX_SIM_DRX = 0x0 (next data byte in FIFO available for reading)
| |-REG_SIM_DRX_STATRXPAR = 1 ==> Parity Ok.
|-REG_SIM_DTX = 00 (next data byte to be transmitted)
|-REG_SIM_MASKIT = 003f
| |-REG_SIM_MASKIT_MASK_SIM_NATR = 1 ==> No-answer-to-reset interrupt is masked.
| |-REG_SIM_MASKIT_MASK_SIM_WT = 1 ==> Character wait-time overflow interrupt is masked.
| |-REG_SIM_MASKIT_MASK_SIM_OV = 1 ==> Receive overflow interrupt is masked.
| |-REG_SIM_MASKIT_MASK_SIM_TX = 1 ==> Waiting characters to be transmit interrupt is masked.
| |-REG_SIM_MASKIT_MASK_SIM_RX = 1 ==> Waiting characters to be read interrupt is masked.
| |-REG_SIM_MASKIT_MASK_SIM_CD = 1 ==> SIM card insertion/extraction interrupt is masked.
|-REG_SIM_IT_CD = fffe0010
|-REG_SIM_IT_CD_IT_CD = 0 ==> SIM card insertion/extraction interrupt is unmasked.
Power up simcard:
* Power enabled!
* Clock enabled!
* Reset released!
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Character underflow!
(0 bytes)
Reset simcard:
* Reset pulled down!
* Reset released!
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Character underflow!
(0 bytes)
SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02)
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34)
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Character underflow!
SIM-T0: T0 Protocol error: Missing ACK byte -- aborting!
SIM-T0: Transceiving APDU-Header: (a0 c0 00 00 0f)
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-T0: Case 4: Input / No output (See also GSM 11.11 Page 34)
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Character underflow!
SIM-T0: T0 Protocol error: Incorrect or missing answer -- aborting!
e0 73 d7 b9 ae ea bf 7e f7 3b 7f 6f 32 fe 25 (15 bytes)
Test Phase 1: Testing bare sim commands...
* Testing SELECT: Selecting MF
SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02)
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-T0: Case 2: No input / Output of known length (See also GSM 11.11 Page 34)
SIM-ISR: Interrupt caught: Waiting characters to be read...
SIM-ISR: Interrupt caught: Character underflow!
SIM-T0: T0 Protocol error: Missing ACK byte -- aborting!
==> Status word: ffff
* Testing SELECT: Selecting DF_GSM
SIM-T0: Transceiving APDU-Header: (a0 a4 00 00 02)
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
SIM-ISR: Interrupt caught: Waiting for character to transmit...
At this point it hangs "forever" - well at least half hour.
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 Bogdan,
> I've used all types of phones and different networks - same result. If I capture the uplink then every time after a
> few seconds I get "segmentation fault". My guess is that in a controlled environment it's going to work, but with a live one, where you have a
> lot of arfcn (on a quick scan I get about 50 on my location) it's unlikely to work.
well, the success could depends from many things:
- wich cable are you using: FTDI or CP2102;
- which phone you have tried: sometimes the jack on C1xx could be not so clean or used and it could create problems of communication at high baudrates.
- the environment that you are using: public network, as i saw from my tests, is quite horrible to make tests (eg. arfcn hopping).
Using a DP-L10 and modifying the AFC value, seems to work well on public netwroks, even if, sometimes it get stuck: problem related with channel hopping/sync IIRC.
I used a Blackberry Test Field to disable EDGE and identify which ARFCN that doesn't hop on GPRS: ( eg. this one is hopping, others may not [1] )
Obviously a private and controlled environment could give you the full percentage of success.
Regards,
Luca
[1] http://tinyurl.com/gprs-hopping
Hi Luca,
I've noticed the change and manual patched everything, but for me seems that it's not going to work. If I capture the downlink, sometimes it capture some bursts, other times not, but even so there is nothing to decode - the arfcn is correct. I've used all types of phones and different networks - same result. If I capture the uplink then every time after a few seconds I get "segmentation fault". My guess is that in a controlled environment it's going to work, but with a live one, where you have a lot of arfcn (on a quick scan I get about 50 on my location) it's unlikely to work.
Bogdan
________________________________
From: "baseband-devel-request(a)lists.osmocom.org" <baseband-devel-request(a)lists.osmocom.org>
To: baseband-devel(a)lists.osmocom.org
Sent: Friday, September 30, 2011 1:00 PM
Subject: baseband-devel Digest, Vol 20, Issue 26
----- Forwarded Message -----
Send baseband-devel mailing list submissions to
baseband-devel(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/baseband-devel
or, via email, send a message with subject or body 'help' to
baseband-devel-request(a)lists.osmocom.org
You can reach the person managing the list at
baseband-devel-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of baseband-devel digest..."
Today's Topics:
1. Layer23 missing (Bogdan Alecu)
Hello,
I'm trying to use the gprsdecode but when I try to patch it there is no layer3.c and also it can't find "
d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5" in the tree. Can someone explain a little bit the new steps?
Regards,
Bogdan
_______________________________________________
baseband-devel mailing list
baseband-devel(a)lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/baseband-devel
Hello,
I'm trying to use the gprsdecode but when I try to patch it there is no layer3.c and also it can't find "
d1cb8ea9b784c7acbafbb2fdcedbdf4655c2f6f5" in the tree. Can someone explain a little bit the new steps?
Regards,
Bogdan