Asus Nexus 7 (2013) Wi-Fi/LTE (flo/deb)

[xxhoeckyxx]

Hey, I have read the theart about the port request for the asus nexus 7 (2012) version, maybe the following log-file will hlep I don´t know. Hopefully it will work :)

My devices: Asus Nexus 7 (2013 WIFI) Device Codename: flo Recovery: TWRP official 3.2.2-0 Partition Layout: Unmodified yet ROM: LineageOS 16.0-20190809-UNOFFICIAL-fo Kernel: 3.4.113-followmsi-g02651df2b4c#1 Build-Number: lineage_flo-userdebug 9 PQ3A.190705.003eng.root.20190809.030350dev-keys

repit-dump.log

sorry for my poor english :S and thanks for help

[ipdev99]

Just to add/clarify to this request. The 2013 Nexus 7 WiFI(flo) and LTE(deb) versions share the same partition table. There are a few variations of both devices. Between 16Gig/32Gig versions and/or the chipset used, the only true difference was the last sector of the device. Outside of the last partition (userdata) all the partitions and unused (free space) started and ended at the same sector number. Three chip manufactures (Kingston, Hynix and Toshiba.), were used in both the 16/32Gig WiFi/LTE models. (So technically there are twelve versions of the 2013 Nexus 7.)

Attached is my 16Gig, 32Gig WiFi (Flo) and 32Gig LTE (Deb). Also one I got from another user with a 32Gig WiFI with a different chipset. (32Flo-other)

(Full recovery log and repit-dump log) repit-16Flo-recovery.log repit-32Deb-recovery.log repit-32Flo-other-recovery.log repit-32Flo-recovery.log repit-dump-16Flo.log repit-dump-32Deb.log repit-dump-32Flo-other.log repit-dump-32Flo.log

[Lanchon]

thanks for such a complete request!!!

so i'll just have to take a look now... :(

[Lanchon]

please note that there is a risk involved in trying REPIT. some devices have signed partition tables and will refuse to boot with a modified partition table. you can read about it in the open issues here. in this case, the device would be hard-bricked. typically this protection showed up on later devices (you device is old), and this is the reason ive mostly stopped work on REPIT. i would expect you are not affected, but who knows.

you can use the strings command on an image of the bootloader partition to try get hints regarding GPT signatures. read about it in the GPT signing issues that are open here.

[Lanchon]

strange... your 16Flo has strangely sized and unaligned /system and /cache partition, and different from the other devices. have you modified these partitions manually?

[Lanchon]

here are some test builds for you:

EXTRACT-THIS-ZIP-(nexus-7-2013-test).zip

they can only shuffle space between system and cache. the data partition is separated from these two by a bunch of dangerous partitions that i dont want to move around; a failure could brick the device in case of problems, so data is left out.

by flashing as-is you would get 0.5 GB extra space in system.

a strange thing about both devices is that they seem to have ext2 system partitions instead of ext4. this is very weird, ive never seen it before. repit does not really support ext2, but ext4 can mount ext2. so could work or not, i don't know. test it.

if it doesn't work, you can force it to work by asking REPIT to wipe system and later reflash whatever you were using from recovery. all repit operations should be very quick on this device.

[Lanchon]

BTW, xxhoeckyxx's /system is ext4 as expected. so i guess it's your hacking that changed that for sure :)

[ipdev99]

Finally had time to give it a try.

It was a little over a year ago when I grabbed those logs. Thought they were my original ones before the hackery started. ;)

My 16/32 WiFi and LTE have been modified since then.

