Announcement

Collapse
No announcement yet.

Announcement

Collapse
No announcement yet.

Overclocked RK3288 kernels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    @Steveboroughs. As far as I know there is no guide how to OC RK3288 devices. But from my experience it is much easier than RK3188 devices because if you are only changing frequencies and voltages and not number of operating points then you just need to change values inside resource.img which isn't even protected by CRC as is RK3188 kernel. Scripts similar to patchomatic are just over ther corner.


    Right now I have only tested changing DDR frequencies and voltage and to GPU. In that last case I'm not exactly sure how data in DTB (Device Tree Blob) are affecting real working parameters of GPU.


    How to change DDR voltage and frequencies:
    1. Copy resource file: "dd if=/dev/block/mtd/by-name/resource of=/sdcard/resource.img bs=1024 count=114"
    2. Open file /sdcard/resource.img in Hex Editor and find ASCII text: "pd_ddr"
    3. After text "clk_ddr" you will find 12 byte structure describing size and offset for that leaf name. For example (hexadecimal): "00 00 00 03 00 00 00 30 00 00 08 57". Most important number here is 30h=48 which tell as how many data bytes that node hold. 857h = 2135 is byte offset in structure which stores names of leafs in that tree. In my case It beggins at hex offset: "174b0". Therefore this exact number index: "operating-points" name which starts at 17d07h. These 48 bytes describe DDR operation points (freq in kHz (4B),voltage in uV (4B) x 6): "00 03 0d 40 00 10 67 38 00 04 93 e0 00 10 67 38 00 06 f5 40 00 11 2a 88 00 08 22 08 00 11 8c 30 00 09 27 c0 00 13 12 d0 00 0a ae 60 00 13 d6 20" which translates to "200000kHz 1075000uV 300000kHz 1075000uV 456000kHz 1125000uV 533000kHz 1150000uV 600000kHz 1250000uV 696000kHz 1300000uV".
    Next leaf name is "channel" and is only 4B long and contain only number "2".
    Next is 5B? long "status" and contains string "okay".

    Next leaf "freq-table" (00 00 00 03 00 00 00 28 00 00 08 da) is important because in my case it contains 40bytes describing freqency table pairs (status (4B), freq kHz (4B)), which is used in working system and correlate with system status: "normal = 0x1", "suspend = 0x2", "video_1080p = 0x20", "video_4k = 0x10", "performance = 0x2000". There you can change working DDR frequencies to your liking. But in my opinion these should correspond with defined "operating points". And remember in actual system only boot, normal and suspend are used. Of course you can force video_1080p and video_4k states by writing and hodling /dev/video_state file but it isn't convinient.

    This is fragment of DTS (Device Tree Source) file which describe above binary data structures:
    Code:
       pd_ddr {
                  clk_ddr {
                           operating-points = <0x30d40 0x106738 0x493e0 0x106738 0x6f540 0x112a88 0x82208 0x118c30 0x927c0 0x1312d0 0xaae60 0x13d620>;
                           channel = <0x2>;
                           status = "okay";
                           freq-table = <0x1 0x927c0 0x2 0x30d40 0x20 0x927c0 0x10 0x927c0 0x2000 0xaae60>;
                           auto-freq-table = <0x3a980 0x4f1a0 0x6f540 0x80e80 0x927c0 0xaae60>;
                           auto-freq = <0x0>;
                    };
       };
    
    
       pd_vio {
                   aclk_vio1 {
                           operating-points = <0x186a0 0x10c8e0 0x7a120 0x10c8e0>;
                           status = "okay";
                     };
         };
    };
    
    
          vd_gpu {
                   regulator_name = "vdd_gpu";
                   suspend_volt = <0x3e8>;
    
                   pd_gpu {
                         clk_gpu {
                               operating-points = <0x30d40 0xdbba0 0x493e0 0xe7ef0 0x668a0 0x10c8e0 0x7a120 0x118c30 0x927c0 0x1312d0>;
                                channel = <0x1>;
                                status = "okay";
                          };
                    };
    Data from kernel source file "include/dt-bindings/clock/rk_system_status.h
    Code:
    #define SYS_STATUS_NORMAL       (1<<0)
    #define SYS_STATUS_SUSPEND      (1<<1)
    #define SYS_STATUS_IDLE         (1<<2)
    #define SYS_STATUS_REBOOT       (1<<3)
    #define SYS_STATUS_VIDEO_4K     (1<<4)
    #define SYS_STATUS_VIDEO_1080P  (1<<5)
    #define SYS_STATUS_GPU          (1<<6)
    (...)
    #define SYS_STATUS_PERFORMANCE     (1<<13)

    You will find current operating voltage set for DDR in /sys/class/regulator/regulator.3/microvolts (vdd_logic?) device file but I'm not sure if these values aren't modified in hardware by changing reference voltage for ACT8846QM regulator like it was with RK3188 boards. When there was no LPDDR3 memory present on the board by changing one resistor manufacturer could replace LPDDR3 memory with DDR3 and wouldn't have to change software. Voltage regulator still "thought" that it was supplying 1,2V and in reality it was 1,5V (1,2 x 1,25 = 64kOhm/51kOhm - voltage divider). I do not know how it is in current design therefore be carefull and do not go beyond 1,3V for a time being.


    Not so far bellow "pd_ddr" in resource.img we have "pd_gpu" and "clk_gpu" branches but till now I didn't tested changing these numbers. They seem fishy to me because they do not exactly correspond with data which I see when executing command: "dmesg|grep mali_dvfs" and there isn't any visible way to change treshold properity.


    After saving changes you can flash back resource.img into resource partition:
    "dd of=/dev/block/mtd/by-name/resource if=/sdcard/resource.img bs=1024 count=114". If something goes wrong and device isn't booting up then you can flash original resource.img "PC way" in Android Tool.
    Last edited by Gormar; 12-24-2014, 23:44.
    RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
    Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
    bricked: VOYO V1 mini 8G/64GB Windows 10

    Comment


      #17
      What's about:

      => google translate https://translate.google.com/transla...-text=&act=url
      ==> '4. resource.img - let's drive' but "... We need tools: Ubuntu with: Rockchip SDK + Device Tree Compiler (dtc)... "
      RK3288 Devices
      - Overview BOX (LINK !)
      - Overview STICK (Dongle) (LINK !)

      MINIX NEO: Z64 W/A - (Intel Z3735F); X8-H Plus - (Amlogic S812H); A2 Lite (sponsored by minix.com.hk)
      UGOOS UT3S (4/32GB with fan) - FW 2.0.6 - (RK3288) (sponsored by GearBest.com)
      Tronsmart Draco AW80 Meta (2/16GB) - FW v2.0rc3 - (Allwinner A80) (sponsored by GeekBuying.com)
      Beelink / UBOX R89 - FW 111k4110_1219 - (RK3288) (sponsored by Netxeon (Beelink))

      RK3188: pcb => "CH001 1332 TN-BX09_V2.1" (K-R42 / CS918...) => wasser KK 1.0.3 (old rev)
      Fly Mouse Mini Wireless Keyboard with 2 mode learning IR remote 'iPazzPort KP-810-16'

      Comment


        #18
        DTC is not needed .

        @no_spam_for_me. Thanks for this link. It might help to better understand resource.img file.

        Personaly I have used dtc few times under Android that's why I have DTS file extracted from Wasser's "resource-dd700-gpu600-beelink-r89-wasser.img" but if you do not plan to change size of table describing operting points for GPU/DDR/CPU then it is not neccessary and old school Hex Editor is all you need.


        One more thing. I didn't write explicitly but above changes I've done exclusively on Android. Who need Linux . Even DTC v4.0.1 can work under this system when it is compiled for armel or armhf platform but it also require two libraries from Linux (libc.2.19.so=>/lib/libc.so.6 and ld.2.19.so=>/lib/ld-linux.so.3). Everything available in "device-tree-compiler_1.4.0+dfsg-1_armhf.deb" file and a moment of work with "dd" and "tar" .

        And very last thing . CPU overclocking.
        From Wasser's DTS file I conclude that "operating-points" leaf in a "pd_clock" branch isn't determining real CPU frequencies and voltages as is described in a manual pointed by you. Much more important is "pvtm-operating-points". But if kernel blocks CPU frequencies above 1608MHz then OC isn't possible with only resource file at hand.
        Proof:
        Code:
        cat resource-ddr700-gpu600-beelink-r89-wasser.dts |grep -A 15 -i pd_core
                                pd_core {
        
        
                                        clk_core {
                                                operating-points = <0x4c2c0 0x10c8e0 0x7b0c0 0x10c8e0 0xc7380 0x10c8e0 0xf6180 0x10c8e0>;
                                                channel = <0x0>;
                                                temp-limit-enable = <0x1>;
                                                target-temp = <0x5f>;
                                                normal-temp-limit = <0x3 0x17700 0x6 0x23280 0x9 0x2ee00 0xf 0x5dc00>;
                                                performance-temp-limit = <0x64 0xc7380>;
                                                status = "okay";
                                                support-pvtm = <0x1>;
                                                pvtm-operating-points = <0x1ec30 0xdbba0 0x61a8 0x34bc0 0xdbba0 0x61a8 0x4c2c0 0xdbba0 0x61a8 0x639c0 0xdbba0 0x61a8 0x927c0 0xe7ef0 0xc350 0xa9ec0 0xe7ef0 0x61a8 0xc7380 0xf4240 0x61a8 0xf6180 0x100590 0x61a8 0x124f80 0x10c8e0 0x61a8 0x159b40 0x124f80 0x61a8 0x171240 0x13d620 0x61a8 0x188940 0x149970 0x61a8 0x1a0040 0x149970 0x61a8 0x1b7740 0x149970 0x61a8>;
                                        };
                                };
                        };
        P.S. So far CPU and GPU OC is a mystery for me. With above DTS files compiled into DTB by Wasser I've got for example CPU operating point 1008000 kHz and 1075000 uV but from DTS file voltage should be either 1100000 (operating-points=0x10c8e0) or 1050000 (pvtm-operating-points = 0x100590) for frequency 0xf6180 kHz .
        Proof:
        Code:
        cat /sys/class/regulator/regulator.13/microvolts
        1075000
        cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
        1008000
        Last edited by Gormar; 12-25-2014, 09:18.
        RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
        Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
        bricked: VOYO V1 mini 8G/64GB Windows 10

        Comment


          #19
          ok what about all the apps for example Antutu it says CPU 1800MHz? is that wrong? I flashed Wassers CPU1800/DDR700/GPU600 and it gave me a good boost in Antutu, over 40k points, anyway can the DDR3 chip take 700MHz safe or should I go for 600DDR instead?

          Tapatalked from my GALAXY S5

          Comment


            #20
            @Gilgamesh. From my test I can only conclude that 1,8GHz isn't realy set in hardware but only reported by kernel as set. Antutu scores went up because of faster GPU and RAM. I've checked this with help of sunspider test and 1,6GHz and 1,8GHz governor performance setting gave virtually identical results. Even limiting max cpu frequency to 1,5GHz worsen the score but not 200 MHz difference between 1,6GHz and 1,8GHz. Oman found some strange limiter in kernel source (#define SAFETY_FREQ (1876*6)/7*MHZ).
            RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
            Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
            bricked: VOYO V1 mini 8G/64GB Windows 10

            Comment


              #21
              @Gormar, ok thanks once again atleast DDR3 and GPU can be overclocked, but I do wonder if it do give any boost in normal usage for example watching movies and other stuff not benchmarking?

              I don't play games either, so maybe it's the CPU that will give a boost in normal usage say for example real 1.8GHz or even 2GHz if the chip can handle it?

              so for the moment we have max 1,6GHz CPU, 700MHz DDR3 and 600MHz GPU.

              Tapatalked from my GALAXY S5

              Comment


                #22
                @Gilgamesh. I don't realy know in which frequency domain VPU (Video Processing Unit) is located. I could be tied to GPU but from low power consumption point it should have his own working frequency consisted with demanded decoding performance.

                As for OC CPU it should speedup "normal" system usage but do not expect miracles. I've read somewhere (kernel patch discussion) that to achive stable 1,8GHz operation RK3288 require 1,4V. If its true then 2GHz is rather out of reach.

                Faster RAM throughput isn't realy needed for better CPU (Cortex a12/17) performance because it is backed up by two channel memory controler (2x32bit) which allow almost two times better transfer from/to RAM than in RK3188 case.
                RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
                Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
                bricked: VOYO V1 mini 8G/64GB Windows 10

                Comment


                  #23
                  @Gormar, thanks! well lets hope we can get 1.8GHz running at least...but I'm looking forward for newer firmwares, sometimes better software can give good boost too.

                  Tapatalked from my GALAXY S5

                  Comment


                    #24
                    FireFly

                    @Gormar

                    Compiling .dts and writing new Kernel & Resource

                    Will try your system. Have reached "End Of Frequency Table ERROR" @2.304 GHZ
                    HeatSink and fan 50C is max temp at 2.208 GHZ after several 2Hr Stress tests
                    GPU to 700 14.5mv ?
                    DDR3 clocked to 1600 (800) with an additional step to 1924 on performance (2124 is possible)

                    The HeatSink with fan has taken temp out and opened up this chip. The RK3288 = Intel I-5 next o/c.

                    Comment


                      #25
                      @coppybob. From what I have read it is hard to belive in such high OC.
                      How did you change #define SAFETY_FREQ (1876*6)/7*MHZ in kernel source? Which voltage did you set for CPU 2GHz working point. Does regulator indicate that voltage is set? To check it change governor to Performance and CPU frequency to 2GHz and see what "cat /sys/class/regulator/regulator.13/microvolts" tells you.
                      RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
                      Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
                      bricked: VOYO V1 mini 8G/64GB Windows 10

                      Comment


                        #26
                        Originally posted by Gilgamesh View Post
                        ok what about all the apps for example Antutu it says CPU 1800MHz? is that wrong? I flashed Wassers CPU1800/DDR700/GPU600 and it gave me a good boost in Antutu, over 40k points, anyway can the DDR3 chip take 700MHz safe or should I go for 600DDR instead?

                        Tapatalked from my GALAXY S5
                        Is it possible to just flash Waster's OC file to my device? It doesn't seem to be the whole kernel, just a zip file that updates it with these values.

                        Comment


                          #27
                          @Steveboroughs. If you don't use Wasser's R89 kernel then probably that resource file will not work with your device. But it is relatively easy to alter your own resource.img because there is no check sum.
                          RK3288 2GB/16GB OC 1.9GHz at 1.2V RAM [email protected] Wasser's 3.0.11 firmware
                          Out: monitor FullHD 16:9, 3.5" jack headphones; In: remote control, USB HUB: keyboard + mouse + pendrive
                          bricked: VOYO V1 mini 8G/64GB Windows 10

                          Comment


                            #28
                            New extreme kernels from sam_ugoos will come soon

                            Sam from Ugoos team preparing and testing new overclocking kernels for RK3288 devices - for guys who have ready protection from overheat and realy want to have extremal powerly devices. Note that you will use this kernels at your own risk. Links on kernels will be posted after final testing stage, So coming soon...

                            This is first testing results with stable values of cpu and ddr frequencies:

                            cpu - 2016Mhz, ram - 744Mhz, video - 598Mhz, antutu - 42662



                            cpu - 2016Mhz (locked at max), ram - 744Mhz, video - 598Mhz, antutu - 43394



                            cpu - 2208Mhz, ram - 744Mhz, video - 598Mhz, antutu - 44707



                            cpu - 2208Mhz (locked at max), ram - 744Mhz, video - 598Mhz, antutu - 45541

                            Comment


                              #29
                              nice! but first two is same values but different score? anyway, so 2GHz is stable enough for 24/7 use? I won't need more than 2GHz if its unstable more than 2GHz CPU

                              Tapatalked from my GALAXY S5

                              Comment


                                #30
                                Originally posted by Gilgamesh View Post
                                nice! but first two is same values but different score? anyway, so 2GHz is stable enough for 24/7 use? I won't need more than 2GHz if its unstable more than 2GHz CPU

                                Tapatalked from my GALAXY S5
                                locked - mean frequency always have maximum value. if not locked - then value floating from minimal to maximum as system decide. I think all will depends by your needs. You will play games 24/7? Or play movies? Or device will have no backround tasks? Kernels ready and now testing by Sam. After he have stable results, we will post links to download

                                Comment

                                Working...
                                X