The Ryzen AI 9 HX 370 on the SER9 is very new processor and needs some very recent parts to get running on Linux. The requirements are: Linux 6.10 or later. Mesa 24.2 or later Linux Firmware 20240811 ONLY (At the time of this writing any newer firmware causes amdgpu to hang). Sadly, manjaro, ubuntu 24.10, bazzite and others that roll the latest stuff come with newer firmware that won’t work with the 890m. You can specify nomodeset for the command line to get an install done, then downgrade to Linux Firmware 20240811. My successful build is using Mageia Cauldron with linux 6.11.4, mesa-24.2.5 and radeon-firmware-20240811. I was able to get the build working with Mageia 9 plus Linux 6.11.4 and mesa 2.4.4 but I did not have 3D acceleration. The firmware tarballs are here: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

HI there , Thanks for sharing . Please let me know, if you have any query , i am glad to help. Your satisfaction is our top priority !

Same problem here. Tried the latest endeavouros doesn’t boot with the latest release without nomodeset. Also tried installing on a 6900HX on usb drive updated everything moved the usb drive to SER9 and hangs on boot. Is that a bios problem or amdgpu driver problem? And how come AMD doesn’t fix this problem? P.S. also tried ubuntu desktop 24.10 to double check with the same results.

It’s the firmware, if you check the site: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ You’ll see that there are two firmwares after 20240811 and on both of those the system, or amdgpu more specifically, will hang, prior to 20240811, the GPU won’t initialize but at least you’ll get a text screen or a vesa display at 1024×768. I worked around the problem by looking at how mageia did their firmware and rebuilt the firmware package, in this case radeon-firmware-YYYYMMDD.rpm and used that. I’ve looked for a way to file a bug report with the firmware guys but I couldn’t find any way to do so. I saw that ETA prime and Techtablets on the YouTube were able to get Linux running which sent me down the rabbit hole for chasing the firmware issue. I don’t know about other distributions but you should, hopefully, be able to get an older firmware rpm/deb/apk that has 20240811. And you’re right, AMD should straighten out the firmware problem, pronto.

EndeavourOS is arch based. I installed a fresh copy and downgraded the linux-firmware to the august release and upgraded everything else. This worked for now but it’s a bypass of the problem. It’s not a solution. Let’s hope the next linux-firmware release will solve this problem.

Well at least you have a working system and it verifies that the firmware is the root cause of the problem. Thanks for following through and posting your results.

