Related
hi all,
i'm going to support multiple android roms loading in my kernel_chooser + root_chooser project.
in few words it will be a powerful bootloader for android.
this is what it will be able to do ( many points are yet working ):
kernel loading thought kexec
boot from external devices
boot from subfolders
custom background
change android /sytem partition
change android /data partition
wipe android /cache partition
what i'm asking to you it's to make your android rom's kernel kexec-ready, applying them a kexec guest patch.
thus to make them ready to load for me.
if not i have to patch your kernel every time you modify it.
kernel_chooser and root_chooser are hosted here: https://github.com/tux-mind/tf201-dev
they are made for the asus transformer prime ( TF201 ), but they can run on any android device with your help.
i will add you to the github collaborators if you want to help.
now we are working on multiple android roms support.
thanks in advance for your time.
-- tux_mind
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
HTCDreamOn said:
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
Click to expand...
Click to collapse
thanks
yes, this should work for all devices, except for a little tuning of the partition with the configuration data ( /data ).
i have to make it to self-detect the /data partition.
let's say for example that you want to use it on your HTC Vision.
i have to build an host kernel by the stock one applying the host kexec patch.
than i have to build an android boot image which contains kernel_chooser as initrd and the above kernel.
this android boot image will be written to your current one though fastboot.
after that kernel_chooser will be able to load any kernel patched with the guest patch.
obviously the loaded kernel must be made for that device
it can also load a custom initrd and use a custom kernel CMDLINE.
so, after i made a HTC Vision kernel_chooser, your rom it's ready to load if you applied the guest patch to you kernel.
i can't explain well how to make you rom "bootable" because we are developing this
but if your kernel is kexec-loadable it will be supported by kernel_chooser.
i will update you in the next days
bye!
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
dtrail1 said:
how different are the methods to use kexec?
Click to expand...
Click to collapse
kexec it's a syscall, so it's the same on every arm device.
HTCDreamOn said:
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
Click to expand...
Click to collapse
there is a good explaination here:
http://forum.xda-developers.com/showthread.php?t=2104706
look at the "Compatibility patch".
for my tf201 the guest patch is this: http://git.lilstevie.geek.nz/?p=ubu...ch;h=54c2e480682afb0629f3854dfea4154f528421e5
which is almost the same...
i hope that almost all kernels have the same host/guest patch, in order to save us a lot of work.
the patch isn't need for kexec, but for hardboot kexec, thus to physically shutdown and restart the device with your kernel, from 0.
the standard kexec it's a assembly jump to 0 ( jmp 0x0 ) with the new kernel loaded in the .text section.
but the standard method don't reinitialize the devices and many other things that could rest in a undefined state.
btw, i have almost done my work.....i'm fighting the android udev which is overwriting my symlinks..
see you!
i got it!
my initial target was to remove devices created by ueventd and replace them with symlink to loop devices.
but android respawn ueventd and replaces my symlinks...
i tried to start the android ueventd, leave it running, and replace the /sbin/ueventd with a infinite sleep static program
but android dont' start at all..i can't even access via adb.
so, the "final" solution is to edit the /fstab.$hardware, which should be in any andoird boot image ( right ? ).
please feel free to suggest any other way to hack the mount process.
you can find the sources here: https://github.com/tux-mind/tf201-dev/tree/master/android_chooser
the program read the paths from kernel cmdline.
the syntax is that:
Code:
newandroid=blkdev:initrd_path:fstab_path
where
blkdev is the linux name of the blockdevice containing the next args ( e.g. /dev/mmcblk0p8 )
initrd_path is the path on the previous blockdevice of the android initrd ( gzipped or not )
fstab_path is the path on the previous blockdevice of the fstab file
the fstab file have this syntax:
Code:
/android/mountpoint /path/to/image/file
where
/android/mountpoint is the android mountpoint to overwrite ( e.g. /system )
/path/to/image/file is the path to the filesystem image file ( on blkdev ) ( e.g. /boot/unrooted.img )
i don't make any documentation until i will be sure that there is no better way to do this.
thanks in advance for your testing
ah, some other useful info.
because we are in testing the program write a log file with some debug info in the root of your blkdev.
so you will find /android_chooser.log on your blkdev with these info in case of errors.
tux_mind
Please
dtrail1 said:
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
Click to expand...
Click to collapse
Dtrail could you explain me kexec and its components required for loading new kernel because my device(electrify 2) is similar to droid razr. Using bmm kexec is boot able because I had checked by flashing droid razr's kernel which gave a boot loop.
I would be pleased and thankful to you if you help me.
NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profileRead more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel
RESERVED
RESERVED
RESERVED
RESERVED
You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.
Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.
NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.
mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.
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 doesn't show up.
Analyzing the output of "dmesg" would show this offending line:
Code:
[ 1.039716] c3 1 kvm [1]: HYP mode not available
I know, however, that the SoC definitely supports KVM (it's based on the ARMv8-A architecture, which means that it has virtualization support, according to this page: https://www.linux-kvm.org/page/Processor_support).
I'm stumped. Can anybody tell me what to do? It would be greatly appreciated!
My marlin_defconfig is attached below.
WaseemAlkurdi said:
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 doesn't show up.
Analyzing the output of "dmesg" would show this offending line:
I know, however, that the SoC definitely supports KVM (it's based on the ARMv8-A architecture, which means that it has virtualization support, according to this page: https://www.linux-kvm.org/page/Processor_support).
I'm stumped. Can anybody tell me what to do? It would be greatly appreciated!
My marlin_defconfig is attached below.
Click to expand...
Click to collapse
This should have been posted in Q&A..
stebomurkn420 said:
This should have been posted in Q&A..
Click to expand...
Click to collapse
Was going to post it under Q&A, but changed my mind, since (a) it's a dev-related question warranting dev attention, and (b) I expect that this thread is going to become the "official" thread of the kernel once it's done.
Thanks for your concern though!
how does kvm affect the kernel? are you trying to add it just for the hell of it? or wanting to work on something bigger?
ztotherad said:
how does kvm affect the kernel? are you trying to add it just for the hell of it? or wanting to work on something bigger?
Click to expand...
Click to collapse
@ztotherad
It's already built-in the kernel sources, but I'm trying to enable it. I am actually attempting to run QEMU in KVM mode as to emulate both Linux and (most importantly) Windows 10 ARM. at native speeds.
I have QEMU built (Limbo's is too old, so I built it myself from source), I just need KVM.
WaseemAlkurdi said:
@ztotherad
It's already built-in the kernel sources, but I'm trying to enable it. I am actually attempting to run QEMU in KVM mode as to emulate both Linux and (most importantly) Windows 10 ARM. at native speeds.
I have QEMU built (Limbo's is too old, so I built it myself from source), I just need KVM.
Click to expand...
Click to collapse
You can't use kvm even If you enable it in kernel.KVM on ARM is based on the ARM virtualization support, i.e. you'll need ARM EL2 permission (on ARMv8) or HYP (on ARMv7).Just like on x86 , you'll have to enable VT-X or AMD-V in BIOS or so.
However sadly, on Qualcomm devices, EL2 isn't designed to be in our reach, even If you unlock bootloader ,all you'll get is full control of EL1.EL2 is instead running QHEE,which is basically for security.So if you still want to run kvm on a Qualcomm device you'll at least either need a prototype device(unfused) to custom qualcomm bootloaders and underlying stuffs, and let your kernel running in EL2, or need a really really powerful exploit like trustzone exploit, to take the control of EL2, EL3, breaking chain-of-trust etc.
Android phones are mostly designed for security concerns and mostly shipped without hypervisor permission.However there are some exceptions like Samsung Exynos that allows you to switch to EL2 with some specific ways.
fxsheep said:
You can't use kvm even If you enable it in kernel.KVM on ARM is based on the ARM virtualization support, i.e. you'll need ARM EL2 permission (on ARMv8) or HYP (on ARMv7).Just like on x86 , you'll have to enable VT-X or AMD-V in BIOS or so.
However sadly, on Qualcomm devices, EL2 isn't designed to be in our reach, even If you unlock bootloader ,all you'll get is full control of EL1.EL2 is instead running QHEE,which is basically for security.So if you still want to run kvm on a Qualcomm device you'll at least either need a prototype device(unfused) to custom qualcomm bootloaders and underlying stuffs, and let your kernel running in EL2, or need a really really powerful exploit like trustzone exploit, to take the control of EL2, EL3, breaking chain-of-trust etc.
Android phones are mostly designed for security concerns and mostly shipped without hypervisor permission.However there are some exceptions like Samsung Exynos that allows you to switch to EL2 with some specific ways.
Click to expand...
Click to collapse
Thanks for the reply! (Apologies for the extreme delay)
You said:
.However there are some exceptions like Samsung Exynos that allows you to switch to EL2 with some specific ways.
Click to expand...
Click to collapse
Can you provide any examples?
WaseemAlkurdi said:
Thanks for the reply! (Apologies for the extreme delay)
You said:
Can you provide any examples?
Click to expand...
Click to collapse
https://github.com/limboemu/limbo/wiki/KVM
I dunno if this works.(Samsung S8 example)Afaik on Exynos you need a special SMC call to the secure monitor (ARM EL3)
fxsheep said:
https://github.com/limboemu/limbo/wiki/KVM
I dunno if this works.(Samsung S8 example)Afaik on Exynos you need a special SMC call to the secure monitor (ARM EL3)
Click to expand...
Click to collapse
I've seen that link. It's basically a kernel compilation guide.
It also makes a serious mistake: that an x86 VM would be able to make use of arm64 KVM. This is impossible.
But what I haven't seen anywhere is this:
a special SMC call to the secure monitor (ARM EL3)
Click to expand...
Click to collapse
Any pointers?
WaseemAlkurdi said:
I've seen that link. It's basically a kernel compilation guide.
It also makes a serious mistake: that an x86 VM would be able to make use of arm64 KVM. This is impossible.
But what I haven't seen anywhere is this:
Any pointers?
Click to expand...
Click to collapse
https://t.me/raspberrypiwoa/34623
https://t.me/raspberrypiwoa/34624
https://t.me/raspberrypiwoa/34625
---------- Post added at 10:56 AM ---------- Previous post was at 10:54 AM ----------
WaseemAlkurdi said:
I've seen that link. It's basically a kernel compilation guide.
It also makes a serious mistake: that an x86 VM would be able to make use of arm64 KVM. This is impossible.
But what I haven't seen anywhere is this:
Any pointers?
Click to expand...
Click to collapse
btw,
https://t.me/c/1160371980/102118
Arm el2 patch
I was searching about KVM and I found that to linux/Android must be boot in EL2 mode for KVM to be work
And I found arm64 el2 patch :
https://patchwork.kernel.org/patch/6749811/
So I would say that try this patch,compile kernel again and install it and paste result here.
If it doesn't work,then try xen virtualiztion but first try this patch
Thank you, waiting for result
Ever get this to work?
WaseemAlkurdi said:
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 doesn't show up.
Analyzing the output of "dmesg" would show this offending line:
Code:
[ 1.039716] c3 1 kvm [1]: HYP mode not available
I know, however, that the SoC definitely supports KVM (it's based on the ARMv8-A architecture, which means that it has virtualization support, according to this page: https://www.linux-kvm.org/page/Processor_support).
I'm stumped. Can anybody tell me what to do? It would be greatly appreciated!
My marlin_defconfig is attached below.
Click to expand...
Click to collapse
I was wondering if you ever got this to work, since I have an exynos device and am trying to get kvm to work too. Also you ever try this: https://patchwork.kernel.org/[email protected]/ patch? Cause if not I might give it a ago.
Same here, enabled the necessary kernel flags, flashed, but still dmesg informs me my cores are at EL1.
Seems @fxsheep has a clear point, but, who knows.
*I'm using the sdm 845 SoC on oneplus6
Any progress on your side?
Sleirsgoevy could get into EL2 and could use kvm.
See it here
raspiduino said:
Sleirsgoevy could get into EL2 and could use kvm.
See it here
Click to expand...
Click to collapse
This just uses Exynos-specific exploit, and as such useless for Snapdragon devices.
This thread is for native Linux development on Galaxy A8/A8+. This means no Halium here. It's also aimed at people who know how to compile their stuff, ect., so don't complain to me about no fancy zip installer.
I have made some fixes in our DECON framebuffer driver, ect that makes TTY, and Xorg, and anything that uses the framebuffer work! (Based on @prashantp01's Quantum Quack kernel because that's what I had at the time and it's a good kernel).
I have tested this using Arch Linux ARM (ALARM), and it boots just fine!
A postmarketOS tree for the regular A8 is in the way of being merged, and I need someone to try the A8+ version.
Please provide a photo of the phone running PostmarketOS with weston on A8+!
Prebuilt zip for A8+ and A8 with postmarketOS weston (not really useful, but good for screenshot) here:
A8: https://drive.google.com/file/d/1cVamhYGmBrDVrzzcIVyCmhLHJIQ3u3Xq/view?usp=sharing
A8+: https://drive.google.com/file/d/1xe9rFu4TRzxmM9yV4lINOHOHsEQ2TD0O/view?usp=sharing
This may also be useful for other 7885 and 7885 based (7884 variants, 7904) devices as well!
What currently works on Arch (and probably on any other native linux distro):
Booting (Arch Linux sometimes hangs on "Triggering uevents" for a few minutes, sometimes boots instantly)
Screen (inc. brightness and turning on/off (due to a hacky workaround in kernel, the screen may show a corrupted screen for a split second when turning on)
Framebuffer console (TTY)
Xorg (unaccelerated)
Touchscreen
Hardware buttons
Battery indicator (detects some other stuff as batteries/charging ports too ATM)
USB OTG (Mouse, keyboard, ect)
(After adding some configs)USB SSH, and web access from PC using USB
Basically anything using Xorg (LightDM, Xfce, GNOME, KDE Plasma, Firefox, Chromium, GIMP, VLC, ect ect ect)
Anything that can use framebuffer (weston's framebuffer backend)
NOTE: This is a guide assumes you know how to do some stuff. For some help you can also reference this
Rough instructions for Arch Linux (Using prebuilt boot.img):
Partition your SD card (using PC or something) so that your second partition will contain your rootfs (the boot.imgs provided use the 2nd SD card partition as root! Change in defconfig if you are building your kernel.)
Install the generic version of ARMv8 Arch Linux ARM to the second partition of your SD card.
Install additional packages by chrooting from Android, or using USB networking
(For dual-boot) back up boot.img
Install the correct boot.img.
To boot back into Android, restore your boot.img
Prebuilt Arch Linux boot.imgs
Source code
VDavid003 said:
This thread is for native Linux development on Galaxy A8/A8+. This means no Halium here. It's also aimed at people who know how to compile their stuff, ect., so don't complain to me about no fancy zip installer.
I have made some fixes in our DECON framebuffer driver, ect that makes TTY, and Xorg, and anything that uses the framebuffer work! (Based on @prashantp01's Quantum Quack kernel because that's what I had at the time and it's a good kernel).
I have tested this using Arch Linux ARM (ALARM), and it boots just fine! A postmarketOS port will follow soon!
This may also be useful for other 7885 and 7885 based (7884 variants, 7904) devices as well!
What currently works on Arch (and probably on any other native linux distro):
Booting (Arch Linux sometimes hangs on "Triggering uevents" for a few minutes, sometimes boots instantly)
Screen (inc. brightness and turning on/off (due to a hacky workaround in kernel, the screen may show a corrupted screen for a split second when turning on)
Framebuffer console (TTY)
Xorg (unaccelerated)
Touchscreen
Hardware buttons
Battery indicator (detects some other stuff as batteries/charging ports too ATM)
USB OTG (Mouse, keyboard, ect)
(After adding some configs)USB SSH, and web access from PC using USB
Basically anything using Xorg (LightDM, Xfce, GNOME, KDE Plasma, Firefox, Chromium, GIMP, VLC, ect ect ect)
Anything that can use framebuffer (weston's framebuffer backend)
NOTE: This is a guide assumes you know how to do some stuff. For some help you can also reference this
Rough instructions for Arch Linux (Using prebuilt boot.img):
Partition your SD card (using PC or something) so that your second partition will contain your rootfs (the boot.imgs provided use the 2nd SD card partition as root! Change in defconfig if you are building your kernel.)
Install the generic version of ARMv8 Arch Linux ARM to the second partition of your SD card.
Install additional packages by chrooting from Android, or using USB networking
(For dual-boot) back up boot.img
Install the correct boot.img.
To boot back into Android, restore your boot.img
Prebuilt Arch Linux boot.imgs
Source code
Click to expand...
Click to collapse
Thanks david
VDavid003 said:
This thread is for native Linux development on Galaxy A8/A8+. This means no Halium here. It's also aimed at people who know how to compile their stuff, ect., so don't complain to me about no fancy zip installer.
I have made some fixes in our DECON framebuffer driver, ect that makes TTY, and Xorg, and anything that uses the framebuffer work! (Based on @prashantp01's Quantum Quack kernel because that's what I had at the time and it's a good kernel).
I have tested this using Arch Linux ARM (ALARM), and it boots just fine! A postmarketOS port will follow soon!
This may also be useful for other 7885 and 7885 based (7884 variants, 7904) devices as well!
What currently works on Arch (and probably on any other native linux distro):
Booting (Arch Linux sometimes hangs on "Triggering uevents" for a few minutes, sometimes boots instantly)
Screen (inc. brightness and turning on/off (due to a hacky workaround in kernel, the screen may show a corrupted screen for a split second when turning on)
Framebuffer console (TTY)
Xorg (unaccelerated)
Touchscreen
Hardware buttons
Battery indicator (detects some other stuff as batteries/charging ports too ATM)
USB OTG (Mouse, keyboard, ect)
(After adding some configs)USB SSH, and web access from PC using USB
Basically anything using Xorg (LightDM, Xfce, GNOME, KDE Plasma, Firefox, Chromium, GIMP, VLC, ect ect ect)
Anything that can use framebuffer (weston's framebuffer backend)
NOTE: This is a guide assumes you know how to do some stuff. For some help you can also reference this
Rough instructions for Arch Linux (Using prebuilt boot.img):
Partition your SD card (using PC or something) so that your second partition will contain your rootfs (the boot.imgs provided use the 2nd SD card partition as root! Change in defconfig if you are building your kernel.)
Install the generic version of ARMv8 Arch Linux ARM to the second partition of your SD card.
Install additional packages by chrooting from Android, or using USB networking
(For dual-boot) back up boot.img
Install the correct boot.img.
To boot back into Android, restore your boot.img
Prebuilt Arch Linux boot.imgs
Source code
Click to expand...
Click to collapse
So one can boot Armbian on A8+ as we do with Android box? Where is dtb for this?
p5uresh said:
So one can boot Armbian on A8+ as we do with Android box? Where is dtb for this?
Click to expand...
Click to collapse
Yes you could probably boot it. The dtb is inside the boot.img
Try installing it to an sd card, chrooting into it from android, generating an initramfs, then replacing the initramfs in the boot.img with the one you generated. (Maybe it could even work without that, wiht arch's initramfs?)
VDavid003 said:
Yes you could probably boot it. The dtb is inside the boot.img
Try installing it to an sd card, chrooting into it from android, generating an initramfs, then replacing the initramfs in the boot.img with the one you generated. (Maybe it could even work without that, wiht arch's initramfs?)
Click to expand...
Click to collapse
OK
Thanks.
postmarketOS tree on the way! Please someone send photo of A8+ running it! Info in first post!
this is absolutely amazing, thank you for the work
im very happy with gentoo linux on my phone haha
saraphiem said:
this is absolutely amazing, thank you for the work
im very happy with gentoo linux on my phone haha
Click to expand...
Click to collapse
You got gentoo to boot? How did the drivers and compatability work out? I am asking this quite seriously as I do want to port it to my own device in the future.
Please update download links
Fandroid Tech said:
You got gentoo to boot? How did the drivers and compatability work out? I am asking this quite seriously as I do want to port it to my own device in the future.
Click to expand...
Click to collapse
well, it boots, tty works as expected with a phsyical keyboard lmao
the power button interestingly triggers a reboot, openrc & sysvinit goes through the "proper" shutdown process
i wasn't able to get much more than that working, unfortunately :c
saraphiem said:
well, it boots, tty works as expected with a phsyical keyboard lmao
the power button interestingly triggers a reboot, openrc & sysvinit goes through the "proper" shutdown process
i wasn't able to get much more than that working, unfortunately :c
Click to expand...
Click to collapse
I tried running it in a chroot, running gentoo on an 10 year old armhf cpu was hell in itself. The bigger problem was trying to update an old system. The closest anybody has gotten to gentoo mobile is sharkbait os, but that was just a chroot I think.
Fandroid Tech said:
I tried running it in a chroot, running gentoo on an 10 year old armhf cpu was hell in itself. The bigger problem was trying to update an old system. The closest anybody has gotten to gentoo mobile is sharkbait os, but that was just a chroot I think.
Click to expand...
Click to collapse
haha sure does take a while to compile things
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` ?