Meizu M6 "miniplayer"

[tonghuren]

I have got the source files, but i don't have the complier on my PC.So, can somebody tell me where I can download the rockboot.ebn?If you have already got one,can you send it to me?I'm using M6SP.

[bertrik]

The rockboot.ebn file is created when compiling the meizu bootloader. I can't really explain the entire building/compiling process here, but please have a look at the rockbox wiki pages on development, for example http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide

[bertrik]

Update on the Meizu M3:
We have audio out working with DMA-driven PCM. We can't access the NAND flash yet, so the first sound was done by compiling a 2-second audio clip directly into the bootloader. The uda1380 audio codec driver could be re-used from the iriver Hxxx port, but this driver will need some modification to properly work with the meizus (there are some differences in use of the MCLK clock signal for example).
FM radio can now also be controlled, again from the bootloader only for now.
The PCM can be easily enabled for the M6's too, the fm radio can be enabled for the M6SL only (the M6SP has a different FM chip).

The clean parts of this have been committed to SVN. To actually hear audio or control the fm radio on the M3, some hacks are needed that are not in a committable state yet. If people want to play with this, just let me know and I can make a patch that includes these hacks.

[paul356]

Hey, guys. It seems that this post haven't been updated for a long time. I hope people won't give hope for rockbox port on m6 series.
I request somebody who can run test code on m6sl to share your rockboot.ebn file with me. I really don't know why I can't run the test code on my m6sl, because I should be able to toggle the backlight if the code is run. I couldn't help to doubt that my cross-complier is not correctly built.

PS: I assume that the test code is run by replacing the firmware updating code. And the firmware update code is the first image file sent by the DFU tool during the normal DFU process. So our test code should be run just after the player accepting the first rockboot.ebn file. Do I need to reset the my player after that? Do I miss some thing?

[bertrik]

Last weekend I was able to display a rockbox logo on my Meizu M6 SP. Unfortunately there is a spurious yellow line at the bottom of the screen (looks like part of the logo) and the player hangs after displaying the image. Probably the next thing will be enabling the SDRAM on the M6SP.

In principe it should be possible to run things directly from RAM in DFU mode, but I haven't been able to make that work on the SP yet (it did work on the Samsung YP-S3 which has the same SoC, using the M6SL DFU method). So I'm still running all test code from NOR flash now.

[MartyLK]

Does anybody have a link to the latest M6SL firmware? I can't find it on the official site and the forum doesn't even show M6 anymore.

[bertrik]

Small status update: I am now able to access the DRAM on the M6SP, I'll commit the change this weekend.
The hang after displaying the rockbox logo still puzzles me, the player seems to hang right after configuring the PCON_ASRAM register that controls the function of the pins used to interface with the LCD.

I think Meizu firmwares can still be found on the meizume forums.

[Ray Wong]

Does anybody have a link to the latest M6SL firmware? I can't find it on the official site and the forum doesn't even show M6 anymore.

http://www.meizu.com/MeizuMp3LiveUpdate/Firmware/M6/2_0_0_4/M6_SL2.004.6.rar

here it is.
meizu  m6 is replaced by meizu m8 phone ..

[PMP]

 

here is TP 2.004.6


http://rapidshare.com/files/307287039/meiau_mptp_fwt200046.zip.html

http://rapidshare.com/files/307287039/meiau_mptp_fwt200046.zip.html?killcode=419665503292886340

SP   s2.004.6

http://rapidshare.com/files/307292769/meiau_mpsp_fws200046.zip.html

http://rapidshare.com/files/307292769/meiau_mpsp_fws200046.zip.html?killcode=5786242892350135964

Music Card T2.004.6

http://www.meizu.com/MeizuMp3LiveUpdate/Firmware/M3/2_0_0_4/M3_T2004.6.rar


I hope you won‘t give up  MEIZU   M3

[bertrik]

SDRAM now seems to work on the Meizu M3 too (haven't tested it extensively though).

Also, I got some more insight on how the DFU mode works on the M3 and M6SP: the image that is sent in DFU mode is not a full RAM executable, but a kind of flash-loader plugin, with a couple of basic flash functions, like flash identification, device erase, block erase and flash write. There is a possibility that this mode can be exploited to write a kind of RAM-loader (as opposed to a flash loader), that can be used to bootload the main rockbox executable.

[PMP]

hope those thing can hlpe


we are a bunch of meizu m6 [tp, sp sl,ts] ,m3[sp,se] woners,
we are looking forward to use ROCKBOX firmware for ages.
By any chance, if we can help to test firmware, we wounld be very glad


http://pmp.5d6d.com/thread-329-1-3.html

http://pmp.5d6d.com/thread-330-1-3.html

[paul356]

Hi guys. Finally I can toggle the back-light of m6sl using the bootloader generated by the rockbox project. This is achieved by modifying boot.lds and crt0.S in folder $ROCKBOX_HOME/firmware/target/arm/s5l8700. It seems that .text section and .rodata is mapped onto flash. During DFU process the flash is not accessible so we need to modify the boot.lds. I don't know modifying crt0.S is necessary or not, because I haven't test this new boot.lds with the current crt0.S file. I hope this will help guys want to get some reaction from the m6sl, though this task is so simple for these experienced developers.

PS: .txt is added to the two file name because this forum doesn't support uploading .S and .lds files.

[saratoga]

PS: .txt is added to the two file name because this forum doesn't support uploading .S and .lds files.

Thats a subtle way of reminding you not to post code to this thread, and instead submit patches to the tracker where they won't get lost. 

[paul356]

Hello, guys. Now I am trying to understand the disassembled code. Because I am a newbie for embeded systems, I have diffcult to understand following code located in M6SL.ebn, offset 0x8578:

Code: [Select]

RAM:22008578                 LDR     R1, =0xFFF
RAM:2200857C                 AND     R1, PC, R1
RAM:22008580                 ADD     PC, R0, R1

It seems that the arm code should be aligned to 4 bytes. But after executing these code the arm processer PC will have an odd address of 0x**009583. So I am puzzled. Is this code meant to incur some sort of exception?

[saratoga]

I'm not much good at arm, but it looks to me like that code just jumps ahead to the nearest 4KB boundary (address that ends in 1+0xFFF), so its probably just trying to align a code block with a page boundary.