Jump to content
HWBOT Community Forums

The Stilt

Members
  • Posts

    101
  • Joined

  • Last visited

Posts posted by The Stilt

  1. A working F2A85X-UP4 does not display anything in the segment display if there is no APU installed.

    Take a bare board (with nothing attached) an measure the resistance between one of the OS-CON capacitors located between the inductors (CPU loop, six inductors located on the left from the socket).

     

    The resistance should be around 1.6k (climbs for a while).

    The resistance for the NB loop (two inductors located above the socket) should be between 2.5 - 2.6k.

  2. Can I ask somebody with UP4 check what post code is displayed on the debug led when no cpu installed?

    Something failed last week and I thought it's the board, because then I tried with 5800K and it was switching off immediately (I think the PSU protection kicks off).

    So I bought another UP4, but when I start the board only 2 segments on the debug display flash for a blink of an eye and it turns off (the led). Board stays on, but does not post. It's the same with both cpus and without a cpu installed.

    I though if both cpus are dead it should display 00, no?

     

    It would be pity if the faulty board killed the other cpu too when I tried it :(

    I'm scared to try the dead board again, so I will just throw it, don't want to risk the PSU too.

     

    When the CPU dies it usually shorts (either VDDCR or VDDNB).

    Unless the VRM CC protections acts fast enough usually the VRM burns too.

     

    In case of a UP4, the VRM CC protection is fast and usually saves the board.

    If you put a broken APU in the socket and try to start it, the Port 80 segment display flashes briefly and then turns black. Depending on how the APU is damaged, the board turns off immediately or continues running (segment still blank).

     

    The most common reasons for a APU to burn is a voltage spike (e.g a large voltage swing from low to high voltage) or simply too high voltage. This is the reason you want to have a smallest possible delta between the cool down (Slowmode) an the running voltage. It will hurt you temperatures, but it will save your APU.

     

    In case the VRM fails it usually kills the CPU in about 90% of cases too.

    And a broken APU can definitely kill a working board too.

     

    To check if the CPU core part of the APU (FM2 or FM2r2) is fine:

     

    Measure the resistance between the two pins (VDDCR & VSS).

    Anything under 25 ohms means the APU is burned.

     

    u7oy.jpg

  3. Gone for good?

     

    I've done this for nearly 13 years now and still it is not getting me anywhere.

     

    Nowdays it does not matter what you know or how good you are at it, the only thing that matters is who you know.

     

    I need to find something that I can get living out from, whatever it might be.

     

    Leaving all of this behind is definitely not something I would like to do, but it appears to be the only way to survive. Simple as that.

     

    When?

    Before new year, at latest.

  4. A small update: Bulldozer Conditioner R1.02B

     

    Original package checksum (MD5): BCC929498EF1B01B7F99B8F2DA805F46

     

    Bulldozer Conditioner R1.02B

    Mirror: http://downloads.hwbot.org/downloads/tools/BDC_R1.02B.zip

     

    Changes:

     

    - Enhanced the NRAC fix

    - Added a UAC prompt (admin rights) for Windows Vista / 7 & 8.

    - Updated the AGESA version info

     

    The enhanced fix included in BDC R1.02B is around 10 seconds faster in SuperPI 32M than the one in R1.00 / R1.01 versions ;)

  5. The actual technical background is under investigation currently.

     

    Until then, I can only speculate and assume:

     

    By default a x87 FP instruction is blocked / partially blocked.

    When the "blockade" is removed (BDC "NRAC": Enabled to Disabled), SuperPI which heavily utilizes this instruction receives a massive boost.

     

    It is not a post tape-out workaround.

    Neither AGESA or µCode control this feature, all of the post tape-out workarounds (errata) are controlled by these two.

     

    If it was something that was actually broken, it would have been fixed in Piledriver and beyond.

     

    A software doesn't go much more unofficial than BDC does.

    It should be used for testing purposes ONLY.

    Obviously it shouldn't be used in systems which can be considered 'critical'.

  6. Back again.

     

    Some of the users have been asking why the "Errata Fix" feature doesn't work (i.e. "Fix required" stated even after the Fix button has been pressed). The feature itself is working fine, however I forgot to add a check in the GUI. Also some claims that the software is wrong when it states that the microcode is outdated has emerged.

     

    So:

     

    A small update: Bulldozer Conditioner R1.01B

     

    Original package checksum (MD5): C3C4E3492B3FBFE1079AE5D57C25172B

     

    Changes:

     

    - Added a hardware flag to indicate that the errata has been fixed.

    - Changed the way how the software is accessing the cores, the tasks are completed quicker than before

    - An APU specific bug fixed

    - Added information about the most recent microcode and AGESA versions under Info menu.

    - Some small changes to the GUI

  7. So, it is friday today isn't it ;)

     

    Bulldozer Conditioner R1.00B

     

    The checksum (MD5) for the zip file is: 418522A93F241CF14EB1D775839AB083

    If the checksum does not match the package has been tampered with = delete and re-download from another location.

    The checksum can be calculated online if you don't have a suitable software on your computer.

    http://onlinemd5.com/

     

    There is not a single bit of malicious code either in the driver or the software itself.

    If you are unsure, please check the contents with https://www.virustotal.com

     

    Supported OS: Windows XP / Windows Vista / Windows 7 / Windows 8* (32 & 64-bit)

    * Not tested

     

    The x86 version works in both 32 & 64-bit operating systems, while the x64 version is 64-bit only.

    The functionality itself is identical between the versions.

     

    Known limitations: Up to 16 CUs (32 cores) supported at the moment. Support for 32CUs (64 cores) will be added in the next version.

     

    Also the R1.00B (Beta) version does not contain the feature to patch the microcode block as I could not make it work stable enough.

     

    The "Errata Fix" button will fix the major errata which can be patched without updating the microcode.

    This feature should not be used as a permanent solution, the bios update should still be used as a primary method (updated AGESA + microcode).

     

    Note: Enabling "Zambezi Stack Special (PD)" feature might cause undefined behavior, however each user should test it's functionality on their own. Some applications might indicate a minor r.e.t.a.r.d.a.tion (god damn "specialbunnyaction") in performance, however SuperPI for example receives a nice boost.

     

    Note: "x87 instruction (NRAC) block" -> Enabled means that the instruction is blocked (default on all 15h family APU/CPU/NPUs). Disabling it make the SuperPI "a bit" faster.

     

    There are most certainly some bugs, so in case you come across one, please report them to this thread.

    The experiences are very welcome also.

     

    No it is time for the midsummer parties so I might be away for a day or two.

    Depending on how epic the headache shall be ;)

  8. Amazing!!! :)

    Is Zambezi still faster than Vishera on SuperPI even using "The Plow of Bulldozer" on both? If the answer is yes, sub-9s with AMD can be a reality eh? :D

     

    I'm not sure if the difference is still there after the new AGESA & µCode versions.

    If it is, < 9 seconds will happen in no time. In any case < 9 seconds will be easy on Vishera too.

     

    The part I was using yesterday was an ultra low leak / ultra high aq specimen, which maxes out at ~ 1.97V on LN2. During the 9.547 second run on the video, the voltage was around 1.89V during the PI. 1.50000V VID + 0.4V offset, loadline set to 0.525mOhm ("Ultra High").

     

    The newer (packed >= 44/12) FX-8 -series parts should be able to do SuperPI 1M at 8GHz - 8.2GHz, if you have a good specimen of course. My clocks were ~ 7900MHz (31.5 * 250.8) in the 9.547s run.

     

    Also disabling the "slave" cores on Zambesi should still help in SuperPI as the remaining "master" core will have a full L2 cache and L3 partition for it's private disposal.

     

    For Trinity and Richland there is no difference any more between the masters and the slaves. Not sure about Vishera as its been a while since I tested it.

     

    At some point I will see what happens when you have a 4MB L3 cache per CU instead of the normal 2MB. This naturally requires downcoring as only 8MB of L3 physically exists.

    The same configuration is used in some of the Opterons, FX-4350 and partially in FX-6 series (1x 4MB, 2x 2MB).

     

    Of course you could set 4MB for the executing CU, 2MB for the seconds CU and 1MB for the remaining two :D

×
×
  • Create New...