FW 13 - Intel Core Ultra S1 vs AMD Ryzen *WITH* Thunderbolt / USB4 *WITH* Linux

Framework Laptop 13 Linux
, , ,
1

Lo,

I’m after a recommendation from both a Linux user and someone who is clued into the world of Thunderbolt and USB4! (an answer from Framework themselves would also be nice)

First a bit of background about what we’re hoping to replace…

At the moment… I use a fairly old Dell XPS 9360 running Linux… and my husband uses a MacBook Pro 13” Mid-2017 running macOS (also dual boots Linux… but some stuff is broken and power consumption is also awful).

We’ve got two desks set up… both with 2 x 1080p DP (DisplayPort) monitors each connected to a Dell WD19TB Thunderbolt 3 dock on each desk. The idea is you can use either desk for either lappy (or an external lappy from someone else who pops around the house).

Both current lappies work with both sets of external displays just fine. In order to keep the MacBook happy (as it doesn’t support DisplayPort MST)… the 2nd monitor (of each pair of 2 monitors per desk) is actually converted from DP to TB3 via this little thing and plugged into the TB3 USB-C port of the WD19TB dock. The XPS 9360 running Linux is also fine with this setup… so I don’t need to keep changing the cabling.

Now the capabilities of these existing docks suits me just fine the way they are… I’m not after a better dock or 4k screens or anything like that.

So I’m looking to buy TWO Framework 13 laptops… and originally I had just read this article…

And just presumed to go with Intel. The article doesn’t mention the “Intel Core Ultra S1” (it just mentions the 11th gen getting the certification after the fact… and 12th gen already having it)… but I’m guessing it’d be daft to go with anything older than “Intel Core Ultra S1” ?

Unless there are compatibility reasons to be considered for Linux somehow for going for an older Intel?

But then today I’ve clicked ‘Laptop 13’ at the top of the main Framework website and then ‘Configure now’ and all I see are AMD options… with the Intel ones buried inside the ‘Shop all’ section… so should I be considering AMD Ryzen AI 300 Series … OR … AMD Ryzen 7040 Series ? OR both?

Concerns…

a) Having the WD19TB work generally for things internal to it (like its DP/HDMI ports, audio, ethernet, etc…)

b) Having the 2nd screen (per each desk) stay connected via TB3 (in the fashion described above) to the WD19TB and that still not being an issue (as I may still need the MacBook Pro for occasional Xcode jobs as I write cross-platform software)

That way I can use the two new Framework laptops, plus the older two laptops…

Will USB4 on the AMD stuff be alright with this? Or am I better sticking with certified Thunderbolt?

Non-thunderbolt thoughts…

I prioritise stability and proper compatibility with Linux above all else. I hear AMD supports LVFS more than Intel? But other than that, are they equal in terms of least faff and compatibility trouble? Second priority after that is battery life. All other concerns (including cost) are tied for 3rd priority.

I was tempted go with a Tuxedo laptop until I realised they’d ditched their upcoming ARM laptop (and no one else seems to be doing this properly with Linux)… and so I looked at the x86 options and realised they run their own APT repo for stuff like out of kernel drivers.

I’m not doubting Tuxedo’s commitment… but I really am after something which is absolutely trivial to support in terms of all the drivers being in mainline kernel, no odd quirks or workarounds (so a generic ISO of any Linux distro will do). I generally run either Ubuntu or Debian as a desktop (usually done via debootstrap then I install everything manually)… so I’d prefer that chipsets in the laptop don’t need extra steps to work! I’m hoping with Framework having an emphasis on Linux that this is true? That these chipsets are hassle-free for Linux users?

Thanks for reading my long ramble!

Oh and p.s. I’m getting a Framework 12 too - but this is more for casual use… I’m aware there is no TB3/USB4. Just hope they release the green stylus!

Thanks again!

2

It might be worth looking through the Dock Megathread to check for compatibility and concerns with the existing docks.

Personally, I have a Kensington Dock from a while back (2019-ish), and while it worked in Windows on my 11th gen, it didn’t on various flavors of Linux. I have the same issues with it, with my AMD 7040 mainboard on Linux. (one display, ethernet, and half the USB ports).

Just another anecdote to help out.

3

Well in truly confusing fashion the WD19TB seems to be listed under both “Supported” and “Unsupported” tables!

I’m not too worried about the WD19TB if I’m honest… if a MacBook Pro can cope with it (minus the MST support) then I’d say it’s generally a good all rounder.

That part of my question is more about if USB4 can cope with things like all the functionality of a proper TB3 dock… as well as having that “mini dock” (that I’m just using to bridge DP to TB3) daisy chained behind it.

4

I use a Wd19TB with AMD models and have no issues. I use two 4k monitors connected over DP. I have also used eDP while both are active.

Framework publishes BIOS to LVFS.

5

