Moved my nvme with manjaro (linux65) from Intel Gen11 to AMD r5 with updated BIOS and seem to be having few temporary issues, if at all 
The flashing itself was weird however, at first it would fail on 2nd PD, but went good after I have moved power to a USB port. It kept rebooting into the flasher, however, even once all 4 were done. I think I have solved that by interrupting boot once.
So far, I had to fix two issues with Ubuntu 22.04 on AMD Ryzen.
Perhaps you could add these fixes to the official Guide?
a. Firefox blurry with fractional scaling
Fixed by adding the line
MOZ_ENABLE_WAYLAND=1
to the file /etc/environment.
b. 3D graphics error
sudo add-apt-repository ppa:kisak/kisak-mesa
sudo apt-upgrade
see: How to Install Mesa Drivers on Ubuntu [Latest and Stable]
Only 512MB of memory were reserved for the GPU. The GPU has access to use a large chunk of the memory beyond that if it needs to. If you are experiencing less issues with a larger allocation to the GPU, then maybe the UMA is bugged?
Entirely possible, because I haven’t had the same display issues (where a large chunk of the screen would either turn white or be flashing white) after changing to UMA_GAME_OPTIMIZED.
I did have one GPU-related hang/crash last Friday, where I had to force-reboot my laptop, though, with repeating messages like the one below:
Nov 10 10:35:29 saikrishna-Framework kernel: [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=14
Nov 10 10:35:29 saikrishna-Framework kernel: [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* failed to reg_write_reg_wait
Before and after doing this, what was your kernel version?
uname -r
There are definitely issues with Memory management and scatter gather (coalescing random GPU VRAM from system memory) even persisting into the current set of amdgpu patches in 6.7 mainline. Allocating 4GB Reserved region which doesn’t get touched by the rest of the kernel for general purpose alleviates this but doesn’t make it go away. So disabling SG is the best option at the moment.
ufechner@framework:~$ uname -r
6.1.0-1025-oem
Updating mesa does not change the kernel version.
My error was:
ac_rtld error(1): too much LDS (used = 47360, max = 32768)
│ LLVM failed to upload shader
│ EE ../src/gallium/drivers/radeonsi/si_state_shaders.cpp:2557 si_build_shader_variant - Failed to build shader variant (type=3)
I am not sure if we are talking about the same issue. My issue is completely gone after updating mesa.
What is SG? And how would you disable it?
Scatter gather add : amdgpu.sg_display=0 to kernel cmd
It’s disabled in older kernels by default so 6.1 might be old enough that you don’t hit it. IIRC it was (re)enabled to be default enabled in the 6.2 series.
Hi all, got my Batch 3 a couple of weeks ago and asibe from a bum stick of RAM, everything works well EXCEPT OpenCL with darktable. I am running an Arch based distro (Arcolinux) and I have no general OS issues. But, the AMD driver packages (aur/opencl-amd) that I would normally install to enable OpenCL in darktable installs without issues but causes darktable to lock up. As darktable is my primary photo software I kinda need to get this working. I can muscle through it in CPU mode but OpenCL greatly accelerates the process.
I’m having the same or a very similar problem. For me, darktable runs fine, even with OpenCL enabled, but upon closing the program never fully exists but leaves behind a zombie process that also keeps the database locked. 
Somehow this even happens with OpenCL disabled in the settings. Maybe we should create a new thread for this either here or over on pixls.us where simila problems have been reported.
Actually, I just tried the much newer rocm-opencl-runtime and it runs correctly with darktable (no zombie process that I can detect) but, if you use a simple-text-shadow watermark, it draws a black box behind the watermark instead of the drop shadow. simple-text watermarks behave normally with OpenCL. I have posted this (with sample images) on pixls.us.
Aaaaand the darktable guys threw the upstream driver devs under the bus. I have posted an issue on the rocm-opencl-runtime GitHub.
For reference, here is that issue:
Awesome, thanks for the digging and the reporting!
I’m running that on Fedora:
sudo dnf info rocm-opencl
Last metadata expiration check: 0:32:24 ago on Mo 20 Nov 2023 07:13:13 CET.
Installed Packages
Name : rocm-opencl
Version : 5.7.1
Release : 1.fc39
Architecture : x86_64
Size : 1.7 M
Source : rocclr-5.7.1-1.fc39.src.rpm
Repository : @System
From repo : updates
Summary : ROCm OpenCL platform and device tool
URL : https://github.com/ROCm-Developer-Tools/clr
License : MIT
Description : ROCm OpenCL language runtime.
: Supports offline and in-process/in-memory compilation.
but have the above issues with zombie processes.
Is there an official way to be alerted of updates?
When new Ubuntu kernel updates are available for the laptop, I have to manually check every so often and update, I would expect framework to have some thread about Linux distro fixes and bios updates together?
If following the guide for Ubuntu 22.04, are using the code block at Step 2 that installs the zenity application, you will be alerted.
If you are using the manual method for OEM C, you’ll have to do this manually.
Just received my Ryzen 7840U system but having trouble getting to Step 9 of the guide. Installation completed successfully but after rebooting (which takes a LONG time) I can generally get to the login screen (though sometimes stuck on a black screen with _ for a bit) and move the mouse slightly or input a few chars of the password but then the system locks up and either stays locked or the screen blanks for a bit and goes back the locked login view.
Ubuntu is 22.04 (image from today), BIOS is JFP30.03.02, basically followed the installation guide verbatim other than selecting Minimal instead of Normal. Not really sure what to investigate next as everything seems as up to date as possible.
EDIT: I should also note that holding the power button for a “few” seconds turns off the screen but LED stays on. Holding it longer turns off the LED.
Is there any effort on upstreaming the OEM kernel specific parts that allows the framework 13th AMD to work properly ? Or is that kernel specifically chosen because it has been quality tested ? I’m just wondering for future kernel updates as well as other distros despite the fact that there is no official support for other distros than Ubuntu and Fedora as far as I’m aware.