390x bios leaked

Discussion in 'Videocards - AMD Radeon Drivers Section' started by WarDocsRevenge, Jun 16, 2015.

  1. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    Using this procedure:-

    I get:
    -6mv = hex FF convert to dec 255
    -13mv = does not work, try it and you will see what's going on.
    -19mv = hex FD convert to dec 253
    -25mv = hex FC convert to dec 252

    Now usually we apply the formula (hex value) convert to (dec value) multiply by (6.25mv) , now that formula would not apply here.

    If we have a formula that made sense of this then performs it warrants a test, otherwise I think we need to not do it due to lack of information.

    I think I did take a risk when adding GPU voltage offset codes to a bios that did not have it and flashing for testing, I was lucky it didn't cause an issue.

    Now I wish to tread careful with this as it could lead to a damaged card.

    I will view your bios to see if it has gpu offset hex in the Voltage ObjectInfo table.
     
  2. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    yep exactly this is danger zone :D without deeper knowledge how it works you can burn your card pretty easy

    problem is that datasheet for IR3567B is restricted and without it there is no way to know which value is important for us
     
    Last edited: Jul 7, 2015
  3. Krteq

    Krteq Master Guru

    Messages:
    668
    Likes Received:
    207
    GPU:
    RX Vega 56 +64 BIOS
    Hmm, and what about MSI Afturburner i2c dump tool? It could be useful.
     
  4. NAJMI ADNAN

    NAJMI ADNAN Ancient Guru

    Messages:
    2,176
    Likes Received:
    0
    GPU:
    Sapphire R9 290X TriX 4GB
    I see, thanks for the heads up. Since it's dangerous I won't try it. I did check the I2CD, there is one value change from 84 to 8F when I reduce to -12mV.

    [​IMG]

    I'm wondering, how do you guys reach epic -200mV undervolt on 2D clocks? I really want very low 2D clock temps.
     

  5. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    you can force afterburner to lower voltages under -100mV by command
    this write values into ir3567b by hand over i2c
    MSIAfterburner.exe /wi6,30,8d,-20 /wi6,30,8e,-11

    also there is other possibilities you can set on this i2c device
     
    Last edited: Jul 7, 2015
  6. NAJMI ADNAN

    NAJMI ADNAN Ancient Guru

    Messages:
    2,176
    Likes Received:
    0
    GPU:
    Sapphire R9 290X TriX 4GB
    Interesting, I will test it tomorrow when I got time.

    I tested the 'TDC limit' and indeed GPU-Z reported it won't go higher than what I specified. Tested 155A 'TDC limit', if it reach that point it will lower GPU clock (and voltage) to reduce power usage. The 'TDP Max' and 'Power Limit' doesn't have any effect though.

    Contrary to most people here, I'm modding the BIOS to reduce power usage and/or reducing heat produced.
     
  7. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    is possible that you somehow select what value is used as limiter.. but dunno which bit can control this
     
  8. Plug2k

    Plug2k Ancient Guru

    Messages:
    1,500
    Likes Received:
    10
    GPU:
    2x Gigabyte Fe 1080TI +WB
    any update/news guys on the R9295x2 voltage ? or are you still working on it or is it a dead end....
     
  9. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    for now its dead end i think as there is no trustable informations about voltageinfo table and how to safely mess with it :D

    so i will add fancontrol and checksum and keep voltageinfo for later if something comes out
     
  10. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    Is it possible to make reader to search VoltageObjectInfo if it has the editable GPU Offset HEX in it?
     

  11. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    its allready searching for voltagetableinfo in developer tab
    search for offset voltage can be added
     
  12. Plug2k

    Plug2k Ancient Guru

    Messages:
    1,500
    Likes Received:
    10
    GPU:
    2x Gigabyte Fe 1080TI +WB
    oh well looks like my hopes and dreams are crushed with one blow lol :(
    still guys great work on the bios editor ...
     
  13. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    its opensource maybe someone else will contribute with working solution :)
     
  14. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    I know we were discussing these dumps and one thing we thought was perhaps the dumps are incorrect due to it stating "Total data structure size: 0000" at the end. Yesterday when I dumped VoltageObjectInfo of a HD5850 and HD7970 bios I got the same.

    We had also discussed if AtomDis (atombios.h) is problem because we know it's not up to date and I tried creating new file from copy paste of viewing Link:- file here. Which failed then I tried selecting portions, related to voltage and that failed to compile.

    I don't think the version of atomdis is an issue for this excercise, as HD7970 is rev 03:01 VoltageObjectInfo table and so is 290X.

    I then tried as you suggested modding 290X VoltageObjectInfo into HD7970 bios and see if VBE7 will give meaningful data and it didn't.

    In this video left is HD7979 rom right is same rom with VoltageObjectInfo from HD7970

    I will place some information I gained from viewing atombios.h . Perhaps someone can take the time to use it to decipher VoltageObjectInfo table using it.

    ATOM_VOLTAGE_OBJECT

    UCHAR ucVoltageType; //Indicate Voltage Source: VDDC, MVDDC, MVDDQ or MVDDCI
    UCHAR ucSize; //Size of Object

    ATOM_VOLTAGE_CONTROL asControl; //describ how to control

    UCHAR ucVoltageControlId; //Indicate it is controlled by I2C or GPIO or HW state machine
    UCHAR ucVoltageControlI2cLine;
    UCHAR ucVoltageControlAddress;
    UCHAR ucVoltageControlOffset;
    USHORT usGpioPin_AIndex; //GPIO_PAD register index
    UCHAR ucGpioPinBitShift[9]; //at most 8 pin support 255 VIDs, termintate with 0xff
    UCHAR ucReserved;

    // Define ucVoltageControlId
    #define VOLTAGE_CONTROLLED_BY_HW 0x00
    #define VOLTAGE_CONTROLLED_BY_I2C_MASK 0x7F
    #define VOLTAGE_CONTROLLED_BY_GPIO 0x80
    #define VOLTAGE_CONTROL_ID_LM64 0x01 //I2C control, used for R5xx Core Voltage
    #define VOLTAGE_CONTROL_ID_DAC 0x02 //I2C control, used for R5xx/R6xx MVDDC,MVDDQ or VDDCI
    #define VOLTAGE_CONTROL_ID_VT116xM 0x03 //I2C control, used for R6xx Core Voltage
    #define VOLTAGE_CONTROL_ID_DS4402 0x04
    #define VOLTAGE_CONTROL_ID_UP6266 0x05
    #define VOLTAGE_CONTROL_ID_SCORPIO 0x06
    #define VOLTAGE_CONTROL_ID_VT1556M 0x07
    #define VOLTAGE_CONTROL_ID_CHL822x 0x08
    #define VOLTAGE_CONTROL_ID_VT1586M 0x09
    #define VOLTAGE_CONTROL_ID_UP1637 0x0A
    #define VOLTAGE_CONTROL_ID_CHL8214 0x0B
    #define VOLTAGE_CONTROL_ID_UP1801 0x0C
    #define VOLTAGE_CONTROL_ID_ST6788A 0x0D
    #define VOLTAGE_CONTROL_ID_CHLIR3564SVI2 0x0E
    #define VOLTAGE_CONTROL_ID_AD527x 0x0F
    #define VOLTAGE_CONTROL_ID_NCP81022 0x10
    #define VOLTAGE_CONTROL_ID_LTC2635 0x11

    ATOM_VOLTAGE_FORMULA asFormula; //Indicate How to convert real Voltage to VID

    USHORT usVoltageBaseLevel; // In number of 1mv unit
    USHORT usVoltageStep; // Indicating in how many mv increament is one step, 1mv unit
    UCHAR ucNumOfVoltageEntries; // Number of Voltage Entry, which indicate max Voltage
    UCHAR ucFlag; // bit0=0 :step is 1mv =1 0.5mv
    UCHAR ucBaseVID ; // if there is no lookup table, VID= BaseVID + ( Vol - BaseLevle ) /VoltageStep
    UCHAR ucReserved;
    UCHAR ucVIDAdjustEntries[32]; // 32 is for allocation, the actual number of entry is present at ucNumOfVoltageEntries

    Your train of thought not far off from the definition of ucBaseVID, but we are still not there with understanding it :( .

    Anyone viewing this thread wishing to do the VoltageObjectInfo dumps the command is :-

    ./atomdis <filename> d 20

    In the OCN thread there is guide to installing Ubuntu & AtomDis for anyone who wants to get involved.
     
  15. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    the key to control voltage is in here
    https://github.com/Canonical-kernel/Ubuntu-kernel/blob/master/drivers/gpu/drm/radeon/atombios.h
    but its so damn complicated i cant think how to start parsing that damn table...

    if we can somehow get never version of atomdis with this changes from official linux radeonhd driver it will help us alot

    if im not wrong we need to search for this values


    typedef struct _ATOM_VOLTAGE_FORMULA_V2
    {
    UCHAR ucNumOfVoltageEntries; // Number of Voltage Entry, which indicate max Voltage
    UCHAR ucReserved[3];
    VOLTAGE_LUT_ENTRY asVIDAdjustEntries[32];// 32 is for allocation, the actual number of entries is in ucNumOfVoltageEntries
    }ATOM_VOLTAGE_FORMULA_V2;

    typedef struct _VOLTAGE_LUT_ENTRY
    {
    USHORT usVoltageCode; // The Voltage ID, either GPIO or I2C code
    USHORT usVoltageValue; // The corresponding Voltage Value, in mV
    }VOLTAGE_LUT_ENTRY;
     
    Last edited: Jul 9, 2015

  16. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
  17. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    i can see that this part of log is correct
    0000: ATOM_COMMON_TABLE_HEADER sHeader :
    0000: USHORT usStructureSize = 0x0074 (116)
    0002: UCHAR ucTableFormatRevision = 0x03 (3)
    0003: UCHAR ucTableContentRevision = 0x01 (1)
    0004: ATOM_VOLTAGE_OBJECT asVoltageObj [0] :
    0004: UCHAR ucVoltageType = 0x01 (1)
    0005: UCHAR ucSize = 0x03 (3)
    0006: ATOM_VOLTAGE_CONTROL asControl :
    0006: UCHAR ucVoltageControlId = 0x12 (18)
    0007: UCHAR ucVoltageControlI2cLine = 0x00 (0)
    0008: UCHAR ucVoltageControlAddress = 0x08 (8)
    0009: UCHAR ucVoltageControlOffset = 0x96 (150)
    000a: USHORT usGpioPin_AIndex = 0x0060 (96)
    000c: UCHAR ucGpioPinBitShift [0] = 0x00 (0)
    000d: UCHAR ucGpioPinBitShift [1] = 0x00 (0)
    000e: UCHAR ucGpioPinBitShift [2] = 0x00 (0)
    000f: UCHAR ucGpioPinBitShift [3] = 0x00 (0)
    0010: UCHAR ucGpioPinBitShift [4] = 0x6d (109)
    0011: UCHAR ucGpioPinBitShift [5] = 0x00 (0)
    0012: UCHAR ucGpioPinBitShift [6] = 0xdf (223)
    0013: UCHAR ucGpioPinBitShift [7] = 0x00 (0)
    0014: UCHAR ucGpioPinBitShift [8] = 0xff (255)
    0015: UCHAR ucReserved = 0x00 (0)

    then it stats to be malformed some values are different or missing

    but this seems like legit setting for first voltage (this is 290X bios)

    we know that this value here
    0014: UCHAR ucGpioPinBitShift [8] = 0xff (255)
    should be always 255

    so we can find out how much info our parser is missing from that

    EDIT2: i can parse some values but without correctly parsed table from atomdis its very very slow proccess
     
    Last edited: Jul 9, 2015
  18. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    If we say that section is correct then the value for

    0014: UCHAR ucGpioPinBitShift [8] = 0xff (255)

    Differs in the bios I can edit GPU hex offset for.

    0014: UCHAR ucGpioPinBitShift [8] = 0x8d (141)

    In the bios dump for VX290X OC the hex code I'm editing comes up as

    0016: USHORT usVoltageBaseLevel = 0x0004 (4)

    I had also been wondering why in the dumps for VoltageObjectInfo all the HEX is not translated, an Asus DCUII 290X STD edition bios it did more translation than VX290X STD & OC.

    [​IMG]

    All I know so far is first HEX is size of table, 7th code increase by 4 when the GPU offset HEX code is present. The HEX code to edit GPU Voltage offset will be next to 8d 00 HEX.

    Now 8d 00 xx 00 (xx being the hex that denotes GPU offset) varies in which position in the table it will be. Roms compared were VX290X OC , The Stilt V2C , TriX 290 OC and PowerColor 290X PCS. So much of the data is the same it just shifts as when those hex code is present.

    It so frustrating not being able to nail this!

    In this thread we have tested cutting & pasting PowerPlay & UEFI from one bios to another. Why does not voltageobjectinfo work that way?

    I even went through the comparison I did for the VX290X STD & OC and there is only one hex that differ in FirmwareInfo data table. Even changing that does not make it work, so is there information in the area before data tables that has something double checking what VoltageObjectInfo for a bios should be?

    [​IMG]

    Now if I added the unknown data area form the OC bios to the modded STD then there really wouldn't be any point as it would be the OC bios.
     
  19. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    its even more complicated.. :D as there are few different tables and each bios have them in different order (or some totally missing)
    on development tab in hawai bios reader i started parsing these values but im not sure if its correct

    for now im using just 1 bios them i will alternate for more variants (as these values

    UCHAR ucVoltageType: 0xB182 -- 1
    UCHAR ucVoltageMode: 0xB183 -- 3
    USHORT ucSize: 0xB184 -- 18

    have impact on what the next table contains...
     
  20. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    You may recall I posted a 8 voltageobjectinfo table compare.

    Here is an updated one.

    [​IMG]

    Asus has same table length as VX290X STD and 7th hex in both is 12, then when VX290X OC has the extra 4 hex codes it change to 16.

    XFX has smaller table than Stilt V32, 7th hex increase by 8 due to blue boxed hex code. Then Stilt V2C has 7th hex increased by 4 due to pink boxed hex.

    Sapphire 290 TriX STD has larger table length than TriX OC but 7th hex has increased by 8.

    Sapphire TriX 290 OC has way smaller table than Stilt V32 but 7th hex is same.

    The red boxed hex (7th) is count of some values within voltage object table OR a count of how many locations to look at within table.

    I can not be sure what offset TriX STD was due to me being unaware at the time that MSI AB stores defaults for a card and it only becomes aware it is a differing card from device id and does not consider bios version for a change to defaults stored.

    If the device id between a differing bios is the same it applies the same stored default GPU offset value when you click reset in it.

    Unless you uninstall with saying no to keeping profiles or manually delete stored defaults for card, then forcing redetection on next run.

    For some reason it will detect and update new clock speeds when a differing bios is flashed and stored defaults are not deleted.
     

Share This Page