Hey Mario :slight_smile: Nice to see you here! (we’ve spoken about Dell things a few times before!)

I guess it’s not a surprise you’d have a few Dell docks laying about and that you’d now back AMD!

But have you ever connected a TB3 monitor (or something which can convert a DP monitor into one… like that AliExpress thing I linked to above) and found that it works too?

I’m not certain if USB4 would work in TB3 mode and allow a TB3 device (that little mini dock) to be daisy chained off the back of the TB3 port on the WD19TB. But it certainly works fine with my Intel based XPS 9360.

6

I haven’t, but my colleagues have! The only monitor that I know of with problems is the apple 5k one.

It internally advertises “two” DP outputs that are tiled even though it’s one cable. Most tiled monitors output the same capabilities for each tile, but for some reason the left tile supports 12bpc and DSC but right doesn’t. This leads to problems both in amdgpu and mutter.

It’s understood though and being worked on.

7

Well I bought two of the AMD Ryzen AI Framework 13 laptops in the end. I also got one of the ethernet port modules too.

I’ve noticed if I connect that ethernet port module to my XPS 9360’s only usb-c port (an odd thing to do I know… as it’s meant to be put inside a framework)… it does indeed work correctly (as it’s just USB-C at the end of the day). Interestingly it’ll also use the MAC address given to it by the XPS 9360 (rather than using its own). So that means it supports MAC Address Override (also known as MAC Address Pass-Through) right?

I’ve noticed you talked about this on another thread… [RESPONDED] Mac address passthrough framework laptop - #2 by x12Mike

But in a Framework 13 laptop nothing happens in terms of MAC overrides.

Also nothing happens with a WD19TB dock either (in terms of MAC override). Which means if I’ve got two/three/four desks (all with WD19TB docks)… then any firewall/dhcp rules tracked via MAC won’t follow the laptop - instead it has to be based on the MAC of the dock… which is not as good.

Now I get that technically you might connect multiple of these modules… so that leads to questions of which one would get a MAC that is specific to “that laptop”.

Couldn’t that just be… whichever is the first one seen plugged in or enumerated on power on? (that actually supports MAC override… like these docks and the ethernet port module).

What’s your take on this? Is this a feasible thing that Framework is missing?

8

Automatic mac address passthrough is a Dell BIOS feature. You won’t have it working in a meaningful way on anything non Dell.

But you can still do similar things with Network manager in gnome or kde GUI tools where you override the Mac address on a per connection basis. You just need to do it on each machine you connect.

9

The way you spoke in that other thread… it was as though something could be stored in the ACPI tables and then an OS like Linux can pick up on that and apply it automatically (done via the Kernel). This is something I know is more than just a Dell thing… you can even spot that in the Kernel source code.

Are you saying Dell does it some other proprietary way which is specific to their docks and Dell branded USB dongles? (as I’ve noticed it works with their Dell USB-C ethernet dongle too).

Basically… what would it take for Framework to somehow implement anything like this.

I know MAC overrides in general can be done in general network config (e.g. like you said, Network Manager and such)… but I’m not on about that.

10

From previous messages above, the aim is to have the firewall have rules specific to a particular laptop. Have you looked into 802.1X to help achieve this.
In summary, you can then put a client TLS certificate on the laptop, and that is used to uniquely identify the laptop, and not MAC address.
All operating systems Mac, Windows, Linux support 802.1X, so it should be a workable solution.

11

Yes I am aware of 802.1X

But that is redefining the issue somewhat :slight_smile: Even at a basic level it is nice to have a wired IP address that follows the laptop around the house whichever dock it is connected to.

12

DHCP is used to assign IP addresses to the laptop.
One of the parameters sent from the laptop to the DHCP server is the MAC address.
Other parameters can also be sent in the DHCP request, e.g. hostname.
You can then program the DHCP server to assign a fixed IP address to that hostname, instead of using the MAC address. If you look, I think you will find that laptops already include a hostname parameter in the DHCP request, so all that is needed is changes to the DHCP server config.
802.1X further extends that, to use TLS certificates, allowing the DHCP server to assign a fixed IP address to a laptop with particular TLS certificate.

13

OK I’m going to save you some time here.

I’ve been working at an ISP for 20 years now. Nothing you’ll say about networking will surprise or educate me.

The core issue is that other vendors like Dell plus others… support the idea of an “Internal MAC” that the laptop has (despite the laptop having no ethernet port itself built in) and then when it detects a USB NIC or Dock that supports having their MAC overridden then it does so automatically without any extra network config needed.

The Framework ethernet port module does support this (as tested on an XPS 9360)… as do many common docks like the WD19TB. So the only thing missing is actually having the Framework laptop know of its own “Internal MAC” to address to hand out? (e.g. in the ACPI tables) and then have something apply it automatically when needed. By automatic, I don’t mean… extra network config required on the client… THEN it’s automatic. I mean “out of the box” automatic.

