Undervolting Through Hex Editor- SimpleMining

24

Comments

  • Wolf0Wolf0 Member Posts: 329 ✭✭✭

    Wolf0 said:

    Shit... that's an odd one... I know this, I know this...

    Yeah! You have a uP1637.

    did u try edit 1080ti ?
    My owner does Nvidia, I do AMD.
  • mike_domike_do Member Posts: 25
    Wolf0 said:

    Shit... that's an odd one... I know this, I know this...

    Yeah! You have a uP1637.

    For future prosperity, leaving a link to my stock ROM (from which I am working) here: https://www.dropbox.com/s/udu5g4rsiy5e553/Sapphire RX470 4GB Samsung (11256-31-21G).rom?dl=0
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    Wolf0 said:

    Shit... that's an odd one... I know this, I know this...

    Yeah! You have a uP1637.

    For future prosperity, leaving a link to my stock ROM (from which I am working) here: https://www.dropbox.com/s/udu5g4rsiy5e553/Sapphire RX470 4GB Samsung (11256-31-21G).rom?dl=0
    @mike_do All right, I'm going to do this one for you free of charge for two reasons. One, it's on an open forum, so everyone (including you) can see the before/after and learn from it, and two, I've never actually done an undervolt on this specific VRM controller via the VBIOS before (the uP1637.) Stand by. You're gonna need to test it, possibly several times, until it's right.
  • mike_domike_do Member Posts: 25
    If it were ever in doubt @Wolf0 is a real asset to the community. Dang!

    I am around and available to test. And if we brick, well, shall be it.

    Thanks!!!
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    @mike_do Waaaaait a minute... before I do this, can you get me an I2C dump of it? Something is fishy here - the VBIOS says that the offset 0x20 (7-bit address, so actually 0x40) - but... the regulator ID states that it is a uP1637... this combination is quite impossible. Just like my Sappire Pulse 580 8G, it is lying to me.

    Before I put in I2C codes, I wanna make sure they're not going to an address with nobody home.
  • mike_domike_do Member Posts: 25
    edited August 2017
    [deleted, irrelevant]
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    I didn't watch the vid - but I found it on overclock.net (I don't use Windows, or I'd be able to tell you exactly how to get the info I need.)

    Try this?
  • mike_domike_do Member Posts: 25
    edited August 2017
    @Wolf0 Got it! File attached.

    For those looking for instructions in the future -- download AIDA64, then go to View -> Status Bar (make sure it's checked). Then right-click the bottom left AIDA64 icon -> Video Debug -> ATI SMBus Dump. Viola.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    FUCK, I'm retarded - I read 10 and thought it was decimal 10 - it was 0x10. This thing doesn't have a uP1637, it has an NCP81022. This means that the I2C address is 0x20, which is indeed possible for an NCP81022.

    This one is it!

    ------[ ATI I2C Device GPU #1 / B06-D25 ]------ 0000 FFFF 2980 7817 FF7F FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0010 6900 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 4AB0 FFFF FFFF FFFF FFFF FFFF FFFF 0020 6622 0000 FFFF FFFF 0000 0018 00A8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0030 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0001 0000 FFFF FFFF FFFF FFFF FFFF FFFF 0040 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0064 FFFF FFFF FFFF FFFF 0055 0050 FFFF 0046 0000 0064 FFFF 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0060 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 012C FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FD00 0000 2B00 4000 5600 3D00 FFFF FFFF 0080 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF D2EB FFFF FFFF 0154 9A30 0000 FFFF FFFF 0090 FFFF FFFF FFFF FFFF FFFF FFFF 9A5F FFFF FFFF 001A 1022 8703 FFFF FFFF FFFF FFFF 00A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00D0 E400 8801 3200 5003 BA0D 2A02 9900 FFFF FFFF FFFF 6401 FFFF FFFF FFFF FFFF FFFF 00E0 FFFF 6E00 D300 B602 A703 CC03 7800 0058 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00F0 FFFF FFFF FFFF 0568 FFFF FFFF FFFF 9C0F F5BC F29C FFFF 4203 FFFF 1B0F FFFF FFFF

    I haven't used this particular method on an NCP81022 before, but an interesting idea would be to tell the controller to no longer listen to commands over SVI2 at all, then set its VID. This would mean that the driver can no longer set voltage, though, so you'd lose power savings (especially when idle.) I do this when I undervolt in real-time on Linux using my toolset - I don't care if the driver can't use it now, because I use my tools to bring the voltage up and down as I please.

    That's not the method I plan to take here, though - I'll just offset the output voltage. This way, the driver will happily send VIDs over SVI2, and the NCP81022 will obey, but it'll apply a negative offset to its main output (the one driving the ASIC.) Basically, if I set the offset to -25mV, and the driver sets the VID such that it should output 1025mV, the final result on the output rail will be 1000mV.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    Almost forgot to fix the little Sapphire signature fuckup with their newer cards - the I2C address is supposed to be in 7-bit format, so I have to change it from 0x20 -> 0x40, or the I2C commands will go into the void. This VBIOS should apply a -75mV offset, which works on ALL OSes that support the GPU:

    http://46.28.204.78/Sapphire-NCP81022-UV.rom
  • mike_domike_do Member Posts: 25
    @Wolf0 Loaded up the VBIOS successfully. Ran it versus the stock VBIOS (upon which you based the mod) on 17.7.1 using ethminer's benchmarking mode (block 4100000). I did not do any tuning in any tool (like WattTool or MSI AB).

    Both VBIOS' drew the same wall watts (156w). System is ~43w, so card is drawing ~113w.

    Given both runs were the same I am guessing the instructions were ignored by the controller.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    @Wolf0 Loaded up the VBIOS successfully. Ran it versus the stock VBIOS (upon which you based the mod) on 17.7.1 using ethminer's benchmarking mode (block 4100000). I did not do any tuning in any tool (like WattTool or MSI AB).

    Both VBIOS' drew the same wall watts (156w). System is ~43w, so card is drawing ~113w.

    Given both runs were the same I am guessing the instructions were ignored by the controller.

    Curious. Let me try reverting the I2C address change. Updated; try again: http://46.28.204.78/Sapphire-NCP81022-UV.rom
  • mike_domike_do Member Posts: 25
    @Wolf0 same. 156w at the wall.

    just to make sure I am not being stupid - this doesn't require me to do anything in software, correct? WattTool for example shows 1000mV for both core and memory. I am not changing any values there.

  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    @Wolf0 same. 156w at the wall.

    just to make sure I am not being stupid - this doesn't require me to do anything in software, correct? WattTool for example shows 1000mV for both core and memory. I am not changing any values there.

    Did you reboot after flashing the ROM? And can you try it on Linux? I'm pretty sure I had it right the first time... lemme pull out a Sapphire 470 4G (later model, should be similar) and put it in Naomi.
  • mike_domike_do Member Posts: 25
    Yes, have rebooted each time.

    I will spin up linux on a drive I have laying around. Probably won't have an answer until tomorrow. Any objection to Ubuntu? I usually put 16.04.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    Okay - did so, and turns out, Sapphire is just straight up lying about where the NCP81022 is at. It's not a 7-bit format to 8-bit format fuckup - just a fuckup. The NCP81022 on my test Sapphire is ACTUALLY at 0x25 (8-bit format), meaning the VOI entry should show the address as 0x4A (7-bit format.) When this is done, the offset works as normal. Your NCP81022 was *also* at 0x25, but I glanced over the actual address in too much of a hurry. Note to self: Pay more attention.

    Unfortunately, I'll need to extend my I2C table once more, because I'm setting an offset on the wrong damn output!
  • mike_domike_do Member Posts: 25
    Happy I didn't mess it up.

    Annoyed at Sapphire for being difficult. Attention to detail! (Sapphire, not you!)
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    Aaaaand that's success on this card - applied the changes to @mike_do 's ROM as well.

    [[email protected] ~]# ./vrmprobe vrmprobe v0.1 GPU 0: Number of VRMs: 0 GPU 1: Number of VRMs: 1 VRM 0: NCP81022 Number of outputs: 2 Output 0: Voltage: 0.9500 Offset: -0.0750 Output 1: Voltage: 0.0000 Offset: 0.0000 [[email protected] ~]#

    VBIOS is here:

    Before modification for voltage: http://46.28.204.78/Sapphire-NCP81022-Stock.rom
    After modification for voltage: http://46.28.204.78/Sapphire-NCP81022-UV.rom
  • mike_domike_do Member Posts: 25
    That worked for me. Consumption fell from 156 at the wall to 144, without any WattTool or other software inputs.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    That worked for me. Consumption fell from 156 at the wall to 144, without any WattTool or other software inputs.

    It can go lower, if you like. That was... -75mV, IIRC.
  • mike_domike_do Member Posts: 25
    edited August 2017
    Yes, I am trying to learn from what you did so that I can get the offset to my desired level (810mv).

    I parsed the hex and noticed you added the following (between reserved bytes and terminate)


    00 00 00 (reserved bytes)
    D2
    00 00 00
    E6
    00
    F4
    00
    FF 00 (terminate)


    I understand the impact this has (-75mV), but can you describe what is happening with this new segment?
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    Yes, I am trying to learn from what you did so that I can get the offset to my desired level (810mv).

    I parsed the hex and noticed you added the following (between reserved bytes and terminate)


    00 00 00 (reserved bytes)
    D2
    00 00 00
    E6
    00
    F4
    00
    FF 00 (terminate)


    I understand the impact this has (-75mV), but can you describe what is happening with this new segment?
    When I only put 0xF4 into 0xE6, it offset the second loop (which, nothing is connected to it.) As such, I put 0x00 into 0xD2 to select the main loop, as well as reset most of the settings in that reg to a sane default value, before doing the offset.
  • mike_domike_do Member Posts: 25
    For those following along at home, the attached image shows the diff between stock VBIOS and that which @wolf0 modded.

    I see 4 changes:

    1. Size of entire table was changed from 42 00 to 4A 00 to accommodate insertion (see #4 below)
    2. Size of voltage object 1 was changed from 0E 00 to 16 00 for same reason
    3. I2C address was changed from 20 to 4A, due to Sapphire being annoying ;)
    4. Between reserved bytes and terminate the following was added: D2 00 00 00 E6 00 F4 00

    NOTE: screenshot is confusing, original is on the right, modded on the left.


  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    mike_do said:

    For those following along at home, the attached image shows the diff between stock VBIOS and that which @wolf0 modded.

    I see 4 changes:

    1. Size of entire table was changed from 42 00 to 4A 00 to accommodate insertion (see #4 below)
    2. Size of voltage object 1 was changed from 0E 00 to 16 00 for same reason
    3. I2C address was changed from 20 to 4A, due to Sapphire being annoying ;)
    4. Between reserved bytes and terminate the following was added: D2 00 00 00 E6 00 F4 00

    NOTE: screenshot is confusing, original is on the right, modded on the left.


    Very good - but you missed a couple of things. The other tables following VOI had their offsets fixed to account for the new size of VOI, and I trimmed the padding between the legacy & UEFI VBIOSes to ensure the image remained the same size before correcting the checksum.
  • mike_domike_do Member Posts: 25
    edited August 2017
    Wolf0 said:

    as well as reset most of the settings in that reg to a sane default value, before doing the offset.

    I assume that's what this diff is?



    I think I mostly understand what's happening in the table. How to interpret/map the changes you made here is still black magic.
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
  • mike_domike_do Member Posts: 25
    For those following along, here's the data sheet for the regulator: https://media.digikey.com/pdf/Data Sheets/ON Semiconductor PDFs/NCP81022.pdf
  • Wolf0Wolf0 Member Posts: 329 ✭✭✭
    I did something charitable... I feel dirty. :P

    At least I'll have something to point folks to when they ask me about undervolting that takes effect on all OSs (AKA properly undervolting via VBIOS offset mods.)
  • rmhrmh Member Posts: 410 ✭✭✭
    Wolf0 said:

    I did something charitable... I feel dirty. :P

    At least I'll have something to point folks to when they ask me about undervolting that takes effect on all OSs (AKA properly undervolting via VBIOS offset mods.)

    Very thank You for this, it cleared all the blur for me.
  • rhaegonrhaegon Member Posts: 3
    edited August 2017
    I remember when i modded my own BIOS (i had also NCP80122 VRM) and it worked for me only adding E6 00 XX 00 , D2 00 00 00 part wasn't necessary on my RX570 Nitro+, weird. I wish my uP9505 were so easy as NCP80122
Sign In or Register to comment.