Linux + u-boot port to MT6235

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Marcin Mielczarczyk marcin.mielczarczyk at gmail.com
Sat Oct 30 11:51:28 UTC 2010


Hi,

On Fri, Oct 29, 2010 at 6:11 PM, Harald Welte <laforge at 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=dd95bcec33237d39274092e2ab1f42eb2633985c
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scig2_jtag.JPG
Type: image/jpeg
Size: 87959 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20101030/8c4fbd6c/attachment.jpe>


More information about the baseband-devel mailing list