JohnSutter
Posts: 1
Joined: Tue Aug 13, 2019 9:02 am

HAT for board with WM8731 - where to start

Tue Aug 13, 2019 9:27 am

I'm working on an amateur radio WSPR receiver project.
It uses a WM8731
I2C, I2S
and an Si5351:
I2C

My goal/hope is to be able to load with EEPROM with the right data to make the
HW plug-and-play without user setup/configuration including a few bytes of calibration
data.

I start reading the very detailed device tree docs and my head starts to spin with all the
options. Generating the hex file seems to have quite a few well written examples/recipes,
but I'm not sure what I need to put in my dts(?) file beyond the simple stuff.

How do I reference/load the WM8731 driver?
Do I need fragments enabling the I2C and I2C before the WM8731?

For now I just edited /boot/config.txt and added
dtoverlay=audioinjector-wm8731-audio
and that works for testing though I had to do enable this and that along the way too.

John

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2279
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: HAT for board with WM8731 - where to start

Tue Aug 13, 2019 12:30 pm

How do I reference/load the WM8731 driver?
That's what the "compatible" strings in the overlay are for.
Do I need fragments enabling the I2C and I2C before the WM8731?
Yes.

Code: Select all

For now I just edited /boot/config.txt and added
dtoverlay=audioinjector-wm8731-audio
and that works for testing though I had to do enable this and that along the way too.
That overlay is a good place to start. Copy the source (https://github.com/raspberrypi/linux/bl ... verlay.dts), give it your own name (I'll assume my8731-overlay.dts for the examples), compile and install it:

Code: Select all

$ dtc [email protected] -I dts -O dtb -o my8731.dtbo my8731-overlay.dts
$ sudo cp my8731.dtbo /boot/overlays
The original idea with the HAT EEPROMs was to build in a compiled overlay (your my8731.dtbo), but newer firmwares - Stretch and later, from memory - allow you to build the name of an overlay into the EEPROM instead. This requires that the overlay is installed (it helps if it is part of a standard kernel image), but has the advantage that the overlay can be changed without needing to reprogram the EEPROM.

Return to “Device Tree”