New AMD7040. Successfully installed Debian 12, rebooted system. Setup desktop and installed software. “New Updates” appeared from the system package manager autoupdate. Items included an ‘AMD Firmware Update’ and ‘System Update (requiring restart)’. After applying the updates and attempting to restart, the system is behaving bricked. No ability to get into the BIOS/UEFI menus. The screen never illuminates.
The LED’s on the motherboard flash red for a time, then briefly green and blue, then back to red for a time. Eventually the LED flashing stops and the fan will randomly spin up slightly.
What are my next self-help steps before a motherboard return/replace?
Hopefully one of those matches. I’d start out with taking the battery out, waiting a little bit and trying again putting it back in. Otherwise contact support
Also; what RAM module? Maybe memory training is failing for some reason? This does take a while after a BIOS upgrade or power loss (like unplugging battery).
When I press the power button:
30 seconds of slow red led blink
5 seconds of fast green blink
1 green+blue blink
5 seconds of fast green blink
1 red+orange blink
more slow red link
If I let it sit after 5 or 10 minutes the fan spins up as if it working hard on something.
IMHO some form of debug/status on-screen is necessary.
Unplugging/reconnecting the main battery for >10min doesn’t change anything.
Removing the memory results in 30 seconds of slow red blinking leds with a different combination of flashes.
QR code on the motherboard for the motherboard goes to the replacement guide, not any information that I need about the mainboard or led codes. Cannot locate AMD7040 LED sequences guide.
Do you happen to have any other RAM besides that 48GB modules you can try? I don’t believe 48GB is POR, but some people have had luck. It sure sounds like memory training hanging to me.
For the blinking led. It is more helpful if you list the blink colours in sequence. There should be 22 blinks.
Sometimes making a video recording and playing it back slowly helps with noting the down.
It successfully trained 2x 48G Crucial before using the Live USB install.
The memory is new and good.
The ‘AMD 7040 firmware update’ from Debian package repo seems responsible. In retrospect I should have had Debian disable firmware packages. ><
There are 30 slow red blinks followed by approximately 10 fast green blinks, a green+blue blink, 10 fast green blinks, and an orange+red blink before concluding with another 30, 30s of slow red blinks. Then after a couple minutes there is fan spinup and noticable heat generation which can last many dozens of minutes until I force it off. I highly recommend putting the complete LED blink table document on the website of the motherboard.
If you want to send me a firmware flash kit and a basic doc/pinout of the chip I’ll volunteer to flash firmwares and test. The other option is to replace the motherboard and you double double double check the firmware and update process of the of Debian stable repo.
Right, but I’m saying a non-POR memory combination that isn’t actively tested might regress from a firmware update. That’s what I’m specifically worried about.
I think you should probably contact Framework support at this point.
I pulled the SSD immediately and all testing has been without NVMe. I will re-add the NVMe once the BIOS/UEFI menus appear once. The display has never illuminated since the debian apt ‘AMD 7040 firmware update’ out of the debian built-in software center.
Tech Support first recommended a ‘memory shuffle’. Removed both sticks of ram, A & B, and then tried the following combinations of both sticks in channels 0 and 1: A0 A1 B0 B1 A0B1 B0A1. All failed and the LED blink code was exactly the same unchanged.
We also verified that the pins of both channel 0 and 1 were beautiful, perfect, and unbent.
Next we tried a mainboard reset. The mainboard reset was to turn off the laptop and unplug charger, remove the input cover and plug in the charger, press the chassis open switch (upper middle of the board) for 2 seconds release and wait for red LED blink on mainboard repeating 10 times, finally press the power button to boot the system. This procedure of resetting the BIOS failed every time. The LED blink patterns were exactly the same.
Then we established with tech support that 2x48G modules are officially supported by the AMD 7040 series according to the AMD 77840U specifications page.
As @Mario_Limonciello mentioned, I’m betting this is a firmware regression bug for memory sizes Framework doesn’t sell, didn’t check, but should be supported because the processor itself supports it. Testing larger sizes of memory is necessary for power users of generative AI, LLM AI, scientific computing, and video editing. Framework owners (like me) love upgrading and hopefully will love this platform up to the 256G limit of the 7840U processor.
I don’t think Debian 12 Apt updates could brick the laptop, even to the point where one cannot get into the BIOS.
So, I suggest looking for other causes of this problem.
FW13 / FW16 are difficult to diagnose problems if the display does not come on, because no output is sent to external displays while in the BIOS screens.
The blink pattern you are seeing is a bit odd also, because their are too many flashes.
I would unplug battery, nvme SSD, keyboard, mid plate. Leaving just one RAM chip and the mainboard.
Then plug in an external USB keyboard to one of the side slots.
Then, connect the power brick. The red lights should flash.
Then press the power button. Does the power button then light up?
Keep pressing (on/off/on/off about twice a second) F2 on the external USB keyboard and see if you can get into the BIOS.
If you do get into the BIOS, switch off secure boot.
I don’t think Debian 12 Apt updates could brick the laptop
I didn’t think so either, but it’s the only anomaly I saw before its last successful reboot. I rebooted ubuntu-liveUSB, debian-liveUSB, and Debian itself many times previously. Maybe it was the firmware-amd-graphics package with a prettier more specific label in the software update center. IDK.
Then, connect the power brick. The red lights should flash.
No. Without the battery after connecting the power brick I get an alternating red flash blue flash every second.
Trying both F2 with an external USB keyboard and F2 on the FW13 keyboard does not enter BIOS. The too many flashes long led pattern previously mentioned substitutes the slow red flashes with a red flash blue flash, otherwise sequences are the same.
Looking at the video you posted. That blink code is Blue, followed by 12x Green.
Red or Orange followed by 7x Green, and then 1x Blue.
The 7x Green then 1x Blue is BIOS code 0x80.
But there is something bogus about the flashes because two of them should be Red
a) Red for the touchpad disconnected (The video looks like the keyboard/touchpad has been removed)
b) Red for the battery disconnected. (I assume this is disconnected, but for the video you might have not disconnected it)
But those are both appearing as green in that video.
So, if the flashes are to be trusted, it is complaining about the RAM, but I would have expected the 12x Green to also have a Red one to indicate a RAM problem.
So, a green blink for : 11 Red/GreenDDR initialized OK
Then a BIOS code of #define PEI_MEMORY_INSTALL 0x80 // Simple Memory test
Before failure this system would initialize the screen and show a Memory Check percent that would quickly count from 0% to 100% before booting the liveUSB’s/Debian. Displaying that test doesn’t happen anymore.
Where is the source code for the simple memory test?
The display cannot work unless the RAM is working.
A misbehaving battery can sometimes cause boot problems, so that is why disconnecting the battery might help diagnose it.
If you do get into the BIOS, look at what bios version is installed.
Debian is the root of Ubuntu and many other Linux distributions, so it should be better tested. The AMD Ryzen 7 7840U supports up to 256G of memory, so testing larger memory sizes should be mandatory. I’ve watched my system function properly on 96GB of memory through reboots from various LiveUSB’s (Ubuntu & Debian) and then booting Debian Bookworm itself.
I could wait for support for another week or two.
I could spend $50 for 16GB of Crucial memory and maybe it boots. Then I can test upgrading firmware/memory for a long term goal of getting 96GB of memory working again. Maybe it fails because the UEFI-GPU initialization is now permanently stuck so I resort to the next option:
For an additional $700 I can buy a new mainboard and test firmware memory combination theories myself or never upgrade the firmware. I dislike the idea of buying a new mainboard with functional firmware to return a motherboard with failed firmware.
F-it, I’ll buy 16G of memory and mess with this again next weekend. I got work to do.
The problem is not debian updates, but doing debian updates via the GUI probably also called a script that updated the bios via something called fwupd. Fwupd is the standard linux way of updating firmware and BIOS. Maybe it updated some firmware and/or BIOS, and whatever it was it bricked it, maybe due to a regression or maybe just a bad download of a corrupted firmware.
There’s no such thing in Debian repositories. But Debian ships standard Gnome Software / Plasma Discover like many distros and these software stores will present you in the same place :
Packages from the distro
Containerized apps (snap/flatpak type)
Firmware updates provided by device manufacturers via the fwupd project
My guess would be that you had an issue with the UEFI firmware update provided by the Framework team. I cannot see how a Debian package update could break your system to the point that you cannot enter the bios / uefi menu which is running before the OS starts.
All green flashes.
Still bricked and no screen illumination or functional BIOS/UEFI interface.
I don’t think Crucial 16GB vs Crucial 96GB of memory was ever the issue. It blinked green/OK for both 16GB and 96GB. The laptop functioned beautifully on 96GB for a time before the Debian update. I cannot see how a Debian package did break the system either, but here we are.
There’s no such thing in Debian repositories.
Of course not. I’m sure it was a friendly description extracted from the update which was shown in the software center update notification dialog instead of a package name.
