Groups | Search | Server Info | Login | Register

Groups > alt.comp.hardware.pc-homebuilt > #43831

Re: The build is ON

Show all headers | View raw

On Wed, 2/5/2025 10:18 AM, bad sector wrote:
> On 2/1/25 12:52, Paul wrote:
>> On Sat, 2/1/2025 8:39 AM, bad sector wrote:
>>> Thanks, I'll get on it Monday but out here in the sticks with only 2 or 3 shops (all with low volumes) it doesn't look good so it's likely to be another delay :-(
>>>
>>>
>>> Well, that didn't take long, none of the locals have any ddr5 in stock at all. Ordered one 8gb card, should have it within a week  KF552C36BBE-8
>>>
>>> Brings up a question though. Let's say it goes as you suggest and I boot with a minimal non-ECC, then set up bios, then reboot with ECC's. Does that mean that every time I put BIOS back into defaults I'd have to repeat the same ritual? Another Darwin award for Asus?
>>>
>>
>> I'm trying to turn your situation into a flowchart
>> that will complete within 30 days.
>>
>> We need to prove all the kit that matters, works,
>> within the return/exchange period. That's the objective
>> right now.
>>
>> The theory is, that once your board is flashed up, it'll be
>> fine. This is similar to what would have happened, if your
>> CPU was "not currently compatible" with the motherboard.
>> We need to make the system healthy enough, to complete
>> a flash up -- or, decide it is not healthy enough and
>> return it.
>>
>> If all goes to plan, you will flash up the BIOS, test with
>> the ECC RAM. The ECC RAM could:
>>
>> 1) Never come up, indicating the Tech Support lied about compatibility with your CPU.
>> 2) Come up in a non-ECC mode - lshw will tell you the mode.
>> 3) Come up in ECC mode once "ECC enable" is used.
>> 4) For some of these results, you will return for refund.
>>
>> At (3), the board will then "always come up". Maybe occasionally,
>> it will come up in non-ECC mode, but will report 64GB of RAM.
>> You will enter the BIOS and "enable ECC" again, then try a boot
>> and see if the mode changes to (3) ECC-actually-works.
>>
>> If the CMOS battery conks out after three years, and you have not
>> saved a profile in the profile storage area of UEFI, then you
>> would not be pulling your two ECC sticks, you'd be entering the
>> BIOS and at a minimum, "enable ECC" again as it would load-BIOS-defaults
>> to Automatic, and it still needs that nudge to go back to "enable-ECC"
>> again.
>>
>> Normally, all should be fine, and it depends on whether the
>> thing starts reliably, how many times you will need to do this.
>> I don't generally need to enter a BIOS here on a daily basis,
>> everything is "stable enough to work".
>>
>> My Test Machine runs on a Profile. I have the RAM tested at
>> a certain set of conditions (no XMP!). If the CMOS battery dies,
>> I "load Profile 1", and that has everything set up. The profiles
>> have names, so I know not to load a "loser-profile".
>>
>> But you're not ready to store settings yet. You probably won't
>> be using EXPO/XMP, because your stick is a JEDEC stick at a guess,
>> not an Enthusiast stick, and the regular DRAM timings in it and
>> auto-bringup, set the timings for it. Consequently, your Profile
>> (if you did a Save-Profike-1 after (3)), would contain a single
>> control flip to "enable-ECC". You could either Load-Profile-1
>> or you could "enable-ECC" after a CMOS battery change.
>>
>> But if we don't make it to (3), then someone lied about capability/support
>> in the BIOS for the board. The hardware undoubtedly supports ECC,
>> and we just need a BIOS in the board to prove it works. The Level1techs,
>> the first few posts I read, does not indicate ECC works yet. But I didn't
>> read all the postings there. But at least that thread looks fertile
>> enough, there could be some sort of answer in there.
>>
>> I had a board, where the hardware had been promised by Intel to support ECC.
>> The ECC in the chipset, did not work. Asus, the manufacturer, pinned off
>> ECC since it did not work. The hardware has always reported (like in dmesg)
>> that there are ECC units, but they are in the "not-working" state, so
>> I get the entertainment/enjoyment of a non-working ECC. But since the
>> board had lots of PCIe lanes, I kept the board, as I was unlikely to find
>> another LGA2011 board at that point of any sort. I had to drive out of town
>> to get that last LGA2011. And I wanted to buy locally, so if the thing
>> was a total bust, I would return it.
>>
>>     Paul
> 
> Well, I hit that (much appreciated) flow-chart with a new 8gb Kingston Fury-KF552C36BBE-8, reseated three times. The verdict is that I get the same yellow LED illuminating as soon as I turn the PSU switch ON even before touching the provisional switch normally in the 'front-panel' which if pressed just repeats the same run. Tried the card in all 4 slots, the only difference being that in slots 2 or 4 I also get the red (CPU) LED flash once on autoshutdown which in all cases comes about 6 seconds later when booth PSU and CPU fans coast down. Also tried with and without the GPU as well as holding down the 'Del' key :-(
> 

( ASUS X870E ProArt Creator WiFi )
( 9900X )
( DDR5 ECC tried and non-ECC tried)

Is the ATX12V plugged in ? The thing somewhere in the upper
left corner for CPU power. It's not a Biostar board, so it should
not be able to get that far without a connection to the CPU power socket.
CPU power connector seated, latch engaged to prevent walkout...

You wouldn't get all those responses if the firmware
was completely crackers. Like if it was crashing at
the start vector, it might not get to light any LEDs.
A crash on a Port 80 card, would be 0x00 or 0xFF (no
opportunity to write any registers).

Similarly, if the CRC check of the main BIOS ROM area failed,
I don't think it could light any LEDs either. The bootstrap code
isn't going to have a lot of POST material in it, or checking.
No "body-of-UEFI" code is in it either. The bootstrap code is the
code that has a chance to run the CRC check.

Processor   CPU No.        Frequency   Wattage  L3    Core  Stepping  ECC-DIMM support 	Validated since BIOS

Ryzen 9     Ryzen 9 9900X  4.4GHz      120W     64MB  12    B0        Yes               all  <===

The ALL on the end, is supposed to indicate it is not possible
for the CPU to be in-compatible with the board.

*******

I think this about sums it up.

   https://www.reddit.com/r/ASUS/comments/1bqmq8d/asus_proart_x670e_creator_wifi_no_post_dram/?rdt=48026

Steps:

1) Power off. Screwdriver out, remove CPU heatsink, sit CPU heatsink on table.
   Lift the lever arm. Lift the cover that applies pressure. With
   ESD strap (discharge yourself), pull the CPU (LGA so it is flat and
   only has needle-point bite marks in each gold land), and go look at the
   socket pins for damage. You're looking for discolored pins. The pins
   are a bit brittle, but springy, and they intentionally have a sharp
   point on the end, to make good contact with the soft gold.

   You will need a strong inspection light for the job. It may take some
   fiddling to figure out the best angle for illumination. There should be
   a smooth repeating pattern to the pin matrix, helping indicate that
   none of the pins has a "flat tire". You can damage a pin by pulling upward
   on it, but crushing them is pretty difficult to do. You would need a steel
   tool applied to the matrix, to really damage it.

