[ROM][5.1.1] AOSP-5.1.1 / CM-12.1 for Lenovo a2109 (20160901)

PJBrs

Senior Member
Developer
Dec 29, 2014
480
405
Further progress...

I've switched to various grouper libs in anticipation of a fix for the camera, fixed the problems with sound that arose as a side effect, accidentally improved the situation with video playback, and fixed selinux. I also added a power hal and switched to an open source lights hal. I think I'll be able to upload something soon-ish.
 

joebine

Senior Member
Jan 14, 2015
150
32
If you have a self booot image, I can check ou the bluetooth devices.

Nice Work PJBrs
 

jeremy6652

Member
May 9, 2015
22
8
This is getting pretty epic... Never thought this Tablet would get 5.1! Keep up the good work!

Gesendet von meinem A2109A mit Tapatalk
 

PJBrs

Senior Member
Developer
Dec 29, 2014
480
405
Hello, that's rather bad news! Since we had I private conversation about this, I'll just reiterate here that I understand you flashed the first version from this post, and followed the instructions in it. I flashed that version and the latest version on my own device, so my first impression would be that you have been very unlucky, but I will flash the rom also on my primary device (upgrade from kitkat) to be sure that the problem is not with the rom itself. By the way, did you check whether the md5sums of your downloads are correct?

From your experience, it seems that your bootloader has somehow got corrupted. To have a chance of fixing this, you should try to get from apx mode to nvflash mode using nvflash. Then you should try to use nvflash to flash the bootloader (referenced in the special files section in the Technical disussion part of this board) to the boot partition, using its partitition number. I'll also note that you did experiment with nvflash a bit, and that we found that some functionality does not work with our device, and we don't know whether flashing partitions is supported. Also, we don't know which partition is the bootloader partition, and what number it would have.

The most helpful info I found is here: [Solved] Unbricking with NvFlash . If we are to have a passing chance of fixing your device, then this is what we shoul build on.

As you might guess, this is uncharted territory for me. I still hope we'll be able to help you out, but no guarantees at all...
 
Last edited:

profeet

Senior Member
Aug 17, 2014
42
7
Hi, @PJBrs, I want to test new rom. Before I flash it, I wipe cash & dalvik cash. What about factory reset, do or not? Now I am on 6.0.5.1 cwm & cm11 rom (build 01.10.15)
And where I can check md5 sum?

Big big thanks for new rom.
 
Last edited:

PJBrs

Senior Member
Developer
Dec 29, 2014
480
405
ROM TAKE DOWN UNTIL FURTHER NOTICE!

One brick is a coincidence, two bricks seems like a pattern to me. I'm investigating.
 

PJBrs

Senior Member
Developer
Dec 29, 2014
480
405

Hello Johan, first of all, I'm very sorry that you and killer2020 accidentally bricked your devices.

I've been reading a lot about nvflash, wheelie and various associated tools in the meantime. The problem to overcome before you can even begin to think about saving your device is to find a certain blob.bin that apparently is neccessary to switch APX mode (the bricked status) into nvflash status (the status with a glimmer of hope). I tried to use the blob file that you can find in the bootloader packages listed in the Technical forum, but I only get:
Code:
sbktool version extraction from blob failed

We need to contact the people at androidroot.mobi for advice.

I'm currently afraid myself to flash my kitkat device. I think I'll first flash from a factory reset state to see what happens, before I update from kitkat itself.

I really have no idea what's going wrong here. Perhaps you just should have waited longer, but 30 minutes *is* a very long time, I actually think the update should have succeeded by then. And anyway, I really don't get why anything should happen to the bootloader at all during a firmware update..?!?! This ROM doesn't even include a bootloader, so it's a mystery to me why it should affect that partition.

For now, I actually think our best bet is either in seeing whether the androidroot.mobi people can help us to fix up a bootloader that puts us into nvflash mode, or to give up. System boards for a2109 are sold at Ebay for about €30, including shipping, and swapping system boards is mostly a piece of cake. Maybe we should do a little crowdfunding here...

One more thing, on a non -bricked device, you can enter apx mode by pressing vol+ and vol- simultaneously while rebooting. You can leave apx mode by pressing vol+, vol- and power simultaneously for about 15 seconds, and after that you can power up normally. But be careful!

More later, I really need to get some sleep.
 
Last edited:

johan111

Senior Member
Jul 7, 2014
22
6
Hello Johan, first of all, I'm very sorry that you and killer2020 accidentally bricked your devices.

I've been reading a lot about nvflash, wheelie and various associated tools in the meantime. The problem to overcome before you can even begin to think about saving your device is to find a certain blob.bin that apparently is neccessary to switch APX mode (the bricked status) into nvflash status (the status with a glimmer of hope). I tried to use the blob file that you can find in the bootloader packages listed in the Technical forum, but I only get:
Code:
sbktool version extraction from blob failed

We need to contact the people at androidroot.mobi for advice.

I'm currently afraid myself to flash my kitkat device. I think I'll first flash from a factory reset state to see what happens, before I update from kitkat itself.

