Closed pfalcon closed 9 years ago
Hi Paul,
There is a mask ROM, you're correct. I forget where it starts, but it's probably around 0xffff0000. Failing that, look at 0xfc000000.
Those addresses were obtained by looking at the code that the MTK loader sends. When you flash a phone using the official loader, it first loads several stages over USB. We captured those traces and noticed it loading a pointer from a specific area of memory. In truth, it might have been better to dereference that pointer in the code rather than hardcoding it, but I was in a hurry to get something up.
We disassembled the ROM to find functions. The USB driver in fernly is loosely based on what I found in the ROM.
Interestingly, their API supports the same calls for both serial and USB. But USB is more interesting, so we dropped serial support.
The ROM is only about 64k, which is impressive as they have things like an RSA implementation in there.
I will put this information in the source when I get a chance. Thanks for asking for clarification.
On 18 February 2015 18:13:49 GMT+08:00, Paul Sokolovsky notifications@github.com wrote:
Would you care to explain (comment in the source) where addresses like below come from:
ldr r3, =0xfff03639 blx r3 ldr r3, =0xfff03653 ldr r3, =0xfff04845
0xfff00000 isn't included in memory map in README.md. Is there some kind of mask ROM in MTK6260 with such predefined routines?
Reply to this email directly or view it on GitHub: https://github.com/xobs/fernly/issues/11
@xobs: Thanks for the changes https://github.com/xobs/fernly/commit/8a4f98b5b17808e63c4db824aa86045044907a26 ! I finally got my MT6260 device (not a Fernvale board), and hope now to join the fun.
So, first question I wanted to clarify is the canonical boot ROM address. 0xfff00000 (3 f's) looks a bit suspicious for 64K size. With fernly shell, I figured out that ROM is mirrored from 0xfff00000 at each 64K offset until the end of address space. But given such structure, wouldn't you think that canonical boot ROM location would be 0xffff0000 (4 f's)? I changed values in usb-loader.S to use 4 f's, and it works the same. As additional argument regarding 0xffff0000 canonical location is that reading one of MTK's Cortex-A datasheets, it mentioned boot ROM being at that address.
It could be that's the canonical address, but the actual address mentioned in the code is one we pulled out of RAM.
Unfortunately IDA has corrupted its copy of the database of my ROM disassembly, so I'll have to re-examine the code to get a definitive answer.
but the actual address mentioned in the code is one we pulled out of RAM.
Yeah, but as @bunnie and you point out (in blogs/presentation) the whole project is based on original research/work, so there's no need to blindly use whatever you saw, coming from a vendor ;-). I'm running with "ffff" addresses for 2nd day - all works ok, But if you don't want to touch something which works already, I surely understand. My concern is to have bootrom area recorded faithfully in address map - will submit separate patch for that.
Would you care to explain (comment in the source) where addresses like below come from:
0xfff00000 isn't included in memory map in README.md. Is there some kind of mask ROM in MTK6260 with such predefined routines?