Always CC beagleboard@googlegroups.com when e-mailing me a support question, otherwise your e-mail is 99.994% sure to go into the dustbin. I’ve taken the liberty of putting you in BCC and removing identifying information in order to provide you with a response that I believe might benefit both you and the community.
Hi Jason,
I am trying to develop a circuit using the BBB for a simple application and I wanted to store the GPIO usage settings in a cape EEPROM.
The issue I have is there are three sources of data for the offsets as follows…
Note that the individual pin settings stored in the cape EEPROMs are currently ignored in our community reference images (ie., https://beagleboard.org/latest-images). This is because we began a process of integrating device tree overlays to handle capes such that you didn’t just get pin configurations, but also got the appropriate device drivers loaded as well. More recently, we’ve moved that support from the kernel into u-boot.
The process now works by looking at the name of the cape and identifying the proper device tree overlay to load based on the name.
A recent set of overlays and issues can be found at https://github.com/beagleboard/bb.org-overlays. There is also a local clone of this repository on the board images at /opt/source/bb.org-overlays such that you can rebuild and test prior to submitting your overlay to our github repo.
The BBB SRM originally by Gerald Coley and updated only a few weeks ago by you – https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
Drerek Molloy’s notes… http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/ which is confirmed by the attached
and GIT Hub setting up GPIO pins https://vadl.github.io/beagleboneblack/2016/07/29/setting-up-bbb-gpio
… and the SRM conflicts with the other sources.
For instance, The SRM gives offset for GPIO_66 [TIMER4 pin P8,7] as 170(decimal) or 0x0AA (hex).
The other sources all give this offset as 0x090 (hex) or 144(decimal).
I believe https://github.com/beagleboard/beaglebone-black/issues can be a good location to file issues related to https://github.com/beagleboard/beaglebone-black/wiki.
Can you be specific about the location in the SRM?
I’ve been working on incorporating a master set of AM335x pin utilization information into BoneScript and have some data on this pin in particular (https://github.com/jadonk/bonescript/blob/master/src/bone.js#L204). I have it as 0x90.
To provide a slightly more definitive answer, you can look at the ball in the schematic (R7) and look it up at https://dev.ti.com/pinmux (using AM335x with the ZCZ package). If you hover over R7, you’ll see it is GPIO2[2]. You can then go and add a GPIO bank, force it to bank 2 and select only GPIO 2 in that bank to be enabled. You can then look at the generated devicetree.txt as I did below and confirm the mux control register is at 0x90:
/* This file was auto-generated by TI PinMux on 11/29/2017 at 10:33:54 AM. /
/ This file should only be used as a reference. Some pins/peripherals, /
/ depending on your use case, may need additional configuration. */
mygpio1_pins_default: mygpio1_pins_default {
pinctrl-single,pins = <
0x90 ( PIN_INPUT | MUX_MODE7 ) /* (R7) gpmc_advn_ale.gpio2[2] */
;
};
/* Optional sleep pin settings. Must manually enter values in the below skeleton. /
mygpio1_pins_sleep: mygpio1_pins_sleep {
pinctrl-single,pins = <
0x90 ( ) / (R7) gpmc_advn_ale.gpio2[2] */
;
};
I therefore went looking for any reference you are making in the SRM and found https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#825-pin-usage.
You should note that the offsets in this table are not meant to be the same as the register offsets within the AM335x. They are offsets within the EEPROM where the mux register information is meant to be stored. As I mentioned earlier in this e-mail, however, they are completely ignored.
The discrepancy is not even the same across the range.
The SCL and SDA pins are shown with inverted offset in the two sources.
You misinterpreted the meaning of that table, if that is the table to which you are referring. Perhaps it should be removed entirely to avoid this confusion. I’ve left it there as some legacy information in case we ever did decide to implement the original vision of taking pinmux configuration data from the EEPROM table. Instead, as mentioned, we are taking the pinmux configuration information from the device tree overlays instead and the only significant information in the EEPROM regarding which device tree overlay is selected are the name and the version.
I can see that the SRM has 2 byte offset steps and the other reference 4 byte steps, also that the start offset (lowest number) is zero not 58(dec) for the other data sources but beyond that I am a wee bit lost.
The offsets do not even run in order
Can you shed any light and explain why there is the discrepancy please.
I have compiled the attached excel wb “BBB GPIO Offset Comparison” for illustration.
I believe I’ve not sufficiently explained the discrepancy above. Perhaps a resolution would be to add the AM335x mux register offset into the same table using the information you provided?
Please provide your specific feedback here to the list or report an issue on the beaglebone-black github repo.