release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Wiki > Main > MeizuM6Port (compare)

Difference: MeizuM6Port (r69 vs. r68)


Introduction

This is a port to a series of flash based player by Meizu (Chinese). The models are the "Mini Player" M6T1, M6TP, M6SP, M6SL, and the "Music Card" M3. There are actually two versions of M3: an earlier version using a Philips codec and a newer one using a Wolfson codec.


Hardware

Gathering information about the hardware is done by reverse engineering.

Type Chip M6 T1/TP M6 SP M6 SL M3
CPU Samsung SA58700 X X X X
SDRAM Samsung K4M28163PH (16MB) X X X X
Flash Memory Samsung/Hynix SLC Type X      
Samsung/Hynix MLC Type   X X X
Audio Codec Philips UDA1380HN X X   X
Wolfson WM8987     X X
FM Radio Sanyo LV24000 X X    
Philips TEA5760     X X
RTC Seiko Instruments S35390A ? X ? X
Sensor QUANTUM QT411 X X    
QUANTUM QT1106     X X
Power Management Linear Technology LTC3455 X X X X
LCD driver IC ??? X      
???   X    
S6D0139?   X X  
S6D0154?     X  
???     X  
???       X
???       X

M6 SP Schematic

We have M6 SP Schematic (Thanks to kgb2008)

There are two hardware revisions for the M3 and currently it is only known that they differ in the codec used. The old revision uses UDA1380HN (similar to M6 T1/TP/SP) and the new revision (starting from 10th March 2008) uses WM8987 (similar to the M6SL). Because of this, the new M3 is sometimes called "M3SL" on Chinese forums, although the official naming is still M3. As of June 2008, there are currently no take-apart pictures of the new M3, so we can't know which hardware other than the codec has actually changed.

Also, the LCD panels on the M6 and M3 have changed a few times. Users have reported different colour tints from two different M6 units with manufacturing dates differing by only a few months. Also, using an old OF version on a new M3 or a recently repaired M3 will render the screen unusable.

Port Status

The port is in a very early stage. These are the basic tasks which need to be done (not necessary in this order).

Task Done Who Comment
gather info about the hardware 90% kgb2008 mostly done, see MeizuReverseEngineering
add meizu skeleton to rockbox 90% markun  
compile the sim 70% markun no button mappings for plugins yet
button mappings for plugins 0%    
write and run some test code 0%    
write a DFU tool for linux 100% wpyh & gevaerts  
implement the drivers   anyone The drivers are specified below
compile the bootloader 0%    
compile rockbox 0%    
implement anything for which we used stubs 0%    

The following rockbox drivers need to be implemented for the Meizu series:

Driver Done Who Comment
LCD 50% ??? Works on M3. Beginning of an LCD driver for M6SP?.
Backlight 50% bertrik Works on M3, to be enabled and tested on other Meizus.
Buttons ? A-4  
ADC 90% bertrik Works for single A/D conversions.
NAND 0%    
USB 0% gevaerts?  
FM radio 50% markun both LV24000 and TEA5760UK. For the TEA5760, i2c bus communication works, tuning to a frequency and mute/unmute has been tested to work.
RTC 80% A-4 There is a driver now for the external S35390A? RTC (TODO: properly implement init sequence). The internal RTC is probably not used.
DMA 80% bertrik A simple DMA module has been coded (provides init/setup/start/callback/stop). Tested with PCM playback.
PCM 80% bertrik A looping audio sample can be played. Not completely tested.

