AMD's Raven Ridge Botchy Linux Support Appears Worse With Some Motherboards/BIOS

[bridgman]

Still waiting for AMD to release a Ryzen mobile driver ... the desktop APU driver appeared days after release, the mobile is still MIA ... I wonder WHY ... exclusivity deals ?

This is an APU ... it does (or should) not matter that it is a laptop part, there is no difference in that regard to a desktop APU ... so the missing drivers are somewhat bugging me ...

I'm having trouble reconciling these two statements. In your first post you are asking for a mobile driver as a separate thing from desktop driver, but in the second post you are saying they should be the same anyways... what am I missing ?

Note that laptops & desktops do tend to differ quite a bit in terms of BIOS details - as debianxfce said the laptop bios option set is usually stripped down, but you also tend to see more vendor-specific customization in laptop SBIOS/VBIOS which can require vendor-specific driver changes as well.

[chithanh]

The vendor specific part doesn't change between driver releases. So if the driver were sufficiently modular, one part could be updated without the other. Like AMD already provides separate downloads of CF game profiles.

Also I think there would be nothing preventing AMD from merging the vendor specific code back into the generic driver and let users choose between vendor driver (supported) and the generic one (unsupported, click-through warning: use at your own risk).

[Darksurf]

Woo! got my raven ridge workstation working! Pulled the kernel from https://cgit.freedesktop.org/~agd5f/...aging-drm-next then upgrade sys-devel/llvm-9999 x11-libs/libdrm-9999 media-libs/mesa-9999 . I still see ACPI errors upon boot, but machine appears to be working well otherwise.

AMD R5 2400G
MSI B350M Gaming Pro
G.SKILL Ripjaws V 16GB DDR4 3200

Installed Sabayon Linux (Gentoo-based) using a VM pointing to a Sata SSD over USB3 (/dev/sdb)
booted up, installed kernel and packages via portage. shutdown VM, moved SSD into machine and booted legacy style. (no UEFI)
Seems to be working well and stable. I've not tried any video games though.

[Djhg2000]

backports to lts is canonicals job, not amds. what next, backports to rhel and sles?

I missed the notification, sorry for the late reply.

I'm of course talking about the LTS version of the kernel. I'm aware various distros have LTS versions as well, but that's not what I'm referring to in the post you quoted.

Just wanted to clear that up.

[pal666]

I'm of course talking about the LTS version of the kernel.

only fixes can be backported to lts kernels

[Djhg2000]

only fixes can be backported to lts kernels

That's for having them included in the official tarball, nothing is stopping AMD from supplying patches which apply cleanly to the latest LTS kernel. Except for, you know, the obvious reasons that come with having such a small dev team.

[agd5f]

That's for having them included in the official tarball, nothing is stopping AMD from supplying patches which apply cleanly to the latest LTS kernel.

Does anyone actually use upstream LTS kernels? Most distros do not. We generally focus on supporting distro kernels (e.g., RHEL, Ubuntu LTS).

[Djhg2000]

Does anyone actually use upstream LTS kernels? Most distros do not. We generally focus on supporting distro kernels (e.g., RHEL, Ubuntu LTS).

Debian favors LTS kernels for most releases (testing and unstable not included unless testing is about to become the next stable).

Surely Debian can't be the only ones taking advantage of LTS though?