Announcement

Collapse
No announcement yet.

Simplifying and automating multi-stick RK3188 kernel compilation

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Simplifying and automating multi-stick RK3188 kernel compilation

    Looking at this forum for some time I noticed all kinds of roms and kernels appearing for different RK3188 sticks. One person add this for stick A, another that for stick B. For as far as I can tell all these RK3188 sticks are 99% identical, yet most people only build stuff for the sticks they own.

    Looking at the kernel, what differences do we see?
    • HDMI connected to a different LCDC
    • different WIFI / BT chipset
    • different voltages in the PMU settings
    • different GPIO lines for controlling the internals
    • anything else?
    Most of the above can be configured through kernel config parameters. Some such as the voltages and GPIO lines through source code, but they could easily be parameterized turning them into kernel config settings as well.

    What's stopping people from building kernels for other sticks then? Well, there's no clear list available with the kernel settings required for different sticks. Everybody reinvents the wheel by trial and error. Another consequence of this is that not all kernels have the same base facilities (such as USB audio support, etc etc).

    What we need is a solid base config, with all the right stick-independent settings included. On top of that we need a small config for each stick containing only the settings required for that stick. When building a kernel for a certain stick, the base config merged with the stick specific config will be used to produce the kernel. Using these configs you can build kernels for sticks you don't own yourself.

    To simplify the process, some convenience scripts can be added such as a multi-stick build script, automatically producing kernels for all configs available. Building the first kernel takes most of the time, any additional builds are incremental and won't add much to the build time.

    To lower the barrier for people to start hacking kernels, a simple "install" script can be made to setup all the right build dependencies on a clean ubuntu machine, clone the kernel sources from github, etc.

    Additional convenience scripts could include setting the correct cross-compile environment variables, updating the github repo clone to the latest version, etc.

    Beside different stick hardware there are some more variants that could be included such as sam321's overclock code. In this way you could say: build me a kernel for all sticks with and without overclock.

    Now instead of posting a kernel for just 1 stick, you can just post a zip with kernels for all sticks

    What is needed?

    I'm willing to invest some time into making all the install, build and convenience scripts. I do need input from others about the kernel specific settings though! This includes all specific kernel config settings and source code modifications. Please look in the list in the top of this post to see what kind of information I need. Just post the information in this thread. Please stay on topic to keep the thread short and readable, thanks!

    UPDATE:
    I created a tool to do this job:
    http://www.freaktab.com/showthread.p...nel-build-tool
    Last edited by phjanderson; 08-28-2013, 08:27.
    Want to thank me for my work? Donate to one of the administrators of this forum here or here, thanks!

    #2
    Originally posted by phjanderson View Post
    Looking at this forum for some time I noticed all kinds of roms and kernels appearing for different RK3188 sticks. One person add this for stick A, another that for stick B. For as far as I can tell all these RK3188 sticks are 99% identical, yet most people only build stuff for the sticks they own.

    Looking at the kernel, what differences do we see?
    • HDMI connected to a different LCDC
    • different WIFI / BT chipset
    • different voltages in the PMU settings
    • different GPIO lines for controlling the internals
    • anything else?
    Most of the above can be configured through kernel config parameters. Some such as the voltages and GPIO lines through source code, but they could easily be parameterized turning them into kernel config settings as well.

    What's stopping people from building kernels for other sticks then? Well, there's no clear list available with the kernel settings required for different sticks. Everybody reinvents the wheel by trial and error. Another consequence of this is that not all kernels have the same base facilities (such as USB audio support, etc etc).

    What we need is a solid base config, with all the right stick-independent settings included. On top of that we need a small config for each stick containing only the settings required for that stick. When building a kernel for a certain stick, the base config merged with the stick specific config will be used to produce the kernel. Using these configs you can build kernels for sticks you don't own yourself.

    To simplify the process, some convenience scripts can be added such as a multi-stick build script, automatically producing kernels for all configs available. Building the first kernel takes most of the time, any additional builds are incremental and won't add much to the build time.

    To lower the barrier for people to start hacking kernels, a simple "install" script can be made to setup all the right build dependencies on a clean ubuntu machine, clone the kernel sources from github, etc.

    Additional convenience scripts could include setting the correct cross-compile environment variables, updating the github repo clone to the latest version, etc.

    Beside different stick hardware there are some more variants that could be included such as sam321's overclock code. In this way you could say: build me a kernel for all sticks with and without overclock.

    Now instead of posting a kernel for just 1 stick, you can just post a zip with kernels for all sticks

    What is needed?

    I'm willing to invest some time into making all the install, build and convenience scripts. I do need input from others about the kernel specific settings though! This includes all specific kernel config settings and source code modifications. Please look in the list in the top of this post to see what kind of information I need. Just post the information in this thread. Please stay on topic to keep the thread short and readable, thanks!
    I already have groundwork laid out in my build_mk908.sh script in my kernel github (link in signature). Wouldn't take much to modify a few things. I already have conditionals in the board file for overclock and overvolt and added it as a kernel config option in menuconfig and through the defconfigs. I would think it wouldn't be too hard to create a list of devices, then submenu it with options (720 vs 1080 build, oc or not, etc.) and then just generate a defconfig on the fly for building (rather than having a ton of defconfigs lying around like I do right now in my build). You are welcome to work off my build script. I designed it the way it is because I wanted to be able to generate builds faster and it's saved me a ton of time. Currently the script lets me choose my toolchain, my build cleanup, logging, which defconfig to use (and let's you modify it), what type of output to generate and where to dump it, etc. It's dirty, but works well for me. Like I said, wouldn't take much to add to it to create what you are proposing. The call-to-arms would be to create a list of devices and some of those device-specific info to make it all happen as you mentioned. As I just have the MK908, I can't help much more than that, but all my mk908 specific stuff is available for consumption in my github.
    Question Reality: Find Your Own Truth!

    My MK908 Cooling Mod and Breakdown : HERE
    My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

    Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

    Want to say thanks for something I did/said or DONATE to my drink fund?

    Comment


      #3
      framework

      I built some device framework into a forked version of my build_mk908 script (now called buildit.sh) found in my
      kernel source github. I just need to finish up the config builder and then can add in other devices as required.
      Currently only has MK908 config stuff and some starter T428 config stuff in there. I welcome any suggestions to
      the build script. As noted in the build script comments, portions of the builder is linked to the arch/arm/mach-rk3188
      source files specific to my kernel tree. Anyone is free to pull that portion of the tree and diff it or use it as they see
      fit with their own kernel source (or look for the SAW tagged comments)

      As mentioned, feel free to make suggestions or criticisms and I'll see what I can do to accommodate them.
      Question Reality: Find Your Own Truth!

      My MK908 Cooling Mod and Breakdown : HERE
      My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

      Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

      Want to say thanks for something I did/said or DONATE to my drink fund?

      Comment


        #4
        Originally posted by thesawolf View Post
        The call-to-arms would be to create a list of devices and some of those device-specific info to make it all happen as you mentioned.
        Indeed! I have a T428, so we have the MK908 and T428 covered now. I think I should be able to distill the MK802IV old/new config from some of the kernel sources around. Any other sticks?

        Input on which sticks are interchangeable is also welcome! For example, I think the Measy U4C is identical to the T428.
        Want to thank me for my work? Donate to one of the administrators of this forum here or here, thanks!

        Comment


          #5
          excelent idea, we can create a basic defconfig for each one of the existent stick, and to solve the gpio ot pmu voltage problems we can create define lines in board-rk3188-box.c; for example:

          Code:
          #if defined CONFIG_TCC_BT_DEV
          #if define btgpioalt
          static struct tcc_bt_platform_data tcc_bt_platdata = {
          
              .power_gpio   = { // ldoon
                  .io             =  RK30_PIN3_PD1,//BT working in iMito QX1 stock:RK30_PIN3_PC7 
                  .enable         = GPIO_HIGH,
                  .iomux          = {
                      .name       = NULL,
                      },
                  },
          #else
          static struct tcc_bt_platform_data tcc_bt_platdata = {
          
              .power_gpio   = { // ldoon
                  .io             =  RK30_PIN3_PC7 ,//BT working in other sticks like old mk802IV
                  .enable         = GPIO_HIGH,
                  .iomux          = {
                      .name       = NULL,
                      },
                  },
          #endif
          
              .wake_host_gpio  = { // BT_HOST_WAKE, for bt wakeup host when it is in deep sleep
                  .io         = RK30_PIN3_PD0, // set io to INVALID_GPIO for disable it
                  .enable     = IRQF_TRIGGER_RISING,// set IRQF_TRIGGER_FALLING for falling, set IRQF_TRIGGER_RISING for rising
                  .iomux      = {
                      .name       = NULL,
                  },
              },
          };
          
          static struct platform_device device_tcc_bt = {
              .name   = "tcc_bt_dev",
              .id     = -1,
              .dev    = {
                  .platform_data = &tcc_bt_platdata,
                  },
          };
          #endif
          Then we must add to the config configuration files a new section to select the stick, like: mk802IV-8188eus;mk908;qx1;etc and define each stick with the correct gpio and pmu setting.

          Or we can make diferent board-rk3188-box.c files for each stick and select in the script what file is need to copy.

          To the QX1 the relevant changes to make wifi and BT work are:
          in board-rk3188-box.c:

          Code:
          #if defined CONFIG_TCC_BT_DEV
          static struct tcc_bt_platform_data tcc_bt_platdata = {
          
              .power_gpio   = { // ldoon
                  .io             =  RK30_PIN3_PD1,//BT working in iMito QX1 stock:RK30_PIN3_PC7 
                  .enable         = GPIO_HIGH,
                  .iomux          = {
                      .name       = NULL,
                      },
                  },
          
              .wake_host_gpio  = { // BT_HOST_WAKE, for bt wakeup host when it is in deep sleep
                  .io         = RK30_PIN3_PD0, // set io to INVALID_GPIO for disable it
                  .enable     = IRQF_TRIGGER_RISING,// set IRQF_TRIGGER_FALLING for falling, set IRQF_TRIGGER_RISING for rising
                  .iomux      = {
                      .name       = NULL,
                  },
              },
          };
          
          static struct platform_device device_tcc_bt = {
              .name   = "tcc_bt_dev",
              .id     = -1,
              .dev    = {
                  .platform_data = &tcc_bt_platdata,
                  },
          };
          #endif
          and
          Code:
          #ifdef CONFIG_REGULATOR_ACT8846
          #define PMU_POWER_SLEEP RK30_PIN0_PA1
          #define PMU_VSEL RK30_PIN3_PD3
          #define ACT8846_HOST_IRQ                RK30_PIN0_PB3
          
          static struct pmu_info  act8846_dcdc_info[] = {
              {
                  .name          = "act_dcdc1",   //ddr
                  .min_uv          = 1200000,
                  .max_uv         = 1200000,
                  .suspend_vol  =   1200000,
              },
              {
                  .name          = "vdd_core",    //logic
                  .min_uv          = 1000000,
                  .max_uv         = 1000000,
                  #ifdef CONFIG_ACT8846_SUPPORT_RESET
                  .suspend_vol  =  1200000,
                  #else
                  .suspend_vol  =  900000,
                  #endif
              },
              {
                  .name          = "vdd_cpu",   //arm
                  .min_uv          = 1000000,
                  .max_uv         = 1000000,
                  #ifdef CONFIG_ACT8846_SUPPORT_RESET
                  .suspend_vol  =  1200000,
                  #else
                  .suspend_vol  =  900000,
                  #endif
              },
              {
                  .name          = "act_dcdc4",   //vccio //modded by leolas stock:3300000 working:3000000
                  .min_uv          = 3000000,
                  .max_uv         = 3000000,
                  #ifdef CONFIG_ACT8846_SUPPORT_RESET
                  .suspend_vol  =  3000000,
                  #else
                  .suspend_vol  =  2800000,
                  #endif
              },
              
          };
          static  struct pmu_info  act8846_ldo_info[] = {
              {
                  .name          = "act_ldo1",   //vdd10
                  .min_uv          = 1000000,
                  .max_uv         = 1000000,
              },
              {
                  .name          = "act_ldo2",    //vdd12
                  .min_uv          = 1200000,
                  .max_uv         = 1200000,
              },
              {
                  .name          = "act_ldo3",   //vcc18_cif
                  .min_uv          = 1800000,
                  .max_uv         = 1800000,
              },
              {
                  .name          = "act_ldo4",   //vcca33
                  .min_uv          = 3300000,
                  .max_uv         = 3300000,
              },
              {
                  .name          = "act_ldo5",   //vcc_rmii
                  .min_uv          = 3300000,
                  .max_uv         = 3300000,
              },
              {
                  .name          = "act_ldo6",   //vcc_jetta //leolas modded stock:1800000 wifi working:3300000
                  .min_uv          = 3300000,
                  .max_uv         = 3300000,
              },
              {
                  .name          = "act_ldo7",   //vcc18
                  .min_uv          = 1800000,
                  .max_uv         = 1800000,
              },
              {
                  .name          = "act_ldo8",   //vcc28_cif
                  .min_uv          = 2800000,
                  .max_uv         = 2800000,
              },
           };
          
          #include "../mach-rk30/board-pmu-act8846.c"
          #endif
          my .config is in my github https://github.com/leolas/ANDROID-KERNEL-QX1/blob/master/config-1080p-30-07-2013

          It works fine in the imito qx1
          REMEMBER, YOUR FEEDBACK IS VERY IMPORTANT TO US.
          My devices:
          Minix Neo X7; Minix Neo X8-H , Minix Neo Z64W & Z64 (Sponsored by Minix)
          MK902 & MK902II(Sponsored by RKM)
          Beelink M8B & Beelink R89 (Sponsored by Beelink)
          Tronsmart VEGA S89H (Sponsored by
          Gearbest.com)
          MELE-PCG03 (Sponsored by Gearbest.com) Discount Coupon:MPCG03
          Ainol Intel Z3735 MiniPC(Sponsored by Gearbest.com)
          Thanks to them I can try to support your devices http://freaktab.com/core/images/smilies/wink.png

          Comment


            #6
            Originally posted by leolas View Post
            Then we must add to the config configuration files a new section to select the stick, like: mk802IV-8188eus;mk908;qx1;etc and define each stick with the correct gpio and pmu setting.

            Or we can make diferent board-rk3188-box.c files for each stick and select in the script what file is need to copy.
            I think it's better to add conditional blocks in some code files such as board-rk3188-box.c. Duplicating files gets messy easily.

            About the configs for multiple sticks, I was thinking of a pretty simple solution. I haven't really thought it all through yet but it would be something like this:

            There's one base kernel config file, containing all the basic settings. Then there are additional kernel config files for each different type of sticks containing only the settings for that specific stick, such as which wifi chip, voltages, etc. All these files are in the standard kernel config format. Next we might have some variant config files, containing overclocks, etc. These files are organized in a few folders, for example: base, device, variants. This will allow you to mix and match the configs, for example: base + mk908 + overclock. On top of this you could add a local config file where people can add their own choices to override the above.

            I did a quick test, if you define a config parameter multiple times, the last one overrides the earlier ones. So it would just be a matter of concatenating these files together.

            You can build all kinds of convenience scripts around this setup, depending on your wishes. Such as a script that can build a certain choice of variants, for example overclocked and non-overclocked, for all sticks from the devices folder.

            The advantage to my idea is that all kernel configs are in plain text in the original format, not hidden in code or Kconfig dependencies. People can also just look into these files and copy the settings to use them without any of those convenience scripts.
            Want to thank me for my work? Donate to one of the administrators of this forum here or here, thanks!

            Comment


              #7
              Originally posted by phjanderson View Post
              I think it's better to add conditional blocks in some code files such as board-rk3188-box.c. Duplicating files gets messy easily.

              About the configs for multiple sticks, I was thinking of a pretty simple solution. I haven't really thought it all through yet but it would be something like this:

              There's one base kernel config file, containing all the basic settings. Then there are additional kernel config files for each different type of sticks containing only the settings for that specific stick, such as which wifi chip, voltages, etc. All these files are in the standard kernel config format. Next we might have some variant config files, containing overclocks, etc. These files are organized in a few folders, for example: base, device, variants. This will allow you to mix and match the configs, for example: base + mk908 + overclock. On top of this you could add a local config file where people can add their own choices to override the above.

              I did a quick test, if you define a config parameter multiple times, the last one overrides the earlier ones. So it would just be a matter of concatenating these files together.

              You can build all kinds of convenience scripts around this setup, depending on your wishes. Such as a script that can build a certain choice of variants, for example overclocked and non-overclocked, for all sticks from the devices folder.

              The advantage to my idea is that all kernel configs are in plain text in the original format, not hidden in code or Kconfig dependencies. People can also just look into these files and copy the settings to use them without any of those convenience scripts.
              Thanks for the QX1 info, Leolas. I'll get it added into the script and make any necessary conditional changes in the board files. Soon the build script will generate config files on the fly so you don't have to have config files laying around. You just pick and choose a predefined device or you can pick and choose settings and build a template that we will generate a kernel config file for you (and give us something to add into the script for that particular device). I created a repo just for the script at: https://github.com/thesawolf/RK3188-kernel-builder
              It is also mirrored in my kernel tree after major updates at: https://github.com/thesawolf/android...ockchip_rk3188

              Question for everyone tho. I currently build a full-featured kernel (with support for tunneling, joysticks, all kinds of USB devices, exFAT support, etc.) so some of the features in the generated kernel configs are included in there by default as I've tested most of them. Should I leave them out for those that want to build really lean kernels or include them by default? Once a kernel config is generated on the fly, a user can easily go into menuconfig and change options themselves.. or I can just build it into the script. (As it stands, you really don't need to go into menuconfig at all with the config builder handling most of the common features)
              Question Reality: Find Your Own Truth!

              My MK908 Cooling Mod and Breakdown : HERE
              My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

              Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

              Want to say thanks for something I did/said or DONATE to my drink fund?

              Comment


                #8
                Originally posted by thesawolf View Post
                Question for everyone tho. I currently build a full-featured kernel (with support for tunneling, joysticks, all kinds of USB devices, exFAT support, etc.) so some of the features in the generated kernel configs are included in there by default as I've tested most of them. Should I leave them out for those that want to build really lean kernels or include them by default? Once a kernel config is generated on the fly, a user can easily go into menuconfig and change options themselves.. or I can just build it into the script. (As it stands, you really don't need to go into menuconfig at all with the config builder handling most of the common features)
                There's always a gray area between what "obviously" needs to be in the kernel and what can be considered "optional". I guess it won't hurt to add a bit more, doubt if that would make the system any slower. If you build a zkernel, the image size won't be very large either.

                With my proposed system of a base config + variant configs you can easily bundle all these things into separate files and call them joysticks, tvcards, etc. Then it's just a matter of selecting what you need

                You could even make a menu around it so people can checkmark the optional things like joysticks, tvcards, overclock, etc etc.

                I will try to make a prototype soon.
                Want to thank me for my work? Donate to one of the administrators of this forum here or here, thanks!

                Comment


                  #9
                  Originally posted by phjanderson View Post
                  There's always a gray area between what "obviously" needs to be in the kernel and what can be considered "optional". I guess it won't hurt to add a bit more, doubt if that would make the system any slower. If you build a zkernel, the image size won't be very large either.

                  With my proposed system of a base config + variant configs you can easily bundle all these things into separate files and call them joysticks, tvcards, etc. Then it's just a matter of selecting what you need

                  You could even make a menu around it so people can checkmark the optional things like joysticks, tvcards, overclock, etc etc.

                  I will try to make a prototype soon.
                  Currently the script has an overclock OPTION that ties into conditionals in the board files (in addition to all the device specific settings). Wouldn't be hard to add other features like peripherals to the script. Would just need to diff a sanitized kernel config vs my feature packed one. And even with all my stuff added in my kernel is a max of 9megs LZO compressed (which isn't really that compressed if you know the difference between LZO, GZIP, etc. LOL)
                  Question Reality: Find Your Own Truth!

                  My MK908 Cooling Mod and Breakdown : HERE
                  My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

                  Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

                  Want to say thanks for something I did/said or DONATE to my drink fund?

                  Comment


                    #10
                    Build script pretty much done

                    LABS v2.5 is ready for public consumption and testing.
                    You can find it in my kernel source or its own github (https://github.com/thesawolf)

                    Builder features:
                    • Toolchain selection (if you use my kernel tree, you can select from System default, Android, Linaro 4.6, latest Linaro, Google or modify script to use your own)
                    • Config builder (will let you create your own or have it automatically generate one for you based on your device settings selected in LABS)
                    • Output specification (tell it where you want to dump your kernel/modules)
                    • Build log options
                    • Clean up options
                    • Thread selection
                    • Save/Reload build settings (for easy reuse)
                    • Commandline run (no need to use menu, just specify -b and will pull your saved build settings)
                    • Auto builder (based on your options selected, will handle all the make calls for you)
                    Device features:
                    • predefined device selection (or gets you started with a template or not, if you don't want)
                    • HDMI resolution selector (480p, 720p, 1080p)
                    • LCD settings
                    • Wifi chipset selector
                    • Bluetooth chipset selector
                    • PMU chipset selector
                    • Specify any predefined special requirements (volts, GPIOs, etc.)
                    • Special options (mainly linked to my kernel sources but includes debugging, overclocking, exFAT, and mali driver options where available)
                    Current Devices supported:
                    • Tronsmart MK908
                    • Tronsmart T428
                    • Imito QX-1
                    Have a working defconfig for another device? Send it to me so I can get your device added into the LABS. Thanks!


                    INSTRUCTIONS:
                    run ./BUILDIT.sh from commandline in a RK3188 kernel tree
                    commandline opts of: -v for vers, -b for unattended build, -?/h for help, no parameters specified will run LABS through the menu system

                    NOTES: A number of features are linked to my kernel tree (ie. the toolchains, etc.) It doesn't take much to edit the script to reflect your personal tree if you don't use mine. Script is commented enough to help you find what you need. Notably, some of the options are linked to source files in arch/arm/mach-rk3188 that I have modified to handle as kernel config options (so you don't have to constantly flag the define tags in the source file). However, if you are using your own kernel source, you will need to look at my Kconfig and board-rk3188-box.c (look for the SAW-tagged comments) and mimic some of them to achieve the same results (for now, anyways)


                    You can download the scripts via :
                    https://github.com/thesawolf/RK3188-kernel-builder/archive/master.zip
                    (Please note that the builder isn't completely sanitized and relies on some features found in my kernel source, see notes above about that)
                    Question Reality: Find Your Own Truth!

                    My MK908 Cooling Mod and Breakdown : HERE
                    My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

                    Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

                    Want to say thanks for something I did/said or DONATE to my drink fund?

                    Comment


                      #11
                      Great work, I can't test it now, lut of home again but I sign it on my to-do list. Thanks

                      leolas
                      REMEMBER, YOUR FEEDBACK IS VERY IMPORTANT TO US.
                      My devices:
                      Minix Neo X7; Minix Neo X8-H , Minix Neo Z64W & Z64 (Sponsored by Minix)
                      MK902 & MK902II(Sponsored by RKM)
                      Beelink M8B & Beelink R89 (Sponsored by Beelink)
                      Tronsmart VEGA S89H (Sponsored by
                      Gearbest.com)
                      MELE-PCG03 (Sponsored by Gearbest.com) Discount Coupon:MPCG03
                      Ainol Intel Z3735 MiniPC(Sponsored by Gearbest.com)
                      Thanks to them I can try to support your devices http://freaktab.com/core/images/smilies/wink.png

                      Comment


                        #12
                        Great work!

                        I have a few comments about the config parameters though:

                        The CONFIG_OVERVOLT_CPU is kind of misleading:
                        Code:
                        static int pwm_voltage_map[] = 
                        {#ifdef CONFIG_OVERVOLT_CPU
                        //Set max voltage from 1375000 to 1450000 OC CPU < 2.16GHz - Sam321
                            800000, 825000, 850000, 875000, 900000, 925000, 950000, 975000, 1000000, 1025000, 1050000, 1075000, 1100000, 1125000, 1150000, 1175000, 1200000, 1225000, 1250000, 1275000, 1300000, 1325000, 1350000, 1375000, 1400000, 1425000, 1450000
                        #else
                            800000, 825000, 850000, 875000, 900000, 925000, 950000, 975000, 1000000, 1025000, 1050000, 1075000, 1100000, 1125000, 1150000, 1175000, 1200000, 1225000, 1250000, 1275000, 1300000, 1325000, 1350000, 1375000
                        #endif
                        
                        
                        };
                        As far as I can see changing the voltage map does not overvolt the CPU. It merely allows higher voltages to be selected in the rest of the code. As long as you do not select the added higher voltages, they will not be used. So it should be safe to simply add the extra voltages to this map without a config parameter. (correct me if I'm wrong)

                        The same goes to:
                        Code:
                        #ifdef CONFIG_OVERVOLT_CPU
                        //SAW -- max voltage setting - Sam321 
                                .max_uV    = 1450000,
                        #else
                                .max_uV = 1375000,
                        #endif
                        Now if we look at this section:
                        Code:
                        #if defined CONFIG_TCC_BT_DEV
                        static struct tcc_bt_platform_data tcc_bt_platdata = {
                        
                        
                            .power_gpio   = { // ldoon
                        //SAW QX1 setting thanks to Leolas
                        #ifdef CONFIG_RK_VOLT2
                            .io        = RK30_PIN3_PD1,
                        #else
                                .io             = RK30_PIN3_PC7,
                        #endif
                                .enable         = GPIO_HIGH,
                                .iomux          = {
                                    .name       = NULL,
                                    },
                                },
                        
                        
                            .wake_host_gpio  = { // BT_HOST_WAKE, for bt wakeup host when it is in deep sleep
                                .io         = RK30_PIN3_PD0, // set io to INVALID_GPIO for disable it
                                .enable     = IRQF_TRIGGER_RISING,// set IRQF_TRIGGER_FALLING for falling, set IRQF_TRIGGER_RISING for rising
                                .iomux      = {
                                    .name       = NULL,
                                },
                            },
                        };
                        The config parameter CONFIG_RK_VOLT2 is misleading, it does not affect any voltage. The block seems to be about a TCC BT device. Without diving further into the code my guess would be that this section defines the GPIO wiring for enabling/disabling the TCC BT device and waking the CPU up through a BT event.

                        I suggest to always use config parameters that describe what it sets. In this case that might be:
                        CONFIG_TCC_BT_DEV_POWER_PIN3_PD1

                        Same goes to this one. The parameter does not describe what it changes:
                        Code:
                            {
                                .name          = "act_dcdc4",   //vccio 
                        //SAW special voltage for QX1, from Leolas
                        #ifdef CONFIG_RK_VOLT2
                                .min_uv        = 3000000,
                                .max_uv        = 3000000,
                        #else
                                .min_uv         = 3300000,
                                .max_uv         = 3300000,
                        #endif
                                #ifdef CONFIG_ACT8846_SUPPORT_RESET
                                .suspend_vol  =  3000000,
                                #else
                                .suspend_vol  =  2800000,
                                #endif
                            },
                        A better name would be:
                        CONFIG_ACT8846_DCDC4_30V

                        Same:
                        Code:
                            {
                                .name          = "act_ldo6",   //vcc_jetta
                        //SAW volt set via kernel config, default 3300000, mk908 and some others
                        //need 1800000 to get wifi/bt working properly
                        #ifdef CONFIG_RK_VOLT1
                                .min_uv         = 1800000, 
                                .max_uv         = 1800000, 
                        #else
                                .min_uv        = 3300000,
                                .max_uv        = 3300000,
                        #endif
                            },
                        A better name would be:
                        CONFIG_ACT8846_LDO6_18V

                        About the CPU overclock:
                        Code:
                        static struct cpufreq_frequency_table dvfs_arm_table[] = {
                        #ifdef CONFIG_OVERCLOCK_CPU //SAW
                        //on MK908, I cannot get anything over 1.7 running properly, 1.7 is cap for now
                                {.frequency = 312 * 1000,       .index = 900 * 1000},
                                {.frequency = 504 * 1000,       .index = 925 * 1000},
                                {.frequency = 816 * 1000,       .index = 1000 * 1000},
                                {.frequency = 1008 * 1000,      .index = 1075 * 1000},
                                {.frequency = 1200 * 1000,      .index = 1150 * 1000},
                                {.frequency = 1416 * 1000,      .index = 1250 * 1000},
                                {.frequency = 1608 * 1000,      .index = 1325 * 1000},
                                {.frequency = 1704 * 1000,    .index = 1350 * 1000},
                        #ifdef CONFIG_EXTREME_OCCPU //SAW
                            {.frequency = 1776 * 1000,    .index = 1350 * 1000},
                            {.frequency = 1896 * 1000,    .index = 1375 * 1000},
                            {.frequency = 1920 * 1000,    .index = 1400 * 1000},
                            {.frequency = 2016 * 1000,    .index = 1450 * 1000},
                        #endif
                        #else
                                {.frequency = 312 * 1000,       .index = 900 * 1000},
                                {.frequency = 504 * 1000,       .index = 925 * 1000},
                                {.frequency = 816 * 1000,       .index = 1000 * 1000},
                                {.frequency = 1008 * 1000,      .index = 1075 * 1000},
                                {.frequency = 1200 * 1000,      .index = 1150 * 1000},
                                {.frequency = 1416 * 1000,      .index = 1250 * 1000},
                                {.frequency = 1608 * 1000,      .index = 1350 * 1000},
                        #endif
                            {.frequency = CPUFREQ_TABLE_END},
                        };
                        What might be "extreme" to you, might be a "normal" overclock to others. How about making individual config parameters for each frequency:
                        CONFIG_OVERCLOCK_CPU_1704
                        CONFIG_OVERCLOCK_CPU_1776
                        CONFIG_OVERCLOCK_CPU_1896
                        CONFIG_OVERCLOCK_CPU_1920
                        CONFIG_OVERCLOCK_CPU_2016

                        Same goes to this one:
                        Code:
                        static struct cpufreq_frequency_table dvfs_gpu_table[] = {
                        #ifdef CONFIG_OVERCLOCK_GPU //SAW -- Sam321 tweaks below
                        //on MK908, 800MHz works, but get lots of artifacting, disabling for now
                                   {.frequency = 133 * 1000,       .index = 975 * 1000},
                                   {.frequency = 200 * 1000,       .index = 1000 * 1000},
                                   {.frequency = 266 * 1000,       .index = 1025 * 1000},
                            {.frequency = 297 * 1000,    .index = 1050 * 1000},
                                   {.frequency = 399 * 1000,       .index = 1100 * 1000},
                            {.frequency = 594 * 1000,    .index = 1250 * 1000},
                        #ifdef CONFIG_EXTREME_OCGPU //SAW
                            {.frequency = 798 * 1000,    .index = 1325 * 1000},
                        #endif
                        #else
                                   {.frequency = 133 * 1000,       .index = 975 * 1000},
                                   {.frequency = 200 * 1000,       .index = 1000 * 1000},  
                                   {.frequency = 266 * 1000,       .index = 1025 * 1000},  
                                   {.frequency = 297 * 1000,       .index = 1050 * 1000},  
                                   {.frequency = 399 * 1000,       .index = 1100 * 1000},
                                   {.frequency = 594 * 1000,       .index = 1225 * 1000},
                        #endif
                            {.frequency = CPUFREQ_TABLE_END},
                        };
                        I don't understand what the CONFIG_OVERCLOCK_GPU does here, the frequency table is the same as the non-overclocked table. Maybe replace all of this with:
                        CONFIG_OVERCLOCK_GPU_798

                        This one is tricky
                        Code:
                        static struct cpufreq_frequency_table dvfs_ddr_table[] = {
                        #ifdef CONFIG_OVERCLOCK_RAM //SAW -- Sam321 tweaks
                        //on MK908, setting NORMAL here does not work, has to be config defined
                            {.frequency = 396 * 1000 + DDR_FREQ_IDLE,    .index = 1100 * 1000},
                            {.frequency = 396 * 1000 + DDR_FREQ_SUSPEND,    .index = 1100 * 1000},
                        #ifdef CONFIG_EXTREME_OCRAM //SAW -- fill with extreme stuff later
                            {.frequency = 492 * 1000 + DDR_FREQ_VIDEO,     .index = 1150 * 1000},
                            {.frequency = 792 * 1000 + DDR_FREQ_NORMAL,    .index = 1250 * 1000},
                        #else
                            {.frequency = 492 * 1000 + DDR_FREQ_VIDEO,    .index = 1150 * 1000},
                            {.frequency = 792 * 1000 + DDR_FREQ_NORMAL,    .index = 1250 * 1000},
                        #endif
                        #else //SAW stock settings below
                            {.frequency = 300 * 1000 + DDR_FREQ_IDLE,    .index = 1000 * 1000},
                            {.frequency = 300 * 1000 + DDR_FREQ_SUSPEND,    .index = 1000 * 1000},
                            {.frequency = 300 * 1000 + DDR_FREQ_VIDEO,      .index = 1000 * 1000},
                            {.frequency = 396 * 1000 + DDR_FREQ_NORMAL,     .index = 1100 * 1000},
                        #endif
                            {.frequency = CPUFREQ_TABLE_END},
                        };
                        Actually all the source trees I found only contain this list:
                        Code:
                        static struct cpufreq_frequency_table dvfs_ddr_table[] = {
                            //{.frequency = 200 * 1000 + DDR_FREQ_SUSPEND,    .index = 950 * 1000},
                            {.frequency = 300 * 1000 + DDR_FREQ_VIDEO,      .index = 1000 * 1000},
                            {.frequency = 360 * 1000 + DDR_FREQ_NORMAL,     .index = 1100 * 1000},
                            {.frequency = CPUFREQ_TABLE_END},
                        };
                        Do we really need to define the suspend and idle frequencies? When does it enter those states? Or perhaps it never does? And why is the video frequency lower than the normal frequency? Does anyone have an idea about this?

                        There seem to be variations between sticks here. If I remember well my stock T428 kernel has the DDR set to 350mhz instead. It seems to overclock quite a bit though.

                        I remember a posting saying that with a custom kernel powering down the stick made it reboot instead. Perhaps this can be explained by incorrect idle or suspend settings, causing the stick to crash and reboot once it enters those states. The safe choice would then be to set the idle and suspend frequencies/voltages equal to the normal frequency/voltages.

                        A side note about voltages: my T428 was unstable even with a normal kernel. It turned out that the bundled 5V 2A EU plug power supply from geekbuying was too weak, I measured the voltage dropping to below 4.4v even when overclocking. Just because a power supply is rated for 2A doesn't seem to mean that it can actually deliver 2A (see: http://www.lygte-info.dk/info/usbPow...Test%20UK.html and http://www.freaktab.com/showthread.p...2A-inadequate/). Replacing the power supply with a better 2A solved the problem for me. I'm using a 5A now and suddenly overclocking works great. I suspect that for some people the increased voltage settings for DDR, CPU or GPU are just to compensate for this overall voltage drop, increasing the voltages increases the load on the power supply though so eventually that will again cause the overall voltage to drop.
                        Want to thank me for my work? Donate to one of the administrators of this forum here or here, thanks!

                        Comment


                          #13
                          Re: Simplifying and automating multi-stick RK3188 kernel compilation

                          Fork and pull request?

                          Signature? Signature!

                          Comment


                            #14
                            You have to consider that alot of the define names are just a naming convention and be altered, including the parameters.. It's not a set in stone thing. There ARE tweaks people will probably want to do to various settings. This is all foundation work and generic enough settings that seem to work ok across the board. YMMV

                            Originally posted by phjanderson View Post
                            The CONFIG_OVERVOLT_CPU is kind of misleading:
                            Code:
                            static int pwm_voltage_map[] = 
                            {#ifdef CONFIG_OVERVOLT_CPU
                            //Set max voltage from 1375000 to 1450000 OC CPU < 2.16GHz - Sam321
                                800000, 825000, 850000, 875000, 900000, 925000, 950000, 975000, 1000000, 1025000, 1050000, 1075000, 1100000, 1125000, 1150000, 1175000, 1200000, 1225000, 1250000, 1275000, 1300000, 1325000, 1350000, 1375000, 1400000, 1425000, 1450000
                            #else
                                800000, 825000, 850000, 875000, 900000, 925000, 950000, 975000, 1000000, 1025000, 1050000, 1075000, 1100000, 1125000, 1150000, 1175000, 1200000, 1225000, 1250000, 1275000, 1300000, 1325000, 1350000, 1375000
                            #endif
                            };
                            This was added and labelled as such to link to some of the overclocking done later on (mainly in the CPU overclocking area) by Sam. Actually, didn't end up using it BUT I kept the tag in there to accommodate O/C work that I knew would need it later. I can simply change it to CONFIG_OVERVOLT.

                            Originally posted by phjanderson View Post
                            As far as I can see changing the voltage map does not overvolt the CPU. It merely allows higher voltages to be selected in the rest of the code. As long as you do not select the added higher voltages, they will not be used. So it should be safe to simply add the extra voltages to this map without a config parameter. (correct me if I'm wrong)
                            You have a point, but I was concerned that there may be settings in this file and others that are pulling and potentially using the voltage maps min and max set voltages to work with. I didn't trace its usage through all the code. Don't forget that the RK3188 uses and mingles code from mach-rk30 AND plat-rk too. No clue how far it might extend so I didn't to define it to be safe.

                            Originally posted by phjanderson View Post
                            Now if we look at this section:
                            Code:
                            #if defined CONFIG_TCC_BT_DEV
                            static struct tcc_bt_platform_data tcc_bt_platdata = {
                            
                            
                                .power_gpio   = { // ldoon
                            //SAW QX1 setting thanks to Leolas
                            #ifdef CONFIG_RK_VOLT2
                                .io        = RK30_PIN3_PD1,
                            #else
                                    .io             = RK30_PIN3_PC7,
                            #endif
                                    .enable         = GPIO_HIGH,
                                    .iomux          = {
                                        .name       = NULL,
                                        },
                                    },
                            
                            
                                .wake_host_gpio  = { // BT_HOST_WAKE, for bt wakeup host when it is in deep sleep
                                    .io         = RK30_PIN3_PD0, // set io to INVALID_GPIO for disable it
                                    .enable     = IRQF_TRIGGER_RISING,// set IRQF_TRIGGER_FALLING for falling, set IRQF_TRIGGER_RISING for rising
                                    .iomux      = {
                                        .name       = NULL,
                                    },
                                },
                            };
                            The config parameter CONFIG_RK_VOLT2 is misleading, it does not affect any voltage. The block seems to be about a TCC BT device. Without diving further into the code my guess would be that this section defines the GPIO wiring for enabling/disabling the TCC BT device and waking the CPU up through a BT event.

                            I suggest to always use config parameters that describe what it sets. In this case that might be:
                            CONFIG_TCC_BT_DEV_POWER_PIN3_PD1

                            Same goes to this one. The parameter does not describe what it changes:
                            Code:
                                {
                                    .name          = "act_dcdc4",   //vccio 
                            //SAW special voltage for QX1, from Leolas
                            #ifdef CONFIG_RK_VOLT2
                                    .min_uv        = 3000000,
                                    .max_uv        = 3000000,
                            #else
                                    .min_uv         = 3300000,
                                    .max_uv         = 3300000,
                            #endif
                                    #ifdef CONFIG_ACT8846_SUPPORT_RESET
                                    .suspend_vol  =  3000000,
                                    #else
                                    .suspend_vol  =  2800000,
                                    #endif
                                },
                            A better name would be:
                            CONFIG_ACT8846_DCDC4_30V

                            Same:
                            Code:
                                {
                                    .name          = "act_ldo6",   //vcc_jetta
                            //SAW volt set via kernel config, default 3300000, mk908 and some others
                            //need 1800000 to get wifi/bt working properly
                            #ifdef CONFIG_RK_VOLT1
                                    .min_uv         = 1800000, 
                                    .max_uv         = 1800000, 
                            #else
                                    .min_uv        = 3300000,
                                    .max_uv        = 3300000,
                            #endif
                                },
                            A better name would be:
                            CONFIG_ACT8846_LDO6_18V
                            Once again, this was simply a naming convention. I realize that detailed defines may be needed as more devices get added, but I didn't want to create too much chaos in the code. RK_VOLT2 is pretty much an overall define to handle QX1 changes, (in this case, just handle BT device and use different voltage to get Wifi/BT combo working on QX1). I could easily name it RK_QX1 too or use the detailed define naming convention. My choice was to opt for a generic naming convention, but I can see what you are saying with an easier-to-decipher define and I agree that defining the structure now would definitely help before we have tons of other device defines in there. I'll make some code adjustments. Thanks for the suggestion.

                            Originally posted by phjanderson View Post
                            About the CPU overclock:
                            Code:
                            static struct cpufreq_frequency_table dvfs_arm_table[] = {
                            #ifdef CONFIG_OVERCLOCK_CPU //SAW
                            //on MK908, I cannot get anything over 1.7 running properly, 1.7 is cap for now
                                    {.frequency = 312 * 1000,       .index = 900 * 1000},
                                    {.frequency = 504 * 1000,       .index = 925 * 1000},
                                    {.frequency = 816 * 1000,       .index = 1000 * 1000},
                                    {.frequency = 1008 * 1000,      .index = 1075 * 1000},
                                    {.frequency = 1200 * 1000,      .index = 1150 * 1000},
                                    {.frequency = 1416 * 1000,      .index = 1250 * 1000},
                                    {.frequency = 1608 * 1000,      .index = 1325 * 1000},
                                    {.frequency = 1704 * 1000,    .index = 1350 * 1000},
                            #ifdef CONFIG_EXTREME_OCCPU //SAW
                                {.frequency = 1776 * 1000,    .index = 1350 * 1000},
                                {.frequency = 1896 * 1000,    .index = 1375 * 1000},
                                {.frequency = 1920 * 1000,    .index = 1400 * 1000},
                                {.frequency = 2016 * 1000,    .index = 1450 * 1000},
                            #endif
                            #else
                                    {.frequency = 312 * 1000,       .index = 900 * 1000},
                                    {.frequency = 504 * 1000,       .index = 925 * 1000},
                                    {.frequency = 816 * 1000,       .index = 1000 * 1000},
                                    {.frequency = 1008 * 1000,      .index = 1075 * 1000},
                                    {.frequency = 1200 * 1000,      .index = 1150 * 1000},
                                    {.frequency = 1416 * 1000,      .index = 1250 * 1000},
                                    {.frequency = 1608 * 1000,      .index = 1350 * 1000},
                            #endif
                                {.frequency = CPUFREQ_TABLE_END},
                            };
                            What might be "extreme" to you, might be a "normal" overclock to others. How about making individual config parameters for each frequency:
                            CONFIG_OVERCLOCK_CPU_1704
                            CONFIG_OVERCLOCK_CPU_1776
                            CONFIG_OVERCLOCK_CPU_1896
                            CONFIG_OVERCLOCK_CPU_1920
                            CONFIG_OVERCLOCK_CPU_2016
                            I'll have to disagree with you on the extra defines here. That will just get really messy. If someone has different overclock needs a differentiating of normal, overclock and extreme overclocking should be more than adequate. This was the reasoning for the 3 tier overclocking convention. The regular frequencies are proven STOCK settings, overclock indicates what they SHOULD be running at or actual overclocking, extreme indicates experimental or unstable frequencies. They can make adjustments to their own frequency tables. Due to the set up of these devices. Overclocking is too variable and touchy. What works in one, does not work in another. (ie. the way I have it set up here is how my MK908 handles o/c so far.. other devices can usually push this limit). As I mentioned before.. the settings here are generic enough to work across the board. When limits get pushed, I moved it into an "extreme" area. For example, the 1776 was a rating I tested while I was attempting to get 1800 work since flat out 1800 didn't work out well enough for me. 1776 works, but not as stable, but I left the frequency to revisit it and play with voltages later. Defining a bunch of different separate frequencies would be ton of extra unnecessary code, in my opinion. Breaking it into categories just seemed easier for people to consume and configure. /shrug I'll take the define convention you propose here under consideration tho. It makes sense, but it gets too messy, in my opinion.

                            Originally posted by phjanderson View Post
                            Same goes to this one:
                            Code:
                            static struct cpufreq_frequency_table dvfs_gpu_table[] = {
                            #ifdef CONFIG_OVERCLOCK_GPU //SAW -- Sam321 tweaks below
                            //on MK908, 800MHz works, but get lots of artifacting, disabling for now
                                       {.frequency = 133 * 1000,       .index = 975 * 1000},
                                       {.frequency = 200 * 1000,       .index = 1000 * 1000},
                                       {.frequency = 266 * 1000,       .index = 1025 * 1000},
                                {.frequency = 297 * 1000,    .index = 1050 * 1000},
                                       {.frequency = 399 * 1000,       .index = 1100 * 1000},
                                {.frequency = 594 * 1000,    .index = 1250 * 1000},
                            #ifdef CONFIG_EXTREME_OCGPU //SAW
                                {.frequency = 798 * 1000,    .index = 1325 * 1000},
                            #endif
                            #else
                                       {.frequency = 133 * 1000,       .index = 975 * 1000},
                                       {.frequency = 200 * 1000,       .index = 1000 * 1000},  
                                       {.frequency = 266 * 1000,       .index = 1025 * 1000},  
                                       {.frequency = 297 * 1000,       .index = 1050 * 1000},  
                                       {.frequency = 399 * 1000,       .index = 1100 * 1000},
                                       {.frequency = 594 * 1000,       .index = 1225 * 1000},
                            #endif
                                {.frequency = CPUFREQ_TABLE_END},
                            };
                            I don't understand what the CONFIG_OVERCLOCK_GPU does here, the frequency table is the same as the non-overclocked table. Maybe replace all of this with:
                            CONFIG_OVERCLOCK_GPU_798
                            As mentioned before. Some of this is to lay ground for future work. Sam found he can push the GPU to 800MHz. It was 600 then jump straight to 800. On my MK908, 800 works.. but I get alot of artifacting so I'll need to revisit the
                            voltages later to see if I can get it working better on my AMP.

                            Originally posted by phjanderson View Post
                            This one is tricky
                            Code:
                            static struct cpufreq_frequency_table dvfs_ddr_table[] = {
                            #ifdef CONFIG_OVERCLOCK_RAM //SAW -- Sam321 tweaks
                            //on MK908, setting NORMAL here does not work, has to be config defined
                                {.frequency = 396 * 1000 + DDR_FREQ_IDLE,    .index = 1100 * 1000},
                                {.frequency = 396 * 1000 + DDR_FREQ_SUSPEND,    .index = 1100 * 1000},
                            #ifdef CONFIG_EXTREME_OCRAM //SAW -- fill with extreme stuff later
                                {.frequency = 492 * 1000 + DDR_FREQ_VIDEO,     .index = 1150 * 1000},
                                {.frequency = 792 * 1000 + DDR_FREQ_NORMAL,    .index = 1250 * 1000},
                            #else
                                {.frequency = 492 * 1000 + DDR_FREQ_VIDEO,    .index = 1150 * 1000},
                                {.frequency = 792 * 1000 + DDR_FREQ_NORMAL,    .index = 1250 * 1000},
                            #endif
                            #else //SAW stock settings below
                                {.frequency = 300 * 1000 + DDR_FREQ_IDLE,    .index = 1000 * 1000},
                                {.frequency = 300 * 1000 + DDR_FREQ_SUSPEND,    .index = 1000 * 1000},
                                {.frequency = 300 * 1000 + DDR_FREQ_VIDEO,      .index = 1000 * 1000},
                                {.frequency = 396 * 1000 + DDR_FREQ_NORMAL,     .index = 1100 * 1000},
                            #endif
                                {.frequency = CPUFREQ_TABLE_END},
                            };
                            Actually all the source trees I found only contain this list:
                            Code:
                            static struct cpufreq_frequency_table dvfs_ddr_table[] = {
                                //{.frequency = 200 * 1000 + DDR_FREQ_SUSPEND,    .index = 950 * 1000},
                                {.frequency = 300 * 1000 + DDR_FREQ_VIDEO,      .index = 1000 * 1000},
                                {.frequency = 360 * 1000 + DDR_FREQ_NORMAL,     .index = 1100 * 1000},
                                {.frequency = CPUFREQ_TABLE_END},
                            };
                            Do we really need to define the suspend and idle frequencies? When does it enter those states? Or perhaps it never does? And why is the video frequency lower than the normal frequency? Does anyone have an idea about this?

                            There seem to be variations between sticks here. If I remember well my stock T428 kernel has the DDR set to 350mhz instead. It seems to overclock quite a bit though.

                            I remember a posting saying that with a custom kernel powering down the stick made it reboot instead. Perhaps this can be explained by incorrect idle or suspend settings, causing the stick to crash and reboot once it enters those states. The safe choice would then be to set the idle and suspend frequencies/voltages equal to the normal frequency/voltages.
                            I defined the suspend and idle because I found I could. Nothing more. I do not know where it's used, if at all. I was looking at stock dmesgs and custom kernel dmesgs and noted the difference. For example, some units seem to be able to get away with calling FREQ_NORMAL with a frequency and their AMP will init with that frequency. I have found on my MK908 that FREQ_NORMAL does not work and I have to init my frequency in a kernel config. With these set, I have had NO problems with rebooting, shutting down or rebooting into any modes (bootloader, recovery). So YMMV. As for why the RAM is lower frequency, I don't know. It's been defined like that in source and in a number of custom kernels and by Sam. I tried setting the freq to the normal frequency and noticed a slight degradation during my benchmarks. I set it to a much lower frequency and got an even worse benchmark. Setting it around this target freq seemed to provide a stable and decent benchmark. I don't know if it's placebo or there is a mathematical reason for it. I'm not the overclocking guru. I've just integrated Sam321's code. But to expand a little. I checked with geekbuying (who in turn checked with "engineers") and the MK908 (at least) uses DDR3-800MHz. Even the STOCK rom inits the ram at 396MHz (or 400MHz). Bumping it up to 800MHz worked fine for me. However, going any higher did not (I suspect I need to do more tweaking). However, bumping up over 1GHz has proven to work for Sam321 and others. The define in my code reflects that and allows someone else to edit the frequency table to make EXTREME_OCRAM run at their own desired speeds. I'll need to tweak my own settings as I try to find a workable "extreme" ram overclock that'll work with my MK908. Like I mentioned earlier. Alot of this was just groundwork and categorization since there are a number of variations.

                            Originally posted by phjanderson View Post
                            A side note about voltages: my T428 was unstable even with a normal kernel. It turned out that the bundled 5V 2A EU plug power supply from geekbuying was too weak, I measured the voltage dropping to below 4.4v even when overclocking. Just because a power supply is rated for 2A doesn't seem to mean that it can actually deliver 2A (see: http://www.lygte-info.dk/info/usbPow...Test%20UK.html and http://www.freaktab.com/showthread.p...2A-inadequate/). Replacing the power supply with a better 2A solved the problem for me. I'm using a 5A now and suddenly overclocking works great. I suspect that for some people the increased voltage settings for DDR, CPU or GPU are just to compensate for this overall voltage drop, increasing the voltages increases the load on the power supply though so eventually that will again cause the overall voltage to drop.
                            Thanks for the tip there. I currently have a 5V 2A (oem) and a 5V 3A that I use frequently. I may need to check to make sure they are both stable. Maybe that's why I have issues with some of the more "extreme" settings that seem to work for other AMPs.
                            Question Reality: Find Your Own Truth!

                            My MK908 Cooling Mod and Breakdown : HERE
                            My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

                            Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

                            Want to say thanks for something I did/said or DONATE to my drink fund?

                            Comment


                              #15
                              I changed the generic RK_VOLTx defines to your recommended individual component defines (made too much sense. hehe) and changed OVERVOLT_CPU to just OVERVOLT (and added framework for undervolting as UNDEVOLT). I made the adjustments to Kconfig and board-rk3188-box.c and will push these out to the kernel tree and update the build script accordingly soon. I still stand by my point about the various O/C defines and am leaving it as is with the OVERCLOCK_xxx and EXTREME_OCxxx.
                              Question Reality: Find Your Own Truth!

                              My MK908 Cooling Mod and Breakdown : HERE
                              My RK3188 Github Repos (NOTE: Works-in-Progress!) : HERE

                              Sent my Epic4G AND Backflip into nearspace... what have YOU done with your phone?

                              Want to say thanks for something I did/said or DONATE to my drink fund?

                              Comment

                              Working...
                              X