Are the 'modes' in the BBB documentation just history or what?

GoogleGroups
1

In the BBB System Reference Manual the P8 and P9 pinouts are
documented with 7 modes for each pin which provide different uses for
the pins.

All of the actual software and descriptions I can find about the BBB
hardware just talk about the Device Tree and Device Tree overlays. I
have already (sort) begun to understand the Device Tree system and I
have actually done a (trivial) recompile of the Device Tree to change
one of the I2C clock frequencies.

Do the modes in the manual have any relevance at all now? I.e. can I
actually start the system in a specified mode? Or are they just
history, or what?

2

cl@isbd.net writes:

In the BBB System Reference Manual the P8 and P9 pinouts are
documented with 7 modes for each pin which provide different uses for
the pins.

All of the actual software and descriptions I can find about the BBB
hardware just talk about the Device Tree and Device Tree overlays. I
have already (sort) begun to understand the Device Tree system and I
have actually done a (trivial) recompile of the Device Tree to change
one of the I2C clock frequencies.

Do the modes in the manual have any relevance at all now? I.e. can I
actually start the system in a specified mode? Or are they just
history, or what?

If you are writing a device tree you will need to refer to the pin modes
to configure the pinmux.

Cheers,

- Ben

3

OK, but I can't really find out *how* the PinMux/Modes are referred to
in the device tree. In fact it seems very difficult to find how the
entries in the Device Tree are mapped to the actual pins, I get the
feeling that it's actually rather simpler than it appears at first
sight but I'm still at the rather lost stage.

The other trouble is that if you look for 'how to enable the UARTs on
BBB' there are many ways of doing it:-

    Edit the device tree in /boot/uboot/dtbs - this will (as I
    understand it) remap things at boot time.

    Create a Device Tree Template for just the things to change, this
    'overlays' the Device Tree so is possible at run time (again, my
    understanding)

    Edit the uEnv.txt file, I assume this controls the above but it's
    far from clear.

I'd love to find a document or tutorial that describes how this all
hangs together but there doesn't seem to be anything other than the
(huge) processor documentation which is vey much reference material
and (as I referred to above) various blogs etc. showing how to do one
particular thing but without any attempt to explain it.

4

Hi Chris,

The BBB SRM gives information about the BBB, but doen't go into details
about the AM3358 processor. I'd suggest reading about pinmux in the
AM335x Sitara Processors Technical Reference Manual, which can be found
on the TI website. Basically, there are far more I/O features than
pins on the processor. Eight times more signals than pins to be
exact. The modes allow selection of which one of the eight for a pin
you choose to use. The TRM will provide the details on the mode that
enables a particular function for a specific pin.

Searching for "pinmux" will find many documents and tools.

Good luck.

Larry

5

[-- text/plain, encoding 7bit, charset: ISO-8859-15, 23 lines --]

cl@isbd.net writes:

> In the BBB System Reference Manual the P8 and P9 pinouts are
> documented with 7 modes for each pin which provide different uses for
> the pins.
>
> All of the actual software and descriptions I can find about the BBB
> hardware just talk about the Device Tree and Device Tree overlays. I
> have already (sort) begun to understand the Device Tree system and I
> have actually done a (trivial) recompile of the Device Tree to change
> one of the I2C clock frequencies.
>
> Do the modes in the manual have any relevance at all now? I.e. can I
> actually start the system in a specified mode? Or are they just
> history, or what?
>
If you are writing a device tree you will need to refer to the pin modes
to configure the pinmux.

OK, but I can't really find out *how* the PinMux/Modes are referred to
in the device tree. In fact it seems very difficult to find how the
entries in the Device Tree are mapped to the actual pins, I get the
feeling that it's actually rather simpler than it appears at first
sight but I'm still at the rather lost stage.

