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

[PJBrs]

Now, on to kernel problems. First of all, I'm initially going back to the kitkat kernel, based on the assumption that we have a kernel problem that crept in later on. I'll offer a test build to those who dare, including @joebine and @fusm. Suspicions:

• New kernel config CONFIG_TEGRA_LP1_950=y uses a lower core voltage in certain low-power modes. This might not be supported across all devices
• I've copied over some memory timings changes from original kai that appear to work on my device (they were also added to grouper but then reverted)
• I've copied from grouper a different mechanism for AES encryption, not using a hardware module but arm-NEON instructions that are usually faster
• I've reverted a patch that may have been required for newer versions of tf_daemon
• All mach-tegra board files have removed all calls to tegra_gpio_enable, but I didn't
• One patch included activation of some pll_a register (have no idea what that is) early on during boot, but I didn't

So, it might be one of those, but finding out will probably brick a few more devices. So, both testers and donations remain very much appreciated, if not for Lollipop, then it'll be for Marshmallow, which requires porting our board files to kernel 3.4 anyway.

You may expect a new build with an older kernel (and associated changes in init) in one or two weeks.

Final note, @joebine, I received your donation, THANKS VERY MUCH!!!

 

[DBlake]

So I decided to dig out my A2109 to test this with.

Oh and PJBrs, a side note, did you see my topic about Ubuntu Tablet? It'd be very interesting to see that on our tablet just to add a bit of variety in OS choices.

 

[DBlake]

What is the takeaway of my previous post? I'd appreciate as many people to report

1. From dmesg: hw_ramcode and board_strap
2. The contents of /proc/board_version
3. The contents of /sys/block/mmcblk0/device/name

This set of data can't be found on my a2109; except the last one, which is MAG2GA.

 

[PJBrs]

First of all - thanks!

This set of data can't be found on my a2109; except the last one, which is MAG2GA.

Well... What about:

cat /proc/cmdline

Otherwise, it would seem that your device ends up using an entirely different mem-table...

And if you would be able to open the device and check the number on the system board, that of course would be awesome It should be something like
PVT_V01_20120519 or MP_V01_20120812...

 

[joebine]

Is there another rom image or I have to use the one from previous post.

 

[joebine]

What is the takeaway of my previous post? I'd appreciate as many people to report

1. From dmesg: hw_ramcode and board_strap
2. The contents of /proc/board_version
3. The contents of /sys/block/mmcblk0/device/name

1.
From dmesg:
<4>hw_ramcode is 0
<4>board_strap is 1

2.
The contents of /proc/board_version
D00

3.
The contents of /sys/block/mmcblk0/device/name
MAG2GA

 

[jeremy6652]

Here are mine also:
hw_ramcode 0
board_strap 1

board_version D00

/sys/block/mmcblk0/device/name M8G2FB

 

[PJBrs]

@joebine, @jeremy6652, thanks very much for the info! You both appear to have (almost) the same device that I have:

1. hw_ramcode=0
2. board_strap=1
3. /proc/board_version=D00
4. /sys/block/mmcblk0/device/name=MAG2GA

Is there another rom image or I have to use the one from previous post.

Sorry, no image yet, I need some time to really dig into the series of changes that I made to my repository first, and find time for that. I hope somewhere during next week, because I think I'd best recompile the whole thing from scratch.

 

[DBlake]

This ts the cmdline:

androidboot.selinux=enforcing tegraid=30.1.3.0.0 mem=1022M@2048M commchip_id=0 a
ndroidboot.countrycode=US androidboot.serialno=FD60060734 androidboot.commchip_i
d=0 video=tegrafb no_console_suspend=1 console=null,115200n8 debug_uartport=lspo
rt,3 usbcore.old_scheme_first=1 lp0_vec=8192@0xbddf9000 tegra_fbmem=8197120@0xab
c01000 core_edp_mv=0 displayboard=0x802a:0x50a0:0x35:0x80:0x00 board_info=f41:a0
0:1:44:2 tegraboot=sdmmc gpt gpt_sector=30535679 androidboot.hw_ramcode=0 androi
dboot.board_strap=1 androidboot.bootloader=20121126.15:56 android.kerneltype=nor
mal

board id on circuitry is the first one you listed.

 

[jeremy6652]

Okay so here are some things I have noticed, I know the main focus lies on figuring out what the hell is going on with this tablet murdering rom but just to get some things together:

• Rotation lock button is a bit buggy (the message that rotation is now locked/unlocked appears again and again).
• Rotation works only from horizontal to vertical for me.
• Screen sometimes just freaks and flashes white for some portions out when having video playback (mainly observed while watching through the YouTube app).
• Minor but really irritating, screen doesn't turn on when I connect the tablet to the charger.
• Sound is really distorted when playing through the built in speakers. Could also just be my tablet, I just ordered a replacement speaker and will tell you if it gets better.

