Hi Jason,

Thanks for your information.
I think we will use the U-Boot overlay method as you suggest.
I was comparing the table 
(https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#825-pin-usage.
 ) with the other sources.

Regards
Andrew

From: Jason Kridner [mailto:[email protected]]
Sent: 29 November 2017 15:44
To: [email protected]
Subject: Re: BBB GPIO Configuration Address Offset

Always CC [email protected]<mailto:[email protected]> 
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.
On Tue, Nov 14, 2017 at 7:19 AM anonymous individual wrote:
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.



--
https://beagleboard.org/about

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9DF5B455C748DB47BB4B5755AF415CAD55DEE640%40S3ID-RTH-EXC01.S3ID.
For more options, visit https://groups.google.com/d/optout.

Reply via email to