Related
Lately... I've been trying to port CWM/TWRP onto a generic device based on the MSM8926 chipset. I have researched and found the proper recovery.fstab mount points and flags but my problem now is how to reference in my device tree the qcom platform. According to master carliv, he said that I have absolutely no reference in my device tree to the qcom(qualcomm) platform, and all android sources have specific requests for qcom devices. So this is where I'm currently stuck at. I have absolutely no idea on how to reference the qcom platform nor even know what to download(like proprietary software needed to create CWM/TWRP). Could someone please guide me on this? I have no experience whatsoever in referencing the qcom platform or even knowing how to download the proprietary software from the phone itself. I've also tried snooping around in CAF(Code Aurora Forum) to find the kernel tag of my phone which would probably be:
Code:
May 07, 2014 LNX.LA.3.5.2.1-02910-8x26.0 msm8226 LNX.LA.3.5.2.1-02910-8x26.0.xml 04.04.02
^ Since I looked at the kernel version for my phone which is
Code:
[email protected] #1 Wed May 7 00:24:52 CST 2014
. I assumed that the kernel's build date is the same as the ones written in CAF except I need to find which platform the kernel was made for and closest platform was MSM8226 which is kinda weird that the phone's build.prop shows that the flattened device tree it has used is MSM8226 rather than using MSM8926.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Bootimage ADB Unsecure Patcher
Android Bootimage ADB Unsecure Patcher is made to ease the development of ROMs.
Its purpose is to modify the ramdisk to set ADB into an unsecure mode,
in order to debug Android ROMs on clean / bringup boots without doing an 'eng' build.
It means adb can be used without any permissions to run logcat or other commands.
The project implements the logic from the MultiROM injection (originally by Tasssadar),
finds the bootimage of your device (boot naming similar to Chainfire's boot detection),
and applies the needed modifications to the ramdisk's default.prop configurations.
The objective of Bootimage ADB Unsecure Patcher is therefore to simply enable unsecure adb
on a regular ROM's bootimage for developers and users who would require it.
Developers no longer need to recompile a bootimage or full ROM with 'eng' pressets,
nor do users need to edit their bootimages with unsecure adb settings if they really need it.
The patcher needs to be flashed again after a ROM / bootimage update.
This is originally based on my bootimagedebuggable function from android_development_shell_tools.
The project also uses my version of libbootimg to support Sony ELF bootimages.
Bootimage Debug Addition Patcher
Another part was added to this project: Bootimage Debug Addition allows developers
to debug unbootable Android builds by providing the following items:
Complete logcat service to /data/debug.logcat.txt
Kernel messages exported to /data/debug.kernel.txt
Runtime properties to /data/debug.properties.txt
Detailed tree of / to /data/debug.roottree.txt
Rebooting to recovery and reading the file contents can help resolving issues rather than guessing.
The patcher is called "bootimage_debug_addition", while the revert is called "bootimage_debug_removal".
For builds running with enforced sepolicies, you might need to flash Universal Kernel Permissive Patcher too.
Downloads (Unlocked Bootloader only)
bootimage_adb_secure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_secure.zip
bootimage_adb_unsecure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_unsecure.zip
bootimage_debug_addition.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_addition.zip
bootimage_debug_removal.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_removal.zip
Other related useful projects
Universal Kernel Permissive Patcher - http://forum.xda-developers.com/-/-t3506338
Source code
Project sources - https://github.com/AdrianDC/bootimage_adb_patcher (branch master)
libbootimg sources - https://github.com/multirom-dev/libbootimg (branch master)
Bootimage ADB Unsecure Patcher created also thanks to :
- Tasssadar for the original MultiROM sources
- The MultiROM-Dev team for our evolution of MultiROM
- Chainfire for the boot detection
- Everyone involved in testing it
XDA:DevDB Information
Bootimage ADB Unsecure Patcher, Tool/Utility for the Android General
Contributors
AdrianDC
Version Information
Status: No Longer Updated
Created 2017-06-07
Last Updated 2019-08-06
Reserved
Changelog
Code:
Bootimage Debug Addition Patcher - 12/06/2017
===========================================
* Complete logcat service to /data/debug.logcat.txt
* Kernel messages exported to /data/debug.kernel.txt
* Runtime properties to /data/debug.properties.txt
* Detailed tree of / to /data/debug.roottree.txt
Bootimage Debug Addition Patcher - 11/06/2017
===========================================
* Initial public release on XDA
Bootimage ADB Unsecure Patcher - 11/06/2017
===========================================
* Update release to support Oreo system default properties
Bootimage ADB Unsecure Patcher - 05/06/2017
===========================================
* Initial public release on XDA
Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.
kirito9 said:
Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.
Click to expand...
Click to collapse
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
It's the path and also requires an mtk header appended to the boot.img or it won't boot. I'll try the separate versions.
AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
MTK-support would be great..
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
If it isn't a challenge then it isn't fun . I'll try to see if I can follow what was done for the libbootimg and see if I can get what is needed for MTK.
Also the libbootimg sources in the first post link needs changing to this libbootimg.
this is great its making life easier
kirito9 said:
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.
Click to expand...
Click to collapse
MTK boot.img headers are only for old mt65xx, that's not needed on newer mtk platforms I think you should consider making a mt65xx specific version of this tool (great tool btw, was looking for something similar ) because it's only (no offense) useful for a couple people still working on mt65xx (and mt65xx with 3.4 will probably never see Ng/Oc due to the egl/mali blobs crashing asap as devices enter suspend).
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Can you explain in simple language
What is this for.
Someone suggest me to flash this as my phone (codename merlin) was not booting after flashing somefeak kernel
Moyster said:
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)
Click to expand...
Click to collapse
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
bigrammy said:
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
Click to expand...
Click to collapse
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )
Moyster said:
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )
Click to expand...
Click to collapse
You sure do your homework Moyster 100% correct :laugh:
I agree the OP should not have to alter their code to support the <2014 boot.img when it's so easy to convert it to a standard/vanilla format. :good:
:highfive:
Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.
CosmicDan said:
Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.
Click to expand...
Click to collapse
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.
AdrianDC said:
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.
Click to expand...
Click to collapse
Cool stuff. I also compiled a "god mode" adbd binary that I can inject to initramfs, the idea being that it runs as root even on user builds, but for some reason it doesn't work on Oreo anymore. Might just need to update my sources for 8.1 or something, or I missed a compiler flag somewhere, but I'm thinking the init might not be actually running adbd in the right permissions. Tried anything like that?
Moto g5 plus, stock rom 7.0 + magisk 16.6. When connecting I get error:
error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.
@CosmicDan: Would you mind uploading a patched standalone adbd god mode binary? I Googled your name like "adbd god cosmicdan", only found some references on XDA and GitHub, but they appear to be device-specific. Would such a binary be universal (work on all commonly used CPU architectures/Android versions)? I think your patch is for ARM64, and I do own 2 ARM64 devices, but also a handful of older phones that are armv7a/32 bit.
Thanks!
So,I was packing up my stuff in my house to move to Hostel when I found a network adapter.In the past I owned one for my Kali Pentesting.Then I gave it up for Exams and never saw it again.Now I had free time and wanted to mess with the college hostel's WiFi.But due to the rules I am not allowed to bring in any "Level 3" devices such as Laptops PC's.All had to be done on a Mobile which should be cheap and When the time comes disposed of easily.I tried buying a Nexus 5 devices but couldn't find in my price range (50$).So instead I bought the Note 3(Great Success)Now all I needed was a Patched kernel.I was going to build one using the cm-14.1 official sources.But while I was searching for solution I found Nexmon.I tried the firmware for bcm4339 using the app on /system/etc/WiFi/bcmdhd_sta.bin and entered the command su and nexutil -m2 and after that LD_PRELOAD=/system/lib/libfakeioctl.so airodump-ng wlan0 in the terminal whi and It worked(Greater Success)Now the I needed to run some tools which only worked in ChrootThis was no easy task.I again needed a Patched kernel.So,I followed the official guide to patch the kernel.I patched and built the kernel flashed it but found that my network adapter was obsolete.So,The only option remained was to use the Inner wireless card which supported injection and all the stuff(Not Natively).For the sake of research I Used Hijacker and used the setting for precommand as LD_PRELOAD=/system/lib/libfakeioctl.so and was able to capture/Decrypt/Crack Handshakes successfully against my own network.Now I am uploading here my compiled kernel with only one patch applied kernel.It's literally the cm kernel with only one patch.I need help in achieving 2 things.
1-Enable native monitor mode without LD_PRELOAD
2-Enable monitor mode internally in chrooted Kali.
Here is the boot.img just flash it and test it with external mode.
I will keep you updated on my Discovery in achieving the 2 above things.Any help would be welcomed.I should mention here that My profession isn't Computer related or any tech stuff.I am studying Medicine and Surgery along with a Speciality in Heart.So,You can't except me to do anything related to code.Again this is a testing build which I have tried on LOS14.1 and booted but couldn't verfiy the wlan1 status due to the fact That I don't currently have a wireless card.So,If you phone blew up,,Established communist empire,Robbed a bank,Tried to invade Russia,Attacked Samsung HQ or do anything I won't be responsible.
HERE'S THE LINK to the latest built nethunter(No chroor)cm13
https://drive.google.com/file/d/1IN1PQdq8Jk9UxOnH9G-gl1yk7X6ylHXr/view?usp=drivesdk
FIND 1
Cloned CM-14.1 repo
Cloned GCC 4.9 repo
Modified the build_kernel.sh for EUR(N9005)
Patched using:
wget http://patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patch
patch -p1 < mac80211.compat08082009.wl_frag+ack_v1.patch
Built using
sh build_kernel.sh
Success!
Made boot.img
Here's it :https://drive.google.com/file/d/1Hixwje3rSz4z9E6D7GuRhgItyJ3EsBW7/view?usp=drivesdk
FIND 2
Cloned Xenial Jairus's repo.
Built ralink,realtek and atheros capable devices.
Working
Log:3 androifilehost approved my request
This is xenial kernel by jairus with little chunks removed
Huge thanks to @Jairus980 for the amazing kernel
Here is the link1 https://www.androidfilehost.com/?w=files&flid=285679
I have ralink which works perfectly.Furthermore there is a folder named ZImages which contain and will contain All the zImages which I will ever create for this device.Just Dowoad android kitchen unpack lineageboot.img or the @Jairus980 kernel img and replace the zImages with mine.
Side note.Most of the kernel Images doesn't work.
Side Side Note:
The Note 3 is a dead device and the only reason I am working on it is the fact that I wanted to test some things before I tear apart my main device.
Side Side Side note
I will only be working on hlte aka hltexx aka hlteur aka N9005 aka The Samsung Galaxy Note 3 Internation Snapdragon Variant.
If you accidentally brick your phone,Blew it up,Damaged your PC,Blew Up your House,Established Communism or Invaded Russia for that Matter and Point finger at me I will laugh at you.Furthermore Black Holes,Accidently ending up solving the antilife equation or summoning a wish granting dragons are Issues I can help with.
Thanks XDA for teaching me stuff
Links added
Sent from my Pixel 3 XL using Tapatalk
Introduction
This thread contains the LineageOS 17.1 custom firmware images for the Unihertz Atom L, a rugged Android phone released by Unihertz in July 2020, and the accompanying LineageOS Recovery used for flashing the firmware.
Please note that this ROM is one of my side projects, for which I could provide zero warranty. By installing this ROM, you acknowledge that you take all the risks that come with installing custom firmwares on your devices, including but not limited to bricking your device, losing your data, etc. You are always suggested to keep backups and make sure you know how to flash back to official ROM before trying any custom ROMs.
Please find the download links in the Download section. The following sections are guides to installing the ROM.
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Working Features
- All basic features (Telephony, VoLTE, Audio, Camera, NFC, WiFi, Bluetooth, ....)
- Programmable PTT (red) button (Functionality can be set in Settings - System - Buttons, under the "Search Button" section)
- 48MP camera seems to be working (unlike on many other super resolution devices)
Known Issues
- VoLTE is working (at least for me) but sometimes quirky. If you find it somehow stopped working, usually turning it off and back on again (in Settings - Network - Mobile Network) will fix it. Putting the device to SELinux Permissive mode also fixes most of the VoLTE quirks but this is not recommended (a few quirks in Enforcing mode is better than having the whole device Permissive)
Unlocking
1. Boot your Atom L to the official OS
2. Go into Settings - About phone, tap "build number" several times to enable developer settings
3. Go to Settings - System - Developer Settings, enable OEM unlocking and ADB debugging
4. Run `adb reboot bootloader` on your PC (there is no way to enter bootloader directly, only possible through adb)
5. Run `adb flashing unlock` and comfirm unlock on device (THIS WILL WIPE ALL DATA)
6. Reboot and now you should see an unlocked warning during boot screen.
Installing LineageOS Recovery
For now the only working recovery is the LineageOS Recovery, because the device's kernel does not load the touch driver in recovery mode for whatever reason, rendering TWRP useless.
1. Download `lineage_recovery_XXX.img` and `vbmeta.zip`, unpack `vbmeta.zip` to get three .img files starting with `vbmeta`
2. Run `adb reboot bootloader` to put your device in bootloader mode
3. Run `fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img`
4. Run `fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta_system.img`
5. Run `fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta_vendor.img`
6. Run `fastboot flash recovery lineage_recovery_XXX.img`
7. Run `fastboot reboot recovery` to reboot into the newly-installed LineageOS Recovery
The LineageOS Recovery is operated by volume keys as selection and power as confirmation (or entering sub-menus). To return to upper levels of menus from sub-menus, press volume up until the selection goes to the first item and then disappears, then press power (i.e. there's a hidden "Go Back" item at the very top of each sub-menu).
The recovery will show a verification failed prompt for most packages that are not signed with the AOSP keys. This is safe to ignore.
Installing LineageOS 17.1
The LineageOS image must be installed via LineageOS recovery.
1. Download `lineage-17.1-Atom_L-XXX.zip`
2. Reboot your device into recovery (`adb reboot recovery` or simply hold volume up while turning power on)
3. Wipe all data (factory reset) (THIS DELETES EVEN INTERNAL STORAGE)
4. Choose Apply Update, then Apply Update from ADB
5. Run `adb sideload lineage-17.1-Atom_L-XXX.zip` from your PC
6. Wait for the process to finish. (The recovery might prompt something about verification failure, just ignore it and continue anyway)
7. At this point, you can then sideload the LATEST Magisk and OpenGAPPS Nano at your will (note that the size of the system partition might only be enough for the `nano` variant of OpenGAPPS) (If installing Magisk / OpenGAPPS fails, you can try rebooting into recovery again in advanced menus, then try installing them again)
8. Reboot into system and enjoy (Note that Magisk might cause your device to boot loop once or two but it will eventually boot)
When updating to a newer build, you have to flash the new zip, and then re-flash whatever mod you have installed previously (Magisk / GAPPS).
Download Links
LineageOS:
lineage-17.1-Atom_L-20200828-peter-signed.zip: https://mega.nz/file/bAgh1BZA#jzMs_0e9NUR9NcALXWp51ZeWttM5rl_3K5T8Or9hAW0
- Synchronized updates from LineageOS upstream.
lineage-17.1-Atom_L-20200728-peter-signed.zip: https://mega.nz/file/vBwlmL5D#wpw8RovBHyVFCLFlhQ2H5QAIb0ECXkT4of0FRijiP6A
LineageOS Recovery:
lineage_recovery_20200728.img: https://mega.nz/file/yc4Dnbyb#yx0Ci9p3q9_lfAiXkGfgWDFnRJI-JSGrv3kyawkU3fw
vbmeta:
vbmeta.zip: https://mega.nz/file/nF51mBoY#ZNY4j92wc_6a1dXch3l5r-w4VFl9QjN7YJaRMKRoEGk
XDA:DevDB Information
LineageOS 17.1 for Unihertz Atom L, ROM for the Android General
Contributors
PeterCxy
Source Code: https://cgit.typeblog.net/android/device/unihertz/Atom_L/
ROM OS Version: Android 10
Version Information
Status: Alpha
Created 2020-07-28
Last Updated 2020-07-28
How different is the Atom XL?
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
tvroman said:
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
Because Unihertz publishes completely different firmware files for the L and XL, so the safest assumption is that there is more difference than just the UHF radio. If you want to risk it, then you CAN try using this ROM on the XL, as long as you know how to revert back to official if things go wrong. (But I cannot guarantee if the kernel image from L that this ROM uses will not cause serious issues like corrupted baseband or something on the XL)
My suggestion is that instead of trying this ROM directly on the XL, someone with XL can try to modify my device tree for L, replacing the kernel, dtbo images and other vendor blobs from the ones from XL, and then re-compile the ROM for XL. This would be the proper way to handle these two devices.
Click to expand...
Click to collapse
Going XL
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
a-dead-trousers said:
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
Click to expand...
Click to collapse
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
PeterCxy said:
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
Click to expand...
Click to collapse
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
a-dead-trousers said:
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
Click to expand...
Click to collapse
> None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
> my dtb file is in the "device" directory and not being transfered into "out" during building.
Because most tools other than `unpack_bootimg` extracts dtb incorrectly.
> Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
Those don't matter. Either will work as long as you flash it with the correct parameters as given in my post.
> And reguarding the rather smallish system partition
No don't do that. Android 10 does not use a separate system partition anymore, instead both system, vendor and product are sub-partitions in a huge super partition. When flashing a new ROM, the partitions are automatically resized to match the new image exactly, instead of leaving free space unused like before Android 10. That's why I need to reserve space in BoardConfig.mk for gapps to be installed correctly.
Still not able to build.
PeterCxy said:
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
Click to expand...
Click to collapse
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
a-dead-trousers said:
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
Click to expand...
Click to collapse
> Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
> Where did you get the "config.xml" and "power_profile.xml" from
Exactly from those apks. Just decompile them using apktool.
PeterCxy said:
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
Click to expand...
Click to collapse
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
PeterCxy said:
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
Click to expand...
Click to collapse
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
a-dead-trousers said:
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
Click to expand...
Click to collapse
> Still giving me errors.
Looks like that dtb.img error was totally my fault -- it was due to my jerry-rigged solution of using prebuilt dtb image that conflicted with one of Lineage's update in August and I haven't built the ROM for a month. Now I have fixed it in the latest commit.
> Can you tell me how you got the list of needed files?
All of those files are for VoLTE support and I started with the list from a commit in Redmi Note 7 Pro's device tree that imported those VoLTE blobs, and then added what was missing one by one (when something is missing the Phone process will crash and you can see what got missing in the logs). I don't think the list will be any different on Atom XL so you can just use the one in my device tree.
Hi.
Thanks to you everything is running smoothly here. But what bugs me is that TWRP is not working on our devices.
Although for the Atom there is a possibility: https://forum.xda-developers.com/android/development/twrp-modded-to-unihertz-atom-t3885793
Before I want to go public with my build I wanted to solve this last "mystery".
So I tried to include it in my current source tree according to the (official?) guide but some errors prevented me from a successful build.
Naturally I asked for some guidance at the most reasonable places I know of but got nothing so far:
https://forum.xda-developers.com/showpost.php?p=83443611&postcount=4622
https://forum.xda-developers.com/showpost.php?p=83455271&postcount=4623
https://github.com/TeamWin/android_bootable_recovery/issues/70
I even tried different repositories (omnirom/android_bootable_recovery) and revisions (android-9.0) but these resulted in missing library "type" (static vs. shared) errors so I assume these are too old for LineageOS 17.1
What I want to know is how you managed to get TWRP to built for your device even though the touchscreen wasn't working?
Did you use your LineageOS source tree or one of the many "minimal" manifests? If so, which one would be the "best" to use?
wkr ADT
@PeterCxy and @a-dead-trousers
Thanks for all the work on this so far. I've got an Atom L and have gotten the ROM's PeterCxy posted running on them as in the OP. Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
dirtylimerick said:
[MENTION=5351691] Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
Click to expand...
Click to collapse
I documented my steps to setup up the build environment in the readme of my repo:
https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL
But leave out the TWRP part. It isn't working yet mostly because TeamWin/android_bootable_recovery and LineageOS/android_bootable_recovery are too similar.
To figure out all the bits and pieces needed for the device I followed the commit log of @PeterCxy build.
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
a-dead-trousers said:
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
Click to expand...
Click to collapse
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. That patching guide is pretty out of date and I imagine it won't work on most recent kernels. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code. Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
PeterCxy said:
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code.
Click to expand...
Click to collapse
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
PeterCxy said:
That patching guide is pretty out of date and I imagine it won't work on most recent kernels.
Click to expand...
Click to collapse
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
PeterCxy said:
Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
Click to expand...
Click to collapse
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
a-dead-trousers said:
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
Click to expand...
Click to collapse
Happy to hear that you were able to figure the touchscreen out. I tried to port TWRP at the very beginning when I started tinkering with the device but quickly grew frustrated and just ported Lineage Recovery instead. I guess I might try patching the kernel image too at some point later.
BTW, for TWRP to work with devices released after Android 10, I'm pretty sure you need an extra set of patches that are not yet fully merged to the main TWRP repository. I remember there's some guy providing another manifest with all the patches applied but I couldn't remember the name.
Hi.
I just officially announced my build for the Atom XL:
https://forum.xda-developers.com/android/development/rom-lineageos-17-1-unihertz-atom-xl-t4171407
Could you please put a link in your first post for those in search of the Atom XL and found your thread instead. Thanks.
wkr ADT
hi @PeterCxy.
During my daily usage of the phone I encountered a strage problem:
The audio jack isn't working. Plugging in some headphones I get this slight click in the earpieces when the circuits connect but nothing else happens. Neither a "headphone" icon in the status bar nor hearing anything coming from the headphones itself. The main speaker of the phone keeps playing the music. Using bluetooth everything is working as expected though. So I used logcat to see if something is coming up during plugging in but nothing "catchy" shows up in the logs. My guess is that some (vendor?) service is missing or not started during booting. Next I checked If something shows up on logcat during boot but I'm not sure for what to look exactly. There are quite a few errors and warnings though. In my despair I started to "fix" the "avc: denied" (SEPolicy) entries. Thats when I found a specific error reguarding VoLTE. Maybe this would fix the problems you had with VoLTE in enforcing mode:
https://github.com/ADeadTrousers/an..._Atom_XL/blob/master/sepolicy/private/init.te
(The line with "socket_device:sock_file")
My provider doesn't support VoLTE so I'm not sure if this helps or not. Maybe you could check it.
Anyway can you please tell me if your device's audio jack is working or not?
If you're (by some mysterious coincidence) not affected by this, can you at least give me some pointers for what to look for to get this fixed on my side.
The Internet Is not very helpful when searching for "android audio jack" or something similiar.
Thanks in advance.
wkr ADT
Hey guys,
Been working on a personal project, and came to this question, which also happens to be the first Im having to post about online..
Is it even possible to boot the kernel in EL2 mode with the sdm845 SoC ?
My end goal here being running qemu - which I'm already are - under KVM ( The tough part )
I Already tried enabling the necessary options in the kernel build, flashing them, with no success.
What I've been reading around is that since the system uses the TrustZone environment, this may not be possible.
[Kernel] Stock Android Pie kernel with KVM
I have been trying for some time now to enable KVM on the Pixel XL, by compiling the stock Google kernel and adding the KVM switches to "marlin_defconfig". Unfortunately, while the kernel with KVM compiles properly and could be flashed, /dev/kvm...
forum.xda-developers.com
On the other hand, under the chipset specifications I've been seen that only EL3 is really protected by the security implementations.
Documentation – Arm Developer
developer.arm.com
I know some exynos chipsets support booting in EL2 out of the box, but I see not much development for Qualcomm based ones.
ARM KVM (Kernel Virtual Machine) enabled Kernel for Samsung Galaxy S8
Hi. Can someone that compiles kernels for this phone compile one with KVM enabled and make it available to download? It should not be too hard. This would really make these machines appealing if you could spin up VMs on them especially...
forum.xda-developers.com
KVM
Limbo is a QEMU-based emulator for Android. It currently supports x86, ARM, PowerPC, and Sparc emulation for Intel x86 and ARM android devices. See wiki https://virtualmachinery.weebly.com for APK...
github.com
So, summing up, is it possible, and if so through what actions, to boot a kernel under LE2 mode on a snapdragon processor?
Also, side note, I'm willing to brick my device, if its worth the try, and adds to any progress of future development.
Edit1: Added links- sources
Cheers!
Sadly, with SDM845 it is impossible to enable KVM in android Linux kernels. As the kernel is booted under EL1 by the firmware. But with this firmware https://github.com/msm8916-mainline/qhypstub, msm8916/msm8935 can.
Is there a way to enable KVM for SM8450 (Snapdragon 8 gen 1) ? I would like to use Qemu on Galaxy Tab S8
linlin3309 said:
Sadly, with SDM845 it is impossible to enable KVM in android Linux kernels. As the kernel is booted under EL1 by the firmware. But with this firmware https://github.com/msm8916-mainline/qhypstub, msm8916/msm8935 can.
Click to expand...
Click to collapse
How i check my device booting with EL1 or EL2 ?
Via `dmesg` ?