[project]Port android to meizu M8

I dont know how hard it is to get the samsung sdk for wince6 to work on ce5. i will see that this evening.

for a hint, If you like to open the back case of M8 I think you can use jtag to quickly restore your M8 from stone to ce.
in other words, you can ignore these post in page 16 if you have jtag because it's only rulz for keep your M8 don't flash to a stone.

Know one here knows where to find those jtag pins, we tried already by studing photots an stuff. Do you know where they are?

But as mentiond, there are two win ces on the phone so i think its save to play with the main xip.bin as long as we keep away from mzupgrade.bin

contact me if you need build an mini xip with only test exe/elf for check GPIO / MemMap

It would be very very nice if you could build such a xip.bin maybe with just send something trhough serial port. i would flash it to my phone and then we will see if it worx.

PS: Just a question to the Loadadress:
The loadadress in the xip.bin tells the bootloader where to start with the os execution. its 8010000 or something. I think this is the absolute position of the code in flash. So there must be a way to calulcate the offset of the code in the xip bin to get it flashed to 8010000 because we need our code there to get executed. This must be the diffrence from startadress where the xip is flashed to codestart in xip i think. So if the xip gets flashed to 8000000 or code must be at offset 1000 in the xip if im right. how is that calculated?

80100000 is baseaddress.
xip.bin released by Meizu (stock firmware) have two area(regeion).
no space hole between two area.
offset in file is virtual address - baseaddress.
A classic load address equas FixedImageBase + OEP in kernel mode module nk.exe of first xip region.

build your hello.exe with 80100000 base address though linker settings (merge all section, file align 1000, no imp), and get oep from LordPE/PETools, calc load address, convert to mini xip.bin by M8Factroy (publish by my protected ID kingvera) and have a nice reset~

I heard of M8 have a 10pin Mini usb female slot, I think if you can write and monitor it on full xip, you'll get same result in your mini xip.
(your hello.exe can not use OpenFile API or any other LoadLibrary around to access serial because there is no windows enviroment at the time).

This thread is soo interesting, i try to watch it every hour! hope you guys will pull this off

This thread is soo interesting, i try to watch it every hour! hope you guys will pull this off

We workk onnit problem here: I have a job :P

I hope i get this evening or weekend time to try to write a small program.
With the codes from the s3c6410 SDK fpr windows ce i think i can figure out som elow level uart routines to get something out of the serial port without the need of any further libraries.

BTW found this in the systeminit asm file

; File: startup.s
;
; Kernel startup routine for Samsung SMDK6410 board. Hardware is
; initialized in boot loader - so there isn't much code at all.

:P looks primising


Okee just got a propgram compiled which sould send something on the SMDK6410 UART port. Just used the functions i found in ebootloader source. this should be lowlevel eneugh

Just for the fun:

this is serial port initialization

void Uart_Init(void)
{
UINT32 DivSlot;
float Div;

// UART I/O port initialize (RXD0 : GPA0, TXD0: GPA1)
rGPACON = (rGPACON & ~(0xff<<0)) | (0x22<<0); // GPA0->RXD0, GPA1->TXD0
rGPAPUD = (rGPAPUD & ~(0xf<<0)) | (0x1<<0); // RXD0: Pull-down, TXD0: pull up/down disable

// Initialize UART Ch0
rULCON0 = (0<<6)|(0<<3)|(0<<2)|(3<<0); // Normal Mode, No Parity, 1 Stop Bit, 8 Bit Data
rUCON0 = (0<<10)|(1<<9)|(1<<8)|(0<<7)|(0<<6)|(0<<5)|(0<<4)| (1<<2)|(1<<0); // PCLK divide, Polling Mode
rUFCON0 = (0<<6)|(0<<4)|(0<<2)|(0<<1)|(0<<0); // Disable FIFO
rUMCON0 = (0<<5)|(0<<4)|(0<<0); // Disable Auto Flow Control

Div = (float)((float)S3C6410_PCLK/(16.0*(float)DEBUG_BAUDRATE)) - 1;
DivSlot = (UINT32)((Div-(int)Div)*16);

rUBRDIV0 = (UINT32)Div; // Baud rate
rUDIVSLOT0 = aSlotTable[DivSlot];
}

