**** BEGIN LOGGING AT Sun Mar 20 02:59:58 2016 Mar 20 04:11:45 Guest90185: I think the Beaglebone Black is your best bet for a first board, its my opinion. Mar 20 04:23:12 on balance, I'd tend to agree Mar 20 04:34:39 see if you can find the kit with a proto board and a copper pad perf board included Mar 20 04:35:09 and a 3.3 volt ftdi cable and 5volt adapter Mar 20 04:38:00 and a really fast (90mb/sec) sd card, I get the 32 gig ones Mar 20 04:40:04 an hdmi monitor, for keyboard and mouse I use a wireless keyboard/track pad combo Mar 20 04:40:14 that way I don't need a sub hub Mar 20 04:40:35 usb hub Mar 20 06:15:03 I'm using a program that starts at boot and it listens to udev for detecting added and removed serial ports. I also need to use the pins as gpio, so I'm using cape-universal to allow run time configuration of the pin mode. The problem is that at boot time, all serial ports except ttyS0 and ttyS3 receive a remove event. Where does this come from, and how can I stop it? Mar 20 06:17:03 This is on a beaglebone green running jessie (which is why the ports are named ttyS*, not ttyO*) Mar 20 07:19:50 ew, cape-universal Mar 20 07:20:29 no idea why weird hackery it performs... are you sure you need it? Mar 20 07:29:29 "but that's how you do it" Mar 20 07:30:10 "right?" Mar 20 07:32:56 zmatt: time to grok up I feel ... Mar 20 07:35:11 ?? Mar 20 07:35:23 not sure why there'd be removals though Mar 20 07:35:25 precisely. Mar 20 07:35:35 I thought cape-universal kept all peripherals active? Mar 20 14:13:30 join Mar 20 14:20:10 zmatt, veremit: It seems like exactly what I need. I need to use the pins both as gpio and as a serial port (not at the same time). If I write my own device tree overlay, I have to choose which of the two I use and I can't use the other. Mar 20 14:21:03 zmatt: Yes, it does keep all peripherals active. That is, it keeps the device files, and they work. But my program listens for udev events, and believes it when it says a port disappears. Mar 20 14:22:29 I wonder how it even knows Mar 20 14:22:33 So I want to know where the removal event comes from and make it not emit it. Mar 20 14:22:46 that's a good question Mar 20 14:23:55 I think it's somewhere in the cape universal code. I don't know about ttyS3, but at least ttyS0 is a serial port by default, so it makes sense that that one doesn't disappear. My guess is that the others are removed with the intention of activating them when the pins are set to uart, but that part isn't implemented. Or something like that. Mar 20 14:24:29 But I can't even find where in the kernel the code that handles the cape-universal mode switching is located. Mar 20 14:25:12 first maybe try using 'udevadm monitor -k' to see what kernel events are being emitted Mar 20 14:26:13 I get the events through an udev rule that listens for add and remove events of tty devices; it receives four remove events (for tty[1245]) and no add events. Mar 20 14:27:03 s/tty/ttyS/ Mar 20 14:27:48 It all happens at boot, so it's hard to start anything before it happens. Mar 20 14:33:16 I can't even find where the sysfs files are created. I got the kernel source, but it doesn't seem to contain any reference to it. Mar 20 14:34:09 (The kernel source from github, linux-stable-rcn-ee.) Mar 20 14:54:43 which one? Mar 20 14:54:59 hmm Mar 20 14:55:28 you mentioned udev events however Mar 20 14:55:37 so that means you can monitor them Mar 20 14:55:56 Yes, I have an event script and I can make it write info to a file. Mar 20 14:57:14 note: I don't really know much about cape-universal since it I still think it's gross :P Mar 20 14:57:14 Everything works without that script. ;-) Except for hot plugging serial ports and having them detected; that's what the script is supposed to do. But now it removes the ports so they are unusable, because it is told by udev. Mar 20 14:58:59 last time I briefly looked at it my impression was that it just pinmuxed Mar 20 14:59:00 I can check if the events happen without it; my guess is that they do. But then I would expect to see add events after it loads. Maybe that's what's missing. Wait, I'll give it a try. Mar 20 15:00:45 what kernel are you using btw? Mar 20 15:04:53 No, without cape-universal loaded, the events are not emitted. Mar 20 15:05:36 I'm using the image build scripts to build a custom system (the seeed image with some extra stuff). It's 4.1.18-ti-r52. Mar 20 15:05:44 well yeah universal also enabled all peripherals Mar 20 15:06:01 although that's not really what's specific about cape-universal Mar 20 15:12:34 Ah, I found it! Mar 20 15:14:30 Your udevadm tip helped. :-) I tried running that and then loading cape-universal manually. It first removes, then adds the ports. But my udev rules for adding didn't match ttyS*, only ttyO*. So the add event didn't make it to my script. The remove was a catch-all, so that always worked. Mar 20 15:24:31 you're welcome :) Mar 20 15:24:48 Now the question is just how I can set the pins to uart at boot time; I put config-pin statements in rc.local, but they seem to be run too soon. They don't work, but they do when calling rc.local manually later. Mar 20 15:26:10 I suppose I could add a sleep statement before them, but that seems very ugly. Mar 20 15:26:34 and fragile Mar 20 15:26:38 Yes. Mar 20 15:28:20 I personally just put stuff i need in my main dtb Mar 20 15:29:28 although even then you sometimes need stuff to wait for devices to show up, especially things that take time to probe or for which a kernel module needs to be loaded Mar 20 15:29:34 you can use systemd dependencies for that Mar 20 15:30:37 Not in an overlay you mean? I wasn't planning to compile my own kernel; I've done that in the past, I'm happy to stay out of kernel space as much as possible. ;-) Mar 20 15:31:10 But you don't need to compile a new kernel to use a different device tree, I think? Mar 20 15:34:13 I could write my own overlay, but it would pretty much be what cape-universal is; I want my users to be able to connect things to any pin they like (as long as it has the function) and tell the program about it at run time. Mar 20 15:37:06 compiling a kernel is really easy actually, but no you don't to do that to customize your dtb Mar 20 15:38:08 ah, well, then cape-universal it is I guess :P well, or synthesize an overlay for the end user's design and load it Mar 20 15:39:36 I might also feel some inclination to go around the kernel, depending a bit on how it responds to that, but that's also because I already directly use many peripherals directly from userspace anyway Mar 20 15:40:20 Yes, compiling a kernel isn't hard, but it's a lot of work to go through all the configuration. Perhaps it's easier now; last time I did it was more than 10 years ago, I think. The main thing I'm trying to never do again is write a kernel module. Writing it is easy, but maintaining it is horrible, because Linus changes his interfaces every week, it seems. Mar 20 15:40:57 well I use rcn-ee's tree which contains his patches and build scripts, definitely makes like easier Mar 20 15:41:07 zmatt: Yes, I am doing that as well. But changing the pin functions cannot be done (without a hack) from userspace. Mar 20 15:41:24 https://github.com/dutchanddutch/jbang/blob/master/src/hw-subarctic.cc#L9 Mar 20 15:41:27 something like that you mean ? Mar 20 15:41:28 ;) Mar 20 15:41:35 (yes, I'll admit it's an ugly hack) Mar 20 15:41:52 Yes, that's exactly what I mean. ;-) Mar 20 15:42:03 but cape-universal is also an ugly hack Mar 20 15:42:06 so, well... Mar 20 15:44:31 btw in the least 30 minutes or so while talking I've also built another kernel ;) it really doesn't take much effort once you do it often enough (and have a moderately decent build machine) Mar 20 15:45:50 but I'm assuming your pinmux changes are just reflecting hardware experimentation by the user Mar 20 15:46:10 i.e. there aren't many situations where you'd genuinely want to do runtime pinmux switching Mar 20 15:47:03 so then overlays are not a bad thing: for safety I'd recommend moving to high-Z (with weak pull in the default direction) before changing hw connections anyway Mar 20 15:50:24 That will be true at some point. I currently have an avr connected to some pins, both to its serial port and to its reprogramming pins. My program can both upload new firmware to it using avrdude with the pins as gpio, and communicate with that firmware over the serial port. Mar 20 15:50:54 I want to make the PRU do the job that is now done by the avr; at that point there should be no run-time pinmux changes. Mar 20 15:52:58 Use uio-pruss. remoteproc is the path to madness. Mar 20 15:56:14 I afk for a while, back later today Mar 20 15:56:16 bbl Mar 20 15:56:34 l8r Mar 20 19:29:05 I am having issues flashing 8.3 to the BBB.. is there anyone who may be able to help me a moment? Mar 20 21:58:28 hi guys... neet to configure a bluetooth device on BBB , device is working but seems i have some problem pairing anyone got a good reference guide? Mar 21 00:52:43 no patience :( Mar 21 00:52:53 yup **** ENDING LOGGING AT Mon Mar 21 02:59:58 2016