Re: Raspberry Pi zero 2 dtb and devices

[Dave Tyson <dtyson%anduin.org.uk@localhost>]

On Tuesday 22 Mar 2022 20:08:48 Brad Spencer wrote:

> 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]

Hi Brad, thanks for your input! It is both informative and at the same time a 
bit depressing for reasons I outline below. However you have given some hints 
so I can test some spi code for which I am very grateful .Sorry it's a bit 
long...

First I just wanted to note that I view the rpi zero 2 as one of the most 
interesting and useful boards to have been produced recently. It is very 
cheap, powerful (albeit with a small memory) and more importantly there is a 
commitment to produce it for 6 years. It has a good selection of interfaces 
which make it ideal for embedded systems and so I think it needs to be well 
supported by the *BSD's as they come without the ludicrous bloat of linux.

My understanding is that the SOC devices do not have a way to enumerate 
the busses and attached devices like x86 systems and so to minimise the 
problems of having a plethora of O/S level config files a hardware description 
file, a dtb, is used to replace the device discovery phase in the kernel.

The SOC chip itself has a set of I/O pins, some of which are made available to 
users by traces from the SOC to connectors on the particular board (e.g. rpi 
3, bananapi zero etc.).

Within the SOC is a crossbar which allows the I/O pins to be connected 
internally to chip subsystems which support special functions such as i2c, 
spi, usb etc. or maybe use just the pins as simple voltage level inputs or 
outputs. The configuration of the crossbar is set by a set of mapping 
registers which are specific to each SOC chip.

On power on-reset the SOC sets these registers to a known manufacturer 
specified state. The boot loader uses the dtb to program the mapping registers 
to match the documented character of the particular board. For example on the 
rpi zero 2 gpio 0/1 are the first iic data/clock respectively and these pins 
are exposed to the user on the 40 pin connector).

The boot loader then loads the o/s and passes the dtb. The kernel uses the dtb 
to build a device tree and call each device driver to initialise the registers 
ready to handle requests from the machine independent device layer. Device 
drivers just confine themselves to the registers associated with the chip 
subsystem embedded in the SOC _they do not touch any of the cross-bar 
registers_ as they have no need to. when a user opens an iic device the data 
should pass though the kernel and end up on the documented pins on the board 
in question.

If the user wants to change the function of an i/o pin then they are free to 
use the gpio device to alter the cross bar register as they desire, but this 
should not be necessary for normal operation of the interfaces in the 
published board description.

That is my understanding of how things should work (and how I would like them 
to work)  but it seems I am missing something because you imply that there may 
need to be extra stuff in the kernel. I used the same dtb supplied with the 
linux distro with NetBSD and it didn't pick up the devices properly so I guess 
something is wrong with the dtb processing.
 
There seems to be very little documentation/man pages on this issues.  I am 
happy to write some stuff once I comprehend it - if that would be deemed 
useful.

Dave