thats pure c

This evening i will compile it with an arm compiler and then i will try to get it in a xip.bin

I really like studing the Codes from the smdk6410 I think they will be very very helpfull when it comes to boot a kernel.

As i studied the bootloader code i found this:

PHP Code:

 SG(TRUE, (TEXT("Press [ENTER] to launch image stored on boot media, or [SPACE] to enter boot monitor.\r\n")));
        OALMSG(TRUE, (TEXT("\r\nInitiating image launch in %d seconds. "),BootDelay--));

...

    while((dwCurrTime - dwStartTime) < g_pBootCfg->BootDelay)
... 


Whtas this? this states clearly: With delay set to 0 seconds (as our eboot does) we cant get into the menu. so our cable could be okay, or if it was okay, we could not get into the menu. so bad luck at all

BUT: if we find some brave meizu users we could try to compile the bootloader from the smdk6410 and try to flash it with our mzboot.bin.

The problem: i think meizu must have changed the bootloader (for the upgrade mode) and if there are any adresses changed beside from the smdk6410 std values the phone will be fucked :/

maybe we could get a defektive m8 (screen sim or sth) this would be fine to try :D

Another interesting thing: i unpacket some of the eboot.bin files i found on the net and all of them also just included a nk.exe (like the mzbooz.bin) so im pretty sure we have our bootloader, and we have the opportunity to flash a new bootloader along with the bios. With the sources of the loader (which we also have) it should be easy to patch the code to show up the boot menu. maybe we could reverse the nk.exe from to go to the boot menu. then we dont have the risk of wrong adresse is file, but the risk of patched it wrong

The delay is stored in the flash i saw in code. so maybe when we could get our own code to run, we could read out the fst block and just change the delay from 0 to 255 or so

Ohh these are very interesting mind games i very like what we are doing
(even if i dont know if i would use android :P )


PS: And another interesting thing: mzboot.bin is not compressed. so we could patch it directly (is there a checksum??)
The code from the extracted nk.exe can completely be found in mzboot.bin.
So if we could find interesting placed (maybe the delay counter) with a debugger, we could pach it directly in me mzboot.bin and flash the patched mzboot to the device, and getting in the eboot menu. But i think the eboot menu isnt a great help...

I think best chance is to create a custom xip.bin and let it start from eboot.

yes, B00FF bin is checksum32 presented,
please do binray patch on nb file.
convert mzboot.bin to nb0 with dumpromy/M8Factory and use BaseAddress 80030000, LoadAddress 80049794 then convert it back to bin.

Hum ^^
The propably easiest thing makes problems ^^
Compiling.


If i use target m8sdk Arm4 i get imports from coredll which i dont get rid of.

If i compile with Visual Studio for intelligent Devices with target Pocket PC 2003 Arm4, i get the program (about 3kb).

I think this should not be the problem, Pocket PC 2003 arm4 should do. (am i right?)

Looked at it in IDA it says No Imports. Thats good
BUT it had sections (.text .rdata .data .pdata) and the wrong base adress (ImageBase 10000)

But how can i merge 4 sections with visual studio? i know how to merge two (/MERGE:.test=.rdata)
when i set baseadress to 0x80100000 in the linker it says "Program to big with Base 0x80100000 and size 0x5000"

Do you know what this is and how i could get rid of this?

Second i used winarm to compile (gcc-system-arm) did a compile and got a file, about 50kb, without imports but with some new functions innit. I think there can be as much helper functions as they want as long as there is no import its no problem. But here too, i dont know how to set the base adress and the file alignment.

Which compiler would you use?

you can use rejacker to do post base address reloc (drag file in rejacker, click Ext -> advanced module reloc).

Soo lets see if i understood this all right:

I take this information from m8pack:

Code:

xip.bin
RomAddress: 0x80100000    RomSize: 0x00F9065C
RomLoadAddress: 0x8010DB24

These are the values of the xip.bin which will install the mzboot and mzupdate system.
This means: The Firmware is copied from eboot to 80100000 in the flash and the bootloader will jump to 0x8010DB24 to execute (this is 80100000 plus entrypoint from nk.exe).
right?

So take lowlevel code from the smdk6410 (because m8 is based on this)
and write a small program. (i have one this, sending something trough uart)
This programm must be a pe file to exchange the nk.exe with it.