ximejo HI there You can email us with pictures of BIOS version and SN picture. Here`s how to check your BIOS version: https://mega.nz/#F!yuISGa4I!s1bQQajKwnsEdzjqq4nopQ See if updating BIOS would improve that situation .

I don’t know about uploading a picture but here’s the output from “dmidecode”: SMBIOS 3.7.0 present. Table at 0×78256000. Handle 0×0000, DMI type 0, 26 bytes BIOS Information Vendor: American Megatrends International, LLC. Version: STX.3xx.SER9.V103.P8C0M0C15.54.Link.GID Release Date: 09/10/2024 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 32 MB Characteristics: It would be nice to be able to use a more up to date amdgpu firmware.

support4 I have updated the bios to the latest release from https://dr.bee-link.cn/ . It still doesn’t boot without nomodset. Have you tested the latest ubuntu desktop release (24.10)? Does it boot on your test machine without nomodeset? Is it our problem? or a general problem? What are the steps to solve this issue?

This is my dimdecode output: # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.7.0 present. Table at 0x78256000. Handle 0x0000, DMI type 0, 26 bytes BIOS Information Vendor: American Megatrends International, LLC. Version: STX.3xx.SER9.V103.P8C0M0C15.55.Link.GID.90 Release Date: 09/26/2024 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 32 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported ACPI is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 0.0 if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); }

To try to get a little more information about this matter I did the following steps: I removed radeon-firmware (Mageia packages it separately from linux-firmware) I booted my system normally, and got the expected error messages: [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: amdgpu: Fetched VBIOS from VFCT [Fri Oct 25 08:11:47 2024] amdgpu: ATOM BIOS: 113-STRIXEMU-001 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/psp_14_0_0_toc.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <psp> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/dcn_3_5_dmcub.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <dm> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/gc_11_5_0_pfp.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <gfx_v11_0> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/sdma_6_1_0.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <sdma_v6_0> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/vcn_4_0_5.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <vcn_v4_0_5> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/gc_11_5_0_mes_2.bin failed with error -2 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: amdgpu: try to fall back to gc_11_5_0_mes.bin [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: Direct firmware load for amdgpu/gc_11_5_0_mes.bin failed with error -2 [Fri Oct 25 08:11:47 2024] [drm:amdgpu_device_init.cold [amdgpu]] ERROR early_init of IP block <mes_v11_0> failed -19 [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: amdgpu: VPE: collaborate mode false [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: amdgpu: Fatal error during GPU init [Fri Oct 25 08:11:47 2024] amdgpu 0000:65:00.0: amdgpu: amdgpu: finishing device. The system then came all the way up into multi-user mode and as expected sddm didn’t start but I could access the system from ssh. I opened two ssh sessions, one I did a “dmesg -Tw” and the other I left for entering commands. Next, I installed the latest radeon-firmware, then did a “rmmod amdgpu” followed by “modprobe amdgpu” at which point the output from the SER9 went black and the following output from “dmesg -Tw” came through from my remote session: [Fri Oct 25 08:14:58 2024] [drm] amdgpu kernel modesetting enabled. [Fri Oct 25 08:14:58 2024] amdgpu: Virtual CRAT table created for CPU [Fri Oct 25 08:14:58 2024] amdgpu: Topology: Add CPU node [Fri Oct 25 08:14:58 2024] [drm] initializing kernel modesetting (IP DISCOVERY 0×1002:0×150E 0×1F66:0×0030 0xC1). [Fri Oct 25 08:14:58 2024] [drm] register mmio base: 0xDC400000 [Fri Oct 25 08:14:58 2024] [drm] register mmio size: 524288 [Fri Oct 25 08:14:58 2024] [drm] add ip block number 0 <soc21_common> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 1 <gmc_v11_0> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 2 <ih_v6_1> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 3 <psp> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 4 <smu> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 5 <dm> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 6 <gfx_v11_0> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 7 <sdma_v6_0> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 8 <vcn_v4_0_5> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 9 <jpeg_v4_0_5> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 10 <mes_v11_0> [Fri Oct 25 08:14:58 2024] [drm] add ip block number 11 <vpe_v6_1> [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: Fetched VBIOS from VFCT [Fri Oct 25 08:14:58 2024] amdgpu: ATOM BIOS: 113-STRIXEMU-001 [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: VPE: collaborate mode false [Fri Oct 25 08:14:58 2024] Console: switching to colour dummy device 80×25 [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: Trusted Memory Zone (TMZ) feature disabled as experimental (default) [Fri Oct 25 08:14:58 2024] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: VRAM: 512M 0×0000008000000000 - 0×000000801FFFFFFF (512M used) [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: GART: 512M 0×00007FFF00000000 - 0×00007FFF1FFFFFFF [Fri Oct 25 08:14:58 2024] [drm] Detected VRAM RAM=512M, BAR=512M [Fri Oct 25 08:14:58 2024] [drm] RAM width 128bits LPDDR5 [Fri Oct 25 08:14:58 2024] [drm] amdgpu: 512M of VRAM memory ready [Fri Oct 25 08:14:58 2024] [drm] amdgpu: 15550M of GTT memory ready. [Fri Oct 25 08:14:58 2024] [drm] GART: num cpu pages 131072, num gpu pages 131072 [Fri Oct 25 08:14:58 2024] [drm] PCIE GART of 512M enabled (table at 0×0000008000300000). [Fri Oct 25 08:14:58 2024] [drm] Loading DMUB firmware via PSP: version=0×09000500 [Fri Oct 25 08:14:58 2024] [drm] Found VCN firmware Version ENC: 1.22 DEC: 9 VEP: 0 Revision: 1 [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: reserve 0×8900000 from 0×8010000000 for PSP TMR [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: RAS: optional ras ta ucode is not available [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: RAP: optional rap ta ucode is not available [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available [Fri Oct 25 08:14:58 2024] amdgpu 0000:65:00.0: amdgpu: SMU is initialized successfully! [Fri Oct 25 08:14:58 2024] [drm] Seamless boot condition check passed [Fri Oct 25 08:14:58 2024] [drm] Display Core v3.2.291 initialized on DCN 3.5 [Fri Oct 25 08:14:58 2024] [drm] DP-HDMI FRL PCON supported [Fri Oct 25 08:14:58 2024] [drm] Wait for DMUB auto-load failed: 3 [Fri Oct 25 08:14:58 2024] [drm] DMUB hardware initialized: version=0×09000500 The system remained accessible from ssh but my “modprobe amdgpu” never finished it ran away at 100% CPU. If I boot the system with the newer firmware installed, it eventually comes up, after several minutes, in multi-user mode but the screen output is black and getting in via ssh shows that “udev-worker” is running 100%, X did not initialize. Reverting back to the 20240811 firmware the system comes up in a functional state; I guess we’re very lucky we have 20240811. I don’t know if this is unique to the beelink SER9 but I did see one poster said that he was unable to get any distribution working on a AI HX 370, which I assumed was probably due to the firmware issue. I have seen that the system seems to have another issue: If it’s not kept busy, it spontaneously reboots, I am assuming that it goes into a very low power usage mode that Linux doesn’t handle and causes a reboot. Enough for this post.

Linux on SER9.

Scrambler

profsantini

Glad it worked.

Can you please let me know if suspend/resume works for you?

Thanks.

profsantini

Scrambler
I have the same issues you describe with suspend/resume.

I also noticed occasional reboots. These, unfortunately, happen with the T302 BIOS.
Can you confirm that the latest BIOS update fixed this kind of problem for you?

Scrambler

profsantini

No. Random freeze/reboot even with T302 bios (gpu firmware is the problem) but less frequently… Windows 11 works ok but has same suspend/resume issues. In addition, i discovered Windows11 USB issues with UASPStor driver (usb ssd storage randomly disconnects during heavy transfers). USB works ok with linux.

As far as i understand, linux suspend/resume issues are related to PCI ASPM.

I failed finding any workaround to all of those issues on both OS’es, so i’m returning my unit and switching to Ultra9 185H platform.

profsantini

Scrambler
What points to a firmware problem for the random reboots? Do you know if there’s an open bug report for this? Is there an older version of the firmware that works?
It seems that the last time there was a firmware problem, it turned out to be a BIOS problem, and it was fixed by Beelink working with AMD developers.
I am thinking about opening a bug report for this to see if it can help in addressing this issue.

Scrambler

profsantini

The symptoms are the same as before the last BIOS update but, at least for me, they have not completely disappeared. First they solved it by installing an older firmware for the amdgpu module. Then came the bios update which in my opinion only adjusted some power management. However, the problem persists with the pci-e because, if you notice, after the resume, the r8169 and iwlwifi drivers lose contact with the hardware. It is as if those devices do not reactivate because some pci-e ports have not “woken up” correctly. Try checking dmesg immediately after the resume and take a look at the errors related to pci-e.

Frankly, I hope this is a fixable issue on Linux, as long as it doesn’t involve disabling C-states or ASPM via a kernel parameter, it wouldn’t make sense on low-power devices like this… and also because I don’t have much faith in Beelink’s long-term bios update frequency.

yucher

pcm720
Are you still running that Arch Linux instance, applying the latest updates and everything works?

Arch is now on kernel 6.14.4 and starting at 6.14.0 kernel has implemented support for AMD Ryzen AI NPU, more AMD CPU Enhancements, updates in AMD P-State Driver and AMDGPU driver enhancements.

I am planning to get SER9 for myself but just can’t make my mind because of the compatibility issues.

Scrambler

yucher

Tested Fedora 42 (kernel 6.14.4-300-fc42) and Fedora Rawhide (kernel 6.15.0-rc4) and issues are still there…

If you want a SER9 AI HX370 and install linux on it, i think you should wait a little more….

pcm720

yucher
Sorry, didn’t get any notifications to my email…
Yeah, I’m still using Arch Linux with the previous Linux-compatible firmware with performance preset and 8000 MT/s RAM overclock as a daily driver with my LG monitor connected via DisplayPort and wired 2.5G Ethernet connection. Since then I’ve upgraded the Wi-Fi module to a MT7925-based card just to get Wi-Fi 7 and newer Bluetooth.

Apart from the general Radeon 890M issues tracked in https://gitlab.freedesktop.org/drm/amd, everything’s working perfectly.
To work around GPU hangs and resets, I’ve set the GPU performance mode to “high” via a udev rule:
ACTION=="add", SUBSYSTEM=="drm", DRIVERS=="amdgpu", ATTR{device/power_dpm_force_performance_level}="high"
Everything has been very stable ever since. Note that I don’t suspend my PC, so YMMV.

Other than that, I haven’t encountered any issues worth noting.
I’ve just updated my SER9 to the latest firmware (V103.P8C0M0C15.73).
I’ll report if I encounter any issues, but I doubt it’ll be any different.

yucher

pcm720 Thanks for confirming.
There are reddit discussions referencing this thread. Majority consensus is to hold off and wait for beelink to address it.
It’s a shame, such a great piece of hardware.

tobesucht

Hi there, I have a Ser9 64 with Ubuntu 24.04 installed and am frustrated with a Green Screen when turning on the Display (from time to time). Can someone please help me identify which BIOS/drivers could help? I tried to contact an Admin via PN but I cannot send the message (complains about missing captcha on all of my browsers…). Thanks!

support4

tobesucht
Please email us with these informations.

Please send us a picture of SN number and BIOS version .
So we would be able to know whether it is latest BIOS and send you files accordingly.
Here`s how to check your BIOS version:

