HPH overclocked kernels by Burs

[Guest]

Ok, your lock means lock at min... ok, that's something I would never do... best way to kill a soc...

I'm not aware of any SoC's that died that way, but as I already said, it's not for everyone and certainly not for 24/7. It's only for those people who want to squeeze even the last atom of performance out of their chips. Ugoos also provided their kernels with locked frequencies, so I wanted to do the same for our boxes. If you think it's not safe, then don't use it. Again, people should be using kernel v2, and these v3 variants are for "special cases" (except for the first one "v31" which don't have any locked frequencies, just DDR increased to 792Mhz).

[Gormar]

So, DDR frequency is increased a little bit more, and as a bonus, I've also increased DDR frequency at which the box operates when in normal mode (non-gaming mode, like browsing the web, streaming music/videos, using most of the apps, and things like that), so you should see some improvements there too. That frequency was increased from 456Mhz to 533Mhz, which also results in more fluid user interface.

I've just looked into one of your resource file with DDR frequency set to 744MHz and spotted one fault. You set "operating-points" to only one possible variant. That mean it will be only freqency which can be set. Values in "freq-table" shouldn't been relevant now because there isn't specified voltage.
What do you see reported by ddrfreq driver? (dmesg|grep ddrfreq)

As to freq-table. From my experience with few firmwares only frequency defined as SYS_STATUS_NORMAL (0x1) and SYS_STATUS_SUSPEND (0x2) are chosen automaticaly. I didn't saw memory frequency set in corespondence to SYS_STATUS_PERFORMANCE (0x2000) setting.

In "Open Hour Chameleon" firmware I've got some problems with DDR freqency hopping between video_4K and video_1080p modes without aparent reason. Thanks to my small script forcing /dev/video_state open/close I can set manualy NORMAL/VIDEO_1080/VIDEO_4K modes but it is rather unnerving.

[Guest]

I've just looked into one of your resource file with DDR frequency set to 744MHz and spotted one fault. You set "operating-points" to only one possible variant. That mean it will be only freqency which can be set. Values in "freq-table" shouldn't been relevant now because there isn't specified voltage.
What do you see reported by ddrfreq driver? (dmesg|grep ddrfreq)

It's not a fault, it's a new "feature" Yes, there's only one DDR operating point, that's why the kernel has locked frequency That was the idea. I currently use kernel v3.1 (no locks), but while testing other v3 locked kernels, dmesg was returning only the frequencies and voltages I've set in DTS files through operating points. So, in case of 744Mhz kernels I was always getting 744Mhz, and same for 792Mhz, independent of "amount of work" thrown at the box (idle, light use, gaming, etc).

[Gormar]

It's not a fault, it's a new "feature" Yes, there's only one DDR operating point, that's why the kernel has locked frequency That was the idea. I currently use kernel v3.1 (no locks)

My bad. I didn't pay attention when you mentioned locked frequencies .

With your kernel v3.1 without locks what DDR frequencies do you see reported in dmesg?

[Guest]

With your kernel v3.1 without locks what DDR frequencies do you see reported in dmesg?

Well, it depends on the case. Now I'm on 533Mhz (normal mode). I increased it from default 456Mhz. If I put some 7-Zip compressing in the background, it hops between 533-792Mhz (with 648 and 744Mhz inbetween).

[Gormar]

Well, it depends on the case. Now I'm on 533Mhz (normal mode). I increased it from default 456Mhz. If I put some 7-Zip compressing in the background, it hops between 533-792Mhz (with 648 and 744Mhz inbetween).

Nice firmware you have. Mine doesn't go beyond Normal DDR frequency.

Thanks to your encouraging input I once more looked at ddr_freq driver source code and found out that RockChip implemented software switch to performance system mode at last . Now going into performance DDR mode is as easy as typing:
echo "p" > /dev/video_state
To return to normal mode change "p" into "n". .

[Guest]

echo "p" > /dev/video_state
To return to normal mode change "p" into "n".

Nice trick. Thanks. It will come in handy when testing new kernels and benchmarking with different settings.

[Guest]

I posted my ResTool app inside APP Developers Kitchen, so you might wanna check it out. It's for people more inclined to Windows OS, and it's used for repacking resource.img files. For DTB<->DTS conversion you can find dtc.exe windows port on the internet. Since this was only first half of the overclocking process, I also needed a windows port of resource unpacking tool that's available only on linux. So I coded my "wanna be" windows port of the tool. For futher info check the dedicated thread.

[Guest]

I've just posted my kernel patcher in another thread, so those interested in it can check it out there. I didn't want off-topicing here, and it deserves its own thread anyway. Just wanted to say that here, so everyone subscribed to this thread get the an info about it...

[sawbones999]

Nice firmware you have. Mine doesn't go beyond Normal DDR frequency.

Thanks to your encouraging input I once more looked at ddr_freq driver source code and found out that RockChip implemented software switch to performance system mode at last . Now going into performance DDR mode is as easy as typing:
echo "p" > /dev/video_state
To return to normal mode change "p" into "n". .

So does this switch force the governor to performance or is this something different?

Thanks!
-SB

[Gormar]

No it doesn't have anything to do with CPU or GPU. This is only information from userspace to ddr_freq driver in the kernel.

I suppose that RockChip would like to make it fully automatic but right now it is the only way to change DDR clock from "Normal" to "Performance". At least in firmwares or rather kernels which I tested.

[sawbones999]

Ah, ok. Thanks!

Cheers,
-SB

[Guest]

Does anyone know which part of the kernel (.c file) is responsible for limiting the gpu@625mhz? Setting it to higher frequency doesn't seem to have any effect. I think gpu can handle at least 50mhz more, and would like to see how it copes with it (temps, performance, etc).

[sawbones999]

I haven't looked at this specific kernel but in a ZTE 3.4 kernel I've been poking into I've seen something like a xxx_freq.c or .h which shows something like min_freq uint32 max_freq uint32.

Actually I think it was the CPU freq I was looking at and I believe it was a .h include, but it may be similar for gpu? There was a comment there, something along the lines of cpu_no_max_freq which if either max or min was equal to then there would be no maximum (or minimum depending on the case) and the max or min would be whatever you feed into the freq table. Also in the comment there was a value for cpu_no_max_freq (this is not verbatim, I don't remember the exact wording). The value was something like 7777FFFF, and I assume that if you substitute that value for uint32 then the maximum freq, which was defined in a separate .c file would be ignored in favor of the freq table.

I have no idea if there is something similar for GPU, and as I said it was a different kernel. I was looking for this info bc I'm thinking about making an oc kernel. Haven't spent too much time on it. Enough to figure out where the freq tables and voltage tables are. For some reason ZTE locked max cpu freq at 1.51Ghz when the SOC is rated at 1.7Ghz and can easily handle 1.9.

Haven't had time to modify anything yet. Adreno 225 also capable of 400Mhz but ZTE locked at 300Mhz. I found that freq table but I dunno about the lock, if I can just change the freq table or if it's locked the way the CPU was. If so, I'd expect something similar to unlock it.

Haven't paid much attention to DDR yet. It's not exactly a high priority project right now, bc I don't even use that phone anymore. It's become popular again, though bc Freedompop is selling lots of them for cheap. I only found out that the source was available a couple days ago.

I dunno if that is helpful to you or not, if not just chalk it up as another Sawbones rant of the day

Cheers,
-SB

[sawbones999]

Burs, take a look in here https://github.com/rkchrome/kernel/b...hip/ddr_rk32.c

It gets pretty complicated because there is config in there for so many different types of RAM, but I believe that once you know for sure which RAM you're working with you should be able to modify the speeds and timing there. At least it looks that way on a superficial glance. There may be other files which would also require modification. I've only just started looking.

Also I'm not sure which kernel this is. It's the one gormar linked to earlier. Judging from the hub being named rkchrome maybe this is not an Android kernel, but a chromium build? I wonder which kernel version it is. Gonna dig some more.

I'd love to see a newer kernel with VPU/GPU driver libs for Android and kvm/ARM support.

Pipe dreams...
Cheers,
-SB