Do you anticipate these images working for AMD? I am hoping to try ublue when my batch 2 AMD Framework arrives, but unsure if it is already known that it will [not?] work.
EDIT: I have now read the relevant documentation, of course only after posting. 
I’m guessing this means it probably won’t work perfectly out of the box, but it doesn’t look that complicated so maybe I would be able to make needed changes myself (provided it can at least boot).
I’d be surprised if it didn’t boot, but if there are model specific differences then we’re set up to account for those.
Got some goodies for you with only a few days until F39 final!
If you’re curious about F39 we’ve been building those images for weeks now so if you’re not affected by an F39 blocker you can switch to it and give it a shot. I’ve personally been switching back and forth just to keep track of development. Not having to reinstall to try a new version of something is a great feature!
We’ve landed some new wallpapers in the images with both light and dark variants.
You can find the source for these here:
I’ve been running Silverblue F39 beta on my AMD Framework, and it works incredibly well. So well that I have been scared to rebase to ublue, even though I know in theory it should be safe, but I am just getting used to immutable OS for the first time. Will hopefully try it when F39 lands!
Not advocating rebasing on a system you’re afraid to change, however, this would be worth a read: https://universal-blue.org/introduction/
Silverblue needs extra stuff to match Ublue. And, for Intel 13th Gen users, we have our own image thanks to the Ublue team- nothing extra needed.
I’d like to try out bluefin on my AMD Framework 13. Would it be better to install the base image or the Framework (albeit Intel optimized) image?
Yeah probably stick to the non-Framework image on the AMD one, though let me know if there’s specific tweaks you need!
It seems that currently the kernel parameter amdgpu.sg_display=0 is at least somewhat helpful in mitigating graphical corruption issues that occur with AMD. Not sure if that is possible to add.
I just sent in a pull request to add it! We’ll split the setup commands into -intel and -amd specifically. (I’ll update the docs later today)
Also filed this issue for the headphone jack if someone wants to take a stab at it!
@Jorge_Castro ; power-profiles needs an out of tree patch if you don’t want to use one of the alternative fixups - details in this thread:
You can blacklist userpsace govt which sorta fixes it - my kernel cli looks like:
amd_pstate=active amdgpu.ppfeaturemask=0xffffffff amdgpu.sg_display=0 cpufreq.default_governor=powersave initcall_blacklist=cpufreq_gov_userspace_init,cpufreq_gov_performance_init
amdgpu.ppfeaturemask=0xffffffff
Be careful with this; the default feature mask upstream is intentional.
amd_pstate=active
This is controlled by a Kconfig option. Unless it’s been changed in your kernel config it’s unnecessary.
amdgpu.sg_display=0
If you’re affected by an issue that needs this, can you please try turning off PSR (amdgpu.dcdebugmask=0x10) and see if that helps it instead? If so; that’s a much better workaround until the underlying issue is fixed.
There are a couple of other things 
pcie_aspm=force pc
ie_aspm.policy=powersupersave
should also be in there for decreased power draw. And yeah one of the fixups to make sure power is set for the energy performance profile (hopefully cpupower gets support for setting this natively soon).
And yeah the amdgpu mask exposure hasn’t seemed to break things for me at all (i get little to no difference with or without it through multiple different kernels)
I believe I read somewhere amd is working on a better way of handling gpu power features than what the current system allows for anyway, so at some point hopefully it isn’t needed. At the moment it’s primarily useful on desktop GPU’s - corectl seems to expose the same bits on the phoenix apu with or without it.
@Mario_Limonciello ; what is amdgpu.dcdebugmask=0x10 doing?
I understand scatter gather disabling vaguely.
My issues seemed to be preceded by related to a iommu/VI extension errors ; and resulted in graphical lockups during power state changes (resume/sleep) where I would get a whited out screen. I’ll try with the debug mask you suggested and see how It goes. But if you could elucidate on that flag a bit, would be super appreciative.
pcie_aspm=force pcie_aspm.policy=powersupersave
These can be a bit too aggressive. I would watch out for PCIe instability or decreased NVME or Wifi performance. If they are stable, it’s best for Framework to adjust the default policies in the BIOS rather than the “big hammer” in Linux like that.
I understand scatter gather disabling vaguely.
This forces all memory allocations to go into VRAM instead of GTT. Turning up the VRAM values in BIOS has a similar effect because more allocations can go into VRAM.
@Mario_Limonciello ; what is amdgpu.dcdebugmask=0x10 doing?
It disables the panel self refresh feature in the Display Core (DC) part of the driver. You can find some high level descriptions in DisplayPort - Wikipedia along with some better links that are more in depth.
In the public AMD bug tracker there are a number of issues open and reported about PSR that are still under investigation, but none of them have been reported on Framework (IIRC) so I’d like to understand if this folds into those issues or is something completely separate.
Yeah - I haven’t noticed anything ‘so far’ with the aspm options set. I got major issues withe the nvme_noacpi option that was suggested in the tlp thread. Including hard lockups and btrfs corruption… so yeah. Will see.
Ideally the ASPM profile should be set by ppd for battery/ac I would imagine.
@Mario_Limonciello ; Ok so the Whited-out screen on resume has returned with the amdgpu.dcdebugmask=0x10 suggestion in lieu of amdgpu.sg_display=0
reverting to Scatter Gather disabling for the moment.
Interesting new error that I am seeing in addition to the IOMMU ones previously posted is the attached. I believe there is something about atomic operations changing in drm layer at the moment and this is likely as i’m running 6.7 which has a bunch of amdgpu related patches and mesa 24.
Thanks for confirming it’s not linked to PSR.
I haven’t had these since adding my user to the video group.
Hey folks,
I wanted to share that I have been running my own custom Kinoite image for the Framework 13 AMD. It’s still a work in progress, but it is at a pretty decent state thus far. This is not meant to be an official distribution per se, but thought I would share what I did with the group in case it’s helpful. It is based off of the awesome work that the universal blue team has done creating the Kinoite-main image. Huge thanks to Jorge for this project.
Copied from my repo:
vm.dirty_writeback_centisecs and kernel.nmi_watchdog parameters for power savingjust fw13-amd to update default kernel parameters (cpufreq.default_governor=powersave, pcie_aspm.policy=powersupersave)just check_sleep to run amd_s2idle.py debug scriptjust check_psr to run psr.py debug scriptjust epp_power to set AMD EPP Hints to Power Savingjust epp_balance_power to set AMD EPP Hints to Balance Powerjust epp_balance_performance to set AMD EPP Hints to Balance Performancejust epp_performance to set AMD EPP Hints to PerformanceAfter first install be sure to run just fw13-amd to set the kernel parameters. If you want the ideal power saving mode run just epp_power to set the power saving mode. If you want to switch back to balanced use just epp_balance_power. This is needed because power-profiles-daemon does not set these properly which significantly contributes to poor battery life on linux by default.
I didn’t run any of the other kernel params (disable scatter gather / iommu, etc) since I didn’t see a need for it myself yet.
Running this image on power saving mode, I can get ~3.5-4 watts at idle, ~6.3 watts during offline video playback. And ~5-8 watts web browsing. The main goals of the image were to create optimized defaults. A lot of the power saving tweaks are what tlp would have done, and are also taken from Archwiki.
The Github repo has the instructions to switch to this image. You can always switch back or to another, which is the beauty of ostree systems. Happy to accept any tweaks or best practices I have missed as I am still new to this. Obviously it’s also forkable / modifiable if you want to use it as a reference for your own image.