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)