Jeff GeerlingModify

A few years ago, I admit it was rare to find someone running Arm hardware more powerful than a Raspberry Pi in a homelab (or more serious) setting, outside of cloud providers running Ampere or custom Arm CPUs.

But as Pis and Rockchip boards have become more powerful (and efficient), and Apple's M-series silicon has become more interesting (the M4 mini being an excellent value proposition for a quiet, tiny server), and even Ampere Altra pricing coming down a bit since it's an 'old' server CPU now, still offering 64 or 128 lanes of PCIe Gen 4... I don't think I'm weird in suggesting Arm is a viable platform for reliable, even powerful servers.

Even for storage.

Continuing the retro computer series, I've recently completed the first part of a restoration of my Aunt's old Macintosh Classic.

This Classic was handed to me alongside my Uncle Mark's Apple II, which I'll probably cover later (we've played a game of whack-a-mole with issues on that machine! Well worth it but I haven't hit a point where enough things are working to cover it well, heh).

The Classic is a strange Mac—it was introduced in 1990 as a budget version of the 1986 Macintosh Plus, with a 68000 CPU in an era when the 68030 was the new hotness.

I forgot to bring my portable Pi media server running Jellyfin on a family trip, but had a small selection of my ripped movie and TV show library on my portable SSD.

One dreaded part of choosing a movie or show to watch after a rainy afternoon and all other avenues of entertainment are exhausted is having the kids (especially the youngest, who can't read yet) choose a movie without the 'movie shelf' showing the movie posters/cover artwork.

So... without the Pi, and only armed with my MacBook Air, I thought I'd spin up a Jellyfin Docker container. Except, macOS is explicitly called out as unsupported for the Docker container for Jellyfin.

Switching tracks, I found Jellyfin is also packed up as a .app for macOS, and you can install it by downloading the .dmg and copying the .app to your Mac, or you can do it like I did, with Homebrew:

This is not a Raspberry Pi Pico. Despite it's tiny size and castellated edges, this is actually a full Raspberry Pi Zero 2W.

Well, sorta. At Open Sauce, probably the most interesting encounter I had was with Jonathan Clark.

You see, I was on a Reverse Engineering panel at Open Sauce, but I mentioned on Twitter, I wouldn't call myself a reverse engineer, more like a 'guy who breaks things sometimes taking them apart, and learns many ways to not break things, sometimes.'

Since I saw some posts calling out the old (now deprecated) way to increase GTT memory allocations for the iGPU on AMD APUs (like the AI Max+ 395 / Strix Halo I am testing in the Framework Mainboard AI Cluster), I thought I'd document how to increase the VRAM allocation on such boards under Linux—in this case, Fedora:

# To remove an arg: `--remove-args`
# Calculation: `([size in GB] * 1024 * 1024) / 4.096`
sudo grubby --update-kernel=ALL --args='amdttm.pages_limit=27648000'
sudo grubby --update-kernel=ALL --args='amdttm.page_pool_size=27648000'
sudo reboot

The old way, amdgpu.gttsize, will throw the following warning in the kernel log:

[    4.232151] amdgpu 0000:c1:00.0: amdgpu: [drm] Configuring gttsize via module parameter is deprecated, please use ttm.pages_limit

After configuring the kernel parameters and rebooting, verify the AMD GPU driver is seeing the increased memory allocation:

Framework casually mentioned they were testing a mini-rack AI cluster in their Framework Desktop presentation back in March.

Imagine my surprise when Nirav Patel, Framework's founder and CEO, was at Open Sauce a couple weeks ago, and wanted to talk! He said they had seen my Project Mini Rack posts earlier this year and thought it was the perfect application to try out their new AMD Ryzen AI Max+ 395-powered Mainboard, as its mini ITX dimensions fit inside a 10" rack.