Re: Raspberry Pi zero 2 dtb and devices

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Dave Tyson <dtyson%anduin.org.uk@localhost> writes:

> I have been testing a rpi zero 2 with a view to use it as a weather station 
> controller. I used Jun Ebihara's image and that boots and runs fine. As I 
> noted in a post on tech-kern there are three i2c interfaces listed in dmesg - 
> but only two work iic1 and iic2. I have no idea what iic0 points to.
>
> Sadly there are no spi devices defined, no gpio interface and no wireless 
> support for the on-board chip.

Ya, I noticed that the SPI interface isn't enabled in the stock dtb, but
you will run into another problem trying to use SPI that I will mention
down further.

But first....  the following overlay enabled SPI on RPI3 I was using.
You will need to find the target-path for your zero and I do not know if
that RPI3 and zero have the same path (looks like they may be the same
on the zero I have and a RPI3, or you might be luckly here).  I groveled
around the source for the DTBs that are compiled with the kernel to
figure out the path and/or use ofctl and looked for the spi lines (I
might have tried overlays for them all until I found the one that
worked).  There is probably a better way to do this... my DTBfoo is not
all that great and being an old fart I find it generally strange anyway.
You will have to compile the overlay into its binary form with dtc and
put that result in /boot/overlays and add a line like
"dtoverlay=ds3231_rpi3.dtbo" to your config.txt file.

/dts-v1/;

/ {
        compatible = "brcm,bcm2835-spi";

        fragment@0 {
                target-path = "/soc/spi@7e204000";

                __overlay__ {
                        status = "okay";
                };
        };
};


However, even if you manage to get the SPI interface found... it will
show up in the dmesg properly if you manage that...  it probably won't
work.  When I was working on the SPI SCMD backend driver recently I
noticed that even if the SPI interface is allowed to be detected in the
device tree file the pins are not set correctly (or rather they may get
reset somehow.. in any case they are not in alt0 mode like they need to
be).  I consulted:

https://pinout.xyz/pinout/pin19_gpio10#

...for example, and put lines in /etc/gpio.conf to set the various pins
to alt0 mode.  You can do it on the command line with lines like
"gpioctl gpio0 10 set alt0" and so on if you compile a INSECURE kernel.
You will probably have to do this for gpio pins 7, 8, 9, 10, and 11.
This will correspond to physical pins 19, 21, 23, 24, 26 on the header.
Only after I did this was the SPI interface functional.  Perhaps I have
the overlay wrong or something... but I have little idea what that
problem may be.  The other implication with this problem is that in the
attach routine for the SPI driver really can't count on being able to
access the device, which can be a pain.. the devices will function after
the pins are set, but getting stuff like the serial number of a chip
when they attach wasn't really possible.  On my RPI3 an SPI read would
work, for example, no errors or anything, but would always return a
literal 0 or FF for everything (forgot which at this point, it was one
or the other).  Things worked fine after the pins were set in
/etc/gpio.conf.  This problem will also effect userland SPI access via
/dev/spi0 and the userland IOCTLs to do that sort of thing.

[snip]




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org