I just got my Nexus 5x in! I've never developed for Android before, so this is all a new experience for me. I managed to get a 6.0.1_r30 generic arm build compiled (forgot to `lunch` for bullhead), so I know my environment is finally sane. However, I'd like to get some clarification on the Snapdragon 808.
I know the Snapdragon 808 is based on the ARMv8-a architecture, which means that it should, in theory, be both arm and arm64 compatible. And, from the look of devices/lge/bullhead/BoardConfig.mk, it appears that the default kernel is dual-arch arm and arm64. However, the primary arch is arm64. I'd like to attempt to build a kernel that's arm (armv7-a-neon) only. You might ask, "Why would you want to do that?" Well, I would like to build Ubuntu Touch for the device. Ubuntu touch is using the KitKat dev tree, so is only 32-bit compatible. Attempts to expand the KitKat tree with an arm64 cross-compilation toolchain were fruitless after spending countless hours attempting it.
At this point, I don't even know if it's worth trying for a couple of reasons:
Hardware drivers are Lollipop, Ubuntu Touch is KitKat
I don't know if ARMv8-a will boot a 32-bit kernel out-right or it has to start in 64-bit mode and drop to 32-bit (if that's the case, would the kernel know to do that? Or does the CPU start in 32 bit mode and bump up to 64 bit mode)?
It's probably pretty unlikely that dropping in a pre-built Lollipop kernel into the Ubuntu Touch dev tree would work -- different ABI's (That's the ever-changing kernel/Android-specific API/syscalls, right?)
So, I'm looking for some help clarifying any of these issues. Is there anybody here really familiar with ARM that could answer these questions? Heck, if these are non-issues, I might even attempt a build.
Related
Hey all. Ever since I learned about the ZF2 and it running on an Intel CPU/SoC vs a typical ARMv7 or ARMv9-based CPU/SoC this idea came to mind. Would it possible to develop a pure Linux (non-Android) based OS/ROM for this device? I run Funtoo Linux (a Gentoo derivative) on one of my desktops and now on a laptop I'm sharing with my brother, and it works great. Having this (or something Ubuntu-based to ease on pkg installs via binaries vs compiling from source for everything) on a phone this powerful would be awesome as well. Besides drivers for baseband / bootloader (of which I know is currently locked at the moment I'm posting this thread) how difficult would this be to accomplish? Does this device boot with EFI? I'd think compiling a kernel for it would be easier than a typical Android kernel since Intel spec is easier to compile for... I'm no developer, but that's my take on it.
Thoughts?
I know with the bootloader unlocked theoretically any kernel built for the device should boot, but are there any specific requirements? Size, certain files, etc? I tried packing the stock Linux kernel and initramfs into a boot.img and it wouldn't boot, so I was looking for suggestions on what may be going wrong. Thanks!
http://forum.xda-developers.com/zenfone2/development/tool-zenfone-2-boot-repack-t3146088
sorg said:
http://forum.xda-developers.com/zenfone2/development/tool-zenfone-2-boot-repack-t3146088
Click to expand...
Click to collapse
I've noticed that, but thanks for the reference
I don't want to repack a stock ZF2 kernel, I want to pack an Arch Linux kernel and an initramfs
Jhdoubleoseven said:
I've noticed that, but thanks for the reference
I don't want to repack a stock ZF2 kernel, I want to pack an Arch Linux kernel and an initramfs
Click to expand...
Click to collapse
You need to compile Arch Linux kernel for Moorefield platform. If Arch Linux provides such hardware config, then it can boot.
Generally speaking, ASUS provides source code for Linux kernel already. So, you can tweak config to Ach Linux requirements, or port hardware specific patches to Arch Linux kernel.
I don't know about your experience, but porting Linux kernel for non-supported platform (i believe Arch Linux doesn't know about Moorefield Z35xx) is not trivial.
Jhdoubleoseven said:
I know with the bootloader unlocked theoretically any kernel built for the device should boot, but are there any specific requirements? Size, certain files, etc? I tried packing the stock Linux kernel and initramfs into a boot.img and it wouldn't boot, so I was looking for suggestions on what may be going wrong. Thanks!
Click to expand...
Click to collapse
One addition to sorg's post:
The size of the whole boot.img must not exceed 16MB, also make sure to include as much from stock initrd as possible: init, init.rcs, binaries in sbin, etc.
If you compile the drivers directly into the kernel, then you don't need the .ko files in the lib/modules folder, making your ramdisk size smaller (by a great degree).
Cheers
[deleted]
sorg said:
You need to compile Arch Linux kernel for Moorefield platform. If Arch Linux provides such hardware config, then it can boot.
Generally speaking, ASUS provides source code for Linux kernel already. So, you can tweak config to Ach Linux requirements, or port hardware specific patches to Arch Linux kernel.
I don't know about your experience, but porting Linux kernel for non-supported platform (i believe Arch Linux doesn't know about Moorefield Z35xx) is not trivial.
Click to expand...
Click to collapse
Ah, thank you very much! Now I'm curious though, the stock Arch kernel is compiled for generic x86-64 processors so why does it need to be platform-specific? I run the linux-ck-core2 kernel which is specifically compiled for the core2 processor series, but the generic one works fine as well on my laptop.
TheSSJ said:
One addition to sorg's post:
The size of the whole boot.img must not exceed 16MB, also make sure to include as much from stock initrd as possible: init, init.rcs, binaries in sbin, etc.
If you compile the drivers directly into the kernel, then you don't need the .ko files in the lib/modules folder, making your ramdisk size smaller (by a great degree).
Cheers
Click to expand...
Click to collapse
Thank you very much! Very helpful info
So you suggest modifying the stock initramfs to then start Arch? Arch uses systemd so I will probably need to figure out what exactly the stock one does so I know where to give it Arch-specific instructions.
Also, do you think the drivers would work with a newer kernel? Would I need to compile them into 3.10 or if I used the latest 4.1 or so do you think it could work?
Never played too much with kernel hacking so I definitely can get some great experience here! Thanks!
Jhdoubleoseven said:
Ah, thank you very much! Now I'm curious though, the stock Arch kernel is compiled for generic x86-64 processors so why does it need to be platform-specific? I run the linux-ck-core2 kernel which is specifically compiled for the core2 processor series, but the generic one works fine as well on my laptop.
Click to expand...
Click to collapse
x86 is only op.code standard - that's all.
Moorefield Z35xx SoC is like all-in-one PC with many devices inside, not just CPU. And every device requires specific driver. There are some devices in Z35xx are very specific and not supported by generic PC drivers.
Also, Z35xx has neither BIOS, nor UEFI. It has SFI which is not used in PC. Kernel has to have support booting process and parsing SFI tables (like PC parses ACPI tables) to get info about connected devices and their resources.
This is just brief platform differences (comparing to standard PC) overview. And you may find more differences if you will study the Moorefield platform.
So if my understanding is correct, Ubuntu Touch was at it's core Ubuntu on top of the android OpenGL ES2.0 HAL and drivers, stagefright, RILD, and Android HAl for camera and imagge processing. Am I correct so far? If so, would it be possible to build another operating system off this platform say Arch for example, locate/code the apps needed to access radios, and then have a full linux distro in your pocket? I'm asking this because I want more from my device (Nexus 6, Nexus 7 2013, and Zenfone2) Are any projects similar to this already in development?
Has anyone managed a 32bit build of the latest aosp and got it to actually boot? Am currently stuck on the android boot screen
We have a 64 bit phone. Why are you attempting to use the 32 bit build?
hopesrequiem said:
We have a 64 bit phone. Why are you attempting to use the 32 bit build?
Click to expand...
Click to collapse
I need a 32bit aosp or cm13 so I can build Sailfish on top of it.
I tried compiling a 32bit aosp and stole vendor binaries from the nexus 5 for 32bit, but I can't get surfaceflinger to do anything aside from getting stuck on boot animation.
now am trying to build cm13 with FORCE_32BIT flag in BoardConfig like I saw somewhere else.
Also since this phone is a dual cpu, it has both libs 32/64 so its not an issue there.
m4r0v3r said:
I need a 32bit aosp or cm13 so I can build Sailfish on top of it.
I tried compiling a 32bit aosp and stole vendor binaries from the nexus 5 for 32bit, but I can't get surfaceflinger to do anything aside from getting stuck on boot animation.
now am trying to build cm13 with FORCE_32BIT flag in BoardConfig like I saw somewhere else.
Also since this phone is a dual cpu, it has both libs 32/64 so its not an issue there.
Click to expand...
Click to collapse
I highly doubt that you'll ever really get this to work. Even if you did get a 32-bit system image onto the device, there won't be any drivers since they'll have been compiled for AArch64.
Correct me if I'm wrong.
davidc14 said:
I highly doubt that you'll ever really get this to work. Even if you did get a 32-bit system image onto the device, there won't be any drivers since they'll have been compiled for AArch64.
Correct me if I'm wrong.
Click to expand...
Click to collapse
I think your slightly wrong. See the Nexus 5x has 2 cpus, not both are AArch64. So the vendor partition has both 32bit and 64bit libs.
Also 64bit cpus are generally backwards compatible with 32bit
m4r0v3r said:
I think your slightly wrong. See the Nexus 5x has 2 cpus, not both are AArch64. So the vendor partition has both 32bit and 64bit libs.
Also 64bit cpus are generally backwards compatible with 32bit
Click to expand...
Click to collapse
Well, no it doesn't have two CPUs. It has six cores on one SoC. It has four Cortex A53 cores and two Cortex A57 cores. You can see this by googling: snapdragon 808. Qualcomm's page details it.
You can see from ARM's specifications that both types of core are ARMv8-a AArch64 cores, which are 64-bit (hence AArch64). You're right that they include AArch32 ARMv7-a compatibility, as they have to for backwards compatibility. But I don't think Google or Qualcomm will have written any 32-bit drivers for the various radios, and GPU, etc on the device. So I don't think you'll get a 32-bit Android rom working on the 5X.
davidc14 said:
Well, no it doesn't have two CPUs. It has six cores on one SoC. It has four Cortex A53 cores and two Cortex A57 cores. You can see this by googling: snapdragon 808. Qualcomm's page details it.
You can see from ARM's specifications that both types of core are ARMv8-a AArch64 cores, which are 64-bit (hence AArch64). You're right that they include AArch32 ARMv7-a compatibility, as they have to for backwards compatibility. But I don't think Google or Qualcomm will have written any 32-bit drivers for the various radios, and GPU, etc on the device. So I don't think you'll get a 32-bit Android rom working on the 5X.
Click to expand...
Click to collapse
Hmm you might be right here, although the vendor partition seems to include identical lib and lib64 shared libs. I'll have to do more digging. The only other solution is to build sailfish 64bit but I don't think such a thing exists :'(
edit:
after digging around the vendor partition it seems theres both 32bit and 64bit binaries.
Because 64bit is a mixed bag, its not all positive. 64bit adrees space has much bigger memory footprint (64bit pointers etc)
I've been trying to update the kernel version on the HD 10 Suez 2017. I am using the sources from this link https://github.com/chaosmaster/android_kernel_amazon_suez/tree/lineage-16.0 on the master Branch I cannot get the the device to boot when building a kernel. However if I use the Android 16 branch, I can get the device to boot but I have an irregularity that I cannot seem to figure out. The screen will go black. It doesn't turn off it just goes black that's if you stop touching the screen or you stop moving the device. aside from that I have not been able to see if anything else is affected but I can get the kernel versions updated at least two 3.18.22 but I haven't continue further because of this the weirdness. I have not tried any other sources as of the moment but was wondering if anybody is run into this problem.
Would this help at all? It’s the googlesource for MTK kernel 3.18
Have you tried building lineage 17 or 18 yet?
https://android.googlesource.com/kernel/mediatek/
https://www.xda-developers.com/alldocube-x-10-5-inch-android-8-1-oreo/
Mt8176 running Oreo 8.1. Supposedly project treble compatable too. Could this mean 8.1 for the HD10 and/or treble support too?
Fix MediaTek no display bug
MediaTek has a family of SoCs that are used in (among other devices) several Chromebooks, such as the MT8173 used in the Lenovo N23 Chromebook and Acer Chromebook R13, plus the MT8183 in the Lenovo IdeaPad Duet Chromebook. We are working hard to have better upstream support for these devices, especially Enric Balletbo, who has been involved in kernel and Chromebook upstream support for a long time. The displays on MT8173 based devices were not functional when using the mainline kernel, this has been rectified with this kernel release.
The cause of this defect was a conflict between the clock and DRM drivers. He found that two different drivers - the MT8173 clocks controller driver, and the MT8173 DRM driver were using the same compatible string mediatek,mt8173-mmsys. This is a problem since in such cases only the first matched driver will be probed. The other one, in this case the DRM driver, never gets probed and so the display was not made available for use. In a collaborative effort between Enric Balletbo and the MediaTek SoC maintainer Matthias Brugger, a top level mmsys driver (Multi-Media subsystem) was introduced to register the clock and DRM drivers. See 1, 2.
Linux 5.8 probably fixed your display bug. What is the chance of moving this tablet up to android 10/11?
source:
https://www.collabora.com/news-and-blog/news-and-events/kernel-5.8.html