Thursday, June 04, 2015

OCNG5.2, coming up...


After long break, I'm happy to say that next drop of OCNG (5.2) is in its final production stages. Ideally, it will be released within a week's time

Highlights of OCNG5.2:
  • supports H8SGL series boards (with fine-grained clock control)
  • ocng-cu (configuration utility) now runs on Windows (no need to boot Linux to reconfigure OCNG any more)
  • based on SM BIOS version 3.5
  • resolves configuration loss issue when using SATA ports 4/5
Stay tuned!


  1. You status AMD OC TITAN !!!
    Master !

  2. Replies
    1. It's going public any day now (finishing utilities package).

  3. Wow windows version ~

    How much more do I have to wait?

    1. Testing various upgrade scenarios now, will notify when done.

    2. OCNG 5.2 is now live --

  4. I am excited, too! I am especially curious to see if the SM v3.5 based BIOS solves the hang-on-reboot issue. The machine is currently rock stable with the SM v3.0 based BIOS but it hangs itself up after each soft reboot, e.g. "save and exit" from the bios.

    1. Daan,

      yeah... this is a known issue with 4p boards.

      From brief examination, it seems to be related to HT (and to the way the board reboots). Specifically, per design, HT connection, once brought up (at power-up) should persist across warm resets (reboot from OS, save&exit from BIOS, etc.). Now, the problem is that, at warm reset, the clockgen chip gets reset (but the CPU does not!) which, in case of warm reset, causes drastic reduction of refclock (and, consequently, HT clock) which I believe is responsible for the hang.

      That said, I'm afraid 3.5-based OCNG will not be of much help in this department.

      I suspect there's a code in the BIOS that explicitly resets the clockgen (and possibly extra board components) early at boot -- that code would need to be identified and possibly removed. Existence of such code would also beg the question of the reasons the vendor added it. Finding it may be non-trivial as it's likely to be using SB GPIO to perform the reset and, as many GPIOs are driven by the firmware, it may be needle in the haystack thing.

      A workaround would be hooking extra code that would use embedded controller to power-cycle the whole system at reset (which would effectively mitigate the issue) which is also a reverse engineering task -- not sure if more complex than getting rid of firmware-initiated clockgen reset.

      I'll try to take a look after 5.2 release.


    2. This comment has been removed by the author.

    3. Wow, you are the expert! This does sound hard to fix and perhaps not worth the trouble.

      I currently work around the reboot issue by using the hardware WDT to reboot the machine. That power cycles the whole board.

    4. That's very clever! Which OS are you using and how much time do you have to wait for the WDT to kick in (when trying to reboot) ?

      I've tested it real quick on Ubuntu 14.04.2 (don't remember the kernel) and it barfed: kernel module was unable to read MMIO address and did not initialize; timer expired and the board power cycled after few minutes.

    5. The WDT that is used on the SM boards is in the Winbond W83627DHG-P chip. I use the w83627hf_wdt driver to keep it alive.

    6. I'll see if it works the same way here, thank you.
      If you feel like playing with 5.2 -- it's out: