Overlays: add overlay for rak-6421 WisBlock hat

[jp-bennett]

The RAK 6421 is a new HAT+ device for Meshtastic, that adds support for the WisBlock ecosystem on the Raspberry Pi. This overlay will usually be loaded via the HAT+ eeprom.

[jp-bennett]

@pelwell I saw the failing tests, and fixed up the two issues: Replaced the spaces with tabs, and added the longer commit message to the commit itself.

[pelwell]

The dtoverlay check will fail for 2 reasons:

1. The overlay file has the wrong name - it should be rak-6421-overlay.dts, otherwise the Makefile logic won't find it.
2. Fragment 3, that disables usage of the MISO pin, is dormant - enabled by the nomiso parameter. But the parameter is declared to enable fragment 2, not 3 - make it say =3.

[jp-bennett]

@pelwell Ah-hah! I think those are fixed now. Thanks!

[pelwell]

3. You haven't documented the parameters.
4. The Load section must say:

dtoverlay=rak-6421,<param>=<val>

[pelwell]

Add a comment when you've done that and I'll restart the workflow.

[jp-bennett]

3. You haven't documented the parameters.
4. The Load section must say:

dtoverlay=rak-6421,<param>=<val>

I can't imagine why someone would want/need to override any of the three values I left in overrides, so I've just yanked that section. Do I still need the <param>=<val> string in this case? It looks like other entries leave it out when Params: <None>

[pelwell]

What you are left with doesn't make sense. If you need the MISO line, delete fragment 3. If you don't need the MISO line, change it from __dormant__ to __overlay__.

[jp-bennett]

@pelwell Thanks for the handholding on this. I've removed fragment 3, and tested the result with real hardware. It still fires up the i2c and SPI busses as expected.

[pelwell]

Your overlay looks OK now, but it is setting some properties to their default values. If you take out this duplication, you are left with:

...
	fragment@0 {
		target = <&i2c_arm>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target = <&spi0>;
		__overlay__ {
			status = "okay";
		};
	};
...

which is the equivalent of:

dtparam=spi=on
dtparam=i2c_arm=on

I'm not sure if this made it into the documentation, but the overlay name string can include parameters (separated from the overlay name by commas, as in config.txt). And as with config.txt DT parameters, any which aren't found in the overlay are then matched against the base dtb. This means that:

dtoverlay=foo
dtparam=spi=on

and:

dtoverlay=foo,spi=on

are equivalent. If the foo overlay does not have an spi parameter, the board's spi parameter is enabled.

Finally, for the last year and half, the firmware has supported a magic overlay name - "none". This means that

dtoverlay=none,spi=on

will always enable the board's SPI parameter.

Putting these pieces together, you should be able to completely eliminate your overlay (if you want to), by making the string in the EEPROM:

none,i2c_arm=on,spi=on

I suggest you give it a try, and let me know what you want to do.

[jp-bennett]

Finally, for the last year and half, the firmware has supported a magic overlay name - "none". This means that

dtoverlay=none,spi=on

will always enable the board's SPI parameter.

Putting these pieces together, you should be able to completely eliminate your overlay (if you want to), by making the string in the EEPROM:

none,i2c_arm=on,spi=on

I suggest you give it a try, and let me know what you want to do.

That works! This is basically all I wanted to do, but didn't find that "none" magic overlay anywhere. I'll go ahead and close this. Thank you so much for your help @pelwell !