On Sunday 03 Apr 2022 13:08:43 Michael van Elst wrote:
> campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell) writes:
> >I think usually it's first-come-first-serve according to the ordering
> >in the device tree (that is, in a pre-order traversal, which is the
> >same as the sequential order in the .dts file) -- not necessarily the
> >numbers in the device tree node names. So if there device tree lists
> >nodes i2c2, i2c0, i2c1, in that order, then it'll be
> >
> >/dev/iic0 -> i2c2
> >/dev/iic1 -> i2c0
> >/dev/iic2 -> i2c1
>
> If you enable all interfaces (status = 'okay' in DTS) you get:
>
> % ofctl -p | grep /i2c@
> 00002474: /i2c@7e205000
> 00002fa4: /i2c@7e804000
> 000030a0: /i2c@7e805000
>
> This is also the order in the DTB:
>
> i2c@7e205000 {
> phandle = <0x46>;
> ...
> i2c@7e804000 {
> phandle = <0x4d>;
> ...
> i2c@7e805000 {
> phandle = <0x15>;
> ...
>
>
> In dmesg you will just see:
>
> bsciic0 at simplebus1: Broadcom Serial Controller
> iic0 at bsciic0: I2C bus
> bsciic1 at simplebus1: Broadcom Serial Controller
> iic1 at bsciic1: I2C bus
> bsciic2 at simplebus1: Broadcom Serial Controller
> iic2 at bsciic2: I2C bus
>
> But with drvctl you can see that the order is different.
>
> % drvctl -p bsciic0 fdt-path
> /soc/i2c@7e805000
> % drvctl -p bsciic1 fdt-path
> /soc/i2c@7e205000
> % drvctl -p bsciic2 fdt-path
> /soc/i2c@7e804000
>
> The FDT code sorts nodes by an 'order' value, which currently
> is the phandle number, see the fdt_get_order() function.
>
>
> Another issue is that depending on the RPI model, different
> I2C interfaces are used by the VideoCore and attaching the
> driver may break functionality, so you normally do not
> attach all 3 interfaces but just the one that is routed to
> the GPIO pins.
OK, thanks to both of you - that is very helpful and answers my query.
I am still trying to get my head around all the dtb stuff - it's not very
clearly documented, but my question on port-arm a while back provided a bit
more info. I have yet to have a poke around in the low level code which
processes the dtb, but have a few ideas to try out.
My understanding of the raspberry pi is that that start*.elf shoves a dtb
appropriate to the board in question into low core and loads the kernel which
then looks at the in-core dtb and processes the device tree to attach devices.
The contents of the dtb shoved in-core can be modified by having code snippets
in the overlay directory and enabling them in config.txt. This is how bullseye
linux seems to do things and I guess this should work with NetBSD.
Cheers,
Dave
