Archana has quit [Remote host closed the connection]
set_ has joined #beagle
<calrama>
zmatt: fwiw the way it's written there sounds to me like the glitches may only occur during the changing of the pinmuxing, not afterwards, but who knows.
<calrama>
In any case, programming a pru core as an external clock for the mcp3462 worked. Now I'm just confused why the adc actually doesn't honor the V_ref it receives and instead outputs way too low codes^^
<calrama>
(vdd==3.3V, vref == 1.8V, input signal == 1.8V, mcp3462 should output something near 32000, but outputs about 20000; super weird; when I give it an input signal of about 2.4V it outputs ~32000)
<calrama>
But that's not really a beaglebone issue, so I'll shut up now^^
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #beagle
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #beagle
<set_>
Hello!
<set_>
64-bits of glory?
<set_>
I am in! I am taking the plunge.
<set_>
I received a nice email from the org about a 64-bit, dual-core behemoth! I want it.
<set_>
I have this 64-bit cam (chipset) that does wonders w/ relational spaces. I have been waiting to try it on an embedded device...
<set_>
Thank you!
<set_>
Is it true? It is a real board already?
thinkfat_ has joined #beagle
<set_>
I looked at DigiKey. They say something but it is $187.50. That sounds a bit like the AI-32. Does that sound right?
thinkfat has quit [Ping timeout: 272 seconds]
<set_>
Now, they say no backorders. I must have missed the window. Blah.
<set_>
Anyway...if you guys produce another batch, send another email to this little fellow from LA.
Shadyman has joined #beagle
<set_>
Someone wake up GenTooMan from his slumber.
<set_>
GenTooMan: Awake and be glorified!
<set_>
Blah. Forget it guys...I will again turn patient.
* set_
loves being patient in rushhour!
ikarso has quit [Quit: Connection closed for inactivity]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has joined #beagle
Guest15 has joined #beagle
<Guest15>
Does anyone know how to find out what /sys/class/pwm/pwm0:0 refers to?
<Guest15>
sorry /sys/class/pwm/pwm-0:0
vagrantc has quit [Quit: leaving]
Guest87 has joined #beagle
Guest87 is now known as Pixel87
<Pixel87>
Hello, I need help regarding a small issue I'm facing on my new BeagleBone black. In the IP login 192.168.7.2 whenever I try to use the digitalWrite() section of page to change inbuilt LED state, it never works (Bonescript) It's just stuck at "Bonescript: initialized", but the other function getPlatform() is giving output which means board is
<Pixel87>
responding.
demirok has quit [Quit: Leaving.]
Pixel87 has quit [Quit: Client closed]
calrama has quit [Quit: Client closed]
otisolsen70 has joined #beagle
insurgent has quit [Read error: Connection reset by peer]
insurgent has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
ayjay_t has quit [Remote host closed the connection]
buckket has quit [Quit: buckket]
buckket has joined #beagle
Shadyman has quit [Quit: Leaving.]
<zmatt>
Guest15: easiest is to go the other way around: if you're using a not too ancient system there should be symlinks in /dev/pwm/
<zmatt>
allowing you to access a specific pwm output directly
<zmatt>
(the numbering of pwm devices should not be relied on, the kernel assigns these in whatever order pwm devices show up during or after boot)
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
<zmatt>
Guest15: but to answer your question more directly: pwm-X:Y is output Y of pwmchipX, and to identify which pwmchip is which the udev rule that creates these symlinks in /dev/pwm/ matches the name of the parent platform device, which contains the address of the peripheral: https://pastebin.com/raw/WPkNGq7v
Guest15 has quit [Quit: Client closed]
otisolsen70 has quit [Quit: Leaving]
SJFriedl has quit [Read error: Connection reset by peer]
SJFriedl has joined #beagle
sicelo has quit [Ping timeout: 246 seconds]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
PatrickE has joined #beagle
alan_o has joined #beagle
sicelo has quit [Quit: Bye!]
sicelo has joined #beagle
sicelo has joined #beagle
sicelo has quit [Changing host]
buzzmarshall has joined #beagle
xet7 has quit [Remote host closed the connection]
ikarso has joined #beagle
<zmatt>
jkridner: it may be better to not call the type-C port "dual role" given that it doesn't actually support host role (as previously discussed) .. and it doesn't really need it anyway since there are two usb 3 type-A ports
<zmatt>
in de board features list I mean
<zmatt>
*in the
<jkridner>
sure, but it can work with some hubs as a host. Suggesting just calling it a client port?
<zmatt>
those hubs are in violation of the usb s[ec
<zmatt>
but we know it's certainly not something you can assume all charging usb hubs will do
<zmatt>
and most other usb devices probably won't work at all unless the host port support source power-role, even if the usb device has independent power
<zmatt>
(since a device that can't source power will be configured as sink-only hence won't even establish an initial connection)
<zmatt>
usb-c is just such a mess :D
florian has quit [Quit: Ex-Chat]
PatrickE has quit [Ping timeout: 252 seconds]
Guest15 has joined #beagle
vagrantc has joined #beagle
akaWolf has quit [Ping timeout: 256 seconds]
akaWolf has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #beagle
jfsimon1981 has quit [Ping timeout: 246 seconds]
jfsimon1981 has joined #beagle
vagrantc has quit [Quit: leaving]
vagrantc has joined #beagle
xet7 has joined #beagle
Guest15 has quit [Quit: Client closed]
Guest15 has joined #beagle
<Guest15>
@zmatt: If I'm reading those udev rules right, it should put ehrpwm3a under pwm-2:0?
otisolsen70 has joined #beagle
<Guest15>
The issue I'm having is when I add ehrpwm2a (u-boot and kernel), it shows up as pwm:0-1 which seems like something might be wrong in the dts. Also there is always a pwm:0-0, but I can't figure out where that's coming from.
ikarso has quit [Quit: Connection closed for inactivity]
waldo323 has joined #beagle
Guest98 has joined #beagle
Guest98 has quit [Client Quit]
waldo323 has quit [Client Quit]
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
calrama has joined #beagle
<calrama>
Does the new bbai-64 come with an image with tidl support? If so, what kernel version?
<calrama>
I'm thinking of picking one up, but if I need to keep using kernel 4.14 (and an old version of tidl) it just makes more sense for me personally to stick to my existing bbai.
<zmatt>
Guest15: I think you didn't read what I said
<rcn-ee>
calrama: the factory image (2022-01-14) didn't have this working at that time... Using these scripts you can update what's in the latest image: https://beagleboard.org/update-ai64/
<zmatt>
Guest15: the numbering is arbitrary and should not be relied on
<rcn-ee>
(probally should rename that directory as edge-ai)...
<calrama>
rcn-ee: Sorry, I meant with the official beaglebone image. I know that I could instead use the processor sdk image from ti, but as I've never used that before I'd like to stick to the image "officially" supported by beagle.
<rcn-ee>
calrama: this is the offical BeagleBoard.org debian based image.. ;)
<calrama>
Ok, very neat. Thanks.
<calrama>
Wait, wat? The processor sdk image from ti is the same one as the ones on beaglebone.org?
<rcn-ee>
We worked with TI over the last few months to integrate 8.0, then 8.1 and 8.2 edge_ai sdk.. we still need to tackle all the ROS demo's... we just had too much fun with random dsp firmware versions..
<calrama>
That's pretty great.
<calrama>
I'll pick one up, then, thanks.
<rcn-ee>
It's Debian 11.3, with TI's v5.10.x-ti kernel, but with all hte edge_ai stuff ported over to debian..
<calrama>
Ah!
<calrama>
On a related note, since we also have some of those boards at work: Will the beaglebone ai also get the same treatment to edgeai?
<calrama>
(not the new 64 bit board, but the earlier one, I mean)
<zmatt>
Guest15: I'm have no idea how you concluded from the udev rules that "it should put ehrpwm3a under pwm-2:0" ... ehrpwmNa and ehrpwmNb will show up as pwm-X:0 and pwm-X:1 with no particular relationship between N and X, it may depend on kernel (version and config), DT, and whether initramfs is used
<rcn-ee>
Sadly no... newer versions of TI's sdk for the am57xx no longer support those functions.. (they call it de-scoped..) Everything had moved to am6xx series of dsp's... Sadly that special eve co-processor on the am57xx was a one off design... on teh TDA4, it's a C6x and C71 DSP instead of a custom co-processor that tild was orignally designed for..
<zmatt>
rcn-ee: EVE predates the AM57xx
<rcn-ee>
didn't remember it being on anything before dra7? was it on soemthing else special?
<calrama>
Ah, I see. Thank you. So there we're going to have to stick to kernel 4.14?
<calrama>
(or use the processor sdk image)
<rcn-ee>
When i lasted looked at the last working SDK, we should be able to support 4.19.x or 5.4.x... i had problems with either cmem or something that broke.. (that's why it got locked to 4.14.x)
<calrama>
I'd be willing to help with that fwiw.
<rcn-ee>
on teh bbai-64 side, TI thru out cmem, it's dmabuff_phys! ;)
<calrama>
4.19 would be awesome.
<zmatt>
rcn-ee: it was on certain dm814x derivatives such as the DMVA3/DMVA4
<rcn-ee>
ah!
<calrama>
(help with testing things out I mean. I do have a vested interest in getting this working, after all^^)
<rcn-ee>
calrama: one of the things i'm worried about is breaking what works.. but we can split that into Buster (4.14.x) and Bullseye (4.19.x/5.4.x)..
<calrama>
Sure :) My "working environment" is on the emmc (buster), so I can just setup a bullseye version on an sdcard.
<rcn-ee>
Now that the bbai64 is out i can look back at the bbai/x15 more..
<calrama>
Yes, please :)
<rcn-ee>
it won't be this week or next... (Doing Demo's at Embedded World in Germany)
<calrama>
No worries. And that's so cool. I'm situated in Berlin and I wanted to attend, but I could not make it. My lab is doing a retreat in the same timeframe.
<rcn-ee>
calrama: ps.. ImgTec is also releasing notes on using their GPU on teh BBAI64 to do even more AI stuff.. the opensource libpowervr drivers from mesa 22.1.x are pre-installed, the kernel side needs more work.. before those open drm drivers work for us..
<zmatt>
(at least I *think* the vision coprocessor on the DMVA3/4 is EVE)
<calrama>
If I can help in any way with testing, feel free to either ping me on github (nick moritzmaxeiner) or shoot me an email (the github nick at fu-berlin.de)
<calrama>
rcn-ee: uh, sweet.
<calrama>
Unfortunately we already bought 4 normal bbai for our work at the lab so I don't think I can swing purchasing the bbai64, unless we actually need it.
<calrama>
But I'll buy one for myself.
<rcn-ee>
no worries!
Shadyman has joined #beagle
demirok has joined #beagle
<calrama>
hm, now this is weird.
<calrama>
digikey says it has 2 in stock, but you cannot order one.
<rcn-ee>
might be regional cache things.. the export codes where enabled yesterday.. nothing like messing things on launch day... last i checked there was 60 in stock.. just limiting everyone to a max of 2..
<zmatt>
hmm, or might that actually *be* the am572x
<zmatt>
who knows, maybe I"m wrong, am572x is certainly the first SoC clearly documented to have EVE
<calrama>
Fair enough. I'll see what it says tomorrow, then. Gotta get some Zzs. Thanks for the infos :)
calrama has quit [Quit: Client closed]
jkridner_ has joined #beagle
<Guest15>
@zmatt: Sorry I saw the adresses of the peripherals (KERNELS=="48440200.*", ENV{PWMCHIP_NAME}="ehrpwm1") and thought it was using that info to name the pwm. I don't fully understand udev so I'll take your word for it. I still have a problem of finding somewhere in my dtbs a mystery pwm...
NishanthMenon_ has joined #beagle
<zmatt>
Guest15: it matches 48440200.* and uses that to assign the name ehrpwm1 to the pwmchip, which is then used to create the /dev/pwm/ehrpwm1a and /dev/pwm/ehrpwm1b symlinks
<zmatt>
none of which has anything to do with the pwmchip numbering (which plays no role in the udev rule)
NishanthMenon has quit [Ping timeout: 250 seconds]
jkridner has quit [Ping timeout: 250 seconds]
kveremitz has quit [Ping timeout: 250 seconds]
alan_o has quit [Ping timeout: 250 seconds]
agraf has quit [Ping timeout: 250 seconds]
x56 has quit [Ping timeout: 250 seconds]
NishanthMenon_ is now known as NishanthMenon
x56_ has joined #beagle
jkridner_ is now known as jkridner
<Guest15>
Right. Because I have ehrpwm2a enabled in dts and ls /dev/pwm shows ehrpwm1a ehrpwm1b.
<zmatt>
ehh
<zmatt>
can you show me what you did in dts?
<zmatt>
also, which kernel version are you using?
agraf has joined #beagle
kveremitz has joined #beagle
<zmatt>
also I assume you mean you enabled ehrpwm2 in dts... there's no way to enable or disable the a/b outputs individually in dts
<Guest15>
kernel is 4.19. What I had at first was my pins connected to &ehrpwm2 and it wasn't working. I changed it to &ehrpwm1 in the dts and then it started working.
<Guest15>
By not working I mean no signal at the pin.
<zmatt>
ehh I'm confused, you just said you have ehrpwm2 enabled in dts, but now you said you changed it to &ehrpwm1 ...
<zmatt>
I don't see any way for it to be possible for /dev/pwm/ehrpwmX{a,b} to exist unless &ehrpwmX is enabled in dts (for X=0..2)
<zmatt>
wait, hold on
<zmatt>
are you using a beaglebone-ai / beagleboard-x15 ?
<Guest15>
beaglebone ai
<Guest15>
I'm using this pin: DRA7XX_CORE_IOPAD(0x358C, PIN_OUTPUT | MUX_MODE10) /* E6: vin2a_d9.ehrpwm2A */
<Guest15>
but it's connected to &ehrpwm1
alan_o has joined #beagle
<zmatt>
yeah, so, *sigh* ... fucking TI
<Guest15>
I can live with that, the problem is that there are TWO pwms and I only have ONE enabled?
<zmatt>
the am57xx for some reason uses 1-based numbering for some (but not all) peripherals, but these may or may not end up having 0-based numbering in other places such as the dts
<zmatt>
in particular, the documentation and pinmux tool think there's ehrpwm1/2/3 but the dts and udev rule call them ehrpwm0/1/2
<zmatt>
it's interesting that for ehrpwm devices the DT node label (&ehrpwm0) uses 0-based numbering
<Guest15>
This wasn't so different from when gpio pin numbers had different meanings...
<Guest15>
So how can I track down this mystery pwm. It's really bothering me.
xet7 has quit [Ping timeout: 240 seconds]
<zmatt>
gpio controllers are 1-based in documentation and in DT node labels, and gpio numbers are technically dynamically assigned hence *ought* not be relied on even though most people do and it's probably safe to rely on for platform gpio controllers
<zmatt>
ls -l /sys/class/pwm/pwmchip*/device
<zmatt>
interesting, pwmchip numbering isn't sequential, it looks like the kernel globally allocates pwm numbers for individual pwm outputs and gives the pwmchip the number of their first output
<zmatt>
this shows the full device path of each pwm output (including parent devices): readlink -e /sys/class/pwm/pwm-*
<Guest15>
There's only one pwmchip and it's device is 48440200.pwm. In the flattened dts file that device node only has one pinmux phandle tha that phandle references my pinmux entry with a single pin.
<Guest15>
Without my entry there is still a pwm pin. I just don't get it.
<zmatt>
pinmux doesn't affect whether or not devices exist
<zmatt>
the device driver knows nothing about pinmux
<zmatt>
if you enable an ehrpwm device in dts (status = "okay";) then the udev rule will export both of its pwm outputs and create symlinks for them
xet7 has joined #beagle
<Guest15>
I've see only one pwm output in /sys/class/pwm when I had some configuration that I'm not too sure about now.
<zmatt>
maybe an ecap device?
<zmatt>
ecap and timer devices have 1 pwm output per device, ehrpwm devices have 2 pwm outputs per device
<zmatt>
it's also conceivable to get only one output of an ehrpwm device in sysfs if exporting the other one failed because it was in use by a kernel driver (you'd also see an error logged by systemd-udevd in that case)
<Guest15>
So if it was attached to a backlight, for example? Maybe that was it.
<zmatt>
yep
<Guest15>
Okay, I didn't know about the /dev/pwm links before so now that I do I'll look there instead of /sys/bus/pwm
<Guest15>
well the simplest solution is to remove said udev rule and export manually. Which I may do on our custom hardware.
<zmatt>
I'd suggest using my solution instead, it avoids having to keep the udev rule in sync with dt
<Guest15>
I'm going strip my device tree down to a single file that doesn't include a lot of the beaglebone stuff. I just don't need it for my hardware.
<zmatt>
sure.. my point was that if you use the solution I suggested in the issue I just linked you can control in your dts whether pwm outputs are exported
<zmatt>
instead of having to do that separately in the udev rule
<zmatt>
so it keeps the udev rules generic (and in sync with upstream, if my fix ever gets applied)
<Guest15>
Fair enough. I'll keep it in mind.
<Guest15>
I don't suppose you'd know how to tell udev not to set a particular usb device up with a driver?
<zmatt>
not sure... blacklisting the kernel module would be an option if the driver is compiled as module and not needed for any other device either
<zmatt>
there's almost certainly a way to do it more selectively
<zmatt>
why?
<Guest15>
It's a composite device - microphone and web camera. I need to make that device available in wine. I can blacklist the camera driver easy enough, but the microphone is getting picked up by alsa.
<zmatt>
it's also possible to detach the kernel driver afterwards from userspace, either via sysfs or via an ioctl on the device file
<Guest15>
yes unbinding it, but finding the right path is really hard
<zmatt>
wine would be in the best position to unbind the kernel driver.. they already have the device open to be able to use it from userspace, all they'd need to do is call that ioctl to detach the kernel driver
<zmatt>
USBDEVFS_DISCONNECT_CLAIM
<zmatt>
what's the reason you can't also just blacklist the usb audio class driver?
<Guest15>
I use other usb audio devices. How would I use USBDEVFS_DISCONNECT_CLAIM? Not seeing any examples. Can I just add it to /etc/udev/rules.d/99-unclaim.rules after everything else runs?
<zmatt>
no it's an ioctl, not something udev can do
<Guest15>
Ah. That's not terribly helpful? I would obviously need to get a 'handle' for that particular usb device. If I could do that easily I could just unbind it.
<zmatt>
it's part of the kernel api for directly communicating with usb devices from userspace (e.g. wine)
<zmatt>
it shouldn't be that hard to identify the device using udev though
<zmatt>
try udevadm info -a PATH where PATH is a sysfs or device path of the audio device (e.g. in /sys/class/sound/ or /dev/snd/)
<Guest15>
What would be ideal is a way to blacklist a vid:pid. Is there no way to do that?
<zmatt>
udev can easily match on vid:pid
<Guest15>
yes, that's how it's binding in the first place
<Guest15>
but is there some way to tell it not to
<zmatt>
I'm not sure if it's possible to prevent the driver from binding if it's already loaded since the kernel will do that, not udev