Open challenges in more detail:

  • Bootloading system: Think of a way we could dualboot both the Meizu OF and Rockbox (probably needed in the near future because only the OF can safely write the NAND). The Meizu M3 has an 1MB NOR flash used to store the OF (about 600 kB actually) used, maybe we could squeeze a Rockbox bootloader next to it.
  • NAND driver: The Meizus use the WhimoryFTL which is currently not supported by Rockbox. Perhaps we can re-use code from openiboot? They seem to have a working (read-only) driver.
  • CPU boosting: Investigate a clocking scheme that allows simple and easy switching of the CPU frequency for high performance or low power consumption. For example 50 MHz idle and 200 MHz boosted. Take into account PCLK/HCLK/FCLK restrictions.
  • USB driver: The s5l8700 SoC in the Meizus seems to use the same USB controller as the TCC players for which there is already a driver in Rockbox. Look into re-using the tcc-usb.c driver.
  • Dual-codec support (M3): The meizu M3 models come with either a UDA1380 codec or a WM8987 codec. The OF seems to do some kind of detection at startup and contains code for both codecs. Should we try to support two codecs in one rockbox firmware too? Or make two builds for the Meizu M3 (one for each codec)?
  • UDA1380 codec cleanup (M3): the uda1380 code is shared with some iRiver players and seems to have some iRiver specific settings in it (for example using a PLL to recover a clock signal instead of simply using the clock signal directly from the CPU). This needs to be cleaned up so both kinds of players have optimum performance without complex code.
  • Button mapping (M3): The meizu M3 has no left/right buttons! What it does have: touch strip to slide up/down or tap (e.g. for select), menu button, play button, hold switch and a "<>" button (+touch sensitive).

The To Do List

We have a small To Do List created by Markun


Take-apart Pictures

Meizu M6 Pictures

More disassembly pictures here

Meizu M3 Pictures

There is an article showing the internals of the M3 compared to the iPod Nano 2G: http://www.meizu.com/support/articleread.asp?articleid=446


Forums


Firmware analysis

The firmware upgrade consists of two files: resource.bin and M6.EBN

resource.bin

This file is full of big-endian UTF-16 strings (strings -eb resource.bin). It probably contains other things like graphics.

M6.EBN

This file starts with some big-endian ARM code (arm-elf-objdump -b binary -m armv4 -EB -D M6.EBN). After 8KB there is a rar archive marker ("Rar!"). The rar file following this contains the file "Source/Blues_Dual_Lib_Data/SDRAM_SAMSUNG_DUAL/SDRAM_image.bin", which is a 1.3MB file with big-endian ARM code.

SDRAM_image.bin contains: "S5L8700 uCOSII with DOkdo FS", which seems to be μC/OS-II

