Custom Kernels for MIUI - Redmi Note 8 Pro Questions & Answers

Hi,
Just wanted to know, are there any custom Kernels for MIUI ?
I can see there are now some custom roms but couldn't find any custom kernels, specifically any that work with MIUI ?
Thanks

I haven't seen any. I'm not sure there's any freestanding kernel for any ROM atm. From my experience, it is not trivial getting a working one for this phone (but I'm not really a phone dev, so YMMV).
If anyone tries building and booting a kernel for this phone, here are some things I've discovered on my own:
1) DTBO
a) official dtbo + non-official kernel = brick and requires SPFT
b) lineage dtbo + official kernel doesn't work (can't remember if it bricks or not)
c) lineage dtbo + custom kernels = ok
I've tried building a device tree manually, including the voodoo public key appends from HyperTeam's tree, but couldn't get one working.
It should be noted that any kind of broken dtbo results in a brick. Which seems weird, because fastboot should be implemented in lk...
2) Boot image
a) When building the image from the kernel, the offsets must be set correctly, especially kernel + ramdisk. For me this is complicated by a bug in the mkbootimg binary which needs a ramdisk with non-zero size to accept the offset.
b) The image must be signed with avbtool. Interestingly, partition name and size don't matter too much.
3) Charging light
When keeping the phone connected by usb, the charging/notification light is on while the phone is in preloader & lk. When the kernel boots successfully, it gets turned off. Checked it by comparing with pstore logs.
Also, there are some proprietary bits in the vendor partition interacting with some interfaces in the kernel which resulted in kernel oopses for me when trying to boot lineage (I'm seeing some page fault in nl80211_vendor_cmd). I'm expecting MIUI to be even worse.

Related

[Q] [lt26] Boot flow, how does it work?

I got my hands on a Xperia S and just started looking into the android development stuff...
If I would compiled a JB kernel for the device as well as AOSP 4.1.2, and lets say the recoveryimage from CM. I am wondering how / if everything works together.
The recovery partition seems to be non writable and it seems that people are advised to flash the CWM recovery to the boot partition. I thought this partition is the one for the actual kernel? Even if so, how does the combination of my kernel.elf and CWM recovery work?
If I get this done this brings up the next question, is the same kernel used to bootup the whole system later on? What I would like to see is something like a flow chart where I see how control is passed around and to what address, and which initrd does what... maybe someone can correct or expand the following:
first stage bootloader (recovery partition?)
apparently I can boot into different modes (fastboot, flash, ...)
on normal boot the kernel from the boot partition gets loaded into ram (execution starts at 0x40208000 ?)
kernel (boot partition)
... does initializaiton stuff ...
in the end init from initrd fires up either the CWM recovery (?) or userspace (?)
I assume in userspace the usr init fires up the dalvik vm and android boots as usual (this is the system partition I get from AOSP ?)
How exactly does it work for CWM and where is it located in the ROM and RAM?
I am sorry if the information is already posted somewhere in these forums but I wasn't able to acquire it so far.
cheers
Welcome to the forum. Thread moved, please post your questions here in Q&A in future.
Thanks
AvRS
Hi,
Let me try to clarify a bit, at least on how I see it:
Bootloader is indeed capable of handling multiple modes:
- flash mode
- fastboot
- normal kernel boot
- recovery / fota kernel boot (disabled with unlocked bootloader)
When unlocking bootloader, the only kernel we can boot is normal kernel. You can write to fota kernel partition, but it will not boot anything unsigned there and will boot normal kernel instead.
So in our custom roms, Android and recovery are using the same kernel, we add recovery files in the Android initramfs, and the switch is handled by init.*.rc with a script that detects keypress and is launching recovery if volume key is pressed.

[INFO] Understanding and troubleshooting bootloops

Since this device tends to bootloop easily and because I've seen lots of questions about it and information is spread across many threads and posts, I'm writing this guide to help you guys troubleshoot bootloops before asking generic "help me" questions.
I) Terminology
1) BROM - A readonly memory on the SoC that runs right when the device boots. Loads the preloader. SPFT talks to it after authentication.
2) Preloader - MTK firmware that resides on flash. It is loaded on the chip's SRAM. It is responsible for initializing DRAM, and is one way of authenticating SPFT (the other is authenticating directly with the BROM, but I believe the way thi is done is known only to MTK and OEM engineers, and not even to authorized service centers). It also loads LK. Its source is distributed to OEMs, but is otherwise unavailable. Plenty of leaks for other devices can be found on the internet (some from the OEMs themselves).
3) LK - Little Kernel. This seems to be the most common platform for Android bootloaders. Mediatek has its own proprietary branch. Same source status as preloader. As an android bootloader, it is responsible for loading recovery or usual kernel image, as well as fastboot flashing.
4) Kernel - If you're on these forums, you should know what it is. You can find it in boot.img
5) DTBO - The device tree for the linux kernel. It specifies which hardware is available on the device. On usual (x86) PC platforms, the BIOS and Option ROMs store device information and offer it to the kernel (through UEFI/ACPI). As arm boards do not have such those, the linux kernel uses dtbos which play the same role.
II) Boot process
1) The ARM cores on the SoC start and jump to the address of the BROM.
2) (I'm not very sure of this, there's too little information) BROM puts the cores into a known state, should listen on the in-build UART for some time (half a decade ago, some leaks said something about 150ms), and if it doesn't receive anything, it loads the preloader.
3) The preloader initializes basic stuff like DRAM (phone's ram), watchdog, USB, etc. If the phone is connected to SPFT, it talks to it and authenticates it (the (in)famous "Account not authorized for this operation" should come from a check in here). I believe it also turns on the charging light. On a normal boot, it further loads lk. I belive that it also shows the chinese menu on pressing the Vol- button on factory preloader, but I did not check this.
4) LK (the one that comes with factory preloader) checks if Vol+ is pressed, and displays the bootloader menu (the one with the 4 english entries). When selecting recovery, it loads recovery. If normal boot is selected, it loads boot.img and dtbo.img and I believe it makes some checks on them (possibly of signatures, see the kernel trees). It then loads the proper image from the logo.bin partition and displays it (note: I've checked Logo Builder; rebuilding the logo.bin partition with it makes LK reboot before showing any image - this is done after the boot menu); examples are the one where it shows "Unlocked" or the Fastboot background. It also checks vbmeta for verified boot. Then it boots the selected entry.
5) The linux kernel does some hardware init, mounts system and starts Android's init.
6) Android does its usual init, mounting vendor, loading modules and firmware, turning on stuff like wifi, bluetooth, gnss, etc.
III) Tips for diagnosing bootloops
1) When bootlooping, plug your phone in a computer and check for the following (this is from my experience):
a) Charging light turning on
b) Vol+ menu showing up
c) Redmi logo showing up
d) Charging light turning off
e) Boot animation showing up
2) Things to do based on where things didn't work as in (1):
If (a) doesn't turn on, you're most likely in deep ****, and I'm not sure who can help you. Edit: Try pressing Vol+ and see if a device with VIDID 0x0e8d:0x0003 shows up. That would be the BROM. If it shows up, try using SPFT (most likely won't work, but you have nothing to lose anyway).
If (b), try SPFT. If it shows "Account not authorized", you have the stock preloader. There's a couple threads here with some methods that may or may not work. Otherwise, ATM you'll quite literally have to pay for your mistake. Grab your wallet and your Windows VM. You'll need them. Be prepared to search for the least shady guy that can help you and have your usb passthrough (on the upstream hub) ready.
If (c) - i.e. you have the menu but no logo, this means you've got LK. Since the Redmi logo doesn't show up, it means something is not quite how lk likes it (and lk is very picky on this phone). If you can, you'll probably want to use fastboot and flash a known good image for whatever you changed. If not, use SPFT.
If (d) - i.e. you have the logo but the charging light doesn't turn off, this means LK didn't boot the linux kernel. Flash a different (working) kernel.
If (e) - the charging light turns off, but you have no boot animation, this means either the kernel panics before it can start Android or that Android failed to boot properly.
From here on, you can use /sys/fs/pstore/console-ramoops to diagnose the problem.
If you do get a boot animation or are close to it, you might also want to try using adb logcat (especially if you've turned on adb debugging, and your ROM can do it on boot).
3) /sys/fs/pstore/console-ramoops
You can access it on a normal boot on some roms (or mount it manually if you've got root), or it's usually mounted automatically on TWRP. This is the kernel log from the last boot and is theoretically stored in RAM (I have reasons to doubt that). Basically, it works like dmesg, but for the last boot.
While it is polluted by zealous MTK debugging info, scrolling through it can often show where the problem is. If you can figure it out yourself, great. If not, post it here, and I (or somebody else) might try to figure out what went wrong and put it on a list of known bootloop reasons and fixes below.
4) Recommendations on posting about bootloop problems:
I think it would help a lot specifying which step from above fails. Also, if the charging light turns off, please, please provide /sys/fs/pstore/console-ramoops. You can easily get it with adb pull from TWRP and it helps *a lot* in figuring out what went wrong.
Hope this info will help you guys getting your devices working again faster (and provide more accurate info when asking for help).
P.S.: Another reference on MTK boot, also around 5 years old.
Reserved for List of bootloop problems:
Reserved
i have:
dm-verity error
Android system on your device is corrupted.
Device will boot in 5s
Click to expand...
Click to collapse
can't boot to my mobile in past week
just i can see my device with "fastboot devices" but not found with adb devices
and in device manager "Android ADB Interface" it's not recognize ( yellow question marks).
also have "adb server version (41) doesn't match this client (39); killing"
hello..
So... /sys/fs/pstore/dmesg-ramoops .. is not there .... /pstore do not exist :-\
and /proc/last_kmsg.. neither :-(
i have.. lineage-14.1-20190213-nightly-asanti-signed install it....
He will be generating them elsewhere???
OP, please add the infamous soft brick symptoms in detail, this maybe help someone in the future.
It shows redmi logo, it can enter vol + menu with some messages (I forgot the message), and it can enter vol - (bootloader), and it will ask for authorization when hooked to SPFT. And also link to that telegram post for work around.
And also, this is crucial info I found. Anything prior global 12.0.7 can be dirty flashed to anything prior that (even A10 to A9). 12.0.7 onward, 12.0.7 is the lowest you can get for dirty flash. I don't know for clean flash. Maybe work, maybe not.
fla5 said:
i have:
can't boot to my mobile in past week
just i can see my device with "fastboot devices" but not found with adb devices
and in device manager "Android ADB Interface" it's not recognize ( yellow question marks).
also have "adb server version (41) doesn't match this client (39); killing"
Click to expand...
Click to collapse
What have you done prior brick? Do you do something like flashing global rom in a locked bootloader chinese flavor phone? If yes, do the unbrick with SPFT. If not, and you have unlocked your bootloader and access to fastboot, I think dirty flash will do the trick.
Sorry for being a lil' off-topic but I would love to ask how to prevent a bootloop after flashing back to stock recovery or/and boot. It happened twice - I used magisk+twrp, an update rolled out, I flashed the stock recovery for my official from (extracted from the official package) and ended up with a loop, did the mi authorized acc unbrick and it worked perfectly, now with the 12.5 rolling out I am preety sure i'll end with a loop again when I'll flash the stock boot or/and recovery.
luq90 said:
Sorry for being a lil' off-topic but I would love to ask how to prevent a bootloop after flashing back to stock recovery or/and boot. It happened twice - I used magisk+twrp, an update rolled out, I flashed the stock recovery for my official from (extracted from the official package) and ended up with a loop, did the mi authorized acc unbrick and it worked perfectly, now with the 12.5 rolling out I am preety sure i'll end with a loop again when I'll flash the stock boot or/and recovery.
Click to expand...
Click to collapse
you need to restore stock recovery and boot. and you can't install the update via updater nor twrp. install full rom via fastboot update or via mi flash (dirty flash is ok). but for 12.5 update, do it in twrp
from 12.0.7 onwards, downgrade without erasing data will lead to bootloop (just flash the correct build for remedy)
Thank you for your answer kekesed97.
Sorry, I made a small mistake. By saying that I used twrp means I had it installed not used for the flash. When the update came out, I thought that installing via ADB the stock recovery and boot will let me update the device like a completly unmodded model. Tried this Twice and always ended with a loop. Afterwards the only solution was updating via flashtools (it's bricked anyway so let's update manually hehe).

β—πŸ“’πŸ”” Do you want to run the latest Android build? Are you brave? Help me test some theories. Project Lazarus! EXPERTS ONLYπŸ””πŸ“’β—

WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Invitations for expert input:
@Lughnasadh
@Az Biker
@Namelesswonder
@roirraW "edor" ehT
@ipdev
Feel free to tag anyone else you think can provide some input and answer questions on this, as well as point out when something obviously won't work[/user]
V0latyle said:
WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Click to expand...
Click to collapse
This is very interesting. Definitely would like to see the results.
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
V0latyle said:
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Click to expand...
Click to collapse
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Yeedatoy said:
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
Click to expand...
Click to collapse
Bootloader
fastboot flash system <system.img>
Yeedatoy said:
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Click to expand...
Click to collapse
Yeah, I tried this. Unfortunately nothing more I can do now, bootloader is corrupted
tested on gogole pixel (sailfish) all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system and boot and flashed new one but after that it bootloop
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
loonbgg said:
all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system boot but after that flashed them but it bootlopp
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
Click to expand...
Click to collapse
Please follow the format in the OP:
Device
Original firmware/build
Type of experiment
Findings and notes
Click to expand...
Click to collapse
I believe the GKI may include its own vbmeta image.
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
V0latyle said:
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
Click to expand...
Click to collapse
Doesn't all the pixels support Treble? At least that's what googling it says.
ieatabiscuit said:
Doesn't all the pixels support Treble? At least that's what googling it says.
Click to expand...
Click to collapse
I honestly do not know. I think it's only the Pixel 3 and up. The previous versions follow a similar format (ramdisk and kernel in boot partition) but either I'm an idiot or installing a GSI is more complicated than it is on Treble devices
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
ieatabiscuit said:
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
Click to expand...
Click to collapse
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
V0latyle said:
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
Click to expand...
Click to collapse
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
ieatabiscuit said:
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
Click to expand...
Click to collapse
A GSI does not include a kernel and is meant to be used "by itself" with the stock kernel. LineageOS is generally developed as a "whole" OS, including kernel and recovery, so it's not just a system image.
There are LOS GSIs though.
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
ieatabiscuit said:
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
Click to expand...
Click to collapse
Did you try booting TWRP to install the GSI?
V0latyle said:
Did you try booting TWRP to install the GSI?
Click to expand...
Click to collapse
Not yet, I'm trying that next
ieatabiscuit said:
Not yet, I'm trying that next
Click to expand...
Click to collapse
Same as doing it through fastboot: I get a system corrupted error, then it powers off/reboots to bootloader. Reflashing stock fixes this, and sets up for the next experiment.

β—πŸ“’πŸ”” Do you want to run the latest Android build? Are you brave? Help me test some theories. Project Lazarus! EXPERTS ONLYπŸ””πŸ“’β—

WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Invitations for expert input:
@Lughnasadh
@Az Biker
@Namelesswonder
@roirraW "edor" ehT
@ipdev
Feel free to tag anyone else you think can provide some input and answer questions on this, as well as point out when something obviously won't work[/user]
V0latyle said:
WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Click to expand...
Click to collapse
This is very interesting. Definitely would like to see the results.
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
V0latyle said:
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Click to expand...
Click to collapse
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Yeedatoy said:
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
Click to expand...
Click to collapse
Bootloader
fastboot flash system <system.img>
Yeedatoy said:
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Click to expand...
Click to collapse
Yeah, I tried this. Unfortunately nothing more I can do now, bootloader is corrupted
tested on gogole pixel (sailfish) all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system and boot and flashed new one but after that it bootloop
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
loonbgg said:
all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system boot but after that flashed them but it bootlopp
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
Click to expand...
Click to collapse
Please follow the format in the OP:
Device
Original firmware/build
Type of experiment
Findings and notes
Click to expand...
Click to collapse
I believe the GKI may include its own vbmeta image.
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
V0latyle said:
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
Click to expand...
Click to collapse
Doesn't all the pixels support Treble? At least that's what googling it says.
ieatabiscuit said:
Doesn't all the pixels support Treble? At least that's what googling it says.
Click to expand...
Click to collapse
I honestly do not know. I think it's only the Pixel 3 and up. The previous versions follow a similar format (ramdisk and kernel in boot partition) but either I'm an idiot or installing a GSI is more complicated than it is on Treble devices
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
ieatabiscuit said:
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
Click to expand...
Click to collapse
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
V0latyle said:
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
Click to expand...
Click to collapse
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
ieatabiscuit said:
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
Click to expand...
Click to collapse
A GSI does not include a kernel and is meant to be used "by itself" with the stock kernel. LineageOS is generally developed as a "whole" OS, including kernel and recovery, so it's not just a system image.
There are LOS GSIs though.
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
ieatabiscuit said:
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
Click to expand...
Click to collapse
Did you try booting TWRP to install the GSI?
V0latyle said:
Did you try booting TWRP to install the GSI?
Click to expand...
Click to collapse
Not yet, I'm trying that next
ieatabiscuit said:
Not yet, I'm trying that next
Click to expand...
Click to collapse
Same as doing it through fastboot: I get a system corrupted error, then it powers off/reboots to bootloader. Reflashing stock fixes this, and sets up for the next experiment.

β—πŸ“’πŸ”” Do you want to run the latest Android build? Are you brave? Help me test some theories. Project Lazarus! EXPERTS ONLYπŸ””πŸ“’β—

WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Invitations for expert input:
@Lughnasadh
@Az Biker
@Namelesswonder
@roirraW "edor" ehT
@ipdev
Feel free to tag anyone else you think can provide some input and answer questions on this, as well as point out when something obviously won't work[/user]
V0latyle said:
WARNING: This is an EXPERIMENT for EXPERTS ONLY and is NOT for beginners or the faint of heart. If results are good, a guide will be forthcoming to use these methods to update obsolete devices.
As many of us are aware, older devices often get left out in the cold when it comes to updates. Users of the Pixel series are well aware of this - devices are generally only supported for 3 years after their release. This means that users of the OG Pixel through the Pixel 4/4XL no longer receive any updates.
However, I think I may have found a way to get around this. To combat fragmentation, AOSP introduced Project Treble as a modular solution for Android builds on various devices. The idea here is that the device-specific software would be kept separate from the kernel and system images, which would be generic, meaning that any kernel or system image could potentially run on any device. The device and vendor specific code are supposed to be contained to partitions such as /vendor_boot, /product, etc.
So, my thinking here is we may be able to manually update the kernel and/or system images on obsolete devices, thereby giving them a bit more life.
Your mission, if you choose to accept it, is to help me develop a way that older Android devices can be easily and painlessly updated to the latest Android builds.
Prerequisites:
Any Project Treble compliant device (Use this app to determine whether your device is compliant)
Unlocked bootloader
Knowledge of ADB/fastboot, device partitions, partition images, and what to do when something goes wrong
Now, the fun part.
Android Preview Generic System Image testing (should work on most devices)
Note: these builds are NOT up to date with current Pixel builds.
Download a Developer GSI release (make sure you're using the correct architecture for your device, use the GMS flavor if you want Gapps)
Extract system.img from the release zip and flash to /system (Not sure if vbmeta will be necessary)
More instructions here
AOSP Generic System Image testing
Note: These builds do NOT include GMS; you'll need to flash the GApps package of your choice. They ARE however updated continually.
Download a GSI from Android Continuous Integration:
master - Updated continuously. Builds below may be updated less frequently.
Android 13
Android 12
Android 11
Android 10
Extract system.img and flash to /system
If desired, flash the GApps package of your choice - unless someone can suggest otherwise, I believe this can only be done through TWRP
NikGapps
LiteGapps
MindTheGapps
Generic Kernel Image testing (may not work for all)
Download a Generic Kernel Image release that corresponds to your Android build (android12-5.10 is the 5.10 kernel for Android 12)
Extract boot.img from the release zip and flash to /boot
Pixel system "upgrade" (These are updated monthly, should work same as a GSI)
Download a full factory image for a newer device (Pixel 6, 7) from Factory Images for Nexus and Pixel Devices
DO NOT attempt to flash bootloader or radio images not intended for your device, this will result in a brick!
Extract system.img from the update image.zip and flash it to /system
Pixel feature "upgrade" (Most likely to have issues)
Download a full factory image for a newer device as described above
Again, DO NOT attempt to flash bootloader or radio images that are not for your device, this will result in a brick!
Extract system.img, system_ext.img, product.img from the update image.zip and flash them to their corresponding partitions
Feel free to try any one or combination of the above, and please share your results in this format:
Device
Original firmware/build
Type of experiment
Findings and notes
Other stuff:
To gain root, just patch your boot image in Magisk, then flash to /boot.
Samsung users: It's highly recommended that you use TWRP. However, if TWRP is not available, you can patch your stock recovery to enable Fastbootd, which will allow you to flash partitions directly from ADB command line.
Click to expand...
Click to collapse
This is very interesting. Definitely would like to see the results.
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
V0latyle said:
Tried some experimenting on my Pixel 2
Is it possible to use fastboot update to update the device using the zip? No, fastboot update apparently expects to see a full update image starting with boot.img. Android-info.txt can be blank
Flashing system.img directly failed too, probably requires resizing /system
Tried to use this guide to resize system. Ended up nuking something important, device would no longer boot any image due to an authentication failure. Tried to flash factory firmware, after flashing bootloader and commanding reboot device is now stuck in EDL mode...but doesn't respond to EDL commands. Maybe only Pixel 3 and above are GSI ready?
Click to expand...
Click to collapse
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Yeedatoy said:
What command did you use to try to flash the system.img and did you try to flash from fastboot or fastbootd?
Click to expand...
Click to collapse
Bootloader
fastboot flash system <system.img>
Yeedatoy said:
You typically have to erase your system.img before flashing a new one, as well as the other partitions you've listed
Click to expand...
Click to collapse
Yeah, I tried this. Unfortunately nothing more I can do now, bootloader is corrupted
tested on gogole pixel (sailfish) all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system and boot and flashed new one but after that it bootloop
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
loonbgg said:
all has fine i expand system partition from this guide https://forum.xda-developers.com/t/guide-expand-the-system-partition-on-pixel-xl-pixel.4097839/
eased system boot but after that flashed them but it bootlopp
did some one try this generic kernel (boot.img) or it need to run em with disable dm-verity ?
Click to expand...
Click to collapse
Please follow the format in the OP:
Device
Original firmware/build
Type of experiment
Findings and notes
Click to expand...
Click to collapse
I believe the GKI may include its own vbmeta image.
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
V0latyle said:
@ieatabiscuit Here's more information on GSIs, although I cannot emphasize enough how important it is to know what you're doing especially on devices that do not support Treble out of the box.
Click to expand...
Click to collapse
Doesn't all the pixels support Treble? At least that's what googling it says.
ieatabiscuit said:
Doesn't all the pixels support Treble? At least that's what googling it says.
Click to expand...
Click to collapse
I honestly do not know. I think it's only the Pixel 3 and up. The previous versions follow a similar format (ramdisk and kernel in boot partition) but either I'm an idiot or installing a GSI is more complicated than it is on Treble devices
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
ieatabiscuit said:
Here's something that may help someone. It directly references a detail about the pixel2/2xl in troubleshooting.
Click to expand...
Click to collapse
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
V0latyle said:
Good find.
I wish I hadn't bricked my Pixel 2...lol
I'll probably be doing this on my Pixel 5 when official support ends.
Click to expand...
Click to collapse
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
ieatabiscuit said:
What are the differences between a GSI on your pixel 5 vs LOS on the same hardware? I have my 5 running LOS right now. When I tinker with my 2xl I'll post results, and what not.
Click to expand...
Click to collapse
A GSI does not include a kernel and is meant to be used "by itself" with the stock kernel. LineageOS is generally developed as a "whole" OS, including kernel and recovery, so it's not just a system image.
There are LOS GSIs though.
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
ieatabiscuit said:
Device: Taimen
Firmware/build: OEM Dec build stock ROM/kernel
Experiment: Repartition and install GSI
Outcome: Soft brick with flashing system.img, but success repartitioning. Flashing a full ROM unbricks
Click to expand...
Click to collapse
Did you try booting TWRP to install the GSI?
V0latyle said:
Did you try booting TWRP to install the GSI?
Click to expand...
Click to collapse
Not yet, I'm trying that next
ieatabiscuit said:
Not yet, I'm trying that next
Click to expand...
Click to collapse
Same as doing it through fastboot: I get a system corrupted error, then it powers off/reboots to bootloader. Reflashing stock fixes this, and sets up for the next experiment.

Categories

Resources