Then it doesn’t matter about special network config at the OS level… or which OS you are running.

14

You’ll find it in the source code because I wrote the patches to use it when I was at Dell :stuck_out_tongue:

It’s relatively straightforward ASL code to export a MAC address from the BIOS to the OS, but there is actually other steps that happen at manufacturing. The system is assigned a pass through MAC address, it’s saved into a region of the SPI ROM that the BIOS will source at bootup to export into the ASL.

If you want to do something a bit hacky yourself; I could conceive making a custom DSDT that has a MAC address encoded in the ACPI object the kernel looks for with a custom MAC address.

But in my view - it’s a lot easier to just do this in userspace if you don’t have BIOS support.

15

Now that sounds like a good idea :slight_smile:

I’d even be tempted to put the Wi-Fi MAC address in the custom DSDT (but obviously what MAC is put in there… would be up to the user). Obviously unwise to have both Wi-Fi and Wired connected at the same time … at least to the same layer 2 network anyway. But then if you’ve got a wired connection you wouldn’t need Wi-Fi.

Does Dell use a specific ACPI entry now? and Lenovo uses another… and someone else uses another… and each OS (e.g. Linux, Windows, or even macOS if it’s a hackintosh) has to know all the different ACPI permutations and apply MAC pass-through overrides based on them?

In other words… is there one common generic and vendor-neutral ACPI entry to find the devices “integrated” MAC?

16

Ah, I see what you mean now.
For permanent ACPI store for MAC address, that would require FW BIOS support and assumes the NVRAM / SPI ROM has enough spare space to store it.
An alternative might be:

  1. Store the MAC address in an efivar.
  2. Read the serial number of the laptop and use a hash function to create a valid MAC address from it.
    Both those methods would survive a re-install of the OS.

It is far simpler on ARM platforms and uboot. On ARM you can use a uboot script to take a value from the EEPROM and insert it into the device tree tables. Providing a method to keep the MAC address the same with different OS installs.

17

I like that idea of storing in an efivar. This could turn into a kernel patch that will look at the efivar in the priority order too. It’s a lot easier to do than a DSDT change would be.

18

So I saw this thread pop up in my mailbox cuz I was mentioned. :smile:

Interestingly we/I have a similar setup.

  • XPSs (9510,9520,9530)
  • WD19DCS docks to go with the dual USB-C of the XPSs
  • I do only have a single 4k Dell monitor connected to the dock via DP
  • I run Mint on all of my devices
  • I occasionally use my multiple Frameworks (both Intel CUPS1 and AMD AI) with that dock, albeit with only 1 of the dual USB-C ports the WD19DCSs provide for power

As a reference, and not sure it matters, but we do disable MAC pass-through on our XPSs, due to reasons we deal with via our laptop provisioning playbook.

The thing is this thread that is confusing/bugging me is where it’s assumed that a piece of hardware that is not a network interface would have a MAC address associated with it. The XPS mother board isn’t modular, the wireless NIC is part of the mobo.

Based on what @Mario_Limonciello said “The system is assigned a pass through MAC address, it’s saved into a region of the SPI ROM that the BIOS will source at bootup to export into the ASL.” it seems redundant to do this based on my understanding of the layout of the XPS mobo.

Why would there be a “laptop” MAC address as well as the builtin wireless adapter MAC address where the “hardware” (mobo + wireless NIC) are one board?

I’m always willing to be wrong, but in all my years of IT work, I’ve just never seen a MAC be assigned to something that is not a network interface. I’m also re-reading the top of this thread and my response for the 9th-10th time realizing that all of my comment here, so far, is specific to the XPS and has no regard for anything other than that. My apologies for this long comment.

That being said, is the primary reason around the MAC questioning to ultimately just get a laptop to get the same IP, no matter what interface it uses to connect to the network?

I saw the comment by @Lantizia above “Also nothing happens with a WD19TB dock either (in terms of MAC override). Which means if I’ve got two/three/four desks (all with WD19TB docks)… then any firewall/dhcp rules tracked via MAC won’t follow the laptop - instead it has to be based on the MAC of the dock… which is not as good.” I obviously have no understanding of the “why” behind the question as it’s specific to this scenario, but if DHCP and firewall rules are the concern, why not just drop machines on different VLANs to control things?

FWIW, I’ve spent like an hour going over all this cuz it really interests me on the questioning and how things may pan out. I’m curious to see how it’s ultimately tackled. :smile:

19

During manufacturing Dell reserves a “pass through mac address” specifically for the use of dongles/docks with the laptop. If you never connect a dongle/dock, it’s never used.

20

It differs from the MAC of the wireless NIC onboard the laptop? It’s interesting, but like I said, seems redundant. Cool to know tho! :smile:

EDIT: I have so many more questions but this thread isn’t the place for it. My apologies to @Lantizia for mildly hijacking the thread.