2) If everything looks good, re-insert CPU, making sure "pin 1" aligns with
   "pin 1". On at least some processors, the shape and pattern don't allow
   seating unless the correct alignment is present. Pin 1 could be a gold
   triangle on the CPU.

3) Once everything is assembled, you'll be doing the manual, section 3.3, "CrashFree BIOS" procedure.

What they don't tell you, is how to prepare the USB stick. Here
is a disktype output, for the first partition on the stick. I don't think
FAT16 is big enough to "cover" the entire stick, so I made a smaller
partition and formatted it FAT16. I've used this stick for the MSI board
first, then the Asus board (for the security-issue flashups). On the MSI,
I might have tried FAT32 at first, and got an error indication. Frustrated,
I resorted to FAT16. And that seems to have worked for two brands of boards.
I would normally have figured FAT32 would work. Your mileage may vary. I have
truncated the whole device readout, because the rest of the output would
only cause uncertainty. This is the part my BIOSes can "see".

disktype /dev/sdc

--- /dev/sdc
Block device, size 14.53 GiB (15606349824 bytes)
DOS/MBR partition map
Partition 1: 1 GiB (1073741824 bytes, 2097152 sectors from 2048)
  Type 0x06 (FAT16)
  FAT16 file system (hints score 4 of 5)
    Volume size 1.000 GiB (1073446912 bytes, 65518 clusters of 16 KiB)

You have two manuals from the Asus download page:

a) Short manual with the hardware details (RAM in slot A2 or slot B2, they seem to like slot A2 for some reason).
b) Longer manual for "BIOS 800 series".

In the (b) manual "E25269_AMD_800_Series_BIOS_manual_EM_WEB.pdf" it tells
you the file in the FAT16 partition is to be named

   ASUS.CAP

The Crashfree code will read down near the end of the ASUS.CAP file
(the download will have a different name with the version in the filename),
and the device identifier is down near the end of the file (usually).
The Crashfree identifies that the ASUS.CAP is for this board, and
not for your other brand of board :-)

Make sure the CPU four pin fan cable is plugged to the *CPU header*.
The boards have many RPM sensor pins of course, but as a seasoned
board jockey, you head-em off at the pass by always having some
fan with pulses on the third pin, to fool the BIOS into thinking
the cooling is installed. I don't know if the CPU and Pump connectors
share an RPM pin -- the BIOS probably checks both of them for pulses.