If I find more stuff I'll add it here.

Oh and btw I think the "M8G2FB" could stand for the 8gig models which I have.

 

[PJBrs]

I'm doing a new build right now. The following commit lists all the changes that I've made:

92003ca68b7d31af9db73a27c8c55d7fafa2313a

Reset kernel, init, proprietary files, liblights and powerhal
This commit reverts to the kitkat kernel, removes the open source
lights hal and open source power hal, and largely reverts to stock
nvidia libs (no grouper libs). This in order to be as kitkat like
as possible, and not to brick any more devices. I also removed the
camera wrapper, as I think it should not be necessary.

Still, some potential risks remain, such as the removal of NvCPLSvc.


I really, really hope this will be it. The bigger problem actually is that I don't know what changes to trust anymore.

 

[DBlake]

I'm doing a new build right now. The following commit lists all the changes that I've made:

92003ca68b7d31af9db73a27c8c55d7fafa2313a

Reset kernel, init, proprietary files, liblights and powerhal
This commit reverts to the kitkat kernel, removes the open source
lights hal and open source power hal, and largely reverts to stock
nvidia libs (no grouper libs). This in order to be as kitkat like
as possible, and not to brick any more devices. I also removed the
camera wrapper, as I think it should not be necessary.

Still, some potential risks remain, such as the removal of NvCPLSvc.


I really, really hope this will be it. The bigger problem actually is that I don't know what changes to trust anymore.

I hope this is the last commit needed to get Lollipop on our 3+yo devices (at least more stable)! Maybe we could work on an ubuntu port after this is "finalized".

 

[PJBrs]

@DBlake, First of all, thanks for opening your device, much appreciated! I've been searching Ebay a lot, and I only see ads for the PVT and MP versions of the motherboard. Regarding ubuntu - it should be possible with the linux4tegra project, and nvidia provides binaries that should run on our device. However, they do not support recent versions of the Xserver, so that's a problem.

 

[PJBrs]

I'm going to wait a bit longer with putting something online, because I might have stumbled upon the root of the brick problem. Please read with me, and post your reactions, because I think I might be on to something that finally makes sense.

First, the main hypothesis:
Our device has a firmware fstrim bug that can sometimes cause a brick. In Lollipop, the fstrim scheduling has changed so that it runs more often, in particular, it will run on boot if it hasn't run once in the preceding three days. I think that the firmware bug is triggered when fstrim is called during first boot right after upgrade. I thus suspect that, on my devices, I was lucky enough that fstrim had been called recently, and @killer2020, @johan111 and @jam97 were not so lucky.

Here's the information. I first stumbled upon a Cyanogenmod page listing EMMC bugs when I did a search for MAG2GA on Google. Apparently, up until and including KitKat, none of us has run into the failure mode that caused this firmware bug to brick a device. This suggest that some associated change must have occurred in Lollipop. And indeed, it has. Searching for "lollipop fstrim changes" I found a page on androidpolice with the following information:

Previously, fstrim was always called in a window of time shortly after midnight and with the requirement that the device is charging and idle, which was likely since most users would be asleep during these hours. However, this approach did not take into account the possibility that some people turn their devices completely off at night, which meant fstrim may never have an opportunity to run. To solve this, a more aggressive scheduling pattern has been created that ensures fstrim is run at boot-time after 3 days have passed without running it.

In fact, this suggest that, when I bricked my own device when I still used KitKat, I may have actually stumbled upon an fstrim issue, because I left it on the charger that time.

So - we have a firmware issue that causes a risk of bricking a device when fstrim is called. fstrim gets called on boot since Lollipop, but only if it hasn't run at least once during the three preceding days. In normal use, calling fstrim hardly ever bricks a device, but calling it during a firmware upgrade, on boot, highly increases the risk of bricking your device. Hence the reason that different people with the exact same device sometimes did and sometimes didn't end up bricking theirs. It would follow that we need to patch the kernel so that it circumvents the firmware issue on the A2109.

What do you guys think? Please read and reason along, and try to poke holes in my argument!

 

[DBlake]

@DBlake, First of all, thanks for opening your device, much appreciated! I've been searching Ebay a lot, and I only see ads for the PVT and MB versions of the motherboard. Regarding ubuntu - it should be possible with the linux4tegra project, and nvidia provides binaries that should run on our device. However, they do not support recent versions of the Xserver, so that's a problem.

I was thinking more of an Ubuntu Tablet/Touch port. It only requires an Android device tree (I think) to port, as well as some other patches. Since you build android and have Kitkat fully functional (their tree is based on 4.4.2), it shouldn't be that difficult to port. See here: Porting to a new device | Ubuntu developer portal

PS: The linux4tegra project does seem very interesting though, I have to say.

PPS: The SD card port got buggered up when I opened the device up so the SD card port no longer works and I'm not about to open it back up to make any more issues.