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

so what about our bricked devices what to do about them ??
I've put up a little fundraiser to subsidise new system boards for @killer2020 and @johan111. My aim is to gather 60 euros. I'm pledging 10 myself, so we only have 50 to go! Please let me know if you want to donate. Remember, two new system boards means that we keep to testers on board, and it's a way for us to express our thanks to those who have bravely and unfortunately tested a borked upgrade.

If you donate, then please either post the amount here, or PM me, so I can put the amount online anonymously, so we can track our target together.

Thanks!
 
So, I think I was able to change the sources so that the updater-script formats system on upgrade. Remember, I'm still waiting to hear who wants to test... Any volunteers?
 
Me, can I install it through the cm recovery without any further steps(commands, whatever)?
Thanks,

Sent from my SM-N910P using Tapatalk
 
Last edited:
Me, can I install it through the cm recovery without any further steps(commands, whatever)?
That indeed should be the case now, but let me try myself first. With my secondary tablet, I'll reinstall kitkat first and then do a direct upgrade. I'll PM you with a link to the package when I'm done testing.

THANKS!

Who else? :)
 
Okay so for me everything WORKED RIGHT! I installed 5.1 nano gapps right after I installed the ROM and it booted. First boot took ages but its definitely worth it because in my opinion the tablet runs much smoother now.
Oh and Hardware rotation button WORKS NOW
 
Last edited:
That indeed should be the case now, but let me try myself first. With my secondary tablet, I'll reinstall kitkat first and then do a direct upgrade. I'll PM you with a link to the package when I'm done testing.

THANKS!

Who else? :)

Can I take part in the test of this new rom?
 
Install it with the old 6.0.5.1 recovery?
Thanks,

Sent from my SM-N910P using Tapatalk
 
Small update, things are not looking very bright. Jeremy's tablet has been successfully upgraded, but Jam's tablet might well be beyond repair. The last thing that comes to mind is the kernel, since it deals with the differences between the various versions of the A2109 (I think there are three or four). But it still sounds rather far fetched.
 
Status update.

Currently, we have three bricked devices and three successfully upgrade devices, and I don't know what distinguishes them. In fact, @jam97's device appears to be identical to mine and to @jeremy6652's devices. I have no firm hypothesis left to go on, after having so thoroughly tested various upgrade scenarios that all succeeded with my devices. In fact, those lead me to believe that the problem is with the kernel, and not with the rest of the rom. First, this is what I learnt about differences between different devices.

There are a few places in which different A2109's can differ. If you do as root

Code:
# dmesg
(the hash sign being the root prompt), you'll notice, very early on, something like:

Code:
<4>[    0.000000] hw_ramcode is 0
<4>[    0.000000] board_strap is 1

These denote different kinds of ram (Hynix, Samsung or Elpida), as can be seen in /arch/arm/mach-tegra/board-kai-memory.c:

Code:
int kai_emc_init(void)
{
        int hw_ramcode;
        hw_ramcode = tegra_get_hw_ramcode();
        printk("hardware ramcode is %d\n", hw_ramcode);
        switch (hw_ramcode) {
        case 0: /* ELPIDA */
                tegra_init_emc(cl2n_dvt_emc_tables_Elpida_1GB_EDJ4216EBBG_DJ_F_ddr3,
                       ARRAY_SIZE(cl2n_dvt_emc_tables_Elpida_1GB_EDJ4216EBBG_DJ_F_ddr3));
                break;
        case 1: /* HYNIX */
                tegra_init_emc(cl2n_dvt_emc_tables_Hynix_1GB_H5TC4G63MFR_H9A_ddr3,
                       ARRAY_SIZE(cl2n_dvt_emc_tables_Hynix_1GB_H5TC4G63MFR_H9A_ddr3));         
                break;
        case 2: /* SAMSUNG */
                tegra_init_emc(cl2n_dvt_emc_tables_Samsung_1GB_K4B4G1646B_HYH9_ddr3,
                       ARRAY_SIZE(cl2n_dvt_emc_tables_Samsung_1GB_K4B4G1646B_HYH9_ddr3));
                break;
        case 3:
        default:
                tegra_init_emc(kai_emc_tables_elpida_1gb_edj4216ebbg,
                       ARRAY_SIZE(kai_emc_tables_elpida_1gb_edj4216ebbg));
    break;
        }

        return 0;
}

The board_strap think, looking at the source, I suspect directly corresponds to proc/board_version ; A00=0x7; B00=0x5; C00=0x3; D00=0x1.

Another thing is to look in:

Code:
# cat /proc/board_version

Which can be A00, B00, D00 or D00, or UNKNOWN.

A final bit of information can be found in the sources for the jsa1127 driver:
Code:
/* Check board ID*/    
int cl2n_board_id = cl2n_get_board_strap();

if(cl2n_board_id==CL2N_BOARD_VER_A00)//EVT
{
    jsa1127_data.compensate_rate = 50;
    jsa1127_data.resolution = DEFAULT_RESOLUTION_R100K ;
    printk("(%s)Check board ID:EVT \n",__FUNCTION__);
}
else if(cl2n_board_id==CL2N_BOARD_VER_B00)//DVT1/DVT2
{
    char buf[10];
    cl2n_get_attribut("/sys/block/mmcblk0/device/name",buf);

    if(!strcmp(buf,"SEM16G"))
    {                      
        //DVT1
        jsa1127_data.compensate_rate = 50;
        jsa1127_data.resolution = DEFAULT_RESOLUTION_R100K ;
        printk("(%s)Check board ID:DVT1, %s \n",__FUNCTION__,buf);
    }
    else
    {
        //DVT2
        jsa1127_data.compensate_rate = 40;
        jsa1127_data.resolution = DEFAULT_RESOLUTION_R800K ;
        printk("(%s)Check board ID:DVT2, %s \n",__FUNCTION__,buf);
    }
}
else//PVT/MP
{
    jsa1127_data.compensate_rate = 40;
    jsa1127_data.resolution = DEFAULT_RESOLUTION_R800K ;
    printk("(%s)Check board ID:PVT/MP \n",__FUNCTION__);
}

This is interesting, because at least the codes "PVT" and "MP" correspond with what's printed on the system boards that I've had. My MP one was from my first device that I bricked. My current ones are both PVT, as are those of @jeremy6652 @jam97.

I assume that a total of at least five versions have been made. A value of A00
in /proc/board_version corresponds with EVT; D00 and C00 correspond with either PVT or MP, and B00 corresponds to DVT1 or DVT2, depending on the contents of
Code:
/sys/block/mmcblk0/device/name
 
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
 
Back
Top