Device-Tree Clarifications (Beaglebone Black)

[tzi...@gmail.com]

The starting point for my questions is the BB-SPIDEV0-00A0.dts.

1. Description of problem:

The following fragment was taken from the above device tree spec:

fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            /* default state has all gpios released and mode set to uart1 */
            bb_spi0_pins: pinmux_bb_spi0_pins {
                pinctrl-single,pins = <
                    0x150 0x30  /* spi0_sclk.spi0_sclk, INPUT_PULLUP | MODE0 */
                    0x154 0x30  /* spi0_d0.spi0_d0, INPUT_PULLUP | MODE0 */
                    0x158 0x10  /* spi0_d1.spi0_d1, OUTPUT_PULLUP | MODE0 */
                    0x15c 0x10  /* spi0_cs0.spi0_cs0, OUTPUT_PULLUP | MODE0 */
                >;
            };
        };
    };

The fragment configures the P9.17, P9.18, P9.21, P9.22 pins to Mode 0 for the SPI driver. I'm also aware of the table P9 Header table with the offset addresses of the pins and the AM335x Sitara Processors Technical Reference Manual (Rev. M) with information on how to configure the CPU registers.

My problem is that the addresses in the device tree fragment above do not match the addresses in the Reference Manual.

In the fragment above the offset addresses are: 0x150, 0x154, 0x158 and 0x15c. In the Reference Manual Chapter 9.3 page 1372 the offset addresses are: 0x950, 0x954, 0x958, 0x95c.

Question: Can someone help me understand where are the addresses from the fragment taken/obtained/calculated from?

2. Description of problem

The following fragments were taken from the above device tree specification:

...
fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
...

...
    fragment@1 {
        target = <&spi0>;   /* spi0 is numbered correctly */
        __overlay__ {
...

I could not find on the web what is the functionality of the target property in a device tree. I'm somehow familiar with the aliases concept. So I think &am33xx_pinmux and &spi0 are aliases for "something". However there is nothing defined in the device tree specification above.

Questions:

What is the functionality/role of the target property? Where are the &am33xx_pinmux and &spi0 defined and what do they mean?

I would also appreciate some links/references if available, so I can further read.

I'm also interested if there is a list with all the aliases for BeagleBone Black.

[Robert Nelson]

On mainline, we recently switched to the "0x950" address vs "0x150",
via the AM33XX_IOPAD macro:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?id=e03b2a26d6bf93d1631aa36985892877986ee7b9

old + 0x800 = offsets shown in reference manual..

>
> 2. Description of problem
>
> The following fragments were taken from the above device tree specification:
>
> ...
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> ...
>
> ...
> fragment@1 {
> target = <&spi0>; /* spi0 is numbered correctly */
> __overlay__ {
> ...
>
> I could not find on the web what is the functionality of the target property
> in a device tree. I'm somehow familiar with the aliases concept. So I think
> &am33xx_pinmux and &spi0 are aliases for "something". However there is
> nothing defined in the device tree specification above.
>
> Questions:
>
> What is the functionality/role of the target property? Where are the
> &am33xx_pinmux and &spi0 defined and what do they mean?

The "target" is where the overlay will either append or add data to
the existing device tree.

am33xx_pinmux:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi?id=refs/tags/v4.7-rc3#n64

Whereas spi0, is adding to the base, as that doesn't exist.

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Micka]

Why did we switch to the macro AM33XX_IOPAD  ?

What is the advantage doing so ? By curiousity

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhWx9Ya8jGUjmkn4HthnW-u14V53S1ksM68fpACNMQ4mg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Fri, Jun 17, 2016 at 9:23 AM, Micka <micka...@gmail.com> wrote:
> Why did we switch to the macro AM33XX_IOPAD ?
>
> What is the advantage doing so ? By curiousity

We switched, such that the random magic #'s now match TI's reference manual..