Then we try to get this program as much nk.exe like as we can. (nk.exe is the kernel of windows ce. Its based at 80100000 so we must base there too and our ROMLoadAdress must be 80100000 plus our entrypoint. We cant use any libs at this time and beacuse there is not system no relocation and stuff can happen. So no imports and stuff here (shoul we say fixedimagebase to the linker?))

Then we will replace the nk.exe with our nk.exe and if we flash the firmware with this program, the bootloader would start the our program, do something (hopefully write something to uart) and nothing more will happen.

If this works we could build a xip.bin with a preinitaialized androind kernel @ 80100000 and this would start android for us

After all, (i hope) the upgrade system on the m8 will be untouched so we can get back to our m8 firmware everytime.

I understood it right ya?
I see that you (@ banxian) are much more common with pe reversing and such stuff. im not good at this pe stuff (relocation unpacking etc, im just a hobby reverser newb )

Okay now that i think i have understood it its much more clear for me

Two things:
m8 pack cant open the mzupgrade and the xip.bin from the bios package:
after some

Code:

NOTE: section at 0003c000 iso 00039000 for QIODevice

comes

Code:

ERROR - invalid xipchain

the second: the xip.bin from the bios pack (which installs a system to install mzboot and mzupgrade) has the same Romloadadress and the same RomAdress like the upgradesystem in mzupdate.bin.
But in my thoughts this is a completly independent upgradesystem. i want to be save that my upgradesystem still works after flashing an unprductive xip.bins. So these values say just how the image is copied from flash to rom when it gets executed right?
so they reside beside in flash until it comes to boot. then the selected image (normal boot or upgradesystem) is copied to 80100000 and gets executed. right?
Just want to be save not to fuck my phone with this :D

PS:rejacker cant rebase the exe (Its not a rebaseable dllfile)

PPS:Because there are no relocations present in file, it must be good enough to set the Imagebase Field from the PE header to 80100000 am i right? This can be done easily

PPPS:Found out, with relocations LordPE can do the job, without relocations just editing the header keeps the code intact (in IDA) but kills some sections. For me thats ok, just want to execute some ARMASM codes

to r3wDy:
yes, you get almost truth.
I'll give you special version that can build xip.bin from hello.exe later.
let's contact by MSN or ICQ for file exchange / bug report.

Code:

ERROR - invalid xipchain

MPack designed for deal with normal offical firmware, so it have more rules than dumpromy, bin files in bios upgrade package failed integeration check.
remove this limit may cost much time than add a lite xip builder.

Guys,
I am happy to see that this project is finally going somewhere!
Thanks for that!

As i studied the bootloader code i found this:

PHP Code:

SG(TRUE, (TEXT("Press [ENTER] to launch image stored on boot media, or [SPACE] to enter boot monitor.\r\n")));
OALMSG(TRUE, (TEXT("\r\nInitiating image launch in %d seconds. "),BootDelay--));

...

while((dwCurrTime - dwStartTime) < g_pBootCfg->BootDelay)
...

Whtas this? this states clearly: With delay set to 0 seconds (as our eboot does)

r3wDy, as far is my studies went i noticed that by default the bootmenu has 0 seconds initiated on retail devices, cause normally this is not used by endusers.
But that doesn´t matter, it should still work with a correct debug cable as long as we are fast enough to push 'space'.
(for refference have a look on hack/mods for wifi, htc,... debug projects)
Of course by rewriting that system part we could be able to autoload the menu instead of autoloading wince.

r3wDy i wanted to ask you iff you hooked on the debug system while performing the bios updates to see what it prompted, maybe it would gain us acces to other system options.

I was also thinking that editing the xip.bin that acces to the flash upgrade option and providing a serial download option could be interesting to dump the original files from Inand in the m8 ?
So if your hello world would work in that custom rom i gues it would be possible to do this so we would not need jtag immediatly, except ofcourse if the m8 gets bricked..

About jtag, when i have my m8 back i will see if the pins next to the sim socket gain any transmitting details whil using a multimeter, maybe this way we could find jtag system.

Last night i was continuing my quest on the bootloader system, and i came accross this :

