[Arm-netbook] 2.7.4 preproduction sample, 1.7 MD, Questions

Paul Boddie paul at boddie.org.uk
Tue Jul 21 23:53:23 BST 2020

On Tuesday, 21 July 2020 23:25:12 CEST Luke Kenneth Casson Leighton wrote:
> On Tue, Jul 21, 2020 at 9:57 PM Paul Boddie <paul at boddie.org.uk> wrote:
> > OK, so the housing DT will contain the following for a VGA port...
> paul: quite late, here, more tomorrow.  summary strategy:
> * look at rbpi "hats" and how dtb overlays are done
> * copy that
> * rename rbpi "hat" overlay pins 0 to M to "eoma68 pins 1 to 68"

It would be useful to know where all these "hats" are defined. I found the 


A common theme seems to involve augmenting the gpio node from the chipset DT 
as follows (in the nicer syntax):

&gpio {
    some_pins: some_pins {
        brcm,pins = <...>;

Then, various other nodes are augmented, also with device-specific details.

> in theory that should be pretty much the entire job, bar removing all
> multiplexed options other than the 1 specialist function and the GPIO
> option.  where in rbpi base "hat" interface there would be up to 4
> multiplexed options per pin (one of which will be GPIO), that must be
> restricted to "GPIO" and "EOMA68 function", per pin.
> that really should be all.

Sorry, I just don't see how the overlays I found do this generically. All the 
node referencing is device-specific, although there is some aliasing done in 
"the firmware" for a limited number of nodes.

That works just fine with things like Raspberry Pi, but what we really need to 
see is what a device tree overlay looks like for a product that is used on 
multiple devices without needing to be customised for each one, if such an 
overlay exists.

The only thing I've found that seems to do pin aliasing is this:


Even then, there is some pretty liberal usage of what appear to be device-
specific node references alongside the pin aliases, but I guess it is a start.


More information about the arm-netbook mailing list