<vd>
hi there -- I have trouble understanding how to enable devices in the device tree with an upstream kernel
<vd>
As a simple example, I have an I2C EEPROM wired on I2C2_* pins with GPIO1_17 wired to its WP. Can someone walks me through the steps required to add support for this device?
ikarso has quit [Quit: Connection closed for inactivity]
<vd>
I guess I have to enable the "I2C mode" for the related pins but that's where I'm failing
<zmatt>
the top four address bits are fixed at 1010 so the address will always be within range 0x50-0x57
<zmatt>
(also, 0x00-0x07 are not valid i2c addresses)
<zmatt>
(valid i2c addresses are 0x08-0x77)
<vd>
the top four address bits are hardcoded by the SoC ?
<zmatt>
by the eeprom
<zmatt>
by this particular eeprom
<vd>
ho ok
<vd>
EEPROM_WP is wired to P9_23
<vd>
what is the 7 arg of PIN_PULL() ?
<zmatt>
then obviously declare that pin, as well as the appropriate gpio
<zmatt>
mux mode
<zmatt>
note btw that these macros are specific to overlay-utils
<zmatt>
if you use bb.org-overlays you need to use its macros instead, which are uglier and more verbose ;)
<zmatt>
mux mode 7 is always gpio (for all pins that have gpio mode)
<vd>
ho ok, I'm using the TI kernel which have no bb.org stuffs, so upstream kernel
<zmatt>
overlay support is u-boot, not kernel
<zmatt>
but if you mean you're using a custom DT rather than an overlay then you'll either need to use mainline macros (or just put the macros of overlay-utils into the include path too)
<vd>
I use barebox and a custom DT which #include "am335x-boneblack.dts"
<zmatt>
okay well then you'll probably want to use mainline pinmux macros I guess :P
<vd>
zmatt the eeprom datasheet says "The CAT24C256 is a EEPROM Serial 256−Kb I2C, internally organized as 32,768 words of 8 bits each.", so shouldn't address-width be <8> maybe?
calculus has quit [Ping timeout: 250 seconds]
<zmatt>
no
<zmatt>
so, I don't know if address-width is needed at all... like, I don't understand why it's a setting since it'd normally be implied by the compatible-string
<zmatt>
but Documentation/devicetree/bindings/eeprom/at24.yaml seems to imply its default is 8 so I explicitly set it to 16 (i.e. two address bytes) just to be safe
<vd>
ok
<zmatt>
these eeproms use one or two address bytes, and sometimes occupy multiple consecutive slave addresses (effectively using up to 3 slave address bits as additional address bits)
<zmatt>
the "word size" is always 8 bits since i2c transfers data in units of bytes
<vd>
so you can declare as many pinmux nodes inside the am33xx_pinmux nodes, but it doesn't mean they will be enabled, you have to reference them from within another node with the pinctrl-* properties
<zmatt>
yes
<zmatt>
you reference them from the device for which those pins are being configured
<zmatt>
some devices may also have multiple states with different pinmux for each, but most commonly there's only a "default" state
calculus has joined #beagle
<vd>
I see
<vd>
Isn't the MUX_MODE the number in brackets in the BBB_SCH.pdf datasheet? e.g. GPIO1_29 [3]
<vd>
some pins have several though, e.g. LCD_DATA5 [4,6,10]
<zmatt>
those are page numbers of the schematic
<zmatt>
where you can find that signal
<vd>
lol ok
<vd>
how do you figure out the mux mode?
<zmatt>
well like I said, gpio is always mux mode 7, but in general which functionality is available on which mux modes of which pins can be found in the datasheet or various overviews, such as the P9/P8 tabs of my pins spreadsheet (https://goo.gl/Jkcg0w#gid=1775283126) if you want a concise overview, or the BBB tab of that same spreadsheet if you prefer a flat list
<zmatt>
the F0-F6 columns indicate the functionalities found on mux modes 0-6 of those pins
<vd>
zmatt so this is what I need to enable my eeprom on upstream kernel which has its WP pins wired to P9_23? http://ix.io/3xfw
<zmatt>
looks plausible enough
<zmatt>
god I hate those AM335X_PIN_GPMC_A1 macros with a fiery passion... naming pins after some random function that isn't the function you're actually using it for sucks, it's just confusing
<vd>
zmatt I cannot agree more, it's painful to follow the datasheet to find the mapping P9_24 -> GPIO1_17 -> GPMC_A1 -> some mux mode (still unclear to me)
<zmatt>
the BBB page of my spreadsheet (https://goo.gl/Jkcg0w#gid=698174264) includes every identifier you could possibly need
<zmatt>
it also has some filter views (under Data -> Filter views) to e.g. sort by gpio
<zmatt>
or by expansion header pin
<vd>
zmatt your spreadsheet is incredible
<zmatt>
:D
vagrantc has joined #beagle
<vd>
I can read the eeprom, thanks!!!
<vd>
I have now to do the same for the i2c rtc, the touchscreen, uarts and chained USB hubs...
<zmatt>
fun fun fun
<vd>
zmatt thanks a lot for your help
Guest71 has joined #beagle
<Guest71>
Hi, I am looking to install ros noetic on the bealgebone blue. I have come into some issues with trying to download the correct software for it. I want to run my beaglebone with ubuntu 20.04+ with ros noetic and be able to install a gui that I can access with tight vnc. I tried using the ROS image provided on the bealgebone website, however this is
<Guest71>
an old version of both ubuntu and ros and won't let me install a gui. Does anyone know where to start looking for a version of ubuntu compatible with the bealgebone blue's armhf architecture? Thanks for your help : D
<zmatt>
why would you run a gui *on* the beaglebone?
<Guest71>
use a camera
<zmatt>
that doesn't answer the question, and in fact makes it even more questionable
<Guest71>
so I can use a camera and opencv and see that my program is working properly and be able to debug it if its not
<zmatt>
oof, this sounds really heavy for a beaglebone
<zmatt>
and then have vnc reencode the screen capture and transmit it via the network... that sounds like it'll be a slide-show, but maybe I'm just being overly pessimistic
<Guest71>
I was working with the newley released debian image. And yea it was a slideshow lol but non the less I want to try it out
<Guest71>
I was looking to trying to just run ros on the bealge, but I was reading that I needed ubuntu to get it to work right with catkin
<zmatt>
weird, why?
<zmatt>
I should note, I don't actually know anything about ros
<zmatt>
but debian and ubuntu are really similar
<zmatt>
normally anything that runs on ubuntu also runs on debian
<Guest71>
someone said on one of the ros fourms that, "armhf binaries are for Xenial only" I'm not sure what this means but I think it has something to do with ubuntu.
<zmatt>
that sounds more like "we couldn't be assed to build separate armhf packages for debian, nor test whether the Xenial packages work on debian"
<zmatt>
(Xenial is Ubuntu 16)
<zmatt>
xenial is pretty old btw, corresponds to debian stretch
<vd>
zmatt like i2c2, i2c1 is the default mode as well?
<vd>
for i2c2 with my eeprom you said that it was the default and indeed I didn't have to do anything to use I2C
<zmatt>
i2c2 on P9.19+20 is setup in the base dts yes
<zmatt>
for the beaglebone black
<vd>
ok, so I was asking if it was the same for i2c1
<zmatt>
no
<vd>
ha!
<zmatt>
the only other pins that are configured are those in use by eMMC and HDMI video/audio (since I think the base dts you mentioned enables all of these, on current official beagleboard.org images those are separated into overlays instead)
<zmatt>
none have default pinmux nodes, since there's almost always multiple different pinmux options for each peripheral
<zmatt>
and in fact, the example I linked to explicitly mentions there are two pinouts available for i2c1 on the BBB expansion headers alone
<zmatt>
(the am335x has two more pinouts for i2c1 that aren't available on the BBB expansion headers)
<zmatt>
you can see which pinouts are available for specific peripherals on the Signals tab of my spreadsheet: https://goo.gl/Jkcg0w#gid=205184135
<vd>
ok so any node for devices wired on the expansion headers must have pinctrl* propeties
<zmatt>
any device that uses onr or more processor pins needs an associated pinmux node
<zmatt>
*one or more
<zmatt>
this is true regardless of whether you create the device node yourself or it's predefined by am33xx.dtsi and you merely enable it using status="okay"; (which undoes the status="disabled"; set on the predefined node)
<vd>
ok
<vd>
erf I feel stupid, there was already a cape_eeprom0 node defined for an at24 on i2c2 @ 54...
<zmatt>
oh yeah I guess those do indeed exist, for CAPE autodetection
<vd>
even though there's no upstream support for it
<vd>
but I guess it's common enough to find eeprom on i2c2 so it landed into mainline
<zmatt>
it's done by u-boot
<zmatt>
so these nodes are just so userspace can list which capes are attached
<zmatt>
if unwanted you can remove them in your .dts using /delete-node/ directives
<vd>
the daughter board wasn't mean to be used as a cape, nor is u-boot or bb.org used. Would you edit &cape_eeprom0 or add your own eeprom@54?
<zmatt>
doesn't matter hugely, I'd probably disabled all four cape_eeprom nodes
<vd>
&cape_eeprom0 { /delete-node/ }; ?
<zmatt>
&i2c2 { /delete-node/ cape_eeprom0@54; }
<zmatt>
;
<vd>
ok
<vd>
zmatt: so for the rtc on i2c1, I must also define i2c_pins in the am33xx_pinmux node? There's not already such definition I can use/enable?
starblue2 has joined #beagle
<zmatt>
the i2c1 bus itself needs a pinmux node
<zmatt>
devices that sit on that i2c bus do not, unless they have additional device-specific pins, such as an interrupt line
<zmatt>
or, for example, a wp gpio
<vd>
yes
<vd>
but the am33xx.dtsi or whatever base file doesn't define the i2c1 pins for convenience?
<zmatt>
no, I already addressed that
<vd>
ok sorry I was a bit confused
<zmatt>
especially since, as I already said, there are multiple pinouts available for i2c1
<vd>
I would have imagine the i2c1_pins already defined but somehow unused, instead of letting the user redefine the AM33XX_PADCONF thingy
<zmatt>
so there's no such thing as _the_ i2c1 pins
<vd>
hum, okay
Guest71 has quit [Quit: Client closed]
Guest45 has joined #beagle
calculus has quit [Ping timeout: 240 seconds]
calculus has joined #beagle
Shadyman has joined #beagle
<vd>
zmatt ho do I know if I should use PIN_INPUT, PIN_INPUT_PULLUP or PIN_INPUT_PULLDOWN?
<vd>
how*
<zmatt>
depends on your hardware situation, though it often doesn't matter hugely
<zmatt>
the primary purpose of internal pull is to keep unconnected pins from floating
<zmatt>
normally if I don't know what to choose, I use whatever is the reset default, since the hardware _ought_ to be designed with that default in mind anyway, since it is the reset default
<zmatt>
though may be specific reasons to use something different
<zmatt>
if there's an external pull-up or pull-down on that net, you should not contradict that with internal pull... in that case I'd configure internal pull in the same direction as external pull
<vd>
they are connected to 3v3, is that PIN_INPUT_PULLUP then?
<zmatt>
if a pin is always being driven strongly (either by the SoC or by external hardware) then internal pull has no effect and disabling it saves a tiny bit of power, though I'd personally still use the reset-default pull for cases where the bbb is booted without the external hardware connected
<zmatt>
what do you mean by "connected to 3v3"
<zmatt>
like, it makes no sense to literally connect it directly to 3v3, so I assume you meant something different than what you just said
<zmatt>
if you mean they have external pull-up then yes I'd use PIN_INPUT_PULLUP
<zmatt>
note btw that "INPUT" vs "OUTPUT" in these macros does not mean what you might think it means (which it why I removed it from my pinmux macro names) .. PIN_INPUT means "input enabled", PIN_OUTPUT means "input disabled" (always perceived as low by the processor)... the setting has no impact on the output-driver, which is always under control of the peripheral selected by the mux mode
<zmatt>
so PIN_INPUT is always safe to use and is required for input-only pins, input/output pins, and even some output-only pins (such as spi sclk)
<zmatt>
while PIN_OUTPUT is merely a power optimization in cases where the input-receiver for that pin is unused
calculus has quit [Ping timeout: 240 seconds]
<vd>
interesting!
calculus has joined #beagle
<vd>
also I'm grep'ing i2c1 in arch/arm/boot/dts/am335x-* and they don't have the same clock-frequency. How do I figure this out?
<zmatt>
and yes (re: the image you sent) those nets have external pull-ups so I'd recommend using PIN_INPUT_PULLUP
<zmatt>
which is also the reset default for those pins, so it also matches my other general advice for configuring internal pull
<zmatt>
clock-frequency is up to you, though common choices are 100 kHz ("standard i2c") and 400 kHz ("fast i2c")
<zmatt>
if there's nothing particularly performance-sensitive on the i2c bus I'd just stick with 100 kHz
<zmatt>
but you can try using 400 kHz if you've verified that all devices on the bus support it, and you feel like the extra performance may be useful
<zmatt>
higher clock frequency puts tighter design requirements on the pcb
<zmatt>
btw, is there are specific reason you've put the rtc and eeprom on separate i2c buses?
calculu5 has joined #beagle
calculus has quit [Ping timeout: 240 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
<vd>
zmatt I really don't know, that is an existing system I'm re-writing the device tree for. I have absolutely no clue why there is an rtc on i2c1
<zmatt>
heh, fair.
<vd>
zmatt there's a similar 3v3 link on the eeprom wp, should I use something different that PIN_OUTPUT?
<zmatt>
the term (for a connection between a net and a supply via a resistor) is a "pull-up"
<zmatt>
and you could use PIN_OUTPUT or PIN_OUTPUT_PULLUP or PIN_INPUT_PULLUP it doesn't really matter
<zmatt>
I guess I'd use _PULLUP just in case but it's really not super important
<set_>
jduchniewicz: Thank you for your input earlier. I will try it out. Who knows what type of properties I can gather and force to give back data?
<set_>
Oh and this is about TF.lite in case you were wondering...
<set_>
I know it. I just forgot to understand again.
<set_>
BBAI and am5729!
<set_>
Neat.
<set_>
Well, I should do a write up so this board gets its proper due.
<set_>
I made a write up a couple years back and cv2 already changed its ideas. now, my info. is bunk.
<set_>
some of the time, things are priceless. Other times, things break. Now, I know.
<set_>
Anyway, @zmatt and vd, I was not trying to interject. I just wanted to reply to the person that gave info. on his/her ideas w/ the TF.lite.
<set_>
I know you guys are being serious. I am just goofin' w/ TF.lite for a nice write up. Points!
<set_>
Ha.
<set_>
Let me say this, though, please. W/out goofin' around w/ the boards your .org produces, I would know less of math, science, articulation, and Computational Power.