Re: question about enumeration of buses on arm systems with dtb files

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

On Sunday 03 Apr 2022 13:08:43 Michael van Elst wrote:
> campbell+netbsd-tech-kern%mumble.net@localhost (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