Blacklist of locked Down Version´s of RK3188 CPU

[JDfense]

Not sure I understand your point and it may be we are talking about different things but let me try to explain with examples.

[Kernel compile] The CPU frequency table is defined by the programmer in the board source file. Let's say the table is: 800, 1000, 1200, 1400, 1600. Each of these frequencies is paired with the required voltage.

[Original RK3188 + 'T' aware kernel] When the kernel code is initiated the frequency table is built up into memory and the CPUs are turned 'on', the CPU limiting code is then run through which defines what to do when the kernel gets hot (most of which is ignored!!), it also checks the eFuse pattern of the CPU to see if it is a 'T' model. The pattern isn't set and so the boot process continues.

Output is a kernel capable of flexing the CPUs between 800-1600 MHz.

[RK3188T + 'T' aware kernel] When the kernel code is initiated the frequency table is built up into memory and the CPUs are turned 'on', the CPU limiting code is then run through which defines what to do when the kernel gets hot (most of which is ignored!!), it also checks the eFuse pattern of the CPU to see if it is a 'T' model. The pattern is set which results in the code stripping all frequencies greater than 1400 from the table.

Output is a kernel capable of flexing the CPUs between 800-1400 MHz. This is the case of all newer 'stock' 4.2.2 kernels, all KitKat kernels (so far) and also includes all newer stock kernels patched by PHJAnderson's patchomatic script.

[RK3188T without 'T' aware code in kernel] When the kernel code is initiated the frequency table is built up into memory and the CPUs are turned 'on', the CPU limiting code is then run through which defines what to do when the kernel gets hot (most of which is ignored!!).

Output is a kernel capable of flexing the CPUs between 800-1600 MHz. This will be the case for old stock kernels (ones that pre-date the T chip), all custom kernels based on the leaked 4.2.2 source and older stock kernels patched by PHJAnderson's patchomatic script.

The difference is here that the T kernels APPEAR to be frequency unstable above 1400 MHz, some more than others. So when the CPU scales to a frequency above the 1400 cap it may or may not fail. This may explain why your T CPU fails at random points during the boot process. It is failing when a frequency above 1400 is being requested.

Okay, I hope I have understood your explanation. Let me see...
This means then, there are no more new rk3188 devices, because the rk3188 was completly replaced by the model T with android 4.22 T-kernel version or newest kitkat 4.42 T-kernel version. Thats possibly why I have the 2.08 bootloader with an android 4.22 stock ROM.

My cs968 Model T does not work with older firmware, because I have very weak Model T, that is unstable over 1.4 GHz while the boot process. Some others will work up to 1.6 Ghz and almost none over 1.6.
As a result, I could forget any further research for my Model T, because it would not run over 1.4 GHz.

There is one point, I still don't understand. Why should Rockship lock down all there new rk3188 to the rk3188T. Do they have a disaster in the production and they want to hide, that they can't deliver enough fast samples, stable over 1.4 Ghz. I won't believe that. If this is the case, it is time to move on to another platform. Hiding these circumstances are not more or less than fraud.

JDfense

[Pet2001]

...
[RK3188T + 'T' aware kernel] ... Output is a kernel capable of flexing the CPUs between 800-1400 MHz. This is the case of all newer 'stock' 4.2.2 kernels, all KitKat kernels (so far) and also includes all newer stock kernels patched by PHJAnderson's patchomatic script.
...
[RK3188T without 'T' aware code in kernel] ... Output is a kernel capable of flexing the CPUs between 800-1600 MHz. This will be the case for old stock kernels (ones that pre-date the T chip), all custom kernels based on the leaked 4.2.2 source and older stock kernels patched by PHJAnderson's patchomatic script.
...

Completely agree with you. I tried to point this out more than a week ago, although not as thoroughly as you've done...

Since I have got a RK3188T which is capable of bearing 1800 MHZ, I would really like to have just kernels compiled without limitations on cpu frequency, even because until now I haven't found a way to change the threshold value in a compiled kernel image and I think it is really hard (almost impossible) to do...

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

Okay, I hope I have understood your explanation. Let me see...
This means then, there are no more new rk3188 devices, because the rk3188 was completly replaced by the model T with android 4.22 T-kernel version or newest kitkat 4.42 T-kernel version. Thats possibly why I have the 2.08 bootloader with an android 4.22 stock ROM.

My cs968 Model T does not work with older firmware, because I have very weak Model T, that unstable over 1.4 GHz while the boot process. Some others will work up to 1.6 Ghz and almost none over 1.6.
As a result, I could forget any further research for my Model T, because it would not run over 1.4 GHz.

There is one point, I still don't understand. Why should Rockship lock down all there new rk3188 to the rk3188T. Do they have a disaster in the production and they want to hide, that they can't deliver enough fast samples, stable over 1.4 Ghz. I won't believe that. If this is the case, it is time to move on to another platform. Hiding these circumstances are not more or less than fraud.

JDfense

Nope you didn't quite get it all . There are still 'full' rk3188 out there. Minix have promised to only use 'real' RK3188 CPUs which has probably increased their sales.

With respect to why why sell the 'T' model so hard, I don't know. When the original chip came out it struggled with performance, especially in tablets where HD resolution tablets had a 'standard' setting that reduced resolution in trade for performance. Also there was the video playback bug that was the source of much debate on this site.

However, the release of SDK 2.0 dramatically increased performance. Perhaps so much so that Rockchip saw the opportunity to increase yield by decreasing the required performance threshold to 1.4 Ghz. It should be noted that even the original kernel sources have a performance 'throttle' (the maximum allowed voltage was 1375 mV).


Using my ipad so apols for any stupid ios spelling 'corrections'

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