this easily explains the function of the QI bootloader used by smartq/neo freerunner, it made me thinking that maybe editing the smdk6410 kernel with the right load address could run the linux kernel straight away from eboot .
The SMDK6410 linux kernel can be found here and it is allready in a bin format. (did not try to convert/analyze yet)
Maybe we should try to edit the load address, and flash it like a regular FW update, this should normally not harm our device since we would not overwrite any bootloader, but just the wince package? (and wince package can allways been reverted with normal upgrade procedure)

Ofcourse it is just some gambling and maybe it wont work since i have not investigated the kernel yet.

Another remark i have is that when going in the hidden wince menus trough the documents explorer you have somewhere the option to see your local disk information, where is stated that we use an inand from samsung. it made me thinking that the /disk is just an hotwired CF disk since the smdk6410 has an cf interface where it is allowed to boot from.
When investigating the diskmanager in wince you would notice two partitions on the same inand, so meaning that the bootloader Eboot and maybe the wince kernel gets stored onto the first partition?

Maybe you banxian have any idea if it would be possible to include a better diskmanager in the meizu xip.bin fw package? this could allow us to mount the first hidden partition?

Reason why it is interesting to know that m8 could have an hotwired CF flash into it is because on smartq they use a cf where there is written away a small loader to let them boot into various kernels., maybe someone with a broken m8 could desolder the flash chip and see how it reacts afterwards, it could provide other hacks onto it similar to the smartq series;-)

Another remark i would like to make is since we would like to load a android kernel and maybe also an wince kernel we will need to begin thinking on how to manage our filesystems on the m8.
we will need an exfat(right?)or fat32 for wince but an ext3/4 aswell for linux.
Since i suspect the /disk to be a hotwired CF i guess it should be easy to mount the m8 /disk in USB modus through a linux system to format those partitions in for exmaple 7gb for wince and 1gb for android/linux?
(in the beginning we do not really need lots of starage space for the linux kernel)
ps since my idea on the hotwired CF i am starting to wonder if those android m8 movies that show CF in the explorer are really fake ones?

there i did it again, i said so much i still think i forgot to mention something

edit:
crap , i forgot something. If we would want to play for save we could always hire a specialist who could write an bootloader? (stupid idea but safer i know)

edit:i just started to think on something.
the smdk has an ifusing rom tool, the FW R3wdy used is called bios fw.
My point: on a pc system you have a bios, a bootloader, a os kernel and os environment.
So if you follow my idea, what is the flash FW ? a bios or a bootloader?
Mostlikely a bootloader since R3wdy found the eboot menu in it
and the ifusing rom has a tool that seems to write away a package that is normally between 1KB and mix 64 KB,but can we be sure?

And another mindspin : on pc you can install a bootloader to load an other bootloader. the first one is stored in the root of de /disk and the second one needs to be stored in the beginning of the filesystem to be able to function. Could it be possible to pull somthing of like this on m8?
I gues if we could manage this, we could look into the eboot loader to the functions : 'POWER + PLAY' (used to upgrade) and add an entry to push multiple buttons while booting to force an other loading address where our second bootloader is stored. Ofcourse the button combination and the loading table needs to be modified...

edit

KAutobuild for s3c6400_defconfig on kernel 2.6.28-git6
The build of s3c6400_defconfig was performed on gerald.kyllikki.org using gcc version 4.2.2 and binutils version 2.17.

http://armlinux.simtec.co.uk/kautobu...defconfig.html

Wow what a long text
The ideas you mentiond (to put the code which starts linux in our FW and boot it with eboot) is just what we trying to achive right now the hello world program would be the first step.

To the CF thing. Read the boot logs:

[UFNPDD] SD or SDHC or MMC is mass storage device

[HSMMC1] Card is Inserted!
[HSMMC1] SetVotage ++
[HSMMC1] SetVotage 11
[HSMMC1] Set
Votage 22
[HSMMC1] SetVotage 33
[HSMMC1] SetVotage --
[HSMMC1] Turn ON the F/B dela
y control.

As you see, the 8gb memory are indeed a wired MMC Card which is used als USB drive in the phone

