POST times in excess of 30-60 seconds when no boot device is found

[Lukew4lker]

Device Information

System Model or SKU

Product Name: Desktop (AMD Ryzen AI Max 300 Series)
SKU: FRANMFCP06

Please select one of the following

• Framework Laptop 12 (13th Gen Intel® Core™)
• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (AMD Ryzen™ AI 300 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)
• Framework Laptop 16 (AMD Ryzen™ AI 300 Series)
• Framework Desktop (AMD Ryzen™ AI 300 PRO Series)

BIOS VERSION

03.03 [BETA] but also experienced in 3.02

Storage:
None - No PCIe or other boot-able devices connected.

Describe the bug

Booting without a valid boot device results in POST times in excess of 30 - 90 seconds. During this period, no output is visible on screen and no LEDs indicate what might be happening. Nothing will be shown on screen until the bios recognizes the lack of boot-able devices and then the machine while show the appropriate error on screen.

Steps To Reproduce

Disconnect all boot-able devices and boot from cold state.

Expected behavior

Relatively quick boot or some indication something is happening. Would consider this a nice to have or "polish" as it's relatively easy to diagnose bad hardware due to long post times.

Operating System (please complete the following information):

None.

[Lukew4lker]

Users are complaining of similar issues on the forum.

https://community.frame.work/t/mainboards-status-leds-and-their-meaning/74678/27

[JohnAZoidberg]

@amstan can you try to reproduce this please?

@Lukew4lker you only have these long boot times in this case?
It could hint to memory training happening. Normally that's cached, even with AC cord disconnected by the RTC battery.

[amstan]

@amstan can you try to reproduce this please?

I have seen this (long boot times due to ramtraining) a couple of times in the past, however:

1. I have seen this issue even when i did have some boot devices
2. I have also had my desktop boot quickly when I didn't have any bootable devices

I'm skeptical this is the way to reproduce the problem, might be a red herring.

Let's see what our BIOS partner has to say.

[Lukew4lker]

It does seem like it might be memory training. I will have another go at having all test cases to duplicate. Should have something by Friday.

Does the board output anything on an LPC bus or other debug port so I can monitor booting?

Presumably memory training happens under certain conditions like a BIOS reset or rtc bat disconnect, would it be possible to have an OSD indicating this to the user?

[amstan]

would it be possible to have an OSD indicating this to the user?

On the screen, no. We were looking in to this, but currently this SOC requires the main memory to display anything on the screen (so you can't do that while training the memory).

Does the board output anything on an LPC bus or other debug port so I can monitor booting?

It does, if you look at the ec console (which is not well documented officially, coming soon (tm)) you'll see lots of post 80 codes in a certain pattern (1085 if i remember correctly) while it's doing the ram training.

[Lukew4lker]

Very good. I'm having some issues copying hawett's instructions on diying the adapter for uart on the EC. Which usb port exposes the EC uart function? I believe it's port 1 per the schematics but would like to confirm.

[JohnAZoidberg]

Very good. I'm having some issues copying hawett's instructions on diying the adapter for uart on the EC. Which usb port exposes the EC uart function? I believe it's port 1 per the schematics but would like to confirm.

The bottom/right one, next to DisplayPort.

[Lukew4lker]

Thanks much. I got output now and I'm seeing the Port 80 codes, Will review tonight.

[Lukew4lker]

I cannot get a boot where the delay is longer than 10-15 seconds without resetting the bios. Typically it's even shorter unless I'm doing other hacky stuff. Attached is a boot log from the EC with timestamps where I reset the bios and it took about 2m5s. Once a bios reset does happen, it does indeed seem like it's trying to train memory and will restart a couple of times. During this, I've noticed that a wake up signal isn't consistently sent to the screen during so it may seem like the system does nothing or is having a hard time booting. More documentation that memory training happens on bios reset like almost all other AMD systems would likely avoid any further heartburn. Lemme know if you need anything else.
Unless you have any issues, I think this is good to close as "Not a bug"

BiosReset_Lukew4lker_10082025a.txt

[amstan]

resetting the bios

What do you mean by this?

You're pressing the cmos reset button near the fans? That's kind of intended behavior that it'll retrain ram then.

[Lukew4lker]

resetting the bios

What do you mean by this?

You're pressing the cmos reset button near the fans?

Correct. Clear CMOS was the only way to get something repeatedly slow under a supported config.

I was able to get a long delay of about 30 seconds or so but I think it's because my display went to sleep. This happened after I unplugged two Nvme drives and moved the display from display port to HDMI on the desktop.

The other case is under a non-supported config with an Nvidia graphics card connected to the PCIe 4x slot. This is very repeatable: If you do not have something to output on connected to the iGPU and you have a graphics card connected to the system then the boot process will just hang up until the point where you connect a cable to a monitor or a dummy plug. I'll create another ticket for a feature request if you want more data on this.

All my testing being reported except for the one mentioned in the previous paragraph was with the config in the original report.

[amstan]

Correct. Clear CMOS was the only way to get something repeatedly slow under a supported config.

Yep, if you delete the ram training data with the cmos reset, you'll have to do it again. Not much else it can do. Of course it'll take longer to boot.

I was scared at first that you were seeing this regularly under normal operation.

Nvidia graphics card connected to the PCIe 4x slot

Yeah, that use case has always been very best effort. I mean... it would be cool if it worked perfectly, but officially it's not supported.

I'll create another ticket for a feature request if you want more data on this.

Sure, feel free to make another ticket to track it, but no promises we'll get very far.

[Lukew4lker]

I was scared at first that you were seeing this regularly under normal operation.

I have been changing around my configuration a lot to test windows, Linux and others distros and will pop nvme drives in and out of the system trying to look at behavior, power draw, and pcie behavior among other things. I noticed the system taking a really long time to load one time after getting ready to move back to Linux after just completing some testing in windows because my arch install was busted. I had thought I had broken my machine until I went for a coffee and came to it back on.