I have another 16Gig WiFi (I know I haven't done anything to) I'll dig it out and charge it up (hopefully the battery didn't balloon.) and grab another set of logs.

Meanwhile I reverted my LTE (Deb) as close to stock as I could and ran the test. It worked fine, save for an error on uevent.

Is there a reason you did not start the heap on 1200058 ? We can squeak out a little more by using the free space in-between tzb and system, unless you think this will cause a problem. (?)

[Lanchon]

I reverted my LTE (Deb) as close to stock as I could and ran the test.

you don't need to be stock to run repit! :)

It worked fine, save for an error on uevent.

what do you mean?

I have another 16Gig WiFi (I know I haven't done anything to) I'll dig it out and charge it up (hopefully the battery didn't balloon.) and grab another set of logs.

because of the ext2/ext4 thing? don't worry, i don't think that's necessary.

Is there a reason you did not start the heap on 1200058 ? We can squeak out a little more by using the free space in-between tzb and system, unless you think this will cause a problem. (?)

yes there is. take a look at your partition table, look at all the < 64MB 'free space' slots... see the pattern?

Model: MMC HAG2e (sd/mmc)
Disk /dev/block/mmcblk0: 15032MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start     End       Size      File system  Name      Flags
        0.00MiB   64.0MiB   64.0MiB   Free Space
 1      64.0MiB   149MiB    85.5MiB   fat16        radio
        149MiB    192MiB    42.5MiB   Free Space
 2      192MiB    195MiB    3.00MiB                modemst1
 3      195MiB    198MiB    3.00MiB                modemst2
        198MiB    256MiB    58.0MiB   Free Space
 4      256MiB    271MiB    14.6MiB   ext4         persist
        271MiB    320MiB    49.4MiB   Free Space
 5      320MiB    321MiB    0.76MiB                m9kefs1
 6      321MiB    322MiB    0.76MiB                m9kefs2
        322MiB    384MiB    62.5MiB   Free Space
 7      384MiB    385MiB    0.76MiB                m9kefs3
 8      385MiB    388MiB    3.00MiB                fsg
        388MiB    448MiB    60.2MiB   Free Space
 9      448MiB    449MiB    1.46MiB                sbl1
10      449MiB    451MiB    1.46MiB                sbl2
11      451MiB    453MiB    2.00MiB                sbl3
12      453MiB    458MiB    5.00MiB                aboot
13      458MiB    458MiB    0.50MiB                rpm
        458MiB    512MiB    53.6MiB   Free Space
14      512MiB    528MiB    16.0MiB                boot
        528MiB    576MiB    48.0MiB   Free Space
15      576MiB    576MiB    0.50MiB                tz
16      577MiB    577MiB    0.00MiB                pad
17      577MiB    578MiB    1.46MiB                sbl2b
18      578MiB    580MiB    2.00MiB                sbl3b
19      580MiB    585MiB    5.00MiB                abootb
20      585MiB    585MiB    0.50MiB                rpmb
21      585MiB    586MiB    0.50MiB                tzb
        586MiB    640MiB    54.0MiB   Free Space
22      640MiB    1480MiB   840MiB    ext4         system
23      1480MiB   2040MiB   560MiB    ext4         cache
        2040MiB   2048MiB   8.00MiB   Free Space
24      2048MiB   2049MiB   1.00MiB                misc
        2049MiB   2112MiB   63.0MiB   Free Space
25      2112MiB   2122MiB   10.0MiB                recovery
        2122MiB   2176MiB   54.0MiB   Free Space
26      2176MiB   2176MiB   0.01MiB                DDR
27      2176MiB   2176MiB   0.01MiB                ssd
28      2176MiB   2176MiB   0.00MiB                m9kefsc
        2176MiB   2240MiB   64.0MiB   Free Space
29      2240MiB   2240MiB   0.03MiB                metadata
        2240MiB   2304MiB   64.0MiB   Free Space
30      2304MiB   15032MiB  12728MiB  ext4         userdata
        15032MiB  15032MiB  0.01MiB   Free Space

GPT partitions on HDDs are usually aligned on 1MB boundaries. but as you can see, many partitions here are aligned on 64MB boundaries. this is the case of /system.

this is very strange and i've only ever seen it on this device. why did google did this?

well you may have heard of the samsung brickbug debacle involving the galaxy S2, which btw i sort of finally fixed it many years later. it so happens that the emmc (the SSD) on this tablet is the same buggy part of the S2. google added a kernel driver to this tablet to patch the emmc's firmware to make it behave better, but it is clear that they still didn't have much confidence on the thing.

partitions 15 through 21 are very small and total around 10MB. then a 54MB chunk of free space follows, aligning the next partition (/system) to 64MB. the partitions before /system contain stuff like the early bootloaders, stuff that if damaged will brick the device for good. my guess is that the erase block size of the emmc's flash memory is 64MB. google seems to have attempted to protect these unchanging and vital partitions by putting them outside of any mutable erase blocks, like those of /system.

but the flash translation layer inside the emmc does not map whole erase blocks, but 512B or 4KB sectors. so even if google wrote stuff to fill the 54MB of empty space after writing those partitions, it is still unknown if all this data ended up on a 64MB erase block of flash or spread out across many. if you ask me, this move by google was misguided.

but i choose to err on the safe side and lose 54MB to lessen the small chance of bricking a tablet later during OS flashing. after all, google had all the specs to decide this matter and i don't.

normally the heap would start at say end_of_partition(21) instead of at a literal sector number. but of all devices supported by REPIT, this is the only one to embed a literal number there instead of a lookup.

on the other hand, the 8MB free space after /cache has no reason whatsoever to be there, so i took it out. but you can still restore it by using REPIT with the explicit stock sizes of /system and /cache.

[ipdev99]

Thank you for the detailed answer. :) Never knew about the Samsung Galaxy S2. The Nexus 7 (2013) killed emmc chips (I do not remember the update). Kingston chips were the weakest but, they were all susceptible. Most of us (who have modified our devices), used the free space when repartitioning. Did not seem to be a problem using custom roms, although now I might think safer.

As for the uevent error. I'm not sure when I actually started getting this error, might be TWRP/Device related. I reset my Deb and saved (attached) the recovery.log

recovery.log repit-dump.log

[Lanchon]

It worked fine, save for an error on uevent.

As for the uevent error. I'm not sure when I actually started getting this error, might be TWRP/Device related.

i still don't understand whether repit worked or not on your device. if it didn't work, i'd need to see a repit log to fix it.

[ipdev99]

The repartitioning worked perfect. The repit-dump.log I attached to my last comment was after running repit. System is enlarged and cache is reduced. 22 640MiB 2016MiB 1376MiB ext4 system 23 2016MiB 2048MiB 32.0MiB ext4 cache

Thank you. I appreciate it and looking forward to flo/deb making to your official releases.

[Lanchon]

published!

the only difference between your test builds and the releases is the addition of this comment:

# This port was possible thanks to the invaluable help of ipdev99 and xxhoeckyxx.

thanks again!