To the bootloader time: i saw in the logs we have two seconds, not 0 so it _MUST_ be possible to get in there. The USB plugs came but the pins are very small and hard to solder sth onnit. But the bootmenu doenst give us the opertunity to save the loader. Just to download an image to ram (this would also be good because we wont need to build custom xips anymore)

Im right now in contact with baixan and i hope we can get some homemade code run on the phone, then the door is open for nearly everything i think

I dont know much about coding, bios flashing etc. but i am pursuiting this thread with fun and curiosity. Thank you guys for your efforts and have luck!! I'll keep my fingers crossed!

Originally Posted by r3wDy

Wow what a long text

Yeah sorry for that :-)

To the CF thing

so it opens a new possibility then ;-)
But desoldering the Inand is not something that will be easily done on a good functioning device

The USB plugs came but the pins are very small and hard to solder sth onnit

so did you manage to solder it to the debug? and did you manage to acces the menu?

download an image to ram (this would also be good because we wont need to build custom xips anymore)

That is indeed a very good option, it saves time on flashing firmware and reduces the risks!
But will the starting point of the fw be of any importance?
if not , instead of building a fw package at the moment you could try to mount the linux kernel as i provided in my previous post to see what it does?

hope we can get some homemade code run on the phone

starts linux in our FW and boot it with eboot

keep us posted on the progress, as i am still very sceptic if eboot will mount the linux kernel. (cause if it would be that simple some chinese would allready have it running..)

I don't doubt some chinese people are working on it, but how could we know? i mean how many of us speaks chinese?

true,
but you could also try and use google.cn to try and find something ;-)

Ps mods,
maybe you could introduce a web based irc/chatting system, it could help while discussing instead of using msn:P
Then everyone could follow or help ;-)

I just tried to flash a xip.bin build with a tool from banxian. I could flash it, but my code got not executed :/

The good thing: even with a non starting m8 we can still reach the upgrade menu tu flash a good xip to the device. So we will try further.

I build a plug but i couldnt reach the menu.
But: it says: 2 seconds to press space but the bootloader doenst wait. I still think we just cant get to it, but we keep trying

For now i will se why the homemade xip cant be executed

r3wDy,

could you try to load the linux kernel from eboot and see what it does?
(but first you will need to change the load address of course)
link once again : here

about the plugs could you inform me on the pin layout you used?
cause we still need to make sure on where to find the m8 rx pin..

and what would it cost me if i buy 1 plug incl shipping? :P

naw just send me a pm with adress ill send it to you.

i used the same layout like mentiond in the thread but i will try other ones when i have time for this.

Yes we will try to load the linux kernel, but @ first we must get to execute any code first.
We tried to build a xip.bin with just the nk.exe innit and this wouldnt execute too, but i think this code should work at least to give errors in serial console but nothing happend. i think there is still some problem with the xip. banxian will sure look at it when he finds time

PS i will hang out @
irc.eu.efnet.info 6667 channel m8android when im working there we could meet

r3wDy,
will pm asap & when i get at work on monday i will try to get on the channel.

about USB,
Possibly the rx is a pin i could not connect with a default plug, so if you find time , we will see :-)



Something else;

we now know that m8 uses a movinand (aka inand, cf, what ever)
this is how it works:


I started researching further on the fact we could try to boot from there.
Somehow they did on smartq (link) by using the fusing tool that writes a sector on the CF card, then by booting with feature 'boot from cf' to mount from there.
this is how they forced that way of booting ;

To boot from the SD card, keep the "move" (also known as fullscreen) button pressed and then press the "power" button.

• Yellow LED: bootloader running, trying to locate and loading a kernel image.
• Green LED: Linux kernel loaded and running.

as i googled further i came accross embedian wiki that has lots of usefull info ! when i went to the download section and connected to their FTP i found a similar tool(and info pdf files) like the original Irom fusing tool samsung provides with s3C6410 chip.
then i came up with the next thing : if we would connect in windows using usb disk modus and tried to write away a custom eboot with the fusing tool wouldnt it be possible to mount from /disk?

My idea was that using the buttons to get in upgrade menu could be the forcing way to mount from the hidden partition in /disk..

It is pure guessing work, but it is an interesting idea?

ps you should really spend some time on the embedian site (ftp and wiki)
this is really interesting!

ps sorry my explanation looks like crap but i was trying to shorten it up :P