Since I have got a RK3188T which is capable of bearing 1800 MHZ, I would really like to have just kernels compiled without limitations on cpu frequency, even because until now I haven't found a way to change the threshold value in a compiled kernel image and I think it is really hard (almost impossible) to do...

It's not hard. Either override the return value for the fuse test (efuse.c) or increase the threshold (cpufreq.c.)


Using my ipad so apols for any stupid ios spelling 'corrections'

[scooter2014]

Rockchip has to coment as simply fraud at this point unless some other reason in place. 3188T locked at 1.4 when devices advertised as 1.8 is fraud. They either failed to tell manufactures or did and they failed to provide.

[cass_1977]

The difference is here that the T kernels APPEAR to be frequency unstable above 1400 MHz, some more than others. So when the CPU scales to a frequency above the 1400 cap it may or may not fail. This may explain why your T CPU fails at random points during the boot process. It is failing when a frequency above 1400 is being requested.

Im willing to give it a go on my tab. I got it for free so cant hurt to try it out and report back how i get on. So what is the best way? Get a kitkat kernel and replace my current one or wht?

[d33]

Im willing to give it a go on my tab. I got it for free so cant hurt to try it out and report back how i get on. So what is the best way? Get a kitkat kernel and replace my current one or wht?

I haven't got a tablet to experiment building kernels it's been awaiting repair since before Xmas. As far as I'm aware only @DNKN is building kernels for a tablet and then only the M9pro.

I think it is far more realistic to wait for someone to develop a kernel patcher for the override.

However, in your case IF the tablet IS a clone of the M8pro then there will be old kernels you can patch from pre-"t"-chip days.

[cass_1977]

I haven't got a tablet to experiment building kernels it's been awaiting repair since before Xmas. As far as I'm aware only @DNKN is building kernels for a tablet and then only the M9pro.

I think it is far more realistic to wait for someone to develop a kernel patcher for the override.

However, in your case IF the tablet IS a clone of the M8pro then there will be old kernels you can patch from pre-"t"-chip days.

This is why I have the other thread. I found a reference to a tv stick too. Thats why I thought it could be a gen (non t) model but no way to find out. As it runs at a similar performance to my mums rk3066 and it had the m8pro reference I did even wonder if it was even a 4 core, lol. Did they do a m8pro with an rk3188? I think, from your very helpful info, im best to play around with custom roms or other stock roms before i get into the kernel. The problem with my rom being labeled as so many other devices is that i have no idea what it really is or what is a close model to test with. Im guessing that compiling android myself would be a start. but then, unless i know my real spec, i cant even begin to look for a compatible donor. First thing is to see if it IS a t model. Is there any way of checking other than the branding on the chip?

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

Not as far as I know. I've just added a printk line to the efuse.c code that will say t or not t in DMESG but only for tv sticks for now


Sent from my iPhone using Tapatalk

[cass_1977]

Not as far as I know. I've just added a printk line to the efuse.c code that will say t or not t in DMESG but only for tv sticks for now


Sent from my iPhone using Tapatalk

Im starting to think it might not be a t at all, maybe even not a 3188. Is there any way to spoof firmware into thinking a dual core cpu is a quad core (Maybe cloning each cpu as it was a real one?)?

[taikanaumi]

Ugoos UM2 only stick with Non-RK3188-T?

I have Ugoos UM2, the reasons you dont hear anything is ,because UM2 runs fine out of the box..
right now I'm running NEOMODE CUSTOM ROM MK809III AP6210 Version 1.9 with Kernel 3
I have no problem, everything working fine, but no bluetooth.... Everything else runs smooth.
if you flash it the screen gonna be small, you can change it: open build.prop & find the line: ro.sf.lcd_density=160
edit that line so it now says: ro.sf.lcd_density=200 or 240
save & reboot..

Now I wanna try NEOMODE CUSTOM ROM v2.1 I hear good things about it..

Thanks for info. el_easy.
some additional question though.
Have you opened your case to see if it has RK3188 non-T? (if so, when did you buy stick?)
have you played 1080? does it play without any hic up?
Blue tooth is not that important to me either, so your set up might be my answer!!

[leolas]

Re: Blacklist of locked Down Version´s of RK3188 CPU

Great explication about how works the kernel limit for T proccesors d33!!

In customs kernels we can remove the limit, but the device can becomes unstable at 1400 up speeds, maybe some of the T devices (like droidtv one) can run at those specs, but the most will freeze, hangs or reboot

Like most people said here, rk3188T is not a crap, if it is selled with his correct speeds, maximum is 1400, you can got more, you are lucky, while in rk3188 maximum is 1600, probably you can got 1800, but all speed over 1600 is a bonus. Not all rk3188 can go up 1600, and not all rk3188T can go up 1400. If the seller announce the correct speed all is fine, if not, is a scam

leolas.

[digger]

Not as far as I know. I've just added a printk line to the efuse.c code that will say t or not t in DMESG but only for tv sticks for now


Sent from my iPhone using Tapatalk

Hi d33,
Thank you very much for sharing your "T" knowledges with us
You write I've just added a printk line to the efuse.c code
Is this inside one kernel compilled by you for definite RK3188 based device?
If so then it would be used like a tester for people who have heatsink on their CPU (like me with K-R42) and are not able to find out whether they have "T" or not.

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

I can't compile and test until the weekend, but then I'll post a kernel with debug message in saying Rk3188 or RK3188T


Using my ipad so apols for any stupid ios spelling 'corrections'

[digger]

I can't compile and test until the weekend, but then I'll post a kernel with debug message in saying Rk3188 or RK3188T


Using my ipad so apols for any stupid ios spelling 'corrections'

Thank you, d33
I'll wait with impatience!
I think your kernel can help a lot of people not to waste their time with useless overclocking attempts.
Have a nice day