meizu-turbo: Add Meizu Pro 5 'turbo' device
Add Meizu Pro 5 'turbo' device. The device boots till USB networking.
Merge request reports
Activity
@elelel I noticed that your device uses UFS storage, and both this thread and this thread seems to suggest that it has 4096 byte sectors instead of the normal 512 byte sector. Could that be what's preventing it from mounting the root filesystem?
I ported a device that uses 4096 byte sectors (google-crosshatch), and I had to add
deviceinfo_rootfs_image_sector_size="4096"to the deviceinfo. Maybe your device needs the same option.To see if this would help, you can run
fdisk -lin telnet and see if the output says
Note: sector size is 4096 (not 512). If that displays, try adding the sector size option to the deviceinfo, rebuild, and reflash the root fs.By Zhuowei Zhang on 2018-12-16T18:23:01
-
Too bad, that the official repository doesn't offer a full git history.
According to discussions on xda (e.g. https://forum.xda-developers.com/meizu-pro-5/development/ultimate-pro-5-kernel-t3310311) the official kernel sources are incomplete. Perhaps they tried to exclude their modificiations while keep appearing as if they're complying with GPL by releasing at least something. It may imply that using the official kernel source release comes with the same problems as with any other unofficial source code recompilation.
I've looked at the repositories, and would go with the official one, with the master branch.
I've examined the official branches and it seems that master branch uses and older Android kernel version, while Ubuntu branch, though named Ubuntu is actually pure newer Android kernel up to a certain commit. If choosing between two, I would think official Ubuntu branch till the first Ubuntu commit is more appropriate.
If these two are the same as the ones we have here...
One of these patches is used in the way you describe in my build. The two patches I was talking about come from kernel.org lists. I can include them as separate patch files.
In any case, I can't get the device to get through switch_root step. Maybe it's kernel-related, I will try kernels from unofficial ROMs and if it helps, use them directly as kernel source. I've updated the wiki with kernel candidates overview.
By elelel on 2018-12-18T15:09:00
Edited by Administrator -
@zhuowei that's a great kernel debugging tip, shouldn't it be added here https://wiki.postmarketos.org/wiki/Troubleshooting:boot ? I'll try that out and post the results. Previously with other method I identified a problem with a binary eudev package which tries to execute arm32 syscall though it is supposed to be an aarch64 package. I documented this error on device's wiki page ( https://wiki.postmarketos.org/wiki/Meizu_Pro_5_(meizu-turbo) ). Here's the related issue I posted: https://gitlab.com/postmarketOS/pmbootstrap/issues/1706
By elelel on 2018-12-19T07:36:02
-
@elelel I'm not sure that's causing this issue: my device (google-crosshatch) is also aarch64 (using a 4.9 kernel), and udev works fine there. (Its kernel only has 291 syscalls, so it's not just executing some random syscall and ignoring it)
I did search for last_kmsg on the Wiki: it's mentioned on some pages, but not the troubleshoot page. Would you like to add it?
By Zhuowei Zhang on 2018-12-19T07:44:41
-
@zhuowei
I'm not sure that's causing this issue: my device (google-crosshatch) is also aarch64 (using a 4.9 kernel), and udev works fine there. (Its kernel only has 291 syscalls, so it's not just executing some random syscall and ignoring it)
My guess the problem is not that eudev is just not executing some syscalls, but that it in general gets compiled as arm32, instead of aarch64. It seems either to be compiled with arm C preprocessor macro defined instead of aarch64, from an old eudev source. So it would be good to know, how PostmarketOS packages get compiled in general (I'm new to Alpine/PmOs and could not find that on wiki).
The paricular syscall in question is sys_getrandom, which is not in Kernel's headers until 3.18. All the kernels for the device available to me are some flavors of 3.10.x. Eudev sources contain a workaround for kernels without the needed syscall constant, relying on defining the particular syscall number in their sources. Even if the syscall is not known for my kernel, the question why eudev uses constant for arm32 from it's workaround ifdefs instead of aarc64 remains.
A way to find what exactly causes the reboot is to recompile eudev with some debugging to further locate the problem, since it's known that the bug is provoked by 'udevadm trigger --type=devices --action=add' command.
You may want to try immediately entering flash mode after the reboot, boot a custom recovery such as TWRP, then read /proc/last_kmsg or /sys/fs/pstore/console-ramoops to see what caused the reboot.
There are two problems with that: I could not get there immediately (I'm not sure if my pressing the buttons is in time) and there's no /proc/last_kmsg or /sys/fs/pstore on my device's TWRP.
Would you like to add it?
I would if I could produce the steps on my device.
By elelel on 2018-12-19T15:12:26
Edited by Administrator -
So it would be good to know, how PostmarketOS packages get compiled in general (I'm new to Alpine/PmOs and could not find that on wiki).
postmarketOS packages get compiled with
pmbootstrap, which creates chroots and then runs Alpine'sabuildinside the chroots to actually build the package (you can see the abuild command inpmbootstrap log). Alpine's packages are directly built withabuild(more).The package build recipes are here:
The paricular syscall in question is sys_getrandom, which is not in Kernel's headers until 3.18. All the kernels for the device available to me are some flavors of 3.10.x. Eudev sources contain a workaround for kernels without the needed syscall constant, relying on defining the particular syscall number in their sources. Even if the syscall is not known for my kernel, the question why eudev uses constant for arm32 from it's workaround ifdefs instead of aarc64 remains.
I can't answer that, but how about backporting the getrandom syscall as done in !69 (merged)?
By Oliver Smith on 2018-12-20T06:06:59
mentioned in commit wiki@1b7ed0af
By postmarketOS Wiki bot on 2018-12-20T06:42:37
-
@elelel Re pstore: Maybe TWRP doesn't have pstore enabled in kernel config? Some of Meizu's defconfigs don't have it enabled. Your kernel config seems to have it(
CONFIG_PSTORE_RAM=y); maybe- reboot back into pmOS's kernel after the crash, and connect to the telnet debug shell
- mount pstore (
mount -t pstore /sys/fs/pstore /sys/fs/pstore, see https://mjg59.dreamwidth.org/23554.html) - check /sys/fs/pstore using the debug-hook's USB networking telnet shell.
If the kernel panicked, there may be a log there.
See Halium's guide for more info.
By Zhuowei Zhang on 2018-12-20T06:47:28
-
I've managed to get SSH by commenting out the line:
udevadm trigger --type=devices --action=addin /etc/init.d/udev-trigger script.The device boots to UI if udevadm does not send add uevent to the following devices:
/sys/devices/152e0000.mfc0/video4linux/video6/uevent /sys/devices/152e0000.mfc0/video4linux/video7/uevent /sys/devices/152e0000.mfc0/video4linux/video8/uevent /sys/devices/14370000.fimc_is/video4linux/video130/uevent /sys/devices/14370000.fimc_is/video4linux/video131/uevent /sys/devices/14370000.fimc_is/video4linux/video132/uevent /sys/devices/14370000.fimc_is/video4linux/video140/uevent /sys/devices/14370000.fimc_is/video4linux/video141/uevent /sys/devices/14370000.fimc_is/video4linux/video142/uevent /sys/devices/14370000.fimc_is/video4linux/video150/uevent /sys/devices/14370000.fimc_is/video4linux/video152/uevent...AND if before sending add uevent to devices with video4linux in path is prepended with 300ms pause. Achieved that by patching eudev, this makes init.d/udev-trigger.sh script work without modifications. Still need to figure out how to do that in less intrusive way.
By elelel on 2018-12-28T20:39:48
Edited by Administrator -
Great work @elelel!
Regarding the video4linux problems, try to add this to the
package()function of your device package:# Disable v4l (video4linux), because without the camera firmware # blobs this makes dev hang with the kernel this device uses (#1033) ln -s /dev/null "$pkgdir"/etc/udev/rules.d/60-persistent-v4l.rulesWe did that successfully to quite a few devices with a similar error here.
I've examined the official branches and it seems that master branch uses and older Android kernel version, while Ubuntu branch, though named Ubuntu is actually pure newer Android kernel up to a certain commit. If choosing between two, I would think official Ubuntu branch till the first Ubuntu commit is more appropriate.
If these two are the same as the ones we have here...
One of these patches is used in the way you describe in my build. The two patches I was talking about come from kernel.org lists. I can include them as separate patch files.
Would you like to switch the kernel sources as described above, so this can be merged?
By Oliver Smith on 2019-01-10T22:14:16