Overclockmatic_RK3288 v1.0.6

[Guest]

Patching the kernel is problematic and it will almost always brake with newer source files.
In tested kernels I always had to change frequency lock in two places but I realy do not know why .

Newer source files or not, my kernel patcher app checks for 128-bit patterns in front and after the cpu safety frequency, so I'm pretty sure I'm modifying the correct offset. Something else here is at play. Like some anti-overclock implemented by mo himself lol

And you have to change two offsets because both are avaluated when setting new frequencies. Also, the cpu safety frequency is not just referenced two times, but there are in fact two different variables with the same value, hence two times written in kernel file.

[cappybob]

@Gomar

Tried on my firefly and seemed to work as designed. Have ran out of time today, so haven't put up next to a home built kernel to check results for sure, but from what I have seen, seems like it is a good quality program, but I like to build my own kernels, enjoy the extra insights and comments of the original coders.

Later--cappybob

[jamesw]

First thing about your device which I noticed is quite weak power supply (5V/2A). I've got similar with K-R42 (RK3188). It can bearly run RK3288 new SoC and you try to OC it. Bad idea.
To investigate what is exactly a problem you should first get better power supply and then prepare boot.img with only DDR memory setting changed. It would be best if auto-frequency is disabled then you can just set top frequency to for example 600MHz at 1250 mV. Then after system boot at "normal" frequency which should be lower than maximum you can switch to DDR "performance" mode and maximum frequency by executing command as SU:
echo "p" > /dev/video_state

After surviving that you can return to "normal" frequency:
echo "n" > /dev/video_state

Example config:

DDR 1
600 1250

Patching the kernel is problematic and it will almost always brake with newer source files.
In tested kernels I always had to change frequency lock in two places but I realy do not know why .

Resource.img is much simpler to alter because it has well known structure.

yes, my power is 5V/2.5A , it should have no problem,

but i just only modify CPU freq and Kernel ,no modify ddr and GPU, but failed, boot can crash,
so i can only use the burs method to modify the DTS and pack resource.img, TVBOX work is very good

thanks your guidance,

[Gormar]

but i just only modify CPU freq and Kernel ,no modify ddr and GPU, but failed, boot can crash,
so i can only use the burs method to modify the DTS and pack resource.img, TVBOX work is very good

If you only repack boot image and change content of DTB in resource.img regarding CPU operation-points without modifying kernel then you doesn't OC CPU at all. In almost all RK3288 "factory" kernels there is defined SAFE_FREQUENCY limit and set to 1608MHz (1876*6/7).

Patching kernel is dangerous and almost unpredictable. If Burs is right HPH kernels made by mo123 can not be properly altered by my patcher.

Newer source files or not, my kernel patcher app checks for 128-bit patterns in front and after the cpu safety frequency, so I'm pretty sure I'm modifying the correct offset.

My patcher search for 32 bit pattern right before SAFE_FREQUENCY and also 32 bit after (64 bit total + 32bit frequency value sanity check). If it detects that value found is less than 1608MHz or greater than 2500MHz then it declare it as false positive and doesn't make any changes. That situation didn't happend to me till now and I tested kernels from HPH, Ugoos and Belink. Therefore I'm almost 100% shure it will modify only CPU frequency locks.

What I mean about "broken patcher" after changing kernel source was that these patterns will change and will need to be updated.

[POPA110]

Can you give another link because I can not download the file
overclockmatic_RK3288_v1.0.5.zip

[Guest]

My patcher search for 32 bit pattern right before SAFE_FREQUENCY and also 32 bit after (64 bit total + 32bit frequency value sanity check). If it detects that value found is less than 1608MHz or greater than 2500MHz then it declare it as false positive and doesn't make any changes.

Also, it's not possible to have values greater than ~2.1Ghz, since they don't fit into 32-bit integer
Try to insert a value of 2.2Ghz, and you'll be left with a brick, ie. black/blue screen

[Gormar]

Can you give another link because I can not download the file
overclockmatic_RK3288_v1.0.5.zip

I've upadated first post with newer version 1.0.6. Previous file was probably delated when this forum layout was changed few days ago.

Also, it's not possible to have values greater than ~2.1Ghz, since they don't fit into 32-bit integer
Try to insert a value of 2.2Ghz, and you'll be left with a brick, ie. black/blue screen