The other trouble is that if you look for 'how to enable the UARTs on
BBB' there are many ways of doing it:-

   Edit the device tree in /boot/uboot/dtbs - this will (as I
   understand it) remap things at boot time.

   Create a Device Tree Template for just the things to change, this
   'overlays' the Device Tree so is possible at run time (again, my
   understanding)

   Edit the uEnv.txt file, I assume this controls the above but it's
   far from clear.

I'd love to find a document or tutorial that describes how this all
hangs together but there doesn't seem to be anything other than the
(huge) processor documentation which is vey much reference material
and (as I referred to above) various blogs etc. showing how to do one
particular thing but without any attempt to explain it.

The pinmux section uses the register offset and in the attached
spreadsheet, that offset is related to the P8/P9 connector pins.

The right column defines how the pins are setup in the V3.15-bone5 device
tree.

Regards,
John

BBB Pinmux - 3.15.6-bone5.xlsx (20.3 KB)

6

Hmm, yes, I know the AM335x Sitara Processors Technical Reference
Manual is the ultimate reference but it is (as I said) an absolutely
huge document and is hardly the place to start if trying to gain an
understanding of this stuff.

I do understand the concept of multiplexing, it's hardly a new idea (I
cut my microprocessor teeth on 8080s, Z80s, 6502s and RCA 1802s) and
the BBB SRM points one in the direction of how it's used on the BBB.

However very, very few of the documents I've found give any clue at
all on how the ready made IO libraries (such as the Adafruit ones) or
the device tree itself control (or map onto) the MUX configurations.

MUX modes by issuing a write to a register somewhere, so the Mux modes
shown in the BBB SRM would then be directly selectable but this
doesn't seem to be the way the BBB works.

7

Thanks, but attachments don't work when using news group access to
gmane (or at least I don't think they do, I couldn't see anything).

Could you possibly point me at a URL for the spreadsheet or mail it to
me directly (E-Mail in header works).

8

In my custom audio cape device tree fragment the modes are setup like thus.

pinctrl-single,pins = <
0x1ac 0x00 /* mcasp0_ahclkx, OUTPUT | MODE0 /
0x194 0x20 / mcasp0_fsx, INPUT | MODE0 /
0x190 0x20 / mcasp0_aclkx, INPUT | MODE0 /
0x198 0x20 / mcasp0_axr0, INPUT | MODE0 /
0x1a8 0x20 / mcasp0_axr1, INPUT | MODE0 /
0x19c 0x02 / mcasp0_axr2, OUTPUT | MODE2 /
0x1a4 0x02 / mcasp0_axr3, OUTPUT | MODE2 */

;

[-- text/plain, encoding 7bit, charset: ISO-8859-15, 23 lines --]

cl@isbd.net writes:

In the BBB System Reference Manual the P8 and P9 pinouts are
documented with 7 modes for each pin which provide different uses for
the pins.

All of the actual software and descriptions I can find about the BBB
hardware just talk about the Device Tree and Device Tree overlays. I
have already (sort) begun to understand the Device Tree system and I
have actually done a (trivial) recompile of the Device Tree to change
one of the I2C clock frequencies.

Do the modes in the manual have any relevance at all now? I.e. can I
actually start the system in a specified mode? Or are they just
history, or what?

If you are writing a device tree you will need to refer to the pin modes
to configure the pinmux.

OK, but I can’t really find out how the PinMux/Modes are referred to
in the device tree. In fact it seems very difficult to find how the
entries in the Device Tree are mapped to the actual pins, I get the
feeling that it’s actually rather simpler than it appears at first
sight but I’m still at the rather lost stage.

The other trouble is that if you look for ‘how to enable the UARTs on
BBB’ there are many ways of doing it:-

Edit the device tree in /boot/uboot/dtbs - this will (as I
understand it) remap things at boot time.

Create a Device Tree Template for just the things to change, this
‘overlays’ the Device Tree so is possible at run time (again, my
understanding)

Edit the uEnv.txt file, I assume this controls the above but it’s
far from clear.