Prese : Win + R ,
Type : msinfo32
Send us the screen.

or try this
https://mega.nz/#F!yuISGa4I!s1bQQajKwnsEdzjqq4nopQ

tobesucht

support4 thanks for your quick response! Is there any secret how I can activate the re-captcha in order to write a private message? I have tried to write you on three different browsers without success. I always get the error message “The recaptcha field is required.” - but I cannot activate anything… Der BIOS version is SER9T301 from 10th of January 2025.

Cheers

support7

tobesucht
You can also send your SN and bios information to this email: support-pc@bee-link.com
We will help you check if you need to update the bios.

About Machine Green Screen.Here are the potential solutions:

① Update the driver. Please go to device manager and uninstall the graphic driver and install the new one. We will give you the corresponding driver according to your SN number

②Please change another HDMI/DP cable.

③ Please go to display setting. Please adjust your display settings in the operating system or graphics driver control panel to the recommended settings.

pcm720

yucher
Obviously I can’t comment on the sleep issues people are having (my SER9 correctly resumes from s2idle), but other than that I feel there’s not much Beelink can do. They did fix their incorrect display configuration in a firmware update half a year ago, so you don’t need to downgrade the amdgpu firmware anymore.

Most of HX370 issues are not specific to SER9 and should be fixed by AMD in their GPU drivers, and it looks like Linux 6.15 will fix GPU resets and hangs caused by hardware video decoding.