another check, is to make sure the DRAM top is "flat" and square
with the plane of the board. It should not be tilted one way or
the other, as that indicates a cam is not actuated. With the one-cam
design, the fixed cam has a little lock mechanism, while the other latch
does the ejecting. You have to make sure your 8GB test DIMM is fully
seated. And when "pressing home", you have your standoffs in that corner
of the board, providing mechanical support. If some of the standoffs
are not present, boards can take a fair amount of bending, but these
are high tech boards so  be careful. At work, on a board this large,
the allowed bend is 8mm out of plane. More than that could crack
a ball on the PCH.

If the attempt to flash up fails, and you've done your best to verify
the assembly is correct, then something needs to be RMAed.  Notice
in the Reddit, that even a second board seems to be able to fail the
same way.

   Paul

Back to alt.comp.hardware.pc-homebuilt | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

The build is ON bad sector <forgetski@_INVALID.net> - 2025-01-30 11:36 -0500
  Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-01-30 12:32 -0500
    Re: The build is ON Paul <nospam@needed.invalid> - 2025-01-30 14:49 -0500
      Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-01-30 17:21 -0500
        Re: The build is ON John B Smith <crasso@nycap.rr.com> - 2025-01-31 15:41 -0500
          Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-01-31 16:11 -0500
            Re: The build is ON Paul <nospam@needed.invalid> - 2025-01-31 21:09 -0500
              Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-01-31 23:32 -0500
                Re: The build is ON Paul <nospam@needed.invalid> - 2025-02-01 05:31 -0500
                Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-02-01 07:31 -0500
                Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-02-01 08:39 -0500
                Re: The build is ON Paul <nospam@needed.invalid> - 2025-02-01 12:52 -0500
                Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-02-05 10:18 -0500
                Re: The build is ON Paul <nospam@needed.invalid> - 2025-02-05 12:47 -0500
                Re: The build is ON bad sector <forgetski@_INVALID.net> - 2025-02-06 08:49 -0500
                Re: The build ..chatGPT scrapped the board and/or the CPU Paul <nospam@needed.invalid> - 2025-02-06 16:01 -0500
                Re: The build ..chatGPT scrapped the board and/or the CPU bad sector <forgetski@_INVALID.net> - 2025-02-06 20:20 -0500
                Re: The build ..chatGPT scrapped the board and/or the CPU Paul <nospam@needed.invalid> - 2025-02-07 00:02 -0500
                Re: The build ..x870e ProArt-Creator in Limbo bad sector <forgetski@_INVALID.net> - 2025-02-28 09:19 -0500
                Re: The build ..x870e ProArt-Creator in Limbo Paul <nospam@needed.invalid> - 2025-02-28 10:45 -0500
                Re: The build ..x870e ProArt-Creator, Scene-1, take N bad sector <forgetski@_INVALID.net> - 2025-03-04 07:41 -0500
                Re: The build ..x870e ProArt-Creator, Scene-1, take N Paul <nospam@needed.invalid> - 2025-03-04 13:37 -0500
                Re: The build ..x870e ProArt-Creator, Scene-1, take N bad sector <forgetski@_INVALID.net> - 2025-03-21 12:49 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N Paul <nospam@needed.invalid> - 2025-03-21 13:52 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N bad sector <forgetski@_INVALID.net> - 2025-03-21 14:39 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N bad sector <forgetski@_INVALID.net> - 2025-03-21 16:17 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N Paul <nospam@needed.invalid> - 2025-03-21 23:18 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N bad sector <forgetski@_INVALID.net> - 2025-03-22 07:52 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N Paul <nospam@needed.invalid> - 2025-03-22 13:23 -0400
                Re: The build ..x870e ProArt-Creator, Scene-1, take N John B. Smith <crasso@verizon.net> - 2025-03-23 09:09 -0400
                The never-ending Asus FUBAR ___Re: The build ..x870e-Creator bad sector <forgetski@_INVALID.net> - 2025-05-05 20:25 -0400
                Re: The never-ending Asus FUBAR ___Re: The build ..x870e-Creator Paul <nospam@needed.invalid> - 2025-05-06 03:37 -0400
                Re: The never-ending Asus FUBAR ___Re: The build ..x870e-Creator bad sector <forgetski@_INVALID.net> - 2025-05-06 18:13 -0400
                Re: The never-ending Asus FUBAR ___Re: The build ..x870e-Creator Paul <nospam@needed.invalid> - 2025-05-06 19:17 -0400
                Re: The never-ending Asus FUBAR ___Re: The build ..x870e-Creator bad sector <forgetski@_INVALID.net> - 2025-05-10 09:46 -0400
                Re: The never-ending Asus FUBAR ___Re: The build ..x870e-Creator Paul <nospam@needed.invalid> - 2025-05-10 13:58 -0400

csiph-web