I’d love to find a document or tutorial that describes how this all
hangs together but there doesn’t seem to be anything other than the
(huge) processor documentation which is vey much reference material
and (as I referred to above) various blogs etc. showing how to do one
particular thing but without any attempt to explain it.

9

>
>I'd love to find a document or tutorial that describes how this all
>hangs together but there doesn't seem to be anything other than the
>(huge) processor documentation which is vey much reference material
>and (as I referred to above) various blogs etc. showing how to do one
>particular thing but without any attempt to explain it.
The pinmux section uses the register offset and in the attached
spreadsheet, that offset is related to the P8/P9 connector pins.

The right column defines how the pins are setup in the V3.15-bone5
device
tree.

Thanks, but attachments don't work when using news group access to
gmane (or at least I don't think they do, I couldn't see anything).

Could you possibly point me at a URL for the spreadsheet or mail it to
me directly (E-Mail in header works).

To explain how the spreadsheet works:

If you look at the AM335x TRM, start with the CONTROL_MODULE Registers in
Section 9.3.1. The first I/O pin is conf_gpmc_ad0 which is at offset 800h,
but the pinmux in the device tree defines this as address 0h so you always
have to subtract 800h from the offset from this table. On the right
column, you will see a reference to 9.3.1.50 which defines the mode, pull
up, pull down, etc. Now you have to use either the schematic or the BBB
SRM to map the processor pin (conf_gpmc_ad0) to a board connector pin
(P8_25).

Regards
John

10

Here is a nice spreadsheet

http://www.embedded-things.com/bbb/beaglebone-black-pin-mux-spreadsheet/

11

I hadn’t googled for “pinmux” for a while:

http://roshan.info/blog/2014/03/03/beaglebone-black-pinmux-and-dts-helper/

12

and of course:

https://github.com/cdsteinkuehler/beaglebone-universal-io

13

I think the fundamental thing that I hadn't grasped until now is that
each individual IO pin can be multiplexed independently. From the
way that the BBB manual shows the pinouts it seemed (to my old
fashioned hardware knowledge) that one had to select one of the eight
MUX settings and that would define what all the pins do.

Now that I realise one can MUX each pin things begin to make a bit
more sense (at least I hope they do and that I have this right!).

14

>> >
>> >I'd love to find a document or tutorial that describes how this all
>> >hangs together but there doesn't seem to be anything other than the
>> >(huge) processor documentation which is vey much reference material
>> >and (as I referred to above) various blogs etc. showing how to do
one
>> >particular thing but without any attempt to explain it.
>> The pinmux section uses the register offset and in the attached
>> spreadsheet, that offset is related to the P8/P9 connector pins.
>>
>> The right column defines how the pins are setup in the V3.15-bone5
>>device
>> tree.
>>
>Thanks, but attachments don't work when using news group access to
>gmane (or at least I don't think they do, I couldn't see anything).
>
>Could you possibly point me at a URL for the spreadsheet or mail it to
>me directly (E-Mail in header works).
To explain how the spreadsheet works:

If you look at the AM335x TRM, start with the CONTROL_MODULE Registers
in
Section 9.3.1. The first I/O pin is conf_gpmc_ad0 which is at offset
800h,
but the pinmux in the device tree defines this as address 0h so you
always
have to subtract 800h from the offset from this table. On the right
column, you will see a reference to 9.3.1.50 which defines the mode,
pull
up, pull down, etc. Now you have to use either the schematic or the BBB
SRM to map the processor pin (conf_gpmc_ad0) to a board connector pin
(P8_25).

I think the fundamental thing that I hadn't grasped until now is that
each individual IO pin can be multiplexed independently. From the
way that the BBB manual shows the pinouts it seemed (to my old
fashioned hardware knowledge) that one had to select one of the eight
MUX settings and that would define what all the pins do.

Now that I realise one can MUX each pin things begin to make a bit
more sense (at least I hope they do and that I have this right!).

Correct