I haven’t had these since adding my user to the video group.
1 Like
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:
Changes to Kinoite-Main Image
- Add PCIE and USB power saving configurations to /etc/udev/rules.d/
- Add wifi power saving configuration to /etc/sysctl.d/
- Add wifi power saving configuration for intel wifi to /etc/udev/modprobe.d/
- Add AMD s2idle and psr debugging scripts to /usr/share/ublue-os/scripts
- Add udev rules to change AMD EPP Hints on AC Power / Battery
- Add sysctl.d rules for
vm.dirty_writeback_centisecsandkernel.nmi_watchdogparameters for power saving - Make scripts / kernel parameters available via just script
-
just fw13-amdto update default kernel parameters (cpufreq.default_governor=powersave, pcie_aspm.policy=powersupersave) -
just check_sleepto run amd_s2idle.py debug script -
just check_psrto run psr.py debug script -
just epp_powerto set AMD EPP Hints to Power Saving -
just epp_balance_powerto set AMD EPP Hints to Balance Power -
just epp_balance_performanceto set AMD EPP Hints to Balance Performance -
just epp_performanceto set AMD EPP Hints to Performance
-
- Install powertop, kernel-tools, fprintd, fwupd, tailscale, 1password and other apps by default
- Install AMDGPU_TOP by default
- Make some commonly installed Flatpaks available to install on first boot, these are completely optional
After 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.
7 Likes
Awesome! Appreciate the share!
1 Like
Hah this is so awesome! Thanks for sharing this!
2 Likes
got bluefin up and running on my FW13 AMD - really like it so far!
the only thing that is not working out of the box is the fingerprint scanner. is there anything special to do on the immutable system?
downloaded the cab file from: Updating Fingerprint Reader Firmware on Linux for 13th Gen and AMD Ryzen 7040 Series Laptops
tried to install it with fwupdtool, but it fails:
sudo fwupdtool install --allow-reinstall --allow-older goodix-moc-609c-v01000330.cab 1e8c8470-a59c-571a-82fd-19c9fa32b9c3
Laden … [******** ]11:58:06.743 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.0: ioctl error: Ungültige Adresse [14]
Laden … [*********** ]11:58:08.722 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.722 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Laden … [************ ]11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Laden … [************ ]11:58:08.723 FuUdevDevice fu_udev_device_get_sysfs_path: assertion 'FU_IS_UDEV_DEVICE(self)' failed
11:58:08.723 FuDevice fu_device_add_parent_backend_id: assertion 'backend_id != NULL' failed
Schreiben … [******************* ]
Ausgewähltes Gerät: Fingerprint Sensor
Entpacken … [ - ]
generic GUID requires a CHID, child, parent or sibling requirement
The problem is the CAB file doesn’t express the requirements appropriately for which systems it can apply to. This is a requirement with newer fwupd versions. Framework needs to respin it.
See [RESPONDED] Fedora 39 Kinoite Fingerprint Reader Not Working - #3 by Mario_Limonciello for more details.
3 Likes
After the last beta test with LVFS went sideways as I lacked the same input kits found on 13th gen and AMD Ryzen configs, I had to rely on the community…then was drawn into other more immediate issues.
Refocusing on this now. Request for input kits matching what current users are getting, will be testing our our LVFS beta (after some internal changes are done). It’s on the list, I promise! 
5 Likes
Very cool! Definitely get significant power savings using this, but the epp_performance command errors out, and with epp_balance_performance or lower (maybe epp_performance too, but can’t verify) I get random mouse dropout while gaming. Not sure what could cause this, but had to switch back to ublue main. Still a great image to rebase to whenever I need a full day of productivity without a recharge. Thanks for sharing, and I’d bet if this image gets more attention from the knowledgeable community here to polish stuff like that, it could become the defacto AMD framework image.
1 Like
Thanks for sharing your results. I will have to look into why the epp_performance setting isn’t working for you. Regarding the mouse maybe it’s due to the usb autosuspend configurations? I’m not sure I haven’t run into any issues with that myself yet.
But also wanted to give you a heads up that you shouldn’t need to manually set the epp settings anymore. I created a COPR with a patched power-profiles-daemon which is now integrated into the image. So when you select power saving / balanced / performance it should automatically set the epp setting for you (no need to use the just script anymore). I am planning on doing a more detailed post / tutorial for the community.
4 Likes
Yes! I’m glad people are finding the power of the fork! I’m on an Intel Framework so I can’t take lead on this, but if we figure it out and get the fixes in then we can just slipstream them in. If you wanna take lead we could set up a testing branch in the repo so we could stage things like this and then just land them when they’re ready.
I am hesistant to carry a patched g-p-p but if someone’s also talking to Fedora/GNOME and there’s communication effort to bring that upstream then it could be a great idea. I’m sure Matt and Fedora talk regularly so perhaps a testing branch might do some good here?
I think if we had a handful of people in the repo then the launch of the 16 could be smooth(er) if we set up branches for the models. My hope is that more Framework owners just dive in, we do shared ownership of the repos so all we need to figure out is a structure in the git repo to sort this and start to think about how to support future models.
EDIT: I’m addressing @Aman_Chhabra too!
1 Like
Happy Holidays! There’s been an ongoing discussion in Fedora about using tuned in F40 and beyond:
This discussion lead to this patch by Mario Limonciello:
We’ve added this patched GNOME power-profiles-daemon to our bazzite and bluefin images so we can try them out, so far the feedback from people trying it appears to be positive so I’m hoping to give it a try this week but thought I’d let you all know!
Note that the framework images are using TLP, so you’ll need to be on a non-framework GNOME image of bluefin or bazzite to try this. I’m hoping to just ship a toggle so end users don’t have to deal with this, so if you’re interested in working on that let me know!
2 Likes
Quick update, we are experimenting with tuned in our :testing images:
I just finished a trip with mine and I prefer it to the TLP setup on my Intel Framework 13. Battery lasts just as long but it doesn’t feel so crippled performance-wise on battery. I have not done hard science on this.
We now have and updated PPD and tuned in images so switching back and forth is a clan reboot. What I don’t have is the time to test them thoroughly, so if any of you have any time to investigate performance between the two (on AMD and Intel) then that’d be awesome. Thanks!
1 Like
I had the opposite experience. Tuned is simply another profile style power optimizer that attempts to figure out what the user wants. You probaly turned turbo off on battery in TLP and well tuned wants to use turbo “where needed” to enhance user experience. Probably why in your instance you are finding it more responsive, just wait until you hit the wrong workload on battery and it keeps kicking turbo in to give you the wanted experience. One of my big issues with tuned is that 1) at the time I tested it there was no easy way to turn turbo off (or I could not find the documentation), and 2) difficult to make it event driven. I don’t want to have to remember to change my profile, it should do it automatically. Primarily plugged in vs battery, docked vs not.
t has potential, but I will wait until it is actually ready.
I’m just using the built in GNOME widget (which drives tuned) to match what I want and it seems to be working fine.
1 Like
Plans for Fedora 40!
Hey ya’ll, we’ve been reorganizing and cleaning up all the Universal Blue images and I thought I’d give everyone a quick update for the Fedora 40 release.
Just about everything you need for the Framework 13 and 16 is in Fedora, there’s really no need to have a full image just for Framework hardware as it’s just passing a karg and a few minor tweaks. Therefore we have decided to sunset the dedicated Framework images and instead have Bazzite and Bluefin support the necessary tweaks to have those images working ootb on the 13 and 16.
The biggest change is we’re switching to tuned for power management. Fedora has plans to switch to this at some point. We switched to this about half way through the F39 cycle and it’s been excellent and allows for having tons of profiles and tweaks. All the desktop GUI stuff is ported over to use it so you shouldn’t notice a UX difference in the power selector thing:
- Bluefin and Aurora(WIP) are more suitable for generic desktop use and work great on the 13 and 16.
- Bazzite will be the go to image if you want to game on a Framework 16
- Both include ROCm out of the box so things like
ollamaandpytorchshould work out of the box, still investigating these.
If you’re looking for a more vanilla Fedora experience, you can use a base image - these will not include tuned. The GNOME ones come with the latest power-profiles-daemon and that has all the right AMD patches, they work great.
Rebasing to a new image
We will stop publishing the framework images sometime at the end of the month when Fedora 40 is released. If you’re on an existing framework image do an rpm-ostree status and look for this line with framework in it:
ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-framework:latest - this tells you the current image that you are on.
Whatever image you are on you will need to rebase to the non-framework version.
rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-main:latest
Note that :latest will put you on F39 and will put you on F40 when it comes out, so if you want to control when to do the major update you can use :39 or :40 if you prefer to do it manually.
Note that we’re in the process of enabling F40 builds, so depending on the image a rebase to F40 now might not work, so just putting this up now in preparation for release. Thanks and if you have any questions feel free to ask!
3 Likes
Tuned doesn’t have support for amdgpu like PPD does. For whatever reason upstream hasn’t merged it. Please don’t switch until this is merged.
5 Likes
Gotcha, we can slipstream the patch in now and then drop it when it’s merged, thanks!
3 Likes
Misspelled the URL, fixed, thanks!
1 Like
Just wanted to say I’ve been on Fedora Atomic/Silverblue since I got my 1st gen Framework, and switching to Bluefin made both video playback and battery-life/heat a lot better. Thank you very much for the build!
1 Like