This rar archive can only be created with an older version of WinRAR (http://www.meizume.com/firmware-m3/5241-m3-firmware-might-relevant-m6-too.html). Archives created using a newer version of WinRAR will brick the device. Fortunately, this is fixable using DFU (see below).

Official Firmware Strings

Here are some strings found in the original frimware.


Firmware Upgrade

Warning: After the update the player will format itself so save your data first.

  1. Hold "play" for 3 seconds to power on.
  2. Connect to the computer with the USB cable
  3. The computer will identify the player automatically as a removable disk
  4. Download the firmware upgrade from http://en.meizu.com/
  5. Decompress the downloaded file
  6. Copy "M6.EBN" and "resource.bin" to the root folder of the player
  7. Disconnect the player from the computer
  8. Hold "play" for 3 seconds to power off
  9. Hold "play" for 3 seconds to power on again
  10. The screen will show: "Upgrading Software, Please wait..." and after a while the player will shut down automatically
  11. Hold "play" for 3 seconds to power on. The player should now work again normally with the new firmware.

If the screen shows: "No Resource! Please Upgrade Resource Again!"

  1. Connect to the computer again and copy "resource.bin" to the root of the player
  2. Disconnect the player via safe disconnection
  3. Hold "play" for 3 seconds to power off, then power on again and now it should work again

Recovery mode (DFU)

Meizu has implemented the DFU protocol. In DFU mode it's possible to flash and recover from a bad firmware flash. For the Meizu's you can use Samsung's DFU Tools in Windows. In Linux it's possible to use the meizu_dfu tool which can be found in the rockbox source tree under utils/meizu_dfu.

To enter DFU mode:

  1. On M6 SP: Hold M and then press and hold power. On M3 and M6 SP: Hold M and then press and hold PLAY.
  2. Wait 2 seconds, then connect device to USB port.
  3. On M6 (both): Release the buttons. On M3: Keep M pressed but release PLAY (if you don't release PLAY the update might stop halfway, leaving the player in a state where you need to run down the battery before you can use DFU again)

To recover in DFU, 2 files must be sent. First the flash updater, then the firmware. The updater for for M6 SP and M3 is "SST39VF800.dfu", on the M6 SL it's "updateNAND_BE_070831.dfu".

DFU Procedure for M3, M6 TP, M6 SP and M6 SL

  1. GET_CPU
    • send usb control out with request = 255, value = 2, index = 0, length = 63
    • should return "S5L8700 Rev.1" (for M3, M6 TP and M6 SP) or "S5L8700 Rev.2" (for M6 SL)
  2. GET_CPU
    • send usb control out with request = 255, value = 2, index = 0, length = 63
    • should return "S5L8700 Rev.1" (for M3, M6 TP and M6 SP) or "S5L8700 Rev.2" (for M6 SL)
  3. SEND_FILE SST39VF800?.dfu (for M3, M6 TP and M6 SP) or updateNAND_BE_070831.dfu (for M6 SL)
    • check DFU signature at 0x20, then write file length + 16 after that (in little endian)
    • append the DFU suffix as specified in DFU specification version 1.0
      • the signature is "RON" for SST39VF800?.dfu
      • the signature is "UFD" for updateNAND_BE_070831.dfu
    • send file in 2048-byte chunks
      • this is done by sending usb control out with request = 1, value = (incremental index from 0), index = 0, length = 2048 or whatever's left
      • after sending the request, send DFU_GETSTATUS and loop until the state == 0x05
    • send usb control out with request = 1, value = (incremental index from 0), index = 0, length = 0
  4. SLEEP 1000
  5. DFU_CLEAR (not for M6 SL)
    • send DFU_GETSTATUS until state == 0x08
    • send DFU_CLRSTATUS
  6. GET_CPU
    • send usb control out with request = 255, value = 2, index = 0, length = 63
    • should return "S5L8700 Rev.1" (for M3, M6 TP and M6 SP) or "S5L8700 Rev.2" (for M6 SL)
  7. GET_CPU (only for M6 SL)
    • send usb control out with request = 255, value = 2, index = 0, length = 63
    • should return "S5L8700 Rev.2"
  8. SEND_FILE M3.EBN (for M3), M6.EBN (for M6 TP and M6 SP) or M6SL.EBN (for M6 SL)
    • check DFU signature at 0x20, then write file length + 16 after that (in little endian)
    • append the DFU suffix as specified in DFU specification version 1.0
    • send file in 2048-byte chunks
      • this is done by sending usb control out with request = 1, value = (incremental index from 0), index = 0, length = 2048 or whatever's left
      • after sending the request, send DFU_GETSTATUS and loop until the state == 0x05
    • send usb control out with request = 1, value = (incremental index from 0), index = 0, length = 0
  9. DFU_DETACH
    • send DFU_DETACH with value = 0, index = 3, length = 4
    • send DFU_DOWNLOAD with value = 16, index = 3, length = 0
    • send DFU_DETACH with value = 0, index = 3, length = 4, loop 5 times

There is also an open source tool called DFU-Util for the OpenMoko project. Unfortunately, this tool does not work unmodified with Meizu players.

Here's the full DFU spec


Links


CategoryFrontpage: Meizu M6 Port Index [New Ports]

IAttachmentActionSizeDateWhoComment
meizu_dfu.tar.bz2bz2meizu_dfu.tar.bz2manage 32.5 K 28 Aug 2008 - 03:56WilliamPoetra meizu dfu tool for linux

r71 - 09 Jun 2010 - 18:38:02 - BertrikSikken

Revision r69 - 08 Jun 2010 - 19:32 - BertrikSikken
Revision r68 - 01 Nov 2009 - 15:42 - BertrikSikken
Copyright by the contributing authors.