IIRC in the kernel CPU frequency is "hold" in variable of u32 type which is defined as unsigned int. Therefore maximum frequency should be a little above 4GHz .

I just have recall that In Ugoos test kernel CPU SAFE_FREQUENCY is set to 1894MHz which isn't clearly above signed int possible values (~2147M).

Theory is one thing but practice is the other . If you know from autopsy that setting SAFE_FREQENCY above 2.2GHz will lock kernel then it is worth investigation.

[Guest]

IIRC in the kernel CPU frequency is "hold" in variable of u32 type which is defined as unsigned int. Therefore maximum frequency should be a little above 4GHz .
I just have recall that In Ugoos test kernel CPU SAFE_FREQUENCY is set to 1894MHz which isn't clearly above signed int possible values (~2147M).
Theory is one thing but practice is the other . If you know from autopsy that setting SAFE_FREQENCY above 2.2GHz will lock kernel then it is worth investigation.

Infact, cpu safety frequency should be unsigned long, but it occupies 32 bits in kernel file.
The "X*6/7" formula is there to support higher frequencies, so the value can be stored as integer.
I just wanted to say if you overwrite it with even 1 byte greater than it can hold, you'll be bricked.
That's from my experience ofcourse, but your mileage could vary.

[Gormar]

Infact, cpu safety frequency should be unsigned long, but it occupies 32 bits in kernel file.
The "X*6/7" formula is there to support higher frequencies, so the value can be stored as integer. I just wanted to say if you overwrite it with even 1 byte greater than it can hold, you'll be bricked.
That's from my experience ofcourse, but your mileage could vary.

I think we shouldn't talk about size of variables when we didn't say anything about underlying hardware. On ARM int type variable has size of 32 bits but on X86/X64 architecture for compatibility reason it is "only" 16 bits. Therefore it is better to use stdint definitions (C99 standard) as in kernel: typedef u32 uint32_t. Where uint32_t is defined as 32 bit size variable in stdint.h (and even deeper in machin/_types.h). Variable of that type can hold maximum value as 2^32 and it is exactly two times above max signed variable value which is exactly 2^31 you talk about.

