29 Oct
2010
29 Oct
'10
8:14 a.m.
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
29 Oct
29 Oct
6:11 p.m.
Hi Marcin,
thanks for introducing yourself and your project.
On Fri, Oct 29, 2010 at 08:14:50AM +0200, Marcin Mielczarczyk wrote:
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).
sure.
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.
Have you tried to use the MT622x support in osmocon ? Steve Margraf
has added support for MT622x to it, you can see it from
http://git.osmocom.org/gitweb?p=osmocom-bb.git;a=commitdiff;h=dd95bcec33237…
If we assume the ROM loader of MTK has not changed between MT622x and MT623x,
it may actually work.
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.
Ok, I see. Could you provide that code? Do you know if the MTK secure
boot mode is used on the phone model you use? If yes, than indeed
it will need some cryptographic verified 2nd stage loader, Dieter has
done some investigation on this.
Then I decided to try find JTAG pins to get all
control on MT6235.
That took me sometime, but finally I succeeded.
This is great. So far, we have not seen any MT622x based phone that has
JTAG exposed. Even the Huayu development modules for the MT622x don't have
it.
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).
Using a scalpel to remove the shielding sometimes is easier than unsoldering.
Other people have reported success using a small dremel tool.
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.
Yes, typically for DRAM there is some kind of initialization sequence
that you run through, it's not just a static set of registers.
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.
this is great.
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.
Sure. Even today, we don't flash any of our OsmocomBB software to the
target phone yet. Loading code in ram and executing it is much more
convenient for development anyway.
I think if you can publish the pinout of the JTAG on the Sciphone G2,
this would be sufficient for other people to join the project. Many
people have a JTAGkey, Openmoko debug board or other OpenOCD compatible
JTAG adapter...
The second step would be to go back to the ROM loader again and try to get code
running through this again. In the end, we will need a development mode where
we can e.g. load u-boot via the ROM loader (serial) and then load the kernel +
rootfs from SD/MMC card. This should provide rapid development cycles.
You can see how my setup looks on attached picture.
Great :)
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 is the same, we should already have code for it (see above).
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.
Please send your SSHv2 public key to me in private e-mail and I will
give you an account on our git server for u-boot.
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.
great. I think SD/MMC support is almost equally important.
It is definitely interesting for us to follow your work if you simply
do your changes (even if it's not working yet, or unstable) in git.
If it comes to GSM I didn't work with it before.
That shouldn't matter - this is where our experience comes in. There are
a lot of unknown variables when it comes to the MT6235 and the corresponding
ABB and RF transceiver chips, but given that we've done similar work before
for the Calypso, and that we now have a vision where we can run Linux with a L1
inside the kernel and L2/L3 in userspace programs, there should be quite some
motivation to make it work.
Regards and thanks for all the good news,
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)
30 Oct
30 Oct
1:51 p.m.
Hi,
On Fri, Oct 29, 2010 at 6:11 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Have you tried to use the MT622x support in osmocon ? Steve Margraf
has added support for MT622x to it, you can see it from
http://git.osmocom.org/gitweb?p=osmocom-bb.git;a=commitdiff;h=dd95bcec33237…
If we assume the ROM loader of MTK has not changed between MT622x and MT623x,
it may actually work.
No I didn't do this, but of course I can try it.
Ok, I see. Could you provide that code? Do you know if the MTK secure
boot mode is used on the phone model you use? If yes, than indeed
it will need some cryptographic verified 2nd stage loader, Dieter has
done some investigation on this.
In this case, first I'll explain how it works.
Nomenclature:
1) internal bootloader - bootloader placed at 0x48000000 in System ROM
2) 2nd stage bootloader or extarnal bootloader - bootloader placed in
NAND - initializes DRAM controller and boots MTK's software - this
bootloader prints info on UART by default
When MT6235 processor starts it has RM1 bit disabled in EMI_GENA
register (External Memory Interface controller),
which forces ARM926 core to jump first to System ROM (0x48000000).
When internal bootloader is executed it initializes UART to 19200n8
and checks if specific character is received.
If no character will be received it continues "normal" boot, so
fetches code from NAND (checks bootloader header at 0x0 address, then
gets 2nd stage bootloader from NAND).
In this case there is no security at all. If we would like to boot
from NAND, it's just matter of placing proper bootloader header at
address 0x0 in NAND, and then placing U-Boot in proper addresses of
NAND (I saw that internal bootloader doesn't fetch code from continues
addresses, which means that code is scattered).
The prove there is no security is that I can execute my own code from
the very beginning. When I initialize CPU with JTAG it's hold at 0x0
address (first address executed) and then I just initialize PLL, DRAM
controller, load UBoot to external RAM and execute it. Everything
works perfect.
There is Secure Engine (SEJ) in MT6235 to protcect program in external
memory, but it doesn't look like it's used.
The other story is second path which can be taken in internal bootloader.
This path is taken when some character will be received by UART at the
beginning of internal bootloader startup. That's where FlashTool comes
in.
Flashtool communicates with internal bootloader and sends its own
chunk of code which is executed in SRAM. This code is called Download
Agent (DA) and it's linked against some security libraries. If you'll
try to download your own code (without these libraries) through
FlashTool it'll just fail.
You can find DA customization kit under following link:
http://en.pudn.com/downloads153/sourcecode/comm/mtk/detail675309_en.html
This is source code where you can build your own Download Agent. This
is how I first executed my own code on MT6235. It has all make files
and it's prepared for ADS compiler.
When you'll build your own Download Agent you just select this file in
FlashTool and you have your code executed in RAM.
I saw that you can use it on all MTK platforms.
FlashTool links are also available on pudn.com
I didn't analyze this path of bootloader, but it could be good to have
it if we would like to create our own flashing tool under Linux (i.e.
for flashing U-Boot).
This is great. So far, we have not seen any MT622x based phone that has
JTAG exposed. Even the Huayu development modules for the MT622x don't have
it.
It means that I was lucky ...
Using a scalpel to remove the shielding sometimes is easier than unsoldering.
Other people have reported success using a small dremel tool.
Exactly, I wanted to do this with dremel tool but keyboard is sticked
on that metal shield (it's visible on attached picture).
If I would remove it, then it would be not possible to assemble my
phone back. I had just one piece, so decided to make more elegant way.
Yes, typically for DRAM there is some kind of initialization sequence
that you run through, it's not just a static set of registers.
In this case there is register EMI_CONN which has to have single bits
enabled/disabled one by one for init sequence.
That was the missing point.
Sure. Even today, we don't flash any of our OsmocomBB software to the
target phone yet. Loading code in ram and executing it is much more
convenient for development anyway.
I agree, but now I have bootloader disassembled and I think it could
be possible to download UBoot permanently without risk.
We could use that to load our own code to RAM over MMC/SD/serial.
I think if you can publish the pinout of the JTAG on the Sciphone G2,
this would be sufficient for other people to join the project. Many
people have a JTAGkey, Openmoko debug board or other OpenOCD compatible
JTAG adapter...
Of course, no problem.
In attachment you can find pinout of JTAG for Sciphone G2.
The second step would be to go back to the ROM loader again and try to get code
running through this again. In the end, we will need a development mode where
we can e.g. load u-boot via the ROM loader (serial) and then load the kernel +
rootfs from SD/MMC card. This should provide rapid development cycles.
Yes, I agree.
In this case to download U-Boot to NAND we can use FlashTool (only for Windows).
Then as you stated we can use U-Boot to load code from SD/MMC/serial.
If it is the same, we should already have code for it (see above).
That's great!
It is definitely interesting for us to follow your work if you simply
do your changes (even if it's not working yet, or unstable) in git.
OK, no problem.
That shouldn't matter - this is where our experience comes in. There are
a lot of unknown variables when it comes to the MT6235 and the corresponding
ABB and RF transceiver chips, but given that we've done similar work before
for the Calypso, and that we now have a vision where we can run Linux with a L1
inside the kernel and L2/L3 in userspace programs, there should be quite some
motivation to make it work.
That's great.
BR,
Marcin
2:53 p.m.
Hi Marcin,
On 30.10.2010 13:51, Marcin Mielczarczyk wrote:
In this case, first I'll explain how it works.
Nomenclature:
1) internal bootloader - bootloader placed at 0x48000000 in System ROM
2) 2nd stage bootloader or extarnal bootloader - bootloader placed in
NAND - initializes DRAM controller and boots MTK's software - this
bootloader prints info on UART by default
When MT6235 processor starts it has RM1 bit disabled in EMI_GENA
register (External Memory Interface controller),
which forces ARM926 core to jump first to System ROM (0x48000000).
When internal bootloader is executed it initializes UART to 19200n8
and checks if specific character is received.
Alright, this is how it works on the MT622x as well.
This is source code where you can build your own
Download Agent. This
is how I first executed my own code on MT6235. It has all make files
and it's prepared for ADS compiler.
When you'll build your own Download Agent you just select this file in
FlashTool and you have your code executed in RAM.
I saw that you can use it on all MTK platforms.
FlashTool links are also available on pudn.com
I didn't analyze this path of bootloader, but it could be good to have
it if we would like to create our own flashing tool under Linux (i.e.
for flashing U-Boot).
That's pretty interesting, since it could be used to create
authentificated code for other phones with the secure romloader, too.
> This is great. So far, we have not seen any
MT622x based phone that has
> JTAG exposed. Even the Huayu development modules for the MT622x don't have
> it.
Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD
successfully detected the CPU, but I couldn't halt the ARM core (same
problem on the Calypso btw). I tried other random ARM7 targets which had
the same EmbeddedICE revision and there it worked.
Yes, I agree.
In this case to download U-Boot to NAND we can use FlashTool (only for Windows).
Then as you stated we can use U-Boot to load code from SD/MMC/serial.
Getting osmocon to work with the secure romloader could be an option as
well. Currently it only supports the non-secure romloader without that
*.auth and SLA_Challenge.dll stuff.
Plus we have a CFI-flash driver for the Compal phones, which might work
on the MTK platform with a few modifications. If that works, we could
flash U-Boot without any proprietary Flashtool/DownloadAgent.
Regards,
Steve
3:19 p.m.
Steve Markgraf wrote:
Did you check the config? I've seen bad reset signal settings in
tcl/target/*.cfg (trst/srst) which stopped me from getting proper
control over the core.
//Peter
> This is
great. So far, we have not seen any MT622x based phone
> that has JTAG exposed.
Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD
successfully detected the CPU, but I couldn't halt the ARM core
(same problem on the Calypso btw). I tried other random ARM7
targets which had the same EmbeddedICE revision and there it
worked.
4:13 p.m.
Hi Steve
On Sat, Oct 30, 2010 at 2:53 PM, Steve Markgraf <steve(a)steve-m.de> wrote:
Alright, this is how it works on the MT622x as well.
I thought so, as I already saw that bootloader checks hardware ID and
compares it with values 6228, 6226, 6223, etc.
That's pretty interesting, since it could be used to create authentificated
code for other phones with the secure romloader, too.
That's true, it should work.
Well, there is the CECT C3100 which has JTAG solder pads. OpenOCD
successfully detected the CPU, but I couldn't halt the ARM core (same
problem on the Calypso btw). I tried other random ARM7 targets which had the
same EmbeddedICE revision and there it worked.
I see that we were going through the same stuff.
I had the same problem with Sciphone G2. I could attach to core but I
couldn't halt it.
At the beginning I detected just four JTAG lines (TCK, TMS, TDI, TDO)
and could attach to CPU, but couldn't do more.
Then I discovered two more lines: RTCK and nTRST. When I connected
them, I still couldn't halt core, but it was just matter of
configuration.
When PLL is configured (CPU: 208/104MHz, AHBx4: 52MHz and AXBx8:
104MHz) 10MHz clock for JTAG should be used.
When PLL is not configured, then RTCK clock should be used.
I use Lauterbach for JTAG communication, but in openOCD should work as well.
Getting osmocon to work with the secure romloader could be an option as
well. Currently it only supports the non-secure romloader without that
*.auth and SLA_Challenge.dll stuff.
Plus we have a CFI-flash driver for the Compal phones, which might work on
the MTK platform with a few modifications. If that works, we could flash
U-Boot without any proprietary Flashtool/DownloadAgent.
Sounds good.
BR,
Marcin
4:25 p.m.
Hi Marcin,
did you ever find schematics of the Sciphone G2 anywhere online? It would
be great to understand which of the I/O lines are connected to which
peripherals, especially for the GSM part.
Also, do you know the RF transceiver chip used in the device? We already know
the MT6129 and MT6139 from the MT622x based phones, but it might be a different
one for the MT6235.
--
- 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)
5:01 p.m.
Hi Harald,
On Sat, Oct 30, 2010 at 4:25 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Marcin,
did you ever find schematics of the Sciphone G2 anywhere online? It would
be great to understand which of the I/O lines are connected to which
peripherals, especially for the GSM part.
No I haven't found schematics for Sciphone G2. That's the only thing
missing actually.
But I found MT6235 reference schematics and I don't think Sciphone
change to much.
Schematics are attached in this message.
Also, do you know the RF transceiver chip used in the
device? We already know
the MT6129 and MT6139 from the MT622x based phones, but it might be a different
one for the MT6235.
It's under plastic antenna, but it seems that I can unsolder it so I can check.
I checked on reference schematics and there is MT6140D.
BR,
Marcin
2 Nov
2 Nov
8:01 a.m.
Hi,
I unsoldered plastic antenna, but there is only WiFi.
Seems that RF transceiver is under metal shield.
I just received second piece of Sciphone and uploaded new pictures
with descriptions on Wiki:
http://bb.osmocom.org/trac/wiki/SciphoneDreamG2
Good thing is that I can fit my microSD card sniffer which will make
SD controller development easier.
First I'll try to identify GPIOs.
BR,
Marcin
Also, do you know the RF transceiver chip used in
the device? We already know
the MT6129 and MT6139 from the MT622x based phones, but it might be a different
one for the MT6235.
3 Nov
3 Nov
6:41 p.m.
Marcin,
I unsoldered plastic antenna, but there is only WiFi.
Seems that RF transceiver is under metal shield.
I just received second piece of Sciphone and uploaded new pictures
with descriptions on Wiki:
I very much enjoyed reading your Sciphone G2 news and it motivated me
to jump in and try to help :-)
So it turns out a good friend of mine is Vice President of the company
that made the Sciphone G2 - it's a small world after all.
I wrote up what I found so far
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2
The G2 was discontinued about a year ago, but over 200,000 were made so
we should be able to find some still.
He donated the absolute last 2 phones we could find in his office to the
OsmocomBB project, a normal black one as well as a prototype red one.
He also donated another 9 boards to OsmocomBB, I took this picture
http://en.qi-hardware.com/wiki/File:Nine_Sciphone_G2_boards.jpg
They are reworked/fixed, but _should_ work (note that 3 are without Wi-Fi).
Now my question:
For those 9 boards, what are the most important missing pieces so they
can become useful for the OsmocomBB project?
I guess a charger/USB cable would be nice (it's not a standard plug).
What else?
LCM? Maybe not so important?
How about antennas? speaker/buzzer?
If I just send these 9 boards to Harald the way they are on the picture,
is that useful? Or should I try to find some more parts? I'm most concerned
about the antenna, not sure whether this is easy to source/find.
Separately, I will try to take pictures of the individual PCB layers, using
a V3.1 PCB. I should have them by the end of the week.
I am also trying to get the schematics, maybe BOM or other helpful data,
but I'm not so sure on those, maybe they cannot find them anymore even if
they would like to give them to us. Don't hold your breadth on those.
Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB, PCBA pictures
uploaded, PCB layer pictures coming. Schematics maybe.
Wolfgang
7:22 p.m.
On Wed, Nov 3, 2010 at 6:41 PM, Wolfgang Spraul <wolfgang(a)sharism.cc> wrote:
Marcin,
I very much enjoyed reading your Sciphone G2 news and it motivated me
to jump in and try to help :-)
So it turns out a good friend of mine is Vice President of the company
that made the Sciphone G2 - it's a small world after all.
I wrote up what I found so far
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2
I'm realy suprised :) I didn't expect taht it'll go that far.
The G2 was discontinued about a year ago, but over
200,000 were made so
we should be able to find some still.
He donated the absolute last 2 phones we could find in his office to the
OsmocomBB project, a normal black one as well as a prototype red one.
He also donated another 9 boards to OsmocomBB, I took this picture
http://en.qi-hardware.com/wiki/File:Nine_Sciphone_G2_boards.jpg
That's great news!
They are reworked/fixed, but _should_ work (note that
3 are without Wi-Fi).
Now my question:
For those 9 boards, what are the most important missing pieces so they
can become useful for the OsmocomBB project?
I guess a charger/USB cable would be nice (it's not a standard plug).
What else?
LCM? Maybe not so important?
How about antennas? speaker/buzzer?
For sure these 9 boards will be useful for this project.
Besides running osmocomBB we have to run Linux with drivers for MTK
peripherals: GPIO, SD/MMC, NAND, I2C, SPI, UART, PWM, USB, LCD, etc.
Most of these peripherals are available on mentioned boards so they'll
be useful for drivers development.
If it comes to USB cable, it's not that important because L12C
connectors (which are in Sciphone G2) are pretty cheap and available
here:
http://www.ipmart.com/main/product/Cable,Compatible,for,China,Mobile,Phone,…
So even without USB cables, LCD, antennas, speakers, etc. boards will
be useful for some people.
If I just send these 9 boards to Harald the way they
are on the picture,
is that useful? Or should I try to find some more parts? I'm most concerned
about the antenna, not sure whether this is easy to source/find.
I already answered above.
Separately, I will try to take pictures of the
individual PCB layers, using
a V3.1 PCB. I should have them by the end of the week.
I am also trying to get the schematics, maybe BOM or other helpful data,
but I'm not so sure on those, maybe they cannot find them anymore even if
they would like to give them to us. Don't hold your breadth on those.
Wow, but I'm not holding my breath yet :)
Schematics would be realy useful ...
You can also ask about technical documentation for BT chip MT6601.
I couldn't find datasheet and it'll be needed to make BT working.
Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB,
PCBA pictures
uploaded, PCB layer pictures coming. Schematics maybe.
That's very good news!
I appreciate your help.
BR,
Marcin
10:24 p.m.
For sure these 9 boards will be useful for this
project.
Besides running osmocomBB we have to run Linux with drivers for MTK
peripherals: GPIO, SD/MMC, NAND, I2C, SPI, UART, PWM, USB, LCD, etc.
Count me in for this work. I have to admit I never got around to test my
Motorola-phones, but the vision to do a full Linux-port surely adds some
endorphine here :)
> Bottom line: 2 full G2 + 9 PCBA donated to
OsmocomBB, PCBA pictures
> uploaded, PCB layer pictures coming. Schematics maybe.
BTW while looking for a source for the G2 in Europe, I found this:
http://www.digizo.co.uk/products/G2-Sci-phone-Google-Android-Interface-Drea…
Dunno if the price is good, but they seem to have a few in stock at
least. (I was lucky though to find a used one in London during the two
days I was there :))
Regards,
Wolfram
10:51 p.m.
Hi,
On 03.11.2010 22:24, Wolfram Sang wrote:
BTW while looking for a source for the G2 in Europe, I
found this:
http://www.digizo.co.uk/products/G2-Sci-phone-Google-Android-Interface-Drea…
I ordered there yesterday, and the phone shipped today.
Dunno if the price is good, but they seem to have a
few in stock at
least. (I was lucky though to find a used one in London during the two
days I was there :))
The price is okay, a few other sellers from Hongkong charge ~90€ as
well. The benefit of having it shipped from the UK is no hassle with
customs, of course.
Regards,
Steve
9 Nov
9 Nov
5:57 a.m.
Marcin et al,
Wow, but I'm not holding my breath yet :)
Schematics would be realy useful ...
You can also ask about technical documentation for BT chip MT6601.
I couldn't find datasheet and it'll be needed to make BT working.
sorry it took a bit longer than I thought, but I was hard at work
and can report some good progress.
A package with 4 full G2 + 4 PCBA + some USB cables and batteries
is on the way to Harald with EMS. Let's hope it arrives soon and
without big customs problems.
Thanks to generous Bluelans support, I have more stuff here, another
6 full phones (4 with buggy touch panel, 2 should be OK), plus
another 4 or 5 PCB. I grinded down 2 PCBs to take pictures of the
layers, and I broke another full set to make an illustrated disassembly
guide. That set is probably still usable, although at least I ripped
off the touch panel cable, and broke the glass under the touch panel,
and maybe added some more damage as part of me making the disassembly
guide. Well, hopefully it helps others making a safer disassembly,
that was the point of it.
I kept adding things to my G2 wiki page
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2
What we have now is:
1) disassembly guide
2) PCB layers, also 1 large PDF with all layers so it should be easy
to flip pages and follow traces
3) G2 schematics PDF, thanks to Bluelans
4) bottom side (LCM side) component placement, thanks to Bluelans
That pretty much concludes what I planned to do. Maybe they can find
the top side component placement file as well, that would be nice. Not
sure though.
Also if the first package of phones arrives safely, I have more phones
and boards I can send people. I plan to give away everything I have.
One thing you could help me with is URLs to the datasheets, as many
as we can find, or have open URLs for.
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Key_Components
You mentioned you are looking for MT6601, I can start to ask around
a bit, also for the full 6235 SDK if we can find it somewhere.
But I don't even have links to the 6235 or 6140 datasheets right now...
Hope this helps, good luck for your work!
Wolfgang
6:14 a.m.
Hi Wolfgang,
On Tue, Nov 9, 2010 at 5:57 AM, Wolfgang Spraul <wolfgang(a)sharism.cc> wrote:
Marcin et al,
guide. Well, hopefully it helps others making a safer disassembly,
that was the point of it.
I kept adding things to my G2 wiki page
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2
Don't worry about broken touchpanel, this set will be still usable.
Thank you for documenting it!
What we have now is:
1) disassembly guide
2) PCB layers, also 1 large PDF with all layers so it should be easy
to flip pages and follow traces
3) G2 schematics PDF, thanks to Bluelans
4) bottom side (LCM side) component placement, thanks to Bluelans
That's a lot of hardware now ...
We have also schematics (which I see are almost the same as reference
schematic for MT6235 which I sent before) and PCB layers, that's
great!
That pretty much concludes what I planned to do. Maybe
they can find
the top side component placement file as well, that would be nice. Not
sure though.
Also if the first package of phones arrives safely, I have more phones
and boards I can send people. I plan to give away everything I have.
That's great, I appreciate it.
One thing you could help me with is URLs to the
datasheets, as many
as we can find, or have open URLs for.
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Key_Components
Best documents I found are on "www.pudn.com" There are a lot of
materials about MTK platform.
The problem is that you have to have account there.
Hope this helps, good luck for your work!
Thank you very much for your help.
BR,
Marcin
10 Nov
10 Nov
4:30 p.m.
Marcin,
a small update, for completeness...
We have also schematics (which I see are almost the
same as reference
schematic for MT6235 which I sent before) and PCB layers, that's
great!
Bluelans digged up and released the battery side component placement
PDF file as well, I updated
http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Schematics.2C_component_pl…
So we have component placement for both sides now, which should make
working with the phone a bit easier...
Cheers,
Wolfgang
9 Nov
9 Nov
8:24 a.m.
Hi Wolfgang,
thanks a lot for your support, including the teardown, PCB layer photographs,
schematics, etc.
I think this really is getting into shape now and we have a much better base
from where to work on actual software for MT6235 based phones.
My biggest concerns at the moment are that all of the peripheral data sheets
are electrical data sheets only and MTK never documents the register set of
e.g. the MT6140 (RF transceiver), MT6601 (bluetooth), MT6188 (fm radio),
wifi, etc.
This means a lot of unneccessary reverse engineering unless we can find an
alternative source for this kind of information. I'm less worried about
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...
But I don't even have links to the 6235 or 6140
datasheets right now...
The links I know only go to 52RD BBS and similar sites, where you cannot
download without an account. I have an account, but we don't want to put them
in the wiki publicly ;)
--
- 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)
10:10 a.m.
For my part I am totally impressed by the PCB layers images. How do you get
them? just grinding with fine sandpaper and a lot of patience, or do you
have a machine?
Sebastien
On Tue, Nov 9, 2010 at 8:24 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Wolfgang,
thanks a lot for your support, including the teardown, PCB layer
photographs,
schematics, etc.
I think this really is getting into shape now and we have a much better
base
from where to work on actual software for MT6235 based phones.
My biggest concerns at the moment are that all of the peripheral data
sheets
are electrical data sheets only and MTK never documents the register set of
e.g. the MT6140 (RF transceiver), MT6601 (bluetooth), MT6188 (fm radio),
wifi, etc.
This means a lot of unneccessary reverse engineering unless we can find an
alternative source for this kind of information. I'm less worried about
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...
But I don't even have links to the 6235 or
6140 datasheets right now...
The links I know only go to 52RD BBS and similar sites, where you cannot
download without an account. I have an account, but we don't want to put
them
in the wiki publicly ;)
--
- 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)
8 Jan
8 Jan
7:08 p.m.
jaki toolchain do arm-a używacie?
czy https://sourcery.mentor.com/sgpp/lite/arm/portal/release1592 ?
How toolchain for arm-and do you use?
or https://sourcery.mentor.com/sgpp/lite/arm/portal/release1592?
i have ubuntu 10.04
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp17…
Sent from the baseband-devel mailing list archive at Nabble.com.
3 Nov
3 Nov
10:47 p.m.
Wolfgang,
thanks a lot for your great help. It's really amazing.
As Marcin said, getting access to some more boards/units would be
useful, especially if they have JTAG access and even if some of them
might not be fully functional. Charger/USB cable are definitely
reqired, all the other parts are more or less optional.
Schematics would also most definitely be great. PCB pictures might be
useful as a replacement if no schematics are available.
Sad to hear that it is already end of life, but good to know that there might
be more MT6235 based designs that have JTAG exposed.
Cheers from Luzern/Switzerland,
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)
11:46 p.m.
Hi Wolfgang,
I'm really amazed by your commitment :)
On 03.11.2010 22:47, Harald Welte wrote:
Sad to hear that it is already end of life, but good
to know that there might
be more MT6235 based designs that have JTAG exposed.
By the way - many shops still sell the "Sciphone G2+", do you know the
difference compared to the G2? One thing I noticed is that the G2 seems
to be triple-band (there's a 850/1800/1900 and a 900/1800/1900 variant),
and the G2+ quad-band.
Can you confirm this?
Regards,
Steve
9 Nov
9 Nov
7:29 a.m.
Steve,
By the way - many shops still sell the "Sciphone
G2+", do you know
the difference compared to the G2? One thing I noticed is that the
G2 seems to be triple-band (there's a 850/1800/1900 and a
900/1800/1900 variant), and the G2+ quad-band.
Can you confirm this?
A positive confirmation for this kind of thing is really hard.
I asked Bluelans sales, and they said they never sold a "G2+". They
thought some online shops just added the '+' to improve their sales
over the ones that have no plus :-)
As for the G2 being triple-band, do you have some links? All I heard
is that G2 is quad-band. The box I am holding in my hand says
"Quad-band phone with WIFI", although that also doesn't need to mean
much.
I could imagine that some ICs on the G2 can do quad, but other
components on the board (filters?) actually pick 3 of those 4?
So - I can only ask back :-) Can anyone confirm that the G2 is really
and fully quad-band? Maybe we have to wait until OsmocomBB is at the
point that we see it running...
I google
"Sciphone Dream G2 tri-band" : 10,300 results
"Sciphone Dream G2 quad-band" : 15,800 results
Welcome to China :-)
Of course you also find "tri-band GMS" and whatever other typos.
Sorry I have no definitive answer.
Wolfgang
9:10 a.m.
New subject: G2 tri-band / quad-band
On Tue, Nov 09, 2010 at 06:29:00AM +0000, Wolfgang Spraul wrote:
I could imagine that some ICs on the G2 can do quad,
but other
components on the board (filters?) actually pick 3 of those 4?
According to the schematics it is a quad-band design. The Antenna switch is a
SP5T (two bands tx, 3 bands rx), followed by an additional filter that
separates the 850 from the 900 in the RX path.
Given that the filters (including the 850/900) are all unbalanced-to-balanced
filters, I doubt that somebody would simply not place them (as you cannot
replace them just with a 0ohms resistor or soemthing. By removing one filter
you would not be able to produce a standard 850/1800/1900 or 950/1800/1900
configuration but something like 850/900/1800 or 850/900/1900 which doesn't
maeke sense.
My personal educated guess is: they are all quad-band.
--
- 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)
10:09 a.m.
New subject: G2 tri-band / quad-band
Hi,
Given that the filters (including the 850/900) are all
unbalanced-to-balanced
filters, I doubt that somebody would simply not place them (as you cannot
replace them just with a 0ohms resistor or soemthing. By removing one filter
you would not be able to produce a standard 850/1800/1900 or 950/1800/1900
configuration but something like 850/900/1800 or 850/900/1900 which doesn't
maeke sense.
Have you noticed that the capacitors on the 850 path are marked as N/C ?
I don't see why they wouldn't have put them tough ... it's not like it
changes the price much.
Sylvain
11:28 a.m.
New subject: G2 tri-band / quad-band
On Tue, Nov 09, 2010 at 10:09:42AM +0100, Sylvain Munaut wrote:
Hi,
no. ouch.
Given that the filters (including the 850/900)
are all unbalanced-to-balanced
filters, I doubt that somebody would simply not place them (as you cannot
replace them just with a 0ohms resistor or soemthing. By removing one filter
you would not be able to produce a standard 850/1800/1900 or 950/1800/1900
configuration but something like 850/900/1800 or 850/900/1900 which doesn't
maeke sense.
Have you noticed that the capacitors on the 850 path are marked as N/C ? I don't see why they wouldn't have put them
tough ... it's not like it
changes the price much.
probably a 'marketing requirement'... "we don't want to sell a quadband
phone
for the same price like a tri-band phone"
--
- 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)
9:46 a.m.
On Tue, Nov 9, 2010 at 11:59 AM, Wolfgang Spraul <wolfgang(a)sharism.cc> wrote:
Steve,
Hi All,
First and foremost, *awesome* work :-)
I have been searching for getting Linux on MT 6235 after I happen to
get this phone in India
http://flyphone.in/products/B%20450.html?model_name=B%20450
I think it is based on MT 6235, as when I connect it using the USB
cable to a Windows box and select the camera mode it identifies the
camera as MT 6235. Reading in a document I found online (one question
here, can I paste the link to the source which I found online, it is a
confidential MTK presentation), it states that MT 6235 can only
support up to 2MP camera and it states that MT 6238 can support upto
3MP, the phone manual says 3.2MP.
Pardon my ignorance, but what would be the best way (source to read,
experiment and create serial cable) to replicate the work you guys are
doing with this phone. I tried the MTK flashtool but it fails, though
it detects the phone as MT 6229.
Thanks,
Rahul
By the way - many shops still sell the
"Sciphone G2+", do you know
the difference compared to the G2? One thing I noticed is that the
G2 seems to be triple-band (there's a 850/1800/1900 and a
900/1800/1900 variant), and the G2+ quad-band.
Can you confirm this?
A positive confirmation for this kind of thing is really hard.
I asked Bluelans sales, and they said they never sold a "G2+". They
thought some online shops just added the '+' to improve their sales
over the ones that have no plus :-)
As for the G2 being triple-band, do you have some links? All I heard
is that G2 is quad-band. The box I am holding in my hand says
"Quad-band phone with WIFI", although that also doesn't need to mean
much.
I could imagine that some ICs on the G2 can do quad, but other
components on the board (filters?) actually pick 3 of those 4?
So - I can only ask back :-) Can anyone confirm that the G2 is really
and fully quad-band? Maybe we have to wait until OsmocomBB is at the
point that we see it running...
I google
"Sciphone Dream G2 tri-band" : 10,300 results
"Sciphone Dream G2 quad-band" : 15,800 results
Welcome to China :-)
Of course you also find "tri-band GMS" and whatever other typos.
Sorry I have no definitive answer.
Wolfgang
9:54 a.m.
On 9-11-2010 7:29, Wolfgang Spraul wrote:
A positive confirmation for this kind of thing is really hard.
I asked Bluelans sales, and they said they never sold a "G2+". They
thought some online shops just added the '+' to improve their sales
over the ones that have no plus :-)
As for the G2 being triple-band, do you have some links? All I heard
is that G2 is quad-band. The box I am holding in my hand says
"Quad-band phone with WIFI", although that also doesn't need to mean
much.
I could imagine that some ICs on the G2 can do quad, but other
components on the board (filters?) actually pick 3 of those 4?
So - I can only ask back :-) Can anyone confirm that the G2 is really
and fully quad-band? Maybe we have to wait until OsmocomBB is at the
point that we see it running...
I google
"Sciphone Dream G2 tri-band" : 10,300 results
"Sciphone Dream G2 quad-band" : 15,800 results
Welcome to China :-)
Of course you also find "tri-band GMS" and whatever other typos.
Sorry I have no definitive answer.
Wolfgang
Hahahaha, I really enjoyed your post :D
8 Nov
8 Nov
3:45 p.m.
Hi Marcin, hi list,
today I received the Sciphone G2 and 'hacked' the headphone cable into a
serial cable (which worked quite well, compared to the Mobistel).
osmocon worked on the first try. I only had to modify the UART_BASE
address in my mtk test code (steve-m/mtk_hack). (log attached)
I've used the FT2232 UART on the OpenMoko Debug Board, but it works with
a PL2303 as well.
Now we need to find out why it doesn't work for you...
Regards,
Steve
6 p.m.
Hi Steve,
On Mon, Nov 08, 2010 at 03:45:28PM +0100, Steve Markgraf wrote:
today I received the Sciphone G2 and 'hacked'
the headphone cable
into a serial cable (which worked quite well, compared to the
Mobistel).
osmocon worked on the first try. I only had to modify the UART_BASE
address in my mtk test code (steve-m/mtk_hack). (log attached)
this is great news. It means people without JTAG (and without soldering wires
to test pads on the PCB) will be able to participate by simply loading code via
the serial port.
I can't wait until I receive the Sciphone G2 boards from Wolfgang
Right now I've been soldering some wires to the test pads next to the MT6227 of
the Mobistel EL570, I'm quite sure they also have JTAG on it. I'm planning to
compare the GSM part of the 622x and 6235 as per the data sheet next. I hope
they are reasonably similar, which would mean any testing / development we do
on the 622x could later be leveraged to the 6235.
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)
9 Nov
9 Nov
4:35 a.m.
Hey,
Will this theoretically work with any MTK6235 based phone? Or is the serial connection
specific to the G2 device? There are plenty of MTK based phones out here, but finding a
specific model is a long shot.
Cheers,
--gq
On 8 Nov 2010, at 21:45, Steve Markgraf wrote:
Hi Marcin, hi list,
today I received the Sciphone G2 and 'hacked' the headphone cable into a serial
cable (which worked quite well, compared to the Mobistel).
osmocon worked on the first try. I only had to modify the UART_BASE address in my mtk
test code (steve-m/mtk_hack). (log attached)
I've used the FT2232 UART on the OpenMoko Debug Board, but it works with a PL2303 as
well.
Now we need to find out why it doesn't work for you...
Regards,
Steve
<osmocon_mt6235.txt>
5:39 a.m.
Hi,
On Tue, Nov 9, 2010 at 4:35 AM, the grugq <thegrugq(a)gmail.com> wrote:
Hey,
Will this theoretically work with any MTK6235 based phone? Or is the serial connection
specific to the G2 device? There are plenty of MTK based phones out here, but finding a
specific model is a long shot.
This will work on all phones based on MT6235 as long as code will be
executed in internal RAM (64KB) and you'll know where are serial port
pins (these are specific for phone). There will be also differences in
RAM, NAND, LCD, etc. and it's matter of writing new driveres for these
peripherals.
BR,
Marcin
6:53 a.m.
Hi Steve, hi list,
On Mon, Nov 8, 2010 at 3:45 PM, Steve Markgraf <steve(a)steve-m.de> wrote:
Hi Marcin, hi list,
today I received the Sciphone G2 and 'hacked' the headphone cable into a
serial cable (which worked quite well, compared to the Mobistel).
osmocon worked on the first try. I only had to modify the UART_BASE address
in my mtk test code (steve-m/mtk_hack). (log attached)
That's really good. I connected PL2303 to my PC and it also worked
(before I used two built-in ports in Dell computer). I had this kind
of problem some time ago with mini2440 board (based on s3c2440).
I was able to download the code and it started on the phone but hanged
just after printing HW version. I'll check why is that.
Unfortunatelly I had problems pushing my UBoot code to
git.osmocom.org, so until I'll not solve them, you can use my patch
from attachment.
This patch should be applied on recent repository of UBoot:
git://git.denx.de/u-boot.git
After applying patch it should be possible to configure Sciphone G2 target:
make sciphone_g2_config
make CROSS_COMPILE=....
After compilation you should be able to download UBoot to Sciphone
using osmocon.
For this, there should be PLL turned on and then EMI controller
initialized to be able to download UBoot code to external RAM (size of
UBoot is about 120KB). You can find this initialization in
"board/mtk/sciphone_g2/sciphone_g2.c" file. It should be applied to
loader.
BR,
Marcin
4 Jan
4 Jan
11:56 a.m.
no, kurde, myślałem, że to rosjanie wrzucili linuxa na sciphona (bo z
rosyjskiego forum wyczytałem o tym) a tu mój krajan :)
no szacun wielki panie Marcinie!
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp17…
Sent from the baseband-devel mailing list archive at Nabble.com.
3 p.m.
Hi !
On Wed, Jan 04, 2012 at 02:56:54AM -0800, wizer12 wrote:
no, kurde, myślałem, że to rosjanie wrzucili linuxa na
sciphona (bo z
rosyjskiego forum wyczytałem o tym) a tu mój krajan :)
no szacun wielki panie Marcinie!
I would appreciate if you could post in English language to this mailing
list. Don't hesitate even if you think your english is bad. Most
people here (including me) are non-native English speakers.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3:05 p.m.
On Wed, Jan 4, 2012 at 7:30 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi !
On Wed, Jan 04, 2012 at 02:56:54AM -0800, wizer12 wrote:
Well, fuck, I thought it was Russians threw Linux on SciPhone (because of the
Russian forum I read about it) and my countryman here:) no estimates of the
great Mr. Martin!
Courtesy google translate.
no, kurde, myślałem, że to rosjanie wrzucili
linuxa na sciphona (bo z
rosyjskiego forum wyczytałem o tym) a tu mój krajan :)
no szacun wielki panie Marcinie!
I would appreciate if you could post in English language to this mailing
list. Don't hesitate even if you think your english is bad. Most
people here (including me) are non-native English speakers.
--
- 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)
7 Jan
7 Jan
12:05 p.m.
sorry
ok, I will be writing in English :P
--
View this message in context:
http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp17…
Sent from the baseband-devel mailing list archive at Nabble.com.
5028
days inactive
5463
days old
baseband-devel@lists.osmocom.org
37 comments
13 participants
participants (13)
-
Harald Welte -
J T Dsouza -
Marcin Mielczarczyk -
Nordin -
Peter Stuge -
Rahul Khanna -
Steve Markgraf -
Sylvain Munaut -
Sébastien Lorquet -
the grugq -
wizer12 -
Wolfgang Spraul -
Wolfram Sang