Blacklist of locked Down Version´s of RK3188 CPU

[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...

[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

[Magnus33]

Iam also guessing that testing has been cut back and limited to 1.4 to get the cpu out to meet increased demand.

There just too much variance in cpu to have anything other then the quickest of tests being done.

Some here have t cpu that barely do 1.4 and others like me have model t cpu's that overclock as good as any none t cpu.

I think we have become victims of supply and demand rather then a major cpu revision.

The cpu not junk but its not whats advertised and i suspect the buyers got caught off guard by this.
A cross board mistake in speed from all sellers is just to unlikely so the cpu makers probably glossed over the cpu speed short comings.

PS: JDfense nice mod

[d33]

There must be a connection between the kernel/loader and the other imgs in the model T firmware.

Or do miss the point?

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.

[JDfense]

The way the code works is to build up a list of frequencies for CPU, GPU and RAM created at compile time. During kernel initiation a check is made to see if the physical efuse (secure bit pattern) for a "T" processor is set, if it is, it iterates through the CPU table removing any frequency greater than 1.4 GHz

So the possibilities are to leave it as is (what I currently do), change the threshold to say 1.6 GHz or to remove the code altogether.

Given the variety of "T" chips it seems sensible to leave it in currently.


Sent from my iPhone using Tapatalk

I understand the freq tablets, saw it in the rkpatchomatic, but why did older kernels with the full freq list fail in a bootloop. I checked this with my cs968 Model T. They must have changed more than this list in the kernel. The 2.07/2.08 bootloader for my model T work with android 4.22, but the 2.xx loader should be for kitkat and if I use any img file from an non t model I got a loop sooner(boot.img) or later(system.img). There must be a connection between the kernel/loader and the other imgs in the model T firmware.

Or do miss the point?

JDfense

[JDfense]

I find it very strange that rockchip would release a chipset with absolutely no specifications at all, So that said the T chipset is a cheaper locked CPU therefore faulty, If rockchip knew differently they have a moral obligation to disclose this, That fact they are Not says a lot!!


THEY KNOW ITS FAULTY AND ARE KEEPING QUITE IN THE HOPES IT GOES AWAY.



Pipo the shame ohhhhhhhhh my !!!!!

Calm down scooter. Maybe d33 has a clue to the solution, but you are right, Rockship is very quiet about there Model T specifications. Sooner or later this secret will be broken.

JDfense

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

d33,

maybe silly question from a non kernel guy. Is it possible add the missing freq tables in the kernel or is compiling a new kernel with fitting sources the only way to fix the model T's?

JDfense

PS.: I see, you are a Pipo-Fan.

The way the code works is to build up a list of frequencies for CPU, GPU and RAM created at compile time. During kernel initiation a check is made to see if the physical efuse (secure bit pattern) for a "T" processor is set, if it is, it iterates through the CPU table removing any frequency greater than 1.4 GHz

So the possibilities are to leave it as is (what I currently do), change the threshold to say 1.6 GHz or to remove the code altogether.

Given the variety of "T" chips it seems sensible to leave it in currently.


Sent from my iPhone using Tapatalk

[scooter2014]

I find it very strange that rockchip would release a chipset with absolutely no specifications at all, So that said the T chipset is a cheaper locked CPU therefore faulty, If rockchip knew differently they have a moral obligation to disclose this, That fact they are Not says a lot!!


THEY KNOW ITS FAULTY AND ARE KEEPING QUITE IN THE HOPES IT GOES AWAY.



Pipo the shame ohhhhhhhhh my !!!!!

[JDfense]

d33,

maybe silly question from a non kernel guy. Is it possible add the missing freq tables in the kernel or is compiling a new kernel with fitting sources the only way to fix the model T's?

JDfense

PS.: I see, you are a Pipo-Fan.

[norbert6]

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

Don't know if this has been mentioned before but the 1.4 frequency limit for T models is in the kernel source. It can be overridden in the leaked Kitkat beta.

So custom kernels built with jelly bean source will be fine as the leaked source was pre T chip.

All recent Stock built kernels will include the mod. It removes all freqs above 1.4 from table. Same for our custom KitKat ROMs as no-one is yet commenting out the limit


Sent from my iPhone using Tapatalk

So it is an easy fix? Sounds promising...
Do you think this will also fix the overall and especially the wifi performance?

[d33]

Blacklist of locked Down Version´s of RK3188 CPU

Don't know if this has been mentioned before but the 1.4 frequency limit for T models is in the kernel source. It can be overridden in the leaked Kitkat beta.

So custom kernels built with jelly bean source will be fine as the leaked source was pre T chip.

All recent Stock built kernels will include the mod. It removes all freqs above 1.4 from table. Same for our custom KitKat ROMs as no-one is yet commenting out the limit


Sent from my iPhone using Tapatalk

[digger]

Im not stupd, I know its a RockChip, just not totally sure its a 'T'. Easy way to work it out is if Allwinner modding tools dont open the roms but RockChip ones do then Im thinking its a RockChip



Chris

Sorry Chris, you are offtopic here with your nice tablet.
But I have my stuped idea to help you to make shure that your CPU chip is RK3188 really.
Try to check it size with trammel
A 31 has 17.9x17.9 but RK3188;3168;3066 have 19x19
Second idea is to investigate PMU chip model soldered on your board. I think it must be different for A 31.

[JDfense]

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

Ahh tell the truth now the dilithium crystals cracked and she wont go to warp tell the replacements come in

No, I think the off topic containment field of the warp drive is breaking down. Beam me up Scotty.

JDfense --->I8160

[Magnus33]

Are you talking about TV cards or Tablets? I havent seen a model t rom that can overclock. The 'T's are no way rubbish. Mine has a battery that lasts over 24hours with my mods (But takes 6 hours to charge )!

I like the battery life on mine but dont like the random lag I get sometimes. I imagine this is due to my rom being wrong and issues with incorrect hardware for said rom?

Any help with the tablet version of these chips would be awesome

This is the andriod tv player forum not the tablet forum so battery life really not a factor here...lol

[cass1977]

Its clear the Model T aren't junk by any means but the huge quality difference between chips means there rushing them out the door with minimal testing.
Likely due to huge demand since they could easily charge more for ones like mine which seem to overclock like crazy.

Whats super annoying though is the fact that you can either give up speed fora more complete rom or get the speed and a incomplete rom.

For many of us the 1.7 rom wont load due to a check failure.

Fortunately the beta 2.1 does work with the overclocking roms and is mostly complete. (no spinning rims though)

Are you talking about TV cards or Tablets? I havent seen a model t rom that can overclock. The 'T's are no way rubbish. Mine has a battery that lasts over 24hours with my mods (But takes 6 hours to charge )!

I like the battery life on mine but dont like the random lag I get sometimes. I imagine this is due to my rom being wrong and issues with incorrect hardware for said rom?

Any help with the tablet version of these chips would be awesome