Meizu Pro 5 (meizu-turbo)

From postmarketOS
Revision as of 23:49, 18 December 2018 by Elelel (talk | contribs)
Jump to navigation Jump to search
Meizu Pro 5
[[|200px|alt=Meizu 5 Pro]]
Meizu 5 Pro
Manufacturer Meizu
Name Pro 5
Codename meizu-turbo
Released 2015
Category testing
Original software Android 5, Ubuntu Touch
Chipset Samsung Exynos 7420 Octa
CPU Octa-core (4x2.1 GHz Cortex-A57 & 4x1.5 GHz Cortex-A53)
GPU Mali-T760MP8
Display AMOLED, 16M colors
Storage 32GB/64GB
Memory 3GB/4GB
Architecture aarch64
USB Networking
3D Acceleration
Mobile data




How to enter flash mode

The device has to be with unlocked bootloader. Android phone version has bootloader locked by default. Locked bootloader may be unlocked with a Beta FlymeOS image for the international phone version. International firmware can be flashed to Chinese phone if one changes phone's id (possible with a 5.1.x Chinese firmware, root and a hex editor).

Press volume down and power while turning on to get into fastboot mode.


Current pmbootstrap utility assumes that boot partition is always named 'boot' on fastboot devices. This device's boot partition has 'bootimg' label. Because of that boot partition must be either flashed directly with fastboot utility, or pmbootstrap config source code has to be fixed.


Currently when turned on, the device enters reboot loop. USB networking workds, telnet debugging hook lets log in at early stage before the reboot. All steps from until switch_root when entered manually in telnet debug shell seem to work without problem. The display is not working - blank black screen. If provoked to display an early splash (e.g. no rootfs), a black image is displayed with white lines on the left and top borders, as if it is a part of zoomed in image. Turning on OpenRC logging does not produce any log files in /var/log on sysroot partition, which suggests that either switch_root and call to /sbin/init fails, or OpenRC fails on very early stage. The same result has been observed on a modified UBPorts kernel (currently in APKBUILD) and on faust98 kernel (see below), both compiled on GCC8 and GCC6.

If one tries to mount the system manually it reboots after "Populating /dev with existing devices through uevents" message:

# mount /dev/mapper/sda41p2 /sysroot
# mount -t proc proc /sysroot/proc
# mount -t sysfs sys /sysroot/sys
# chroot /sysroot
# touch .....runlevel
# /etc/init.d/devfs start
# ls /dev
  ... (long and legit output) ...
# openrc 
 * Mounting security filesystem ... [ ok ]
 * Mounting debug filesystem ... [ ok ]
 * Mounting config filesystem ... [ ok ]
 * Mounting fuse control filesystem ... [ ok ]
 * Mounting SELinux filesystem ... [ ok ]
 * Starting udev ... [ ok ]
 * Generating a rule to create a /dev/root symlink ... [ ok ]
 * Populating /dev with existing devices through uevents ... [ ok ]

Reboot is provoked by the following command called from "udev-trigger" OpenRC script:

udevadm trigger --type=devices --action=add

Eudev seem to suffer from this problem:

Development notes


There are several candidate kernels for the port:

  1. Official kernel sources
    1. Android branch. This branch seem to contain the very first kernel used for the earliest FlymeOS 4.x ROM. It is reported to be uncomplete, in particular, it misses Meizu proprietary sources for power management.
    2. Ubuntu branch. This branch seem to contain kernel actually used in more recent official Android releases (3.10.100) at least till commit f866ad068f11fb5e68ff87901346483945972ae9. After that Ubuntu-specific patches as well as generic bugfixes come.
    3. Android 7 kernel, not released. Kernels from previous two links were only used in very early official ROMs. Later kernel sources were not realeased. There is a Github issue requesting the release. Meizu is known to respond positively to such issues.
  2. Unofficial sources
    1. UBPorts kernel. Based on Meizu Pro 5 branch. Contains Ubuntu Touch fixes and ports, mainly Android binder and anbox-specific patches.
    2. faust93's kernel. Kernel used in at least two unofficial Android roms. This kernel, probably based on CM14.1, seems to be most up to date candidate, but contains a lot of patches from assorted sources and may be not very stable

See also

Initial merge request