1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

390x bios leaked

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

  1. 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 :)
     
  2. 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.
     
  3. 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
  4. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64

  5. 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
  6. 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.
     
  7. 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...
     
  8. 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.
     
  9. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    we need to make something like this :) comparing bioeses is useless in this case as there is alot of different values not on same places

    USHORT usStructureSize: 0xB17E -- 116
    USHORT usStructureRevision: 0xB180 -- 3
    UCHAR ucTableContentRevision: 0xB181 -- 1

    UCHAR ucVoltageType: 0xB182 -- 1
    UCHAR ucVoltageMode: 0xB183 -- 3
    USHORT ucSize: 0xB184 -- 18
    UCHAR ucVoltageGpioCntlId: 0xB186 -- 8
    UCHAR ucGpioEntryNum: 0xB187 -- 150
    UCHAR ucPhaseDelay : 0xB188 -- 96
    UCHAR ucReserved: 0xB189 -- 0
    ULONG ulGpioMaskVal: 0xB18A -- 0
    ULONG ulVoltageId: 0xB18E -- 14614637
    USHORT usVoltageValue: 0xB192 -- 255

    then get IR3567 datasheet from somewhere and check how final voltage is made
     
    Last edited: Jul 9, 2015
  10. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    Is and isn't.

    Why I say that is first 16 hex values other than 1st & 7th are the same in all 8.

    When the table grows in data in Asus vs VX290X STD vs VX290X OC its added after hex values FF 00 01 07 0C 00 0A 00. Everything from hex values FF 00 01 07 0C 00 0A 00 is the same but moved along in table.

    In XFX vs Stilt V32 vs V2C, you will note in XFX vs Stilt V32 extra data is added after hex values FF 00 01 07 0C 00 0A 00. Everything from hex values FF 00 01 07 0C 00 0A 00 is the same but moved along in table. Everything before the new data is the same in XFX vs V32.

    Then in V32 vs V2C extra data is again added between orange boxed code & red. And orange and red boxed values are the same.

    Then look at TriX 290 STD VS OC extra data added after hex values FF 00 01 07 0C 00 0A 00. Everything from hex values FF 00 01 07 0C 00 0A 00 is the same but moved along in table. But due to shorter table length and inclusion of 6D 00 DF 00 8D 00 04 00 some values are truncated. Before the additional data in STD vs OC they are the same hex values in same location.

    Regardless of us deciphering the table and having access to IR3567 datasheet the fact remains a copy and paste of the OC bios table into STD bios did not work, even though I removed the padding in appropriate area to accommodate it.

    I've tested 3 versions of the STD bios modded with gpu voltage offset :-

    [​IMG]

    One of the above was copy paste of table, only thing different would be unknown data between 0 - A125.
     
    Last edited: Jul 9, 2015

  11. Jrt3D

    Jrt3D New Member

    Messages:
    1
    Likes Received:
    0
    GPU:
    R9 290 vapor-x
    Someone knows the hex values to modify the min and max rpm? I've tried to modify the temp and rpm values but didn't work. Can i try to flash the bios of any r9 390 that stop the fans in idle on my r9 290 vapor-x , or i need a specific sapphire card bios?

    Thanks to OneB1t for HawaiiBiosReader and to all contributors in this thread.
     
  12. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    OneB1t can you view this video carefully.

    Link:- http://youtu.be/wPZBxQWkpO8

    I think the 7th hex may denote length of values used in some way after the first row of 16 hex values.

    It may just be coincidence that the count denoted by 7th hex stop at hex values 04 07 0C 00 .....

    Or maybe it isn't coincidence?

    *** edit ***

    Just viewed XFX 390X rom, 7th hex is 66 , when selecting from 17th hex with length of 66 selection finish at hex values 04 07 0C 00 .....
     
    Last edited: Jul 9, 2015
  13. OneB1t

    OneB1t Master Guru

    Messages:
    262
    Likes Received:
    0
    GPU:
    R9 290X@R9 390X 1050/1325
    this is useless we need to match these numbers into some structure.. without it its not going to work as you never know which value is just size/i2c address etc.. and which is voltage control
     
  14. The Stilt

    The Stilt Member

    Messages:
    15
    Likes Received:
    0
    Playing with the VRM controller without knowing what you´re doing is pretty damn dangerous.

    Tell me what you are trying to achieve exactly.

    Also I would suggest not to spend too much time in supporting Gen. 1 EVV systems (Bonaire, Hawaii) as all the work goes to waste with Gen. 2 EVV (Tonga, Fiji >>).

    If you tamper with the voltages, keep the levels sane.
    If people start killing their cards due excess overvoltage or power draw the ODMs will notice pretty quickly. The next thing you´ll know is AMD or the ODMs adding password protection to the VRM config.
     
    Last edited: Jul 10, 2015
  15. stelistcristi

    stelistcristi New Member

    Messages:
    4
    Likes Received:
    0
    GPU:
    Radeon R9 270 (reference)
    Hi there. Does anybody know if this BIOS can be modded (R9 370 -> R9 270)?
    techpowerup.com/vgabios/173048/msi-r9370-2048-150528.html

    I have a Radeon R9 270 reference card and I don't know if is compatible. This is my current BIOS:
    techpowerup.com/vgabios/161778/ati-r9270-2048-131126.html

    Thank you in advance for your amability! ;)
     

  16. gupsterg

    gupsterg Member Guru

    Messages:
    177
    Likes Received:
    1
    GPU:
    RX VEGA 64
    Set GPU core voltage offset.

    At present can only modify it to a different offset in roms which have it present (which are limited).

    For example in the Vapor-X 290X OC bios I have 8d 00 04 00 in VoltageObjectInfo table, this bios has +25mv GPU core voltage offset. If I change 04 to an appropriate one I get the desired GPU core voltage offset.

    In the Vapor-X 290X STD bios the VoltageObjectInfo table is missing those hex values.

    It has same values in it excluding 1st hex and 7th plus missing 8d 00 04 00. Even inserting those values to the same place and shifting the other values like the OC bios equals black screen. Even if first hex value is adjusted to include the increased length of table.

    Even inserting a copy of OC bios VoltageObjectTable into the STD bios also does not work, even if the empty values in bios at the end of command tables are shortened to keep bios size right.

    Bios compare Vapor-X 290X STD vs OC

    [​IMG]

    VoltageObjectInfo table compare Vapor-X 290X STD vs OC

    [​IMG]
     
    Last edited: Jul 10, 2015
  17. DrunkenDonkey

    DrunkenDonkey Master Guru

    Messages:
    204
    Likes Received:
    2
    GPU:
    2xPC 290 PCS+
    Ha, The Stilt here. Now you guys got the best resource, he sure as hell knows how to modify voltages on 290/x, I have used your bios mods :)
     
  18. cyraxus

    cyraxus Member

    Messages:
    20
    Likes Received:
    0
    GPU:
    NVIDIA GTX465
    Hi. i have amd 7870 ghz edition..(elpida) i tried before flashing r9 270x bios(same memory) .i edited clock and ram frequency and flashed. But after installing catalyst driver i got grey screen.What is problem? i want to flash r9 370 msi bios(samsung memory) to my 7870. vbe7 is open that bios. How is it possible ? Can you help me please?
     
  19. The Stilt

    The Stilt Member

    Messages:
    15
    Likes Received:
    0
    Generally using the VRM offset to adjust the voltage is a bad idea.
    It will destroy the efficiency as the offset isn´t state specific but applied on all states instead.

    If you wonder why I used the offset to adjust the voltage in the most recent builds I published (MLU), the reason is pretty simple: It was the only way I could release the bioses without making 256 different VID versions of each variant ;)

    E.G. stock Hawaii XT:

    DPM0 = 300MHz - 0.96875V
    DPM1 = 516MHz - 1.01875V
    DPM2 = 727MHz - 1.05000V
    DPM3 = 840MHz - 1.07500V
    DPM4 = 890MHz - 1.10000V
    DPM5 = 936MHz - 1.12500V
    DPM6 = 977MHz - 1.18750V
    DPM7 = 1000MHz - 1.21250V

    Then set the clocks to 1150MHz and the voltage offset to +100mV through AfterBurner or bios mod:

    DPM0 = 300MHz - 1.06875V
    DPM1 = 516MHz - 1.11875V
    DPM2 = 727MHz - 1.15000V
    DPM3 = 840MHz - 1.17500V
    DPM4 = 890MHz - 1.20000V
    DPM5 = 936MHz - 1.22500V
    DPM6 = 977MHz - 1.28750V

    DPM7 = 1150MHz - 1.31250V

    The correct and especially more efficient way is to modify the commanded VID of the highest DPM state. This way the voltage in all of the other states remain intact and the power consumption is only increased in the highest performance state.

    The trouble in altering the commanded VIDs is that there is no easy way to check the default value, which varies between the specimens and leakage levels. The default voltage is calculated by the display driver based on fused leakage information.

    I´ll try to find some time to write and application which can be used to check the default voltages on Gen. 1 EVV GPUs (Bonaire / Strato and Hawaii). The code will contain some proprietary stuff so it won´t open source.

    Anyway I suggest you cease playing around with the VRM controller for now.
     
    Last edited: Jul 10, 2015
  20. Plug2k

    Plug2k Maha Guru

    Messages:
    1,485
    Likes Received:
    5
    GPU:
    2x Gigabyte Fe 1080TI +WB
    The stilt, mate is there any way to change the highest state voltage on R9295x2 bios`s.
    so that we can change the offset in those cards.

    seems these cards have no objectinfo table to work with and these guys are trying to figure it out as well..
     

Share This Page