I really have no idea what's going wrong here. Perhaps you just should have waited longer, but 30 minutes *is* a very long time, I actually think the update should have succeeded by then. And anyway, I really don't get why anything should happen to the bootloader at all during a firmware update..?!?! This ROM doesn't even include a bootloader, so it's a mystery to me why it should affect that partition.

For now, I actually think our best bet is either in seeing whether the androidroot.mobi people can help us to fix up a bootloader that puts us into nvflash mode, or to give up. System boards for a2109 are sold at Ebay for about €30, including shipping, and swapping system boards is mostly a piece of cake. Maybe we should do a little crowdfunding here...

One more thing, on a non -bricked device, you can enter apx mode by pressing vol+ and vol- simultaneously while rebooting. You can leave apx mode by pressing vol+, vol- and power simultaneously for about 15 seconds, and after that you can power up normally. But be careful!

More later, I really need to get some sleep.

Thanks for your research, I hope it will be possible to revive the tablet soon. None of the button combination works, my tablet is really dead :/ I has been thinking about the motherboard replacement, but the price is almost half of the new or refubrished Medion tablet, which is twin brother with Lenovo. What is more, the screen of my A2109 also needs to be changed because it looks like a spider web since my 2-years old son threw it against the floor ;) So I would rather buy a new tablet than try to replace the broken parts of old Lenovo. I really enjoyed A2109 (except awful viewing angels), especially sound quality and very handy size, but I think it is time to say goodbye, unless solution to unbrick it will be found. I will wait some time before purchasing a new device, let see what happens. Regards.
 

PJBrs

Senior Member
Developer
Dec 29, 2014
480
405
Okay, here's some problem analysis.

PROBLEM DESCRIPTION
@killer2020 and @johan111 report a hard brick after using my cm-12.1 upgrade package to upgrade an existing KitKat installation. After upgrade, the device seems to hang somewhere during andriod boot, the screen displaying a message such as "Android is upgrading app 9 of 89". When the user then powers off to reboot, the device does not boot anymore, but only powers up to apx mode. This suggests that either the bootloader became corrupt and/or the partition table.

PROBLEM ANALYSIS
I used the same package on my device, but I did not upgrade an existing KitKat install, since I had earlier flashed some lollipop system images using fastboot. I don't know in what ways these two approaches differ from what @johan111 and @killer2020. I currenlty assume that flashing a partition using fastboot first formats that partition, while using an upgrade package just overwrites those files that differ from previous versions. This would suggest that the problem is caused by packages and libraries that I removed since KitKat, such as nvcpud.

What I find strangest is that the upgrade package contains information for only two partitions, i.e., boot and system. It leaves other regular partitions (cache, user data and recovery) alone, and it certailnly shouldn't touch the more "exotic" partitions such as misc and staging, let alone the bootloader partition. Furthermore, the actual installation of the upgrade package apparently succeeds without problem, and the device reboots normally first, suggesting that, at that point, the bootloader, boot and system partitions are all still okay. Only later during the upgrade process, some android process apparently does things to partitions that it shouldn't do. (That even shouldn't be possible, especially not with selinux enforcing. I would personally expect that problems might arise with testing a new rom. In fact, developing can be seen as a long series of soft-bricking and unbricking one's device, going back and forth between recovery, fastboot and booting android, but since there is no reason to assume that anything would touch the bootloader, there is also no reason to assume that a hard brick would occur.)

Hypotheses:
1. Some package from KitKat that is no longer present in my Lollipop version goes ballistic during first android boot after updating.
2. The existing KitKat + Gapps combination leaves gapps in place upon upgrade, but that's too much data to also hold the Lollipop upgrade, which the updater script doesn't properly check, and then during conversion from dalvik to art this somehow takes too much space in system... Ehm, well, I don't really understand where this hypothesis is going...

My expectation is that, as a solution, the upgrade should format system as part of the upgrade process.

EXPERIMENTS
I'm thinking about a series of experiments to test these hypotheses, all using an existing KitKat installation as a starting point. I'll use my second A2109, which currently is on Lollipop as a test device, which I will first downgrade to a clean, running KitKat installation without gapps, and before each test I'll boot KitKat three times to verify that it works correctly.

1. Perform a factory reset (which, as far as I understand, formats cache, and user data partitions), format system, and install cm-12.1 using fastboot, with a boot.img and system.img.
2. Perform a factory reset (which, as far as I understand, formats cache, and user data partitions), format system, and install cm-12.1 using a regular update package with recovery.
3. Format system, and install cm-12.1 and then gapps using a regular update package with recovery.
4. Find all files in system that were removed after KitKat, erase them, reboot to recovery, and install cm-12.1 and gapps using a regular update package with recovery.
5. Install gapps for KitKat, find all files in system that were removed after KitKat, erase them, reboot to recovery, and install cm-12.1 and gapps using a regular update package with recovery

If a brick occurs after step 1 or 2 then I'm quitting android development, because that would be black magic to me.
If a brick occurs after step 3, then apparently something in cache is malfunctioning. Almost as bad as after step 1 or 2, but at least it offers a way forward using a normal system image.
If a brick occurs after step 4, then apparently the update script needs to format system.
If a brick occurs after step 5, then apparently apparently the update script needs to format system because gapps is too much or sth.

Any suggestions are very very very welcome!
 
Top