<Guest4494>
Is it possible to use P8_7 and P8_9 as regular gpio pins? If so, to make this happen do I need to create a custom device tree overlay file?
<set_>
Hello Guest4494: Have you tried config-pin yet?
<set_>
I just plugged in. i will attempt config-pin.
<Guest4494>
Hi set_, no I haven't but I'm not using the stock debian. I'm building my own buildroot image, so I don't have config-pin.
<set_>
Oh.
<set_>
Um, I just tried via config-pin on the BBB. p8.7/9 does not configure correctly on my board. Hmm. I wonder what is going on?
<Guest4494>
Though the pinout diagram I have for the BBB shows 7 & 9 as gpios, I think their default mode is something else (timer?).
<set_>
Dang it. I have a Cape on my board. Let me test another board.
<set_>
Hmm. Maybe. That is one of the ways someone can use that pin.
<set_>
i.e. for p8.7, timer is one use of that pin.
<set_>
Hmm. Maybe so. @zmatt will probably need to direct you then if you are using his ideas and use cases.
<set_>
W/ Buildroot, have you installed Cape-Universal somehow?
<set_>
If so, okay. If not, okay. It is probably more complicated than just writing an overlay for those specific pins.
<set_>
I do not know what beagleboard.org peoples have done for handling those pins. I will go and search.
<Guest4494>
No, but it does use am335x-boneblack.dts as part of its default for the DTB it builds, so most of the things one gets with Debian on BBB are the same.
<Guest4494>
I meant, no, I don't have cape-universal in my buildroot image.
<set_>
Oh. I see in am335x-bone-common-universal.dtsi, there are calls to the node.
<set_>
Currently, I cannot help b/c I have no clue as to what they are doing right now w/ those pins.
<set_>
Oh! Do you have a uEnv.txt file or are you just building w/out it?
<Guest4494>
That's interesting, because I've got the #include am335xx-bone-common.dtsi commented out. But that's not the same as am33x-bone.common-universal.dtsi.
<Guest4494>
Buildroot does create a uEnv.txt but I'm not using it.
<set_>
Oh. Let me go and search the am335x-bone-common.dtsi file. And okay about the uEnv.txt file.
<Guest4494>
Perhaps I should. Currently, I just create a fat partition, put MLO, kernel, DTB, rootfs, and u-boot.img file on it, and create a extlinux/extlinux.conf file there, too.
<set_>
Nice.
<set_>
I used to do more than not but that was a while back.
<set_>
I was unaware of uEnv.txt being built. That makes me what to build again.
<set_>
I also saw there is a am335x-bone-common-univ.dtsi that calls am335x-bone-pins. I think w/ *** bone *** in /dev/, people now want specific things to work for now. I am not quite sure, i.e. as I am not a full-fledged member or anything like that idea.
<set_>
The am335x-bone-pins file is a .h file. This file may provide some support.
<Guest4494>
I tried using https://kilobaser.com/beaglebone-black-device-tree-overlay-generator/ which will generate a dts file for a pin to be gpio or whatever one wants. I generated a dts file for 7 & 9, put them into my custom dts file, and buildroot seems to successfully build a new dtb file from it. But when I tried to boot, the kernel, rootfs, and dtb
<Guest4494>
are all loaded, but when the kernel then tries to execute, it crashes after several seconds, triggering a reboot.
<Guest4494>
That web page is fairly old I think. May not be accurate anymore (?).
<set_>
Odd. I tried it a long time ago. I never got it to work well enough b/c of what goes on currently w/ the beagleboard.org persons and their community.
<set_>
I think the BONE ideas are ways to simplify the execution of specific source w/ said peripherals.
<Guest4494>
I'm not familiar enough with dts files to know if what it produces is currently valid.
<set_>
Me neither...really. It is not easy, i.e. esp. w/ so many files out there currently.
<set_>
Tracking down the current file and its directives gets time consuming. It works in the end but one would have to have a good memory and lots of notes.
<set_>
Guest4494: Try the USB to TTL converter cable for seeing what is going on in your kernel build when it breaks...
<set_>
This is a good idea too.
<Guest4494>
Do you mean for a serial console?
<set_>
There are some smart people who enjoy assisting in kernel panic or kernel _____ ideas.
<set_>
Sort of...but it is a way to view your u-boot and kernel starting instantiation.
<set_>
Those, UART0, headers on the BBB for exactly that...
<Guest4494>
I've got a usb-to-ftdi cable plugged into header (6-pin). So, I see the u-boot messages, I can see the kernel et al being loaded into memory, and then the kernel being started. But there's no dump when it fails.
<set_>
Right. Keep the terminal open. C & P it to pastebin.com or another paste service.
<set_>
Someone may provide some support. I do not know everything you are going through right now but it may, the output, provide some ideas to me so I can further assist.
<set_>
Also...
<set_>
Guest4494: Try line by line searching to learn about what exactly is taking place in your output.
<set_>
That is an awesome way to learn more about what exactly is taking place.
<set_>
brb
<set_>
Guest4494: Are you willing to try to give the output of the boot log?
<Guest4494>
I can, but there's not really any output once the kernel starts executing. Hang on, I'll pastebin it...
<Guest4494>
It will sit for about 20 seconds at that last line, and then it will just start over again. So, no real output indicating what is wrong.
Shadyman has joined #beagle
<set_>
This file.../rootfs.cpio.uboot is labeled like this idea or is it labeled like /rootfs.cpio ?
<set_>
or does it even matter? Have you tried to stop u-boot to prompt specific commands?
<zmatt>
Guest4494: "cape-universal has some sort of conflict on P8_7/8/9/10" ... cape-universal conflicts with literally everything you do in a device-tree that uses pins, since it makes all unused pins runtime-configurable. that presumably doesn't matter if you're using buildroot since you don't have cape-universal
<zmatt>
there's nothing special about P8.07-10, they're normal pins
<Guest4494>
Oh, hi zmatt. Ok, that would seem to simplify things a bit.
<Guest4494>
Here's one of the sections I added to my dts file to try to make P8_7 act as a regular gpio: https://pastebin.com/Kf23mVbW
<zmatt>
Guest4494: this is source code for an overlay, I hope you didn't just paste that into a main device tree because that would be pretty bad
<Guest4494>
As mentioned above, buildroot builds it, but when I try to boot with it and the new kernel BR generates with it, it hangs for about 20 seconds when the kernel begins executing, but then just restarts
<Guest4494>
I did. I'm not good enough with dts files to be know how they would be different.
<Guest4494>
I did suspect that might be part of the problem, but was uncertain (and thus why I'm here. ;-))
<zmatt>
this still won't work for you, but at least it shouldn't completely break your DT
<zmatt>
bone-pinmux-helper is an out-of-tree driver that's presumably not part of your kernel.
brook has joined #beagle
<zmatt>
however, what this snippet does isn't really needed anyway since these pins (indeed almost all pins) default to gpio mode
<Guest4494>
Including P8_7 and P_9?
<Guest4494>
P8_9, that is.
<zmatt>
yes
<zmatt>
all digital I/O on P8 and P9 that isn't already in use by a kernel device will default to gpio mode
<zmatt>
to inspect your pinmux state at runtime, see if my show-pins utility works: https://github.com/mvduin/bbb-pin-utils/#show-pins I've never tested it on a mainline kernel, but I think it should work
<Guest4494>
Hmm, maybe there's another way to solve this: I just went back to the code I wrote ~6 months ago. It's still using Adafruit_BBIO.GPIO to control the pins, and it's failing to toggle P8_7 & P8_9. This was before you suggested using iio instead, which I did, but not on this project that I'm now revisiting. But I *can* toggle 7 & 9 via sysfs.
<Guest4494>
Perhaps I'll try it with iio instead, just to see if there's a difference. I know Adafruit_BBIO is getting a bit long in the tooth.
<zmatt>
I suggested iio? iio is for using the ADC, not gpio
<zmatt>
sysfs is how you control gpio
<Guest4494>
Yes, you did, and it worked great. But that was for the ADC.
<zmatt>
(there's also a newer API for gpio but it kinda sucks so I'd still recommend using sysfs gpio)
<Guest4494>
Yeah, I think I looked at that API; syntax seemed...a bit odd.
<zmatt>
my problem isn't with its syntax but with its semantics :P
<Guest4494>
Well, if sysfs is the way to go, I can do that. Feels a bit funny in python, but whatever.
<zmatt>
how does it feel "funny" ?
<Guest4494>
Having to deal with file handles and such instead of just object methods or function calls. But that's probably just me.
<Guest4494>
I'll just end up creating my own class to abstract the file stuff anyway. I get spoiled because most everything I tend to want to do, someone else has already done and done better than I would, so I try to not re-invent the wheel.
<zmatt>
I mean, with pathlib it can be literal one-liners.... Path('/sys/class/gpio/gpioN/value').write_text('0') ... that's not very efficient, but then again python isn't very efficient in general ;)
<zmatt>
for more efficiency you'd want to keep an open file handle, like https://pastebin.com/UwDFNb9Z (this example doesn't deal with initializing the direction of the gpio, just with getting/setting the value)
<zmatt>
(note: the '/dev/gpio' on line 10 is for people like me who use udev to create symlinks for gpios in that location, that doesn't apply to you with buildroot but it doesn't affect using this class with gpio numbers)
<Guest4494>
Thanks for that. I've got something similar that I suspect I partially stole from you/from one of your pastebins last summer when I was last working on this particular project.
<set_>
Hey.
<set_>
What does the buffering=0 mean in that source?
<zmatt>
it disables buffering, creating a raw filehandle where read and write correspond directly to calls to the kernel (which is definitely what you want in this case)
<set_>
Oh.
<set_>
Nice.
<set_>
No buffering, i.e. buffering=0.
<set_>
So, it is like using system calls in C?
<zmatt>
yes
<set_>
Hmm. That is neat. So, is that what decorators do?
<set_>
Oh! I see decorators are used to call the function, too.
<set_>
either from the current file or a multitude of files, decorators can do it!
<zmatt>
??
<set_>
I was reading about decorators some more just now.
<XVR>
Hello all! When trying to order a BeagleBoard X15 in Europe, it seems to have some restriction for all european countries on Mouser. Is this something others have seen? If so, does anyone know why?
demirok has quit [Quit: Leaving.]
vagrantc has joined #beagle
demirok has joined #beagle
<KevinP>
Writing a custom overlay and I want to configure four GPIOs in the DT. Can anyone see what if anything I have done wrong? It compiles cleanly, but the /sys/class/gpio information is not correct.
<KevinP>
// Helper to show the loaded overlays under: /proc/device-tree/chosen/overlays/
<KevinP>
fragment@0 {
<KevinP>
target-path="/";
<KevinP>
__overlay__ {
<KevinP>
gpio-hog;
<KevinP>
gpios = <14 GPIO_ACTIVE_HIGH>;
<KevinP>
ouput-low;
<KevinP>
line-name = "AB1_UART_TX_EN1";
<KevinP>
};
<KevinP>
};
<KevinP>
};
<KevinP>
fragment@3 {
<KevinP>
target = <&gpio1>;
<KevinP>
__overlay__ {
<KevinP>
P2_02-hog {
<KevinP>
gpio-hog;
<KevinP>
gpios = <27 GPIO_ACTIVE_HIGH>;
<KevinP>
ouput-low;
<KevinP>
line-name = "LED_BB";
<KevinP>
};
<KevinP>
};
<KevinP>
};
<KevinP>
};
florian has quit [Quit: Ex-Chat]
<vagrantc>
KevinP: when pasting more than a few lines, please use a paste service and post the link here
ikarso has quit [Quit: Connection closed for inactivity]
<KevinP>
Apologies for the long post.
<vagrantc>
sorry i don't have anything substantive about the issue, but maybe someone else will eventually chime in
<zmatt>
KevinP: gpio hogging is mutually exclusive with gpios being exported by cape-universal (or any other kernel user of gpios), if you want to use gpio-hog then you need to disable the relevant gpios in cape-universal
<zmatt>
if your intent is to still have the gpios exported to userspace, then gpio-hog is the wrong mechanism to use
<KevinP>
I do not want them exported to userspace.
<KevinP>
I will look into cape universal.
<zmatt>
okay, then assuming you're using cape-universal you still need to disable the gpios, which also requires a new enough kernel revision (see https://pastebin.com/2w2XtJBP )
<KevinP>
more proof that more that one set of eyes is always a good thing.
<zmatt>
also keep in mind you're not configuring pinmux for the pins you're hogging... this isn't a problem necessarily since they default to gpio mode although it's generally preferred to have pinmux for them anyway to ensure the pins are claimed in the kernel and can't be accidently used by another device
<zmatt>
with gpio-hog this is a bit annoying since there's no good choice of device to attach the pinmux to, although it's permissible to just attach it to the gpio controller itself
<vagrantc>
apparently did not understand what i meant earlier ... :/
KevinP has joined #beagle
<zmatt>
KevinP: you may want to look at https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi ... it uses gpio-of-helper to configure gpios, which does export the gpios to userspace but is otherwise similar to gpio-hog in that it allows for configuring gpios, but has the benefit of grouping your gpios together in one device (instead of having to stick them on the gpio controller) which also gives ...
<zmatt>
...a place to attach pinmux
<zmatt>
and overlay-utils makes the ugly boilerplate of overlays unnecessary and has nicer pinmux macros
<zmatt>
of course if you really don't want them exported to userspace then gpio-hog is still the way to go
<KevinP>
I'm definitely going to look into it.
<zmatt>
exporting them using gpio-of-helper also makes the label you use show up e.g. in the output of my show-pins utility, which can be useful for diagnostics
<KevinP>
I've used show-pins a couple of times. Nice utility.
buckket has quit [Quit: buckket]
buckket has joined #beagle
set_ has quit [Remote host closed the connection]
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
set_ has joined #beagle
xet7 has quit [Quit: Leaving]
ikarso has joined #beagle
XVR has quit [Quit: Client closed]
xet7 has joined #beagle
<KevinP>
Question, if accessing GPIOs in userspace through /sys/class/gpio is deprecated, what is the preferred userspace access method?
<zmatt>
sysfs gpio is not going away and in my opinion still the best way to use gpio on linux
<KevinP>
I was just wondering if I should update my code.
<zmatt>
no, the linux kernel has a very strict "don't break userspace" policy
<zmatt>
the "replacement" is the gpio chardev and libgpiod, but it conflicts with gpio-of-helper (and hence with cape-universal), has no alternative way to configure gpios in DT, doesn't support per-pin access control, and most obnoxiously it resets outputs to high-z if the process that set them exits (or more precisely if the gpiod device is closed)