As to RockChip formula I think you are confused by its shape. Don't think too much about 6/7 divider but notice that SAFETY_FREQ is used as it is computed. Therefore kernel frequency limit check doesn't take into account that it was derivered by some strange eqoution (checked in source and experimentally but right now I haven't any link). I'm realy not sure what is the purpose of doing so but for me it have one task: to obfuscate that RK3288 SoC is working with lower frequency than advertised . And it does this marvelously ;(.

You mantioned that setting this limit above 2,2GHz freezes your box. Do you mean changing this value in kernel source (2210*6/7 MHz) or rather inside kernel.img file (1894 MHz)?
Strange thing is that on the first try I could run my RK3288 with 2GHz clock at 1.4V (kernel.img limit set to 2016 MHz) but right now it freezes on boot screen . It sometimes get past post screen and will work quite stable if I disconnect all but one of my USB devices . In that light talking about 2.2GHz limit is rather theoretical.

[Guest]

You mantioned that setting this limit above 2,2GHz freezes your box. Do you mean changing this value in kernel source (2210*6/7 MHz) or rather inside kernel.img file (1894 MHz)?

Inside kernel.img file, but 2210Mhz. Try to insert it, and it will fall apart into pieces. I can't remember every value I was testing, but I think even 2ghz bricks it.

[Gormar]

Inside kernel.img file, but 2210Mhz. Try to insert it, and it will fall apart into pieces. I can't remember every value I was testing, but I think even 2ghz bricks it.

I can't confirm yours findings.

Of course if I set highest CPU operation point in resource.img higher than my SoC can handle it won't boot or will freeze but If I set it to 1920MHz and kernel.img lock to 2210MHz or even higher all work well.

[Guest]

I'm not sure what you're trying to saying here, but like I said, when I write value of 2.2 billions (Hz) at the safety frequency offset inside hex editor, my box doesn't boot. At first I was sceptical about that weird safety frequency formula, so I tried to put a value directly into kernel file, just like you would in the source code by replacing default 1894Mhz.

[Gormar]

I'm not sure what you're trying to saying here, but like I said, when I write value of 2.2 billions (Hz) at the safety frequency offset inside hex editor, my box doesn't boot. At first I was sceptical about that weird safety frequency formula, so I tried to put a value directly into kernel file, just like you would in the source code by replacing default 1894Mhz.

First: default kernel limit is 160800000 (5fd82200h) which with little-endian memory addressing is written in kernel.img file like this: "0022d85f". Therefore this is obviously real limiting value and thats strange formula in source code isn't taken into account when CPU freqency is changed and chacked against SAFETY_FREQ limit.

Second: In your case if you set kernel CPU OC limiter to higher value than 2.2 billions (GHz) and make highest frequency pvtm-operation-point inside resource.img as 2GHz or above you may encounter overclocking limit of your particular chip rather than clipping of 32bit variable. To my knowledge there is no problem with this variable and 2.2-2.5GHz values because 32 bits size allows it to hold numbers just above 4 billions (4GHz).
On the other hand I encountered other limit that doesn't allow to set CPU frequency above 2208MHz (of course virtualy). Maybe in some kernels setting this limit above that value can cause some perturbations. But if you wouldn't test very high kernel limit (> 2.2GHz) with moderate CPU overclock (< 2GHz) you will never be sure what is at fault.

Third: In your OC kernels I found CPU frequency limit set to 1894MHz.

[Guest]

Third: In your OC kernels I found CPU frequency limit set to 1894MHz.

1894Mhz is there as a result from a source code formula. Default was 1876x6/7, which locks cpu at 1608Mhz. Since my test values above 2210Mhz soft-bricked my box, I've put 2210 as a maximum, which was also sugggested by Sam from Ugoos. So, the same is for Ugoos overclocked kernels, and they also have 1894Mhz set as safety frequency. I still didn't patched my kernel using your tool, but just to be sure, you're setting 2208Mhz as safety frequency? I've tried that before on HPH v1.4.1 kernel, and my box didn't boot. I don't know how would it behave after patching with your tool using newer v1.4.5 kernel, but if it works for you, I might give it another go.

[Gormar]

1894Mhz is there as a result from a source code formula. Default was 1876x6/7, which locks cpu at 1608Mhz. Since my test values above 2210Mhz soft-bricked my box, I've put 2210 as a maximum, which was also sugggested by Sam from Ugoos. So, the same is for Ugoos overclocked kernels, and they also have 1894Mhz set as safety frequency.

I thought so. Therefore maximum CPU frequency with those kernels (Ugoos and HPH) is 1894MHz. (period). Resource file containing 2210, 2116, 2008, 1920 Mhz CPU operation points is therefore just for show and misleading even more than RockChip 1800MHz mistification with 1608MHz maximum frequency.

As to higher CPU OC limit value in kernel. My RK3288 don't "withstand" higher frequencies than 2016 MHz and even at that speed it isn't stable enough. Therefore I haden't started to think about adding 2216MHz and 2210MHz CPU operation points in resource file. For everyday use I set kernel lock in kernel.img as well the highest operation point value in resource.img to 1920MHz (equivalent of 2324 value in kernel source code formula) at 1.4V.

I still didn't patched my kernel using your tool, but just to be sure, you're setting 2208Mhz as safety frequency? I've tried that before on HPH v1.4.1 kernel, and my box didn't boot. I don't know how would it behave after patching with your tool using newer v1.4.5 kernel, but if it works for you, I might give it another go.

I tried CPU kernel lock as high as 2500MHz (2917*6/7*MHz in kernel source code) and without changing resource.img all went well. But If I realy try to make CPU run at speed greater than 2016MHz it will completly soft "die" (no boot screen at all). When the highest CPU operation point in resource file is set to this frequency my RK3288 sometimes completes system boot especially if I disconnect USB devices from my device.

Note: My overclockmatic_RK3288 patcher will always suggest changing CPU frequency lock inside kernel image to the highest frequency value for CPU in its config file. In case that cfg file don't exist it will use the highest value from defaults which at this moment (v1.0.6) is 2000MHz @ 1.4V but after my latest expieriences I might lower it to 1920MHz in next revision before people will start to complain about soft bricked devices. After hearing from you that this SoC can go as high as 2,2GHz which prove to be wrong I considered 2GHz as a moderate OC .