Linux + u-boot port to MT6235

Harald Welte laforge at
Fri Oct 29 16:11:41 UTC 2010

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


> 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;a=commitdiff;h=dd95bcec33237d39274092e2ab1f42eb2633985c

If we assume the ROM loader of MTK has not changed between MT622x and MT623x,
it may actually work.

> I found on 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

> 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 "".
> 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 Welte <laforge at> 
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

More information about the baseband-devel mailing list