support4

pcm720
Hi there

Thanks for sharing !

profsantini

pcm720

Without setting power_dpm_force_performance_level to high, I get random reboots even when booting to a tty.
I doubt that fixing hardware video decoding issues would resolve this.

Moreover, it doesn’t look like other AI 9 HX 370 computers out there (e.g. the Framework laptop) experience the same problem. To me, this looks like a BIOS bug that was not completely addressed by the last update. And I don’t think Beelink is actively looking for a fix, with Windows working OK for some reason.

pcm720

profsantini

Really? It took me less then five minutes to find these

https://community.frame.work/t/amdgpu-crashes-on-fw-13-hx-370/68950
https://community.frame.work/t/amdgpu-random-crashes-on-ryzen-ai-hx-370-6-14-4-arch1-1/68516

HX370 issues not specific to any device:
https://gitlab.freedesktop.org/drm/amd/-/issues/3800
https://gitlab.freedesktop.org/drm/amd/-/issues/3794 (closed, but the fix is in 6.15)
https://gitlab.freedesktop.org/mesa/mesa/-/issues/12528 (VCN timeout issue)

So no, HX370 power management is just buggy in general and it has nothing to do with the firmware (BIOS).

profsantini

pcm720

Yes, though it looked to me like the problem described in the Framework forum is not quite the same affecting the Beelink SER9.
But I could be wrong.

What is encouraging is that the BUG that appears to be mitigated by forcing the power state is reportedly fixed in 6.15: https://gitlab.freedesktop.org/drm/amd/-/issues/3794
Looking forward to the next kernel release.

« Previous Page