Abstract

Tutorials abound online for using the Raspberry Pi as an AVR programmer, for example this one. I'm adding another because:
  1. some are outdated with respect to Linux kernel (GPIO) developments, and
  2. I have a rather different setup than others use

Background

The ATtiny family from Atmel Microchip couldn't be easier to program. Well, ok, yes it could. It could use UF2 files and work like the Pico, but would that really be easier?

AVRs are programmable by the SPI, and Raspberry Pi's just happen to (sort of) expose an SPI interface in their 40-pin GPIO headers.

Linux kernel

I say "sort of" because the kernel has to be told to dedicate those pins to SPI and if, like me, you're running something (e.g. Void) other than a Debian derivative (e.g. Raspbian), raspi-config might not exist to do that.

In that case simply add 

dtparams=spi=on
...to (the end of) /boot/config.txt and reboot.

Incidentally, before you edit config.txt... 

lsmod | grep spi
...probably won't yield any results, but after the config.txt change (and reboot!) you should see a couple modules with spi in their names. Success!

Physical setup

Happily the ATtiny85 can even work with the 3.3V output of a Pi. Some tutorials include voltage level shifters which should also work, but are not necessary (at least with the ATtiny85)! Save yourself time and get one of these breadboard adaptors.

Linux GPIO has matured

Many tutorials have command lines relying on old Linux GPIO tools which used the /sys interface. It might still work. I don't know, but on recent distros, you will want the libraries and executable utilities from: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git.

And on a new Void installation you'll need... 

xbps-install -Su base-devel autoconf-archive avrdude
...to build the GPIO tools... 
./autogen.sh 
./configure --prefix=$HOME
And avrdude is a Swiss army knife utility for working with AVR which you will need for flashing your ATtiny and more.

Using the (new) GPIO utilities

Pull RESET low to enable programming the flash memory by SPI. 
gpioset -s GPIO22=0 &
Notice the preceding leaves gpioset running in the background so you can do other things. This is necessary because only while gpioset is running can it keep GPIO22 pulled low; when it exits there are no guarantees about the state of GPIO22. Then... 
avrdude -p t85 -P /dev/spidev0.0:/dev/gpiochip0 -c linuxspi -B 500 -U flash:w:main.hex 
fg
The fg command will foreground gpioset which you can now just kill with ctrl-c. You might also want to... 
gpioset -s GPIO22=1
...to insure RESET is no longer pulled low. (And, no, you don't have to use GPIO22.)

The "t85" is for the ATtiny85 I'm using; adjust that for your μP. Congratulations! Assuming the terminal output was positive, you just programmed your ATtiny's flash memory with whatever was the content of main.hex.

Other resources

Errata

Beware old avra packages

Ubuntu Jammy includes a woefully out of date avra package (v1.3 from 2010) that did not even include tn85def.inc for ATtiny85.

Dogma isn't wisdom

Go ahead: be root!

I'm using a Raspberry Pi 400 as a single-purpose tool: an AVR programmer. This is one instance where one can safely disregard what is normally wisdom: don't work as root longer than required.

If you're dealing with hardware interfacing you're going to encounter permissions obstacles, and you will either have to prefix everything with sudo or add your (normal) user account to various groups, or...some other workaround to touch GPIO.

It's easier to just run as root. Normally this would be very bad advice, and, yes, you can still shoot yourself in the foot doing this, but in a context like this wherein:

  1. you're using a machine for one purpose: AVR programming
  2. it doesn't contain hours of unbacked up work
  3. it's not (persistently) network-connected
...it's perfectly sensible to disregard dogma and just work as root.

Yes, write assembly code

The Intertubes are awash with dire warnings about the dangers of coding in assembly. Yes, it's arcane and has different (not more) footguns than C, but it's simple. Well, x86 isn't simple. Once upon a time it was, but now it's a swamp. AVR, however, (and RISC more generally) is simple. Extremely simple. There is no question what your μP is and is not doing when you write assembly.

So get yourself a good assembler... 

xbps-install avra
...and learn what it means to know exactly what your computer will do. 
avr -I /usr/include/avr main.asm
...will emit a variety of files. The plain *.hex is what you'll load with avrdude.

avr-gcc, avr-binutils avr-libc are also options, and Microchip provides their own compiler, too.