Q: Are you Dead?
A: No. But on these day, I'm do something else (learning C/Python). I will come back in some day.
This is an experimental kernel based on the latest Air kernel(v4.4). I patched and re-config the kernel for testing and/or for fun.
My patches will never ever comes into other kernels.
1. using ext4 subsystem for ext2/3.
A very funny thing is Air kernel enabled "using ext4 subsystem for ext2/3", but independent ext2 support enabled, too.
I know It is insignificant for the performance. But that makes me feel sick So I disabled independent ext2 support to get a smaller(0.5kb lower?) kernel.
2. using the BFS scheduler.
For small systems, the default scheduler - CFS, is a very complex things, and complex code cause a low performance in embedded systems. BFS is a simple scheduler for embedded systems. It can makes the CPU go faster. In fact, some people think it makes Android UI slower than before.
BFS is written by Con Kolivas.
For more information, you can visit Con Kolivas blog: http://ck-hack.blogspot.com/
3. UKSM
Linux kernel uses KSM to merging same pages for KVM virtual machine. Cyanogenmod modified Android, so KSM can work with Dalvik too. And we can get more RAMs. UKSM is a new project, it more powerful than KSM. It works without any modify. UKSM will scan all data in memory and merge them.
UKSM is a Chinese project, and it's still in development.
You can visit http://http://kerneldedup.org/en to learn more. But there only one page is available in English now.
Usage of UKSM: http://kerneldedup.org/en/projects/uksm/uksmdoc/usage/
4.Deadline for default I/O scheduler. (In v0.06)
CFQ cause low boot performance and missing app icons on my phone. So I set deadline for default scheduler.
WARNING: Don't use it with Jelly Bean, if you do it, your phone will unable to boot, unless you flash a Jelly Bean's kernel.
Latest version
The latest version is v0.09.
All version (included broken/buggy kernel) downloads: http://biergaizi.info/pub/
Voodoo color
It has Voodoo color only(no 65fps or blue color)
Download: http://biergaizi.info/pub/[BFS returns][Air kernel 4.4][0.09][voodoo-color].zip
65fps+Blue color
It has 65fps + blue color.
Download: http://biergaizi.info/pub/[BFS returns][Air kernel 4.4][0.09][65fps+blue].zip
Known Issue:
1.Random crashes/reboots.
Note1: I think it's a upstream issue.
Note2: Issue 1 was no longer exist in v0.06
Found a bug?
If you phone is crashed or auto-rebooted, please type this command after you first reboot:
cat /proc/last_kmsg > /sdcard/kernel_log.txt
Then you can find a file in your sdcard(usb mass storage) and its name is kernel_log.txt
Please reply and upload it for attach file, it can help me to solve the problem.
The source code is available from patches, sources on Github will remove soon:
http://biergaizi.info/pub/sources/
About the version number:
My zips' name are follow these rules:
[BFS returns][Air kernel x.x][x.x][voodoo-color]
.......^...............^.............^...........^
..Codename..Based on what...Main.....voodoo-color or
.....................version of....version....65fps+blue color
.....................Air kernel.....number
For example, [BFS returns][Air kernel 4.4][0.05][voodoo-color] is stand for:
the kernel's codename is 'BFS returns', based on Air kernel 4.4, the main version number is 0.05, and this kernel is a voodoo-color-kernel.
And I must talk about the main version number:
...x.........................xx..................x...............-...x.
...^..........................^..................^..................^
."Milestone".............times of.............small fix for.....complied version or zipped
version with major.....small changes......this release...version (changed kernel
....changes..........................................................config, version of gcc,
.........................................................................or fixed a broken zip file)
For example:
0.05 is stand for no major changes, and the fifth time of release with small changes, no small fix for it, just complied one time.
Q&A:
What is a scheduler?
Your computer often has 1-8 CPUs only, a CPU can do one thing in one time only. But you can run 500 processes on it. Why? Because scheduler switches processes. For example, You have 1 CPU only, and you opened 100 processes, scheduler will let one process run some time, and interrupt it, then let the next process run. So, there is a single process running only. But CPU is very fast, and scheduler switches them quickly, so you can't feel it.
How long does the scheduler let one process run? Different schedulers have different answers. But all of them are using algorithms to schedule process rational.
The history of CFS & BFS?
5 years ago, there was a scheduler called CFS. It's a very high performance scheduler, so it replaced O(1) scheduler when it merged. Facts have proved that, it is really high performance, because it can use on a supercomputer with 4096 CPUs.
On a supercomputer, a priority is very important and useful. Because many people are connecting to the supercomputer and work on it, so, you must specify the priority to people, to share the resources fairly. CFS is this kind of scheduler: it has advanced priority system. Such as group scheduled, so we can specify the priority to every single user & usergroup.
But, Does the most people use the supercomputer??
For me, I still use a computer with legacy device: a Pentium M CPU sometimes. And I use SCMs, such as a MP3 player, or devices with ARM chips, such as routers, iDevices, and my Nexus S smartphone.
By design, CFS will use on everywhere. So, it can't optimize for the device you are use. For example, we still use a supercompuer to elaborate it: priority is important on the supercomputer, but how about on the SCMs or smartphones? There are only one user at the same time. But, CFS is trying to compute the priority of the users every second!! These things are useless on low-performance-devies, and cause the low performance. It really not optimized for the low-performance-devices.
So, Con Kolivas, the designer of CFS (he just wrote some paper for it, the developer is Ingo Molnár. He also is the developer of O(1), wroto CFS before Con Kolivas. Con Kolivas is very angry for that) wrote a new scheduler for low-performance-devices, called BFS, Brain **** Scheduler. Why Brain ****? Because it very easy and simple, and kind of stupid scheduler, but it can improve performance on low-performance-devices. It removed some "awesome" design, such as advanced priority, but a stupid and simple one, etc.
It really a bad scheduler for 8-core-systems, and a terrible scheduler for 16-core-systems. But a great system with single-core and dual-core. Con Kolivas said it will never be in to the mainline Linux kernel, because it isn't a general scheduler, but I will keep update for it outside the mainline kernel code.
But now, CFS is better than before too. Lots of people think, CFS is the winner now.
Tell me something about UKSM.
This is an improvement upon KSM.
Its new features:
1. Full system scan:
It automatically scans all user processes' anonymous VMAs. Kernel-user
interaction to submit a memory area to KSM is no longer needed.
2. Rich area detection:
It automatically detects rich areas containing abundant duplicated
pages based. Rich areas are given a full scan speed. Poor areas are
sampled at a reasonable speed with very low CPU consumption.
3. Ultra Per-page scan speed improvement:
A new hash algorithm is proposed. As a result, on a machine with
Core(TM)2 Quad Q9300 CPU in 32-bit mode and 800MHZ DDR2 main memory, it
can scan memory areas that does not contain duplicated pages at speed of
627MB/sec ~ 2445MB/sec and can merge duplicated areas at speed of
477MB/sec ~ 923MB/sec.
4. Thrashing area avoidance:
Thrashing area(an VMA that has frequent Ksm page break-out) can be
filtered out. My benchmark shows it's more efficient than KSM's per-page
hash value based volatile page detection.
5. Full Zero Page consideration(contributed by Figo Zhang)
Now uksmd consider full zero pages as special pages and merge them to an
special unswappable uksm zero page.
How to tweak UKSM?
http://kerneldedup.org/en/projects/uksm/uksmdoc/usage/
You are just add BFS patch to Air kernel, the kernel is useless, everyone can do it!!!
Yes, I am a patcher and a compiler. Some kernel in XDA, also just add some patch and small hack to improve proformance. And users will not compile their own kernels, right? I'm doing the same thing. I will do more work soon.
Catalog:
Jul.24.2012 | 0.09:
1. Backported Codel queue management algorith from Linux 3.5.
Jul.23.2012 | 0.08:
1. Updated kernel source to Linux 3.0.38!
P.S: This time I didn't just copy r_data's code, I did it by myself. Because r_data is working on Jelly Bean's kernel and forgot to update this kernel!
Jul.15.2012 | 0.07:
1. New UKSM patchset.
2. r_data just updated him version information.
Jun.28.2012 | 0.06:
1. New UKSM patchset.
2. Deadline for default I/O scheduler.
3. Based on real Air kernel 4.4, not 4.3 weekly.
Jun.23.2012 | 0.05:
1.Updated kernel source code to Air kernel 4.4.
2.ext2/3 mounted by ext4 subsystem.
3.UKSM replaced KSM.
Apr.09.2012 | 0.03:
1.Update kernel source code to Air kernel 3.9.5.
2.There are not High Bigmem/Non-High Bigmem versions, because I don't want to build 4 versions. And I don't know my kernel is a what version. I think it's a High Bigmem version.
3.Source code are not on Github yet.
Apr.08.2012 | 0.02:
1.Use r_data's config, a major update!
2.Based on Air Kernel 3.9
3.Fix a BFS of bug.
4.Source code are not on Github yet!
5.[Apr.09]Quickfix: Fix the bad zip file.
Apr.05.2012 | 0.01:
1.First release.
2.Based on Air Kernel 3.8
3.BFS kernel.
biergaizi said:
Catalog
Apr.05.2012 | 0.01:
1.First release.
2.Based on Air Kernel 3.8
3.BFS kernel.
Click to expand...
Click to collapse
I'm a huge fan of Air. I don't really get the idea of how BFS can improve an already awesome kernel, but I'll give it a try, and report back asap. Thanks for your work.
EDIT: Sorry, still not as smooth as Air. Going back to v3.8. Good job anyway. Cheers!
Sent from my Nexus S
apatal said:
I'm a huge fan of Air. I don't really get the idea of how BFS can improve an already awesome kernel, but I'll give it a try, and report back asap. Thanks for your work.
EDIT: Sorry, still not as smooth as Air. Going back to v3.8. Good job anyway. Cheers!
Sent from my Nexus S
Click to expand...
Click to collapse
I'm sorry for that. Because I just want to add latest BFS to the kernels for somebody who want to try it (included me). And I use Linux a long time, I just want to learn how to compile Android kernel.
But I can't get r_data's kernel config file, and I don't know his Email address. So, I write a terrible one. This kernel has lots of bugs. I think you was saw the version number of it, 0.01
I will still improve it.
Thanks.
I did a comparison of the performance of bfs and cfs a while back using the two kernels that provided both, Matr1x and GlaDOS. CPU scores improved with bfs but graphics deteriorated and i noticed UI lags with bfs. The results are still available to view on the kernel spreadsheet (see link in my signature).
kernels ; battery ; ROM ; gov/sched
Now with summaries in the first posts. Convenient for XDA app users!
Because BFS use interrupts for multitasking, so it cause UI lags. But the overall performance should improved I think.
Your test proved it. Thanks
biergaizi said:
because bfs use interrupts for multitasking, so it cause ui lags. But the overall performance should improved i think.
Your test proved it. Thanks
Click to expand...
Click to collapse
终于! 有个中国人开始写内核了, 支持支持~~~
biergaizi said:
Because BFS use interrupts for multitasking, so it cause UI lags. But the overall performance should improved I think.
Your test proved it. Thanks
Click to expand...
Click to collapse
I am curious... You said earlier you wanted to develop a kernel to use BFS... but then you said you "found" r_data's config file.... meaning he didn't give it to you, so you haven't actually "developed" anything... so that you can add a scheduler for users who typically don't use BFS.
By Bedalus' own own testing, the BFS causes some lags in UI functions, but "may improve overall system performance".
So I am curious; when there are well developed, and tested kernels like Matr1x, Glados, Steve Garon's, and the official Air Kernel with amazing performance, speed, smoothness and responsiveness, what benefit does your kernel offer?
I am a consummate kernel flasher, and guess I would like to know your sales pitch. You know benefits, etc.
While I try many kernels, I try none without some research first. and so far, sooner than later I return to Air Kernel for it's stability and responsiveness.
Thanks
Steviemac12 said:
I am curious... You said earlier you wanted to develop a kernel to use BFS... but then you said you "found" r_data's config file.... meaning he didn't give it to you, so you haven't actually "developed" anything... so that you can add a scheduler for users who typically don't use BFS.
.......
So I am curious; when there are well developed, and tested kernels like Matr1x, Glados, Steve Garon's, and the official Air Kernel with amazing performance, speed, smoothness and responsiveness, what benefit does your kernel offer?
Click to expand...
Click to collapse
C'mon, give the kid a break, he's got his heart in the right place
It's open source and on a git somewhere; he is also crediting r_data.
So although it still isn't a very compelling kang of the Air kernel, he hasn't done anything sleazy.
Sent from my Nexus S using xda premium
motorator said:
C'mon, give the kid a break, he's got his heart in the right place
It's open source and on a git somewhere; he is also crediting r_data.
So although it still isn't a very compelling kang of the Air kernel, he hasn't done anything sleazy.
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
My apology... never said he did anything "sleazy". Re-reading now, It came off a bit... well not exactly as I intended.
Just trying to understand where he is going with his project.
Again... biergaizi no offense intended. I think I am having sour grapes (jealous) because I wish I could learn to do what you guys do.
will give this one a try and maybe I can be more constructive.
Thanks Motorator for the kick in the pants..
I'm in the same boat as you in that I wish I knew how to code or at least compile some of this stuff.
Don't take it the wrong way. I didn't mean anything harsh; I just don't want young'uns like the OP to get discouraged.
Maybe this gets traction, or maybe it goes the way of most hobby coding projects. Whichever it is, we should at least let him try
Sent from my Nexus S using xda premium
motorator said:
I'm in the same boat as you in that I wish I knew how to code or at least compile some of this stuff.
Click to expand...
Click to collapse
+1 on this.
I've been hanging out in this forums and I'm getting an itch to start contributing as well, that is, contributing beyond merely test-driving their creations and actually coming out with something useful myself.
I even have the beginnings of a plan on how to go about it. Wish me luck!
apatal said:
I even have the beginnings of a plan on how to go about it. Wish me luck!
Click to expand...
Click to collapse
All the best with your plan. I hope you succeed and motivate us all to also take part :thumbup:
Sent from my Nexus S using xda premium
Nice try, and keep on going.
Steviemac12 said:
I am curious... You said earlier you wanted to develop a kernel to use BFS... but then you said you "found" r_data's config file.... meaning he didn't give it to you, so you haven't actually "developed" anything... so that you can add a scheduler for users who typically don't use BFS.
By Bedalus' own own testing, the BFS causes some lags in UI functions, but "may improve overall system performance".
So I am curious; when there are well developed, and tested kernels like Matr1x, Glados, Steve Garon's, and the official Air Kernel with amazing performance, speed, smoothness and responsiveness, what benefit does your kernel offer?
I am a consummate kernel flasher, and guess I would like to know your sales pitch. You know benefits, etc.
While I try many kernels, I try none without some research first. and so far, sooner than later I return to Air Kernel for it's stability and responsiveness.
Thanks
Click to expand...
Click to collapse
In Linux community, there are lots of people don't develop anything, but just compile the source code into binary. And do you know Zen Kernel? It just add other hacker's(not in mainline kernel)patches into it.
Why I can't do the same thing in XDA
qtwrk said:
终于! 有个中国人开始写内核了, 支持支持~~~
Click to expand...
Click to collapse
谢谢支持。看来Unicode还是很强大的。
-------------------------
Unicode is really a great characterset.
biergaizi said:
In Linux community, there are lots of people don't develop anything, but just compile the source code into binary. And do you know Zen Kernel? It just add other hacker's(not in mainline kernel)patches into it.
Why I can't do the same thing in XDA
Click to expand...
Click to collapse
Please accept my apology. Sometimes I talk out of my ass and this was one of those times.
Wish I could do what you are doing.
Sent from my Nexus S using xda premium
Just flashed this kernel and I think it's pretty snappy, I think basing it on Air Kernel is a good idea. I would say that this is something we're missing here in the NS forums is a Kernel based on BFS, I know most kernels come with the option of either, but a focused BFS kernel is certainly not a bad thing, I used to love it back in my days on the Desire.
I remember the days of compiling kernels for my Linux boxes when I was younger, I now just let updates decide what's best since I was constantly tinkering and getting it wrong.
toyface said:
Just flashed this kernel and I think it's pretty snappy, I think basing it on Air Kernel is a good idea. I would say that this is something we're missing here in the NS forums is a Kernel based on BFS, I know most kernels come with the option of either, but a focused BFS kernel is certainly not a bad thing, I used to love it back in my days on the Desire.
I remember the days of compiling kernels for my Linux boxes when I was younger, I now just let updates decide what's best since I was constantly tinkering and getting it wrong.
Click to expand...
Click to collapse
I'm using Linux everytime. And I'm carzy, I think install from source will get a high performance(because I was had a laptop with legacy hardware, compile packages with march= is really works). So, I using Gentoo, compile everything.
But I'm also a funs of Fedora.
If today I'm lazy to compile:
I will boot Fedora
Else:
I will boot Gentoo
Lenovo Tab 3 8/TB3-850F
Stock Android 6.0 Marshmallow ROM
Rooted, BusyBox, Zipaligned
TWRP Flashable Installer
DISCLAIMER:
By proceeding further, please take note that your warranty will be null and void. You hereby take full responsibility for any positive or negative consequences which may incur by installing this ROM and, in doing so, you are absolving me from any liability in the event that your device gets bricked or is otherwise rendered inoperable. This ROM has been thoroughly tested. Follow the instructions carefully and pay attention to detail and things should go smoothly and without incident.
Note:
For members interested, I should note that I have compiled a build of this ROM with up-to-date security patches (June 1, 2018) and several custom features, which I will be posting in the next couple of days.
DESCRIPTION:
This is a Stock Android 6.0 ROM for the Lenovo Tab 3 8/TB3-850F. This ROM should also be compatible with the LTE variant of this device (TB3-850M), but such compatibility has not been confirmed. This ROM is the most current stock build available for the TB3-850F.
SPECIFICATIONS & FEATURES:
•Android Version: 6.0 Marshmallow
•Build No. TB3-850F_S100031_171010_ROW
•Software Version: TB3-850F_160412
•Kernel Version: 3.18.19
•Android SDK: 23
•Security Patch Level: September 5, 2017
•Build ID: MRA58K
•Build Date: October 10, 2017
•Root: Magisk v16.7-beta (Systemless)
•SafetyNet Pass (ctsProfile & basic integrity)
•BusyBox: v1.28.4 (Static Binaries) /system/bin/
•Zipaligned: /system/app & /system/framework
•Force Encryption Disabled
•dm-verity Disabled
•Init.d & su.d Support
•Optimized for Low RAM
•TWRP Flashable Installer
INSTRUCTIONS/REQUIREMENTS:
First and foremost, your device must have an unlocked bootloader and you must have TWRP custom recovery installed. If you need instructions on doing this, please see my thread here: https://forum.xda-developers.com/android/general/guide-lenovo-tab3-8-tb3-850f-t3559786 Also, because installation requires the /userdata partition to be formatted, an external microSD card is needed.
1. Download the ROM zip from the below download link and save it to external storage;
2. Boot your device into TWRP recovery mode;
3. On TWRP's main screen, select Wipe>>Advanced Wipe and select Cache & Dalvik, then swipe to commence wiping;
4. Again, on the main screen, select Wipe and then select Format Data in the lower right of your screen. Swipe to commence formatting (this step is crucial for the disabling of force encryption);
5. Select Install, navigate to the location of the ROM zip, select it and swipe to commence installation (takes 3 to 4 minutes);
6. Reboot System;
BUGS:
No known or reported bugs...Please report any bugs or instabilities in comments.
Open Source Code: https://pcsupport.lenovo.com/us/en/...ies/tab3-8/za17/za170001us/downloads/ds112711
Mentions/Thanks:
•Thanks to @pndwal for his support on this device and assistance in my absence.
•Thanks to @osm0sis for his static BusyBox installer and Magisk Module.
•Thanks to @topjohnwu for his legendary and world famous Magisk Systemless Interface.
•Thanks and credit to the brilliant coder, @SuperR., for his superb Windows version Kitchen.
•Thanks to @Hemphiz for breaking ground on the Tab 3 8" and for his guidance.
Download Links:
TB3-850F_S100031_171010_ROW: https://drive.google.com/file/d/1pKu1If-9Y9adeigUe5-HEBbqmFej5zYB/view?usp=drivesdk
Lenovo Tab 3 8/TB3-850F
User Manual (English) PDF: https://drive.google.com/file/d/18gCTfuZecJnlB0ddBIN02YPaDpuvmzov/view
Installing now, will report after review!
Sent from my Redmi Note 5 using Tapatalk
LineageOS and RR ports for this device are coming along decent. The trick is not the ROM itself on /system, but rather the kernel/ramdisk, which was specifically compiled for the TB3-850M chipset. Soon as I get a bootable kernel, we are in business with Nougat for TB3-850F.
MotoJunkie01 said:
LineageOS and RR ports for this device are coming along decent. The trick is not the ROM itself on /system, but rather the kernel/ramdisk, which was specifically compiled for the TB3-850M chipset. Soon as I get a bootable kernel, we are in business with Nougat for TB3-850F.
Click to expand...
Click to collapse
That's good news. Look forward to trying.
If it helps, I kept the original Lenovo box sticker for TB3-850F. It says: CPU:MT8161P QC 1.0GHZ 64BIT. (So it seems on-line information, Kernel Auditor, Phone Tester and CPU-Z etc, are in fact reporting CPU / Vendor correctly as MT8161P.)
I was interested in this for overclocking potential, but it may help streamlining kernel for chipset. (I guess CPU speed may still be crippled by MT6735 hardware / SoC.)
Hope you get it booting. PW.
The rom works great, much better then stock!
Battery life is very good and speed is much better!!
Thank you!
Sent from my Redmi Note 5 using Tapatalk
pndwal said:
That's good news. Look forward to trying.
If it helps, I kept the original Lenovo box sticker for TB3-850F. It says: CPU:MT8161P QC 1.0GHZ 64BIT. (So it seems on-line information, Kernel Auditor, Phone Tester and CPU-Z etc, are in fact reporting CPU / Vendor correctly as MT8161P.)
I was interested in this for overclocking potential, but it may help streamlining kernel for chipset. (I guess CPU speed may still be crippled by MT6735 hardware / SoC.)
Hope you get it booting. PW.
Click to expand...
Click to collapse
This is still quite perplexing. It does appear there are two variants of the TB3-850F -- an MT8161P variant and an MT6735M variant. Although SP Flash Tool and the scatter file both indicate that my chipset is the MT6735M, I went as far as to disassemble my device to check the nomenclatures on my logic board -- which, to no surprise, is the MT6735M. Since the MT6735M and the MT8161P are in fact two entirely different chipsets, the only logical conclusion is that there are two variants to the TB3-850F. Curiously however, both chipsets are listed under MediaTek's specs as being arm64 architecture with a max clock of 1.0 GHz and 1GB RAM. My RCA Voyager tablet runs on the MT8161P and performs nearly exactly like my Tab 3 8.
MotoJunkie01 said:
This is still quite perplexing. It does appear there are two variants of the TB3-850F -- an MT8161P variant and an MT6735M variant. Although SP Flash Tool and the scatter file both indicate that my chipset is the MT6735M, I went as far as to disassemble my device to check the nomenclatures on my logic board -- which, to no surprise, is the MT6735M. Since the MT6735M and the MT8161P are in fact two entirely different chipsets, the only logical conclusion is that there are two variants to the TB3-850F. Curiously however, both chipsets are listed under MediaTek's specs as being arm64 architecture with a max clock of 1.0 GHz and 1GB RAM. My RCA Voyager tablet runs on the MT8161P and performs nearly exactly like my Tab 3 8.
Click to expand...
Click to collapse
Yes, you may be right, but perhaps not the only logical conclusion. My thinking is that there may be one variant with MT8161P CPU and MT6735M board chipset. (Eg. Kernel Auditor gives MT8161p as vendor, but MT6735 as hardware, and build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P). This would most likely mean MT8161P CPU functionality would be somewhat limited by MT6735M chipset, even though the two must be compatible. Of course, if you found MT6735M printed on your main chip (CPU), this theory would be wrong, and there could in fact be a number of variations.
I mentioned earlier: 'Phone Tester gives CPU Info: MT8161p. Kernel Auditor gives MT8161p as vendor, but MT6735 as hardware. CPU-Z gives MT6735 as SoC. Build.prop gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P. Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)'
Also, the MT8161p CPU specs I found say 1.3 GHz (although TB3-850f is limited to 1.0 GHz), hence my assumption that a kernel modified to allow overclocking should achieve 30% boost easily easily and perhaps 1.7 GHz or so would be achievable.
If you did find MT6735M printed on your main chip (CPU), I'm happy to try to disassemble mine to see if it's a different variant. (Guessing this would confirm my original TB3-850F Lenovo box sticker which says CPU:MT8161P QC 1.0GHZ 64BIT).
I'll do more digging into this if you think it may help with port or overclocking.
Hope it leads to some improvements anyway. Thanks for your efforts with our device. PW.
pndwal said:
Yes, you may be right, but perhaps not the only logical conclusion. My thinking is that there may be one variant with MT8161P CPU and MT6735M board chipset. (Eg. Kernel Auditor gives MT8161p as vendor, but MT6735 as hardware, and build.prop also gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P). This would most likely mean MT8161P CPU functionality would be somewhat limited by MT6735M chipset, even though the two must be compatible. Of course, if you found MT6735M printed on your main chip (CPU), this theory would be wrong, and there could in fact be a number of variations.
I mentioned earlier: 'Phone Tester gives CPU Info: MT8161p. Kernel Auditor gives MT8161p as vendor, but MT6735 as hardware. CPU-Z gives MT6735 as SoC. Build.prop gives ro.board.platform=mt6735m, but also ro.lenovo.cpuinfo=MT8735P. Russian 4PDA forum gives 850f Processor Type: MT8161, with MT8735 for 850M variant. (http://4pda.ru/devdb/lenovo_tab3_8:850f)
So it's hard to know what or who's correct, but looks to me that newer CPUs have likely been installed on boards originally designed for MT6735. (My CPU could actually be MT8735 as given by build.prop if Lenovo had excess chips from 850M, or simply decided to use these in both models. - I guess they may even have started with MT6735 for 850f before progressively using MT8161 and MT8735.)'
Also, the MT8161p CPU specs I found say 1.3 GHz (although TB3-850f is limited to 1.0 GHz), hence my assumption that a kernel modified to allow overclocking should achieve 30% boost easily easily and perhaps 1.7 GHz or so would be achievable.
If you did find MT6735M printed on your main chip (CPU), I'm happy to try to disassemble mine to see if it's a different variant. (Guessing this would confirm my original TB3-850F Lenovo box sticker which says CPU:MT8161P QC 1.0GHZ 64BIT).
I'll do more digging into this if you think it may help with port or overclocking.
Hope it leads to some improvements anyway. Thanks for your efforts with our device. PW.
Click to expand...
Click to collapse
I see what you're saying, but let me emphasize that the board and the chipset are the same entity. If a device has an MT6735M CPU, it's hardware (or board platform) is also MT6735M. And vice versa for the MT8161P. The MT6735M and the MT8161P are both very different CPU/board platforms, but with very similar specs.
Same with Qualcomm, a MSM8909 CPU has an MSM8909 board platform.
The ro.board.platform (build.prop) of my Tab 3 8 has the MT6735M correct, as is my hardware confirmed by disassembly.
For an example, my RCA Voyager 7" tablet has the MT8161P CPU, supported by the MT8161P board platform (chipset).
With MediaTek, a failsafe way of checking hardware specs (aside from disassembly) is using the SP Flash Tool w/scatter file.
There is some room for overclock with the mt6735m. The mt6735 for example (without the "m" suffix) has a max clock of 1.394 GHz. The mt6735m is simply a ramped down version of the mt6735. Hardware wise, the mt6735 and mt6735m are the same. The difference arises in the coding of the kernel/ramdisk configs.
So, you and I agree on overclocking potential, albeit for different reasons.
MotoJunkie01 said:
I see what you're saying, but let me emphasize that the board and the chipset are the same entity. If a device has an MT6735M CPU, it's hardware (or board platform) is also MT6735M. And vice versa for the MT8161P. The MT6735M and the MT8161P are both very different CPU/board platforms, but with very similar specs.
Same with Qualcomm, a MSM8909 CPU has an MSM8909 board platform.
The ro.board.platform (build.prop) of my Tab 3 8 has the MT6735M correct, as is my hardware confirmed by disassembly.
For an example, my RCA Voyager 7" tablet has the MT8161P CPU, supported by the MT8161P board platform (chipset).
With MediaTek, a failsafe way of checking hardware specs (aside from disassembly) is using the SP Flash Tool w/scatter file.
There is some room for overclock with the mt6735m. The mt6735 for example (without the "m" suffix) has a max clock of 1.394 GHz. The mt6735m is simply a ramped down version of the mt6735. Hardware wise, the mt6735 and mt6735m are the same. The difference arises in the coding of the kernel/ramdisk configs.
So, you and I agree on overclocking potential, albeit for different reasons.
Click to expand...
Click to collapse
Thanks for that. Just though lenovo may have decided to use old board stock if pin outs still compatible with newer CPU, but I have no knowledge if this is possible in practice.
From what you're saying seems TB3-850F would have had two or more different sets of box specs, which I had thought would be illogical for one model, but I guess I'm wrong.
I'll open mine up sometime just to physically check chipset is in fact MT8161P as claimed on box. (How can I use scatter file to check specs?)
Guess knowledge of variants produced may prove useful in any case. Thanks for your attention to detail here. Hope port(s) are progressing well. PW.
pndwal said:
Thanks for that. Just though lenovo may have decided to use old board stock if pin outs still compatible with newer CPU, but I have no knowledge if this is possible in practice.
From what you're saying seems TB3-850F would have had two or more different sets of box specs, which I had thought would be illogical for one model, but I guess I'm wrong.
I'll open mine up sometime just to physically check chipset is in fact MT8161P as claimed on box. (How can I use scatter file to check specs?)
Guess knowledge of variants produced may prove useful in any case. Thanks for your attention to detail here. Hope port(s) are progressing well. PW.
Click to expand...
Click to collapse
Thank you also @pndwal for your devotion and support on this device. You have truly delved off deep into both the hardware and software attributes of the Tab 3 8. I, like yourself, truly hope that future development for this tablet yields fruitful.
I have noticed that the official Lenovo user manual for the Tab 3 8 covers both the 850F and the 850M. Likewise, the open source code for our stock OS is for both tablet variants. Interestingly, the 850M LTE variant of the device appears to use the MT8735 board platform which, of course, encompasses an LTE cellular modem. I just recently realized that both the MT8161P and the MT6735M also have LTE cellular modems. I have an acquaintance over at Droid Hub who has a TB3-850F and uses LTE data on his device by way of a simple GSM SIM card micro USB dongle. He changed a few lines in build.prop to enable the Mobile Networks menu in Settings and he uses his device exactly as if it were the 850M variant. I'm going to try the same thing with my 850F.
As far as custom Nougat goes, the only difficulty lies in the kernels for both LOS & RR. Both custom builds have kernels (boot.img) compiled specifically for the 850M's MT8735 chipset. I'm corresponding with a friend who specializes in Linux kernel coding to get some needed assistance on converting the kernels over to 850F specs.
MotoJunkie01 said:
Thank you also @pndwal for your devotion and support on this device. You have truly delved off deep into both the hardware and software attributes of the Tab 3 8. I, like yourself, truly hope that future development for this tablet yields fruitful.
I have noticed that the official Lenovo user manual for the Tab 3 8 covers both the 850F and the 850M. Likewise, the open source code for our stock OS is for both tablet variants. Interestingly, the 850M LTE variant of the device appears to use the MT8735 board platform which, of course, encompasses an LTE cellular modem. I just recently realized that both the MT8161P and the MT6735M also have LTE cellular modems. I have an acquaintance over at Droid Hub who has a TB3-850F and uses LTE data on his device by way of a simple GSM SIM card micro USB dongle. He changed a few lines in build.prop to enable the Mobile Networks menu in Settings and he uses his device exactly as if it were the 850M variant. I'm going to try the same thing with my 850F.
As far as custom Nougat goes, the only difficulty lies in the kernels for both LOS & RR. Both custom builds have kernels (boot.img) compiled specifically for the 850M's MT8735 chipset. I'm corresponding with a friend who specializes in Linux kernel coding to get some needed assistance on converting the kernels over to 850F specs.
Click to expand...
Click to collapse
Nice work by your acquaintance re. LTE from dongle. (Does this somehow use LTE modem in tablet CPU, as I would have thought modem must still be LTE capable to receive LTE data. - or can non LTE modem transfer LTE with CPU support?)
Regarding TB3-850F variants, it seems here are probably a few. TB3-850F is not the full model number. There are also Machine Types (ZA17 for TB3-850F [https://pcsupport.lenovo.com/za/en/products/tablets/a-series/tab3-8/za17/parts/PD104294] and ZA18 for TB3-850M [https://pcsupport.lenovo.com/za/en/products/tablets/a-series/tab3-8/za18/parts/PD104294]), and Machine Type Model No.s. For example, my box label says Machine Type Model No. :ZA170082AU. There is also ZA170001US, etc.
I guess the extension numbers (0082AU etc) identify different variants within the series (TB3-850F, or ZA17), eg different chipsets as we have deduced, as well as other differences (eg. Lenovo's specs mentions 1GB/16GB RAM as well as 2GB/16GB variants of TB3-850F, and Lenovo's Hardware maintenance manual (good photos of internals here too, bit no chipset identification shown) [https://download.lenovo.com/consumer/mobiles_pub/lenovo_tab3_8_hmm_en_v1.0_201604.pdf] lists different parts for black or white models, for 2 MPixel or 5 MPixel rear camera models, and for models with WiFi antenna only or WiFi, BT and GPS in combination it seems.) Seems these variants are largely determined by market location, but 1GB/16GB RAM versions are probably the most common. Hope this helps.
Glad to know you have Linux kernel specialist friend. This will no doubt prove invaluable. I trust you revel in a steep learning curve!
Did a little digging on scatter files. Would I be right in thinking that scatter files generated from different variants might provide enough information to make a kernel work across the 850F range? Regards, PW
pndwal said:
Nice work by your acquaintance re. LTE from dongle. (Does this somehow use LTE modem in tablet CPU, as I would have thought modem must still be LTE capable to receive LTE data. - or can non LTE modem transfer LTE with CPU support?)
Regarding TB3-850F variants, it seems here are probably a few. TB3-850F is not the full model number. There are also Machine Types (ZA17 for TB3-850F [https://pcsupport.lenovo.com/za/en/products/tablets/a-series/tab3-8/za17/parts/PD104294] and ZA18 for TB3-850M [https://pcsupport.lenovo.com/za/en/products/tablets/a-series/tab3-8/za18/parts/PD104294]), and Machine Type Model No.s. For example, my box label says Machine Type Model No. :ZA170082AU. There is also ZA170001US, etc.
I guess the extension numbers (0082AU etc) identify different variants within the series (TB3-850F, or ZA17), eg different chipsets as we have deduced, as well as other differences (eg. Lenovo's specs mentions 1GB/16GB RAM as well as 2GB/16GB variants of TB3-850F, and Lenovo's Hardware maintenance manual (good photos of internals here too, bit no chipset identification shown) [https://download.lenovo.com/consumer/mobiles_pub/lenovo_tab3_8_hmm_en_v1.0_201604.pdf] lists different parts for black or white models, for 2 MPixel or 5 MPixel rear camera models, and for models with WiFi antenna only or WiFi, BT and GPS in combination it seems.) Seems these variants are largely determined by market location, but 1GB/16GB RAM versions are probably the most common. Hope this helps.
Glad to know you have Linux kernel specialist friend. This will no doubt prove invaluable. I trust you revel in a steep learning curve!
Did a little digging on scatter files. Would I be right in thinking that scatter files generated from different variants might provide enough information to make a kernel work across the 850F range? Regards, PW
Click to expand...
Click to collapse
You are very correct in your analysis of extension numbers and variant specs. (By the way on disassembly, I should have mentioned that it is necessary to remove the battery and some of the reinforcement adhesive in order to view the MediaTek nomenclature identifying the SoC.) You are likewise correct on your scatter file analysis. In terms of kernels, since our TB3-850F stock OS is based on Android 6.0_r2, our supporting kernel is version 3.18.19. With the Nougat (7.1.2) LOS and RR custom ROMs to be ported from 850M, we need at least a version 3.18.31 kernel version to boot the ROMs and for hardware blob support. In fact, both ROMs would boot right now and would, in theory, function completely normally if we had a supported kernel. Of course you already know all this so I'm merely thinking out loud so to speak. My colleague (who assisted on the old BlueSpark kernel project for older Motorola smartphones) is helping me compile a Nougat supporting kernel from source. And, since Lenovo did release the source code for the camera drivers for the 850F, custom shims won't be needed and the available blobs can be put in place for fully normal camera function. (Although the cameras appear to be identical on both the 850F and 850M, the difference in SoC platforms gives rise to different hardware blobs.)
Interestingly, and just like the stock OS for our device, the LOS and RR Nougat ROMs are compiled to function on the 850F and 850M. So technically, no porting is needed whatsoever on the ROMs themselves. The only real work is compiling a kernel to boot the ROMs. This is where I hope to gain some much needed knowledge and instruction on the Linux kernel and GCC. To keep you up to date, I can proudly say that a version 3.18.31 kernel is currently being built for the 850F. Soon as it is finished I will plug the custom /system files and new kernel into my Android kitchen and, much like Chef Boyardee, cook up something real proper-like. :silly:
MotoJunkie01 said:
You are very correct in your analysis of extension numbers and variant specs. (By the way on disassembly, I should have mentioned that it is necessary to remove the battery and some of the reinforcement adhesive in order to view the MediaTek nomenclature identifying the SoC.) You are likewise correct on your scatter file analysis. In terms of kernels, since our TB3-850F stock OS is based on Android 6.0_r2, our supporting kernel is version 3.18.19. With the Nougat (7.1.2) LOS and RR custom ROMs to be ported from 850M, we need at least a version 3.18.31 kernel version to boot the ROMs and for hardware blob support. In fact, both ROMs would boot right now and would, in theory, function completely normally if we had a supported kernel. Of course you already know all this so I'm merely thinking out loud so to speak. My colleague (who assisted on the old BlueSpark kernel project for older Motorola smartphones) is helping me compile a Nougat supporting kernel from source. And, since Lenovo did release the source code for the camera drivers for the 850F, custom shims won't be needed and the available blobs can be put in place for fully normal camera function. (Although the cameras appear to be identical on both the 850F and 850M, the difference in SoC platforms gives rise to different hardware blobs.)
Interestingly, and just like the stock OS for our device, the LOS and RR Nougat ROMs are compiled to function on the 850F and 850M. So technically, no porting is needed whatsoever on the ROMs themselves. The only real work is compiling a kernel to boot the ROMs. This is where I hope to gain some much needed knowledge and instruction on the Linux kernel and GCC. To keep you up to date, I can proudly say that a version 3.18.31 kernel is currently being built for the 850F. Soon as it is finished I will plug the custom /system files and new kernel into my Android kitchen and, much like Chef Boyardee, cook up something real proper-like. :silly:
Click to expand...
Click to collapse
Well, you certainly know how to wet one's appetite! - Thanks for the heads-up - Hope you get into the kitchen soon. I'll try to generate scatter file for ZA170082AU soon and post. Thanks, PW
@MotoJunkie01
Sounds like you have a lot if good help. Thought I'd just mention a contributor who whose expert help broke ground for TB3-850F (in @Lister Of Smeg's thread), @Tzul, who may be of assistance.
Interestingly, among other things he wrote:
"I have mentioned this in the other topic you found. It's normal that scatter files sometimes don't list the exact chip type in the platform field. My Tab 2 A10-70F for example has an MT8165, but the scatter file says "platform: MT6752". The name that is used there must exist in the config files of the SPFT (see platform.xml and storage_setting.xml, for example), and the settings that are defined there must be "compatible" with your actual chip type...
I don't think that waiting for SPFT updates will help. Like I wrote above, the Tab 2 A8-50F was based on the same MT8161 chip, and its scatter file lists "platform: MT6735". There's either something strange going on with your Tab3, or it's a driver issue."
All best, PW
pndwal said:
@MotoJunkie01
Sounds like you have a lot if good help. Thought I'd just mention a contributor who whose expert help broke ground for TB3-850F (in @Lister Of Smeg's thread), @Tzul, who may be of assistance.
Interestingly, among other things he wrote:
"I have mentioned this in the other topic you found. It's normal that scatter files sometimes don't list the exact chip type in the platform field. My Tab 2 A10-70F for example has an MT8165, but the scatter file says "platform: MT6752". The name that is used there must exist in the config files of the SPFT (see platform.xml and storage_setting.xml, for example), and the settings that are defined there must be "compatible" with your actual chip type...
I don't think that waiting for SPFT updates will help. Like I wrote above, the Tab 2 A8-50F was based on the same MT8161 chip, and its scatter file lists "platform: MT6735". There's either something strange going on with your Tab3, or it's a driver issue."
All best, PW
Click to expand...
Click to collapse
That's good info to know. And yeah I may just give that member a shout and see if he'd be willing to join forces on developing for the 850F. A small development team would be nice -- and you would be more than welcome to be a part. You definitely have a broad understanding of Android and you know the 850F inside and out.
I'm still leaning towards the possibility that Lenovo sold variants of the 850F.
MotoJunkie01 said:
That's good info to know. And yeah I may just give that member a shout and see if he'd be willing to join forces on developing for the 850F. A small development team would be nice -- and you would be more than welcome to be a part. You definitely have a broad understanding of Android and you know the 850F inside and out.
Click to expand...
Click to collapse
Thanks for vote of confidence. Happy to help where I can, and I'd love to set up a machine for foray into 'developing', but I have serious time constraints presently, so just an 'ideas man' (and willing tester) for now.
Looking forward to being kept up to speed with progress though. Regards, PW.
MotoJunkie01 said:
...I'm still leaning towards the possibility that Lenovo sold variants of the 850F.
Click to expand...
Click to collapse
Yes, I think that's a given also. Didn't intend to infer otherwise - just thought Tzul's info might be of interest / use because of variations (and because scatter file info may be misleading but also may work fine for 'compatible' platforms (chipsets) - I'm guessing this may make things simpler when it comes to 850F/M differing chipsets as well as any different chipsets within 850F range)... PW.
pndwal said:
Thanks for vote of confidence. Happy to help where I can, and I'd love to set up a machine for foray into 'developing', but I have serious time constraints presently, so just an 'ideas man' (and willing tester) for now.
Looking forward to being kept up to speed with progress though. Regards, PW.
Yes, I think that's a given also. Didn't intend to infer otherwise - just thought Tzul's info might be of interest / use because of variations (and because scatter file info may be misleading but also may work fine for 'compatible' platforms (chipsets) - I'm guessing this may make things simpler when it comes to 850F/M differing chipsets as well as any different chipsets within 850F range)... PW.
Click to expand...
Click to collapse
Yes I totally agree with you there.
Ok @pndwal, I have successful boot of the LineageOS 14.1 ROM for our 850F. Everything force closes and crashes on initial setup but I know the issue there. (Involves the .dex files in /system/priv-app and /system/framework. I'm debugging now to get things stable enough to launch. Fingers crossed.
MotoJunkie01 said:
Ok @pndwal, I have successful boot of the LineageOS 14.1 ROM for our 850F. Everything force closes and crashes on initial setup but I know the issue there. (Involves the .dex files in /system/priv-app and /system/framework. I'm debugging now to get things stable enough to launch. Fingers crossed.
Click to expand...
Click to collapse
Great news! Looking forward with eager expectation. Really appreciate your efforts PW
pndwal said:
Great news! Looking forward with eager expectation. Really appreciate your efforts PW
Click to expand...
Click to collapse
Most apps are now stable on the LOS build. Ironing out Bluetooth and WiFi issues and hope to have a beta build posted this week.