From: nospam@needed.invalid   
      
   On Sat, 7/12/2025 8:46 PM, bad sector wrote:   
      
   >   
   > I never touched the CPU, the next boot failed after I edited the BIOS and   
   among a few other things disabled the CPU-native graphics.   
   >   
   > Then following your advice I managed to reboot into BIOS, ultimately able to   
   launch an OS. I ha it made using 1/2 of my memory!   
   >   
   > J. O. Aho suggested and I prepped a BIOS upgrade usb drive (there are 3   
   different BIOS sections in the manual, all of them full of mistakes).   
   >   
   > As I pressed the bios flash button the LED never illuminated so after about   
   6 seconds I let it go.   
   >   
   > Now I cannot get past the yellow (ram) LED no matter what ddr5 I set in no   
   matter what ram slot.   
   >   
      
   Hmmm.   
      
   Restore non-ECC DIMM in the "best working socket" your previous testing   
   revealed.   
      
   You are likely going to need to flash the BIOS back to some   
   previous version, at a guess.   
      
   On some systems, switching off the power three times, when the machine   
   is in trouble, initiates "load setup defaults" so you (in theory) can   
   get back in control of the machine.   
      
   *******   
      
   The purpose of a non-bricking BIOS design, is to never erase the bootstrap   
   section.   
      
   Then, one of the BIOS flashing options, should always have an interpreter   
   ready to   
   read the USB stick and FAT file system, find the named file, and flash it in.   
      
   I don't know if that BIOS flashing code has been written to work with   
   only CPU registers (so a non-working memory is not a problem). Some of the BIOs   
   code must operate that way, in order so the BIOS code can commission the DRAM   
   subsystem.   
      
   On my ten year old machine, the flasher is a chip connected right to the USB   
   port.   
      
   On my three year old machine, the CPU and RAM must be working, for a flash   
   operation   
   to move forward. Which means, even if AGESA isn't optimal, there is some code   
   present that can do a flash, but a lot more things can still go wrong. It is   
   definitely not as foolproof as a flasher-chip type solution.   
      
   When a "machine has a button", we don't really know how that works. and while   
   you   
   would hope a flasher-chip, if it existed, would be physically placed near the   
   USB stack that supports flashing, the board layout could be such the chip is   
   just about anywhere. But usually the layout done by humans, the chip is closer   
   to where it is being used, rather than being routed across from the other side   
   of the board.   
      
   We don't know, if the flasher button terminates in a GPIO signal on the SOC   
   portion   
   of the CPU, or whether it terminates on a flasher-chip. I guess that is part   
   of the   
   fun. Even when you have a flasher-chip, the board *still* has firmware or   
   software   
   based flashing options, in addition to the "unbrickable" USB flasher chip.   
      
   *******   
      
   You may be at the point, you're going to need to take this in somewhere, and   
   see if a techie can flash it back to something that works. You *used* to be   
   able to flash a BIOS backwards, but it took some standalone flasher and an   
   MSDOS boot media, to "free-form flash", meaning a version check was not   
   done on purpose, and you could move backwards. We stopped using such flashers,   
   more than ten years ago, which is why I'm kinda wondering what options   
   are available for going back to an older version.   
      
   At a minimum, what is supposed to happen, is a model number string in the   
   BIOS image is checked, so you can't flash in the BIOS from some other board.   
   The version is a separate issue. The only interface you may have, is a   
   single LED, where the "blink frequency" is all that tells you whether   
   the flash is ongoing, or, the blinking represents a failure on the   
   users part, to pass all the model and version number requirements. A single   
   LED has a definite lack of expressive power.   
      
   The behavior of the machine I'm typing this on, changed after a year. The   
   machine seemed to develop an address map problem. Shutting off the iGPU and   
   using an NVidia video card, was part of the solution. My first hint of   
   (some sort of) trouble, was the RealTek Ethernet chip would stop   
   sending/receiving   
   packets after 30 seconds. At first I thought I had a DNS problem, but no, the   
   chip   
   just stopped after 30 seconds (looked driver-related). I purchased a   
   replacement   
   Intel NIC (possibly a Startech), and shut off the RealTek in the BIOS. And   
   after   
   that, I was "back in control" after a fashion, but this is only a superficial   
   fix,   
   and whatever is wrong in there, still seems to be wrong. And in my case,   
   flashing up (a couple times to date), made absolutely no difference to the   
   symptom set. It wasn't like an older BIOS was "bugged" and a newer one made   
   a difference.   
      
   But at this point, until things stabilize in your computer room, you'll be   
   working with the non-ECC DRAM in its "best" socket. While you try to   
   re-gain a stable BIOS behavior.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)