[project]Port android to meizu M8

Originally Posted by evow04

one last dump question, dit one of you guys managed to extract contents from eboot file?

a newer dumpromy can do this work (usage: dumpromy -c -d boot mzboot.bin), but I failed to upload it to this forum.

currently I make workaround on OEP magic jump and stack workaround, and building a CE6 image from clone BSP (I call it M7) with analysted address config at same time.

I notice eboot must use a bib config file to assign stack range for C code in it manually. I'll analyst target image later.

PS: target M7 xip.bin failed start without any hint as excepted.

Thanks Banxian,
will try to have a look onto it tomorrow, problem is that have so much work for the moment i rarely find time for now

with analysted address config at same time.

that could be usefull!

I notice eboot must use a bib config file to assign stack range

actually eboot.bin is build by compiling eboot.bib to eboot.nb0,
that is why i was interested to know how far you would be able to reverse the eboot binary file.
It would show every load address and other memory allocations.
(if i am correct, like already mentionned i suck in win ce embedded )

I used IDA for analyst one function I interest only.

.text:80044C10 LDR R10, =0xA0020854
.text:80044C14 LDR R6, =0x12345678
.text:80044C18 MOV R2, R4 ; pGPIOReg
.text:80044C1C MOV R1, R7 ; pDispConReg
.text:80044C20 MOV R0, R8 ; pSPIReg
.text:80044C24 STR R6, [R10]
.text:80044C28 BL LDI_initialize_register_address
.text:80044C2C MOV R2, R4 ; pGPIOReg
.text:80044C30 MOV R1, R9 ; pMSMIFReg
.text:80044C34 MOV R0, R7 ; pDispConReg
.text:80044C38 BL Disp_initialize_register_address
.text:80044C3C LDR R3, [R4,#0x830]
// I truncate some because over forum limit
.text:80044C8C MOV R0, #1
.text:80044C90 BL sub_80055F6C
.text:80044C94 ADD R0, SP, #0x84+RGBDevInfo ; pDevInfo
.text:80044C98 BL LDI_fill_output_device_information
.text:80044C9C ADD R0, SP, #0x84+RGBDevInfo ; pInfo
.text:80044CA0 BL Disp_set_output_device_information
.text:80044CA4 MOV R0, #DISP_VIDOUT_RGBIF
.text:80044CA8 BL Disp_initialize_output_interface
.text:80044CAC MOV R7, #0
.text:80044CB0 MOV R3, #480 ; uiHeight
.text:80044CB4 MOV R2, #720 ; uiWidth
.text:80044CB8 MOV R1, #DISP_16BPP_565 ; BPPMode
.text:80044CBC MOV R0, #DISP_WIN1_DMA ; Mode
.text:80044CC0 STR R7, [SP,#0x84+uiOffsetY] ; 0
.text:80044CC4 STR R7, [SP,#0x84+uiOffsetX] ; 0
.text:80044CC8 BL Disp_set_window_mode
.text:80044CCC MOV R3, #0x5D000000
.text:80044CD0 ORR R1, R3, #0x300000 ; uiFrameBufferAddress
.text:80044CD4 MOV R0, #DISP_WIN1 ; Win
.text:80044CD8 BL Disp_set_framebuffer
.text:80044CDC MOV R1, #DISP_WINDOW_ON ; WinOnOff
.text:80044CE0 MOV R0, #DISP_WIN1 ; Win
.text:80044CE4 BL Disp_window_onfoff
.text:80044CE8 BL LDI_initialize_LCD_module
.text:80044CEC MOV R0, #DISP_ENVID_ON ; EnvidOnOff
.text:80044CF0 BL Disp_envid_onoff
.text:80044CF4 MOV R3, #0xAD000000
.text:80044CF8 MOV R1, #0xA8000
.text:80044CFC ORR R2, R3, #0x300000 ; 0xAD300000
.text:80044D00 ORR R3, R1, #0xC00 ; 0xA8C00
.text:80044D04 ADD R3, R2, R3
.text:80044D08 MOV R1, #0
.text:80044D0C
.text:80044D0C loc_80044D0C ; CODE XREF: InitializeDisplay+1D0j
.text:80044D0C STRH R1, [R2],#2
.text:80044D10 CMP R2, R3
.text:80044D14 BNE loc_80044D0C

Code:

 
MOV R0, #0x50000000
    ORR R0, R0, #0x100000
    ORR R0, R0, #0x800
MOV SP, R0
B |?start@@YAXXZ|

I use this to get a 2048 byte stack I think (50100800 - 50100000).
now I can call start() writen in c and let screen blink some seconds.
https://sourceforge.net/projects/rej...r.rar/download
I'll try to draw some register value on screen today.

@banxian yes bitch (sry :P) that was what i wanted to hear from you
if we could use every code we write we will fuck that thing up
But: this means our ram starts @0x50000000phyiscal. then 0x80000000 is virtual adress. This btw. would conform with the enty in the oal mem table from smdk6410

Code:

    ; mDDR 128 MB
        ;DCD     0x80000000, 0x50000000,  64     ; 64 MB DRAM
        DCD     0x80000000, 0x50000000,  128     ; 128 MB DRAM

(maps 128 mb from 0x50000000 to 0x80000000)
This is a very intersting information for us, because we now can plan a memory layout for the kernel.
To see how/if the kernel boots we still need to get serial out to work, but i think with a working stack this cant be so hard anymore

@evow
we are now in a stage where you must stop thinking von wince and drivers and stuff. Imagine just a bare processor and ram. noting more nothing less.
When we gain cnotrol from eboot, we are there where windows would start initializing. So in this stage there is nothing can be done with windows apis or anything. we cant use any code which would use any part of windows. So haret and stuff is a nogo. We (i) try now to do what haret wold to. Prepare for a kernel boot and jump to the right adress in ram.

We are reversing bin files with a tool called IDA. Google for it.
The three parts of the Bios package are the following: (as mentioned above)
mzboot.bin code from eboot mzupgrade.bin small windows ce which will come up when up press power/music button xip.bin a small windows ce which is capable of upgrading the mzupgrade and the mzboot.
So no steploader to reach here.

So i think next step is to try to compile and boot a small linux kernel ( a busybox etc). I will try to steup a stack too and then i will try to write a small bootloader for linux as mentiond in the linked document.
If we get this we can start to reverse/collect drivers from oteher smd6410 android projects. But @first we need a running systen.

@banxian maybe you should look in image_cfg.inc for the stack. there are all adresses listed which are used by smdk6410

DRAM_BASE_PA_START EQU (0x50000000)
DRAM_BASE_CA_START EQU (0x80000000)

;// NK Area
IMAGE_NK_OFFSET EQU (0x00100000)
IMAGE_NK_PA_START EQU (DRAM_BASE_PA_START+IMAGE_NK_OFFSET)
IMAGE_NK_CA_START EQU (DRAM_BASE_CA_START+IMAGE_NK_OFFSET)
IMAGE_NK_UA_START EQU (DRAM_BASE_UA_START+IMAGE_NK_OFFSET)
IMAGE_NK_SIZE EQU (0x03F00000) ; Set Max size, This will be tailored automatically.


TOP_OF_STACKS_PHYSICAL EQU (DRAM_BASE_PA_START+IMAGE_NK_OFFSET) ; Stack Top is in front of NK Image
TOP_OF_STACKS_VIRTUAL EQU (DRAM_BASE_CA_START+IMAGE_NK_OFFSET)

; Stack Size of Each Mode
FIQStackSize EQU 256
IRQStackSize EQU 256
AbortStackSize EQU 256
UndefStackSize EQU 256
SVCStackSize EQU 1024
;UserStackSize EQU 2048


BTW lookk @ nkarea. its stated with NK_START = 80100000 so there must be a jump to the entrypoint elsewhere.
As i see it confirmed that at least the ram layout is the same in m8 and smdk6410 (starts at 0x5000000) we at least can use the same memory layout. its completely describedin image_cfg.inc and could be a great healp
You could tty this stack layout. (stack is between eboot and NK.exe

Code:

;--------------------------------------------------
;    Initialize Stack
;    Stack size and location information is in "image_cfg.inc"
;--------------------------------------------------

        mrs        r0, cpsr

        bic        r0, r0, #Mode_MASK
        orr        r1, r0, #Mode_IRQ | NOINT
        msr        cpsr_cxsf, r1                ; IRQMode
        ldr        sp, =IRQStack_PA            ; IRQStack

        bic        r0, r0, #Mode_MASK | NOINT
        orr        r1, r0, #Mode_SVC
        msr        cpsr_cxsf, r1                ; SVCMode
        ldr        sp, =SVCStack_PA            ; SVCStack

But as i see this sould be done already befor starting steploader...
anyway we could set stack again to this area when we are getting control from eboot.

Arg ^^ but no wonder. i see there are three startup.s. 1 for start all the hardware -> init stack is there. one for start from sleep reset stack is there and one for starting the kernel- > init stack is there. So it seems we need to init the stack before starting the kernel. so this seems to be okay. i ill just try this code this evening and see

I summed up the values in image_cfg.inc and git the following memory layout

Code:

0x50000000
to
0x60000000
is
complete ram DRAM_SIZE (256MB)
consists of:

0x50000000     BASE_ADRESSE
to
0x50020800    
is ??

0x50020800
to
0x5002A000
is IMAGE_SHARE_ARGS_OFFSET

0x5002A000
to
0x50030000
is ??    

0x50030000    
to
0x500B0000    
is EBOOT

0x500C0000
to
0x500F0000
is EBOOT BINFS BUFFER


0x500FDFB8
to
0x50100000
is
SVCStackSize    EQU    1024
UndefStackSize  EQU    256
AbortStackSize  EQU    256
IRQStackSize    EQU    256
FIQStackSize    EQU    256
in this order


0x50100000
to
0x53F00000
is NK AREA

0x54000000
Begin EBOOT USB BUFFER
size ??

from 0x50100000 on is our code, we should stick with this layout so that we know where what is. I think its not nice to search bugs which may occur when stack is overwritten
so from 0x50100000 - to end we need to place:
small bootcode <then> compressed kernel image <then> compressed initramdisk <then>
4mb space for extracted kernel image <then> space for extracted ramdisk

rest is to play with.

r3wDy,
i am aware that you guys are now trying to work further without wince api´s
but keep in mind wince is just mainly c coding, so if you are willing to use serial out for debug i am pretty sure c coding source will help you writing a script for activating it. Maybe i did not express wel.
ps about haret i ment the capabilities to use reverse enginering tools not *nix loader!

About drivers, true you can use android/*nix drivers from other project. that was why i pointed out to try the ce 6 core from a much liking device to see what it does. since it is ce it is the least work that needs to be done to get it loading.. and would be a nice breakthrough aswel.
keep in mind that driver for ex. cell will need to be compiled ourself, i guess it will hard to find one precompiled.

write a small bootloader for linux

i am not following , to replace eboot or to load from eboot?
if the last, you can just use uboot- or qi-git (i think qi will be better since it is a stripped loader)

Now since my knowledge about eboot/ce is limited i will use my knowledge on a better way:
since loading from eboot will be nice, it can be usefull one day to have the jtagging.

so..
m8se

6 pins on the left, 16 on the right (22 in total if counted well)
My guess here is the left is sim, right could be jtag.

M8

23 pins all in 1 group

So since i can not make a live check i need to trust on pictures, and they tell me the SE will be easiest to jtag, but we would like to do it on the normal m8.
so.. i will see if i can find a broken one for sale or so then i can use a heatgun to desolder the s3c610 cpu and follow the pads to trace jtag pins.
SMDK6410 whitepapers shows us where they are located so that can not be so hard to find out.
If i can not find a broken m8 i could try to find 1 real jtag pin and use this way of working :

In order to find out the test points leading to JTAG balls, I used a very small conductive wire, moved it under the PXA255 to one ball line which contains some JTAG related balls, made sure to keep the wire as much as possible in contact with all balls of that ball line (by pulling the wire tightly), then tried to do some resistance measurement against various test points nearby. When I got a winner (multimeter beeps), then I wrote down some note and then tried to verify later whether it actually is one of the JTAG pins by cross correlating with the 90 degree oriented ball line which also has that JTAG ball we suspect to be the one...
Unfortunately I wasn't able to identify too many JTAG test points that way...
Sure sounded much better than killing a whole Axim by de-microwaving a whole PXA255 Axim PCB, but it didn't help much.

ofcourse i firstly will need to eliminate the sim pins and unused or ground pins.
so if no one helps on it.. i hope to have my m8 back in about 2 weeks to get started with it.

so for now over and out

So i think i need to explain a little bit:
When eboot is done, it sets up some Memory Structures and jump right to the first byte of nk.exe (which is the loader for the windows kernel)
We are now at a point where we write our code to this point where eboot would jump if it would start windows. But is jumps to the first byte of our code, and so our code gets exceuted. Thats how we gained control over the device.
So there is no chance of using any windows api dll driver or whatever. We can use nothing but C and Arm Assembler Code.
(Thereforce no CE driver could help in any way, because CE Driverstructure can only be used by windows ce.)

To boot Linux the same has to be done.
Yu need to initialize a memory structure, disable some CPU featers (interrupts,MMU,Chacheing) and jump right to the adress in Ram where the first byte of the kernel sits. )This is the loader from which i talked not a bootloader just to initialize the kernel)
So the Linux kernel gets exceuted.

Yesterdy evening i tried to boot a linux kernel but the CPU halted on copy the kernel image to 0x54000000 (this is where i decided to put the kernel for testing). I couldnt even copy 1 byte to this location.

I think of a memory exception. I thought 0x50000000-0x60000000 (256 MB physical adressing) would be the RAM.
This leads me to the point that my assumptions about the memory layout are not perfect, or i need further code to initlitze the RAM completly. Another thing could be that the compiler always links code from core.dll to my executable (and as mentiond this is a nogo because there is not such a dll ).
I cant wait to get home to try another location to test this.


To the jtag thing: i alreday made test an could not find any connection from the pins to one of the sim card contacts.

And to:
keep in mind that driver for ex. cell will need to be compiled ourself, i guess it will hard to find one precompiled.
Never mind, im a software engeneer im am able to compile and write C Code. So this would not be the problem. I just work more in application development and are not a lowlvel hardware/driver developer so this is quite new to me. But anyway we are on a good way i think.

As i know banxian he will have a kernel up and running bevore im even able to test my memory layout

Meizu use a modified eboot (mzboot) to load their multi xip bin. if eboot found ROMHDR they will jump to the LoadAddress (LaunchAddr), or jump to BaseAddress (ImageStart) if there is no such one.
currently I use a magic jump (B LoadAddress) if entry point is not lower bound of input PE's sections.
surely if eboot detect power+music/volume key combine, firmware updater get booted.

PS: I produced a xip.bin with 80030000, and call someone in meizu to flash in to M8.
lucky after flash his M8 come to a stone.
but he can repair it himself refuse told me anything about Jtag defination.

bad news, I must rent a new house before 20 oct or lost residence, after rent I'll try to add ELF support into lite xip builder, and do more workaround than elf2flt to mix elf format loader/kernel with minimum rootfs can load from eboot run. the kernel can be treat as xip it self, and have overlay rootfs at tail, I can use symbol table to fill offset argument for rootfs back to flat binary of elf.
I got new SMDK and some modified busybox from aesop but I havn't time to test it in this week.

he can repair it himself refuse told me anything about Jtag

Mm good to know, but if this guy is chinese he could be working @ meizu :-) Can not see any reason why (s)he would not share it otherwise (unless it isnt true ofcourse)
Anyway allmost every phone has Jtag and i will find it!
So if any of you guys now where to find a broken m8 i am sure to desolder the chip if it takes to long finding it the hard way :P

Now it is been ages that i done finding JTAG pinout the hardway, so if anyone recalls it please share!!
i gues the m8 will have 8 pins or the minimum 4(?) needed to use jtag
One of them should be 3.3 volt (i thought) while m8 is booted,
TCK/TMS/TDI/TDO are between 35~100 ohm resistance if i recall correctly.
Most of the pins will be ground and should be easily eliminated (but needed ofcourse)

All the other details i will google again, cause it doesnt come at me for the moment

btw banxian , goodluck and lots of fun while moving out your current house;-)

i alreday made test an could not find any connection from the pins to one of the sim card contacts.

that is strange :s i would have been expecting that cause it oftens happens this way
Anyway did you manage to find by any chance a near 3.3 volt pin?
(for ground you could use the serial conenctor or battery pin '-' but you will now that i think!)

not a lowlvel hardware/driver developer so this is quite new to me

yes indeed do not worry to much about it, if a kernel mounts lots of users will be helping i think/hope.

So while Banxian is moving and r3wDy is testing alot and i have no m8 for the moment..
are there any other m8 users that own a multimeter and that are willing to help on the jtag?

Pleaseeeee???? (puppylooks)

some pins get 3.09 and some pins get 4.26 to ground. other pins havn't voltage.
I have Jlink v8 and Jtag slot for fly line, but I worried about I will just kill my JLink or M8 in some seconds.

I have only little to contribute =(
I could only find two possible candidates for the GND pin on the M8 SE

Both have zero resistance to the -pole.
Since i cant measure the voltages with the battery inserted and dont want to solder cables to my brand new phone i could not search the other pins, sorry.

banxian best wishes to you.
You will find a nice flat, just focus on that, the M8 can and will wait!
Winter is comming (to quote George R.R. Martin, house Stark)
If you live in Hamburg/Germany i will be happy to help moving!

Both have zero resistance to the -pole.
Since i cant measure the voltages with the battery inserted and dont want to solder cables to my brand new phone i could not search the other pins, sorry.

The phone will boot just with USb cable connected. Yu dont need a battery.
PS he looks for a flat in shanghai i think A littlebit away from hamburg

@banxian
I face problems with accessing const/static data in my programs because of adressing.
Because there is no MMU activitaded i think, no Virtual Adresses are usable.
Therefore our code runs from 0x50100000 and not 0x80100000. If i make an array (with kernelcode or sth) i crash the cpu when accessing it. Looked in IDA the data is placed @ 0x801xxxxxx. If i take a pointer to 0x501xxxxx i can access and get the right data. While for an array i can use the absolute adress in code (got from ida) i dont want to to this with every static/global var.
The first thing that came to my mind was: just base it @ 0x5000000 but you said flashing wrong could kill the phone. Do you think i could rebase the code to 0x5* ?
The other (hard way) would be enableing the MMU and virtual adressing, and map 0x5 to 0x8. The codes for this are in startup.s and should go nicely before stackinit i think.
Problem with this we cannot really debug anything :/.
This evening i will try to enable the mmu and see what happens

I dont know if we need a complete init of the MMU or if we just could turn it on. Anyway i will try both. The question is: What do we also need from startup.s? PLL/RLC/IRQ its all in there...
I try the mmu first and then well see

LOL i just got to compile the whole startup.s and its dependcies into an exe file. Just changed the CPU clock in defines to 666 (may i try 798 MHz?) and corrected the ram sized to 256.
Then i opend it in IDA and what i saw could be expected but i was suprised
Just the same Codestructure as in the beginings any of nk.exe
Look pretty good, i think this evenig i will intrgrate it in my loader and see if it worx. if it does i hope i can code just as normal. This would be a great help to bring linux up

Originally Posted by r3wDy

Therefore our code runs from 0x50100000 and not 0x80100000. If i make an array (with kernelcode or sth) i crash the cpu when accessing it. Looked in IDA the data is placed @ 0x801xxxxxx.

yes, so I use 50100800 from null space our xip.nb0 header.
I update MPack with this V/P fix but I can't post a link to public download now (because some code in heavy modify).
I'll send your a private build.

So ..since schematics are easier i made a quickdraw.
Let us label them 1 by 1

@banxian,
yeah, you better wait until you know more about the pins before damaging your hardware! Once you know something more you can try to hook it up.

@Loonix,
i was thinking the same thing that you confirm.
And every little part helps contributing, so thank you very much!

@r3wDy,
It seems that you are making a nice progress?!
Clocking the CPU higher will be nice to run everything smoother, but do not forget that it will drain battery faster end keep in mind we have no idea what the state of the 'cpu' is.
I mean Meizu could be the cheap-ass builder by buying cpu´s that can not run safely on the maximum frequency , maybe that is why the used a lower clocking to avoid overheating/cpu halts/...
But that is something we will know after experimenting ;-)

To all who is willing to help and search for jtag.

1/
First start by looking for the ground pins, that should be the most of them.
to find this : take a mutimeter and place it on resistance mode.
shorten your pins and take note of the reading on the display.
then plug one pin to the metal of the usb plug and an other to the pin you want to test. you will notice the display will provide you with other readings, use you knowledge and start poking those pins ;-)
2/
Do the same for the 6 sim pins it could be that they are mapped to the available pins..
3/
attach your usb cable for charging and boot m8 (just like r3wdy said)
switch your multimeter to voltage mode and write down the voltages.
Ofcourse it is obvious to use an earlier ground pin as "-" for this test..
4/
Now it is time to check resistance while m8 is on,
attach "-" to a ground pin, and the "+" at your pin you want to test..

So if you guys can test it and sum your findings that would be great (ps double results from different people is usefull to shorten human reading errors )

btw on pictures it seems that on m8SE pin 12 till 22 is connected with eachother, they could be ground.. for m8 i can not say anything cause i have no sharp pictures

Well, here are my measurements



and again as text
01: 2,85
02: 0,04
03: 0,04
04: 0,04
05: 0,01
06: 0,80
07: 4,13 - 4,16
08: 3,06
09: 0,00 (GND? )
10: 3,04
11: 0,00
12: 0,35 - 0,38
13: 0,16 - 0,19
14: 3,04
15: 0,15 - 0,19
16: 3,04
17: 0,17 - 0,19
18: 0,00
19: 0,00 (had written down a 3,04 first but may have ben misstaken)
20: 0,29 - 0,36
21: 0,00
22: GND? (<- this is the pin i measured from)

Thanks for your input Loonix!

May i ask you to measure once again but with the black pin from the multimeter ( "-" ) pushed against a screw or iron from the housing or the '-' side from the battery connector?
just to make sure that your ground is really the ground :-)

And when you are busy could you test the resistance (ohms) also?

Btw, i am thinking that the best moment to perform the test is while the m8 powers on, then there should be the peak moment..

And by any chance a user with a normal m8 could do this also?

Oww , does anyone knows a tool that could enable the jtag stream from wince core? That would make it easier to eliminate pins cause the reading mostlikely will change when they are active.

Nothing to contribute...
BUT I think you guys are SERIOUSLY CRAZY... and the Good kind
I say this with the utmost respect and admiration, the whole thread went above my head... could not even catch a single "1" or a "0"..

HATS off to you guys... MEIZU should follow this thread and send you guys money for doing all you guys are doing...

Again... You all are CRAZY.....

Thanks 919263,
and you are actually right, it is crazy.
buying an android phone would be easier, but this seems like so much more fun ;-)

I am just willing to point something out about the SE;
first is: i think it has an improved S3C6410 chipset.
second: about serial, it might help for ones with an se that want the serial output to be working; here you have the close-ups from the internals.
my point: se user will have it far more easier to track the pins, and it looks like the serial tx/rx is not been cute off, take a look in the right above corner


You will notice the coper leads towards the Chipset.
if you would zoom out the picture you would see the power pins go to right and the data pins to the left...

ps is that a battery in the right below corner? what would happen is..:P

@banxian, do you have an idea what type of jtag would be used by m8 ?

On a site (there where the smdk6410sdk resides link is here in forum) there is a jtag definition file from the smdk6410.

But thats not what i wanted to post. Im here to post really big things:

Uncompressing Linux............................................. ................
..........

crc error

-- System resetting

we are fucking close :P

PS this is a std. linuxkernel no android but this wont be the problem if we get it to run