Re: Raspberry Pi zero 2 dtb and devices

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

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

> On Tuesday 22 Mar 2022 20:08:48 Brad Spencer wrote:
>
[snip my stuff]

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

[snip some explaination]

What you wrote is mostly consistent with my understanding too.  I have a
lot of RPIs doing stuff for me, several RPI3, an RPI2, and a couple of
RPI zero 1.3 boards.

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

Ahh.. well, different OSs will use the dtb information in different
ways.  What you wrote may be true of Linux, but may not at all apply to
anything else.

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

You can not get away with using the Linux dtb files with a NetBSD
kernel.  They very much will not work, and further, most (perhaps all)
examples out there that provide overlays for Linux will not work out of
the box.  They can be useful to get understand concepts, but even if
they are transliterate into something that NetBSD uses (i.e. change
target-path stuff, for example), they may not work if the drivers do not
read the attributes the same way.  At least that is my experience.  A
real example...  there are overlays out there that can turn off
blue tooth and turn the serial port back into a real UART.  I have not
found a single one of those overlays to work on a NetBSD system.

Also...  you more or less should use the *SAME* dtb and firmware for the
same NetBSD kernel.  That is, if you run 9.x, then you should use the
9.x dtb and firmware.  To be honest, this isn't quite as strict, but I
have had to update that from time to time as I have moved forward with
versions of NetBSD.

Back to the SPI problem, there is probably something wrong with the spi
attachment on the RPI with respect to pin assignment.  The dtb, when
turned back into text, that NetBSD uses seems to imply that the
functions of the pins are to be alt0, but I can't prove that the SPI
attachment routine does that, nor am I entirely clear that it should (it
probably needs to).  I2C works fine out of the box, and doesn't appear
to set the pins, but I suspect that gets more testing and it may work
differently anyway.  At one point I found a documentation page out there
(mostly for Linux) that explained what the lines in the dtb meant,
including the raw values (0x04 meant use alt0 or some such thing, for
example).

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

Ya, I get that...  In the worse cases I have use the dtc command and
turned the binary dtb files back into text so I could get some sense of
what they may be getting at.  However, the result of doing that flattens
them and they do not exactly compare with what is in
/usr/src/sys/external/gpl2/dts/dist/arch/arm/boot/dts which I think
would be the source code for the dtbs used for a 32bit arm used by
NetBSD.  The grep command has been my friend on more than one occasion.

> Dave


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