**** BEGIN LOGGING AT Tue Nov 06 03:00:00 2018 **** BEGIN LOGGING AT Tue Nov 06 03:25:32 2018 Nov 06 09:17:47 hi all! Is anybody up for a 3 day contract work in London? sometime spring 2019 or summer 2019. we would like at least 3 mentors 9am to 5pm to mentor other more novice hardware hackers into producing a TRL 3 (working demonstrator). If so, please PM me. I am putting together the budget so travel and hotel could be paid for if needed. Nov 06 09:19:06 If you know of any other IRC channel where openhardware/IoT hackers lurck please let me know! Nov 06 09:19:13 what is a TRL 3 ? Nov 06 10:14:37 Snert: TRL is technology readiness level. So TRL1 or 0 is doodle with "this thing might work" and TRL9 is something that you buy off the shelf. TRL3 could be more or less something that works and you can make a small quantity off but definitely not read for any kind of production. Nov 06 10:14:42 Hope that helps! Nov 06 10:29:03 hi Nov 06 10:29:58 i want to know about beagle bone Nov 06 10:31:05 i want to know Visualization on beaglebone sensor Nov 06 10:31:19 but i can't install gnuplot Nov 06 10:31:53 because my beaglebone is Amstrong system Nov 06 10:32:13 then i can't use "sudo" command Nov 06 10:32:17 how can i do? Nov 06 10:32:30 i want operating Visualization Nov 06 10:32:36 plz tell me Nov 06 10:32:37 thz Nov 06 10:58:34 anwlstkd: install the latest firmware from http://beagleboard.org/latest-images Nov 06 13:33:07 m Nov 06 15:19:32 Hello, I have installed Xenomai on BeagleBoardX15. I would like to know the kernel drivers in use. But lscpi -k return ---> 00:00.0 PCI bridge: Texas Instruments Multicore DSP+ARM KeyStone II SOC (rev 01). It does not list any kernel drivers in use. How can I find the same? Nov 06 15:23:22 sakshi: hmm, I think lspci can indicate the driver in use Nov 06 15:23:29 if not, it's also easy to find in sysfs Nov 06 15:23:57 oh you're already using -k Nov 06 15:24:57 do you have any actual pci devices connected to it? I suspect the root bridge does not count Nov 06 15:26:50 zmatt: the ethernet interface should return a kernel driver rite? Nov 06 15:26:57 no, why? Nov 06 15:27:15 nothing on the x15 is connected to the pci bus Nov 06 15:27:33 they're all platform devices Nov 06 15:28:08 okay, so how do I get the kernel driver that manages the eth0 interface? Nov 06 15:28:43 ls -ld /sys/class/net/eth0/device/driver Nov 06 15:29:40 it's the cpsw driver (wihch lives in drivers/net/ethernet/ti/) Nov 06 15:31:17 (as an aside, my assumption was right that it's normal for lspci -k to not show any kernel driver for the pci host bridge, it's also not shown on my x86 laptop) Nov 06 15:31:55 yes, ls -ld /sys/class/net/eth0/device/driver points to a cpsw driver. Nov 06 15:33:50 Okay Nov 06 15:34:43 in general if you want to know the drivers in use, this may be of use: Nov 06 15:34:49 find /sys/devices -name driver -exec readlink -m {} \+ | sort -u Nov 06 15:35:52 EW... spaces in a driver name? o.O Nov 06 15:35:59 (/sys/bus/mdio_bus/drivers/Micrel KSZ9031 Gigabit PHY) Nov 06 15:36:40 yes, I get the same spaces in driver name Nov 06 15:36:47 disgusting Nov 06 15:37:00 to start rtnet, I need to follow the steps here https://pastebin.com/0xqn0ydj Nov 06 15:37:34 So I need to find the kernel driver for eth0 interface and remove it. Nov 06 15:38:03 xenomai replaces the normal kernel driver? does xenomai have its own driver that supports TI CPSW ? Nov 06 15:38:59 nope, not listed on the rtnet homepage Nov 06 15:39:05 eh, documentation page Nov 06 15:39:25 http://www.rtnet.org/doc.html scroll down to "Supported Network Adapters" Nov 06 15:39:33 it's a very limited set Nov 06 15:41:39 the /lib/modules/4.14.71-ti-r80/kernel/drivers/net/ethernet has smsc, which is supported Nov 06 15:41:58 anyway, if you do ever want to "remove" a driver that's compiled into the kernel rather than built as module... you can't use modprobe -r in that case but you can still "unbind" the driver from the device (e.g. "echo 48484000.ethernet >/sys/bus/platform/drivers/cpsw/unbind") Nov 06 15:42:16 uhh, and how does that help? Nov 06 15:43:08 to use rtnet you'll need a supported ethernet controller Nov 06 15:43:33 I thought supported network adapter should be enough Nov 06 15:43:43 same thing Nov 06 15:44:05 but the x15's "network adapter" is the CPSW, which rtnet (currently) doesn't seem to support Nov 06 15:44:24 Ah okay, got it! Nov 06 15:44:55 Thanks a lot!:) Nov 06 15:46:46 it might be relatively easy to add such support, given that very little code is required to get CPSW in a working state, but I have no idea how hard it is to write a driver for rtnet Nov 06 15:47:28 (I've written my own simplistic driver for CPSW in a baremetal Forth environment a long time ago) Nov 06 15:52:26 the driver for rtnet should also be specific to CPSW? Nov 06 15:52:46 o_O Nov 06 15:53:41 eh, yes, just like it'll have specific drivers for each of the other network adapters rtnet supports Nov 06 15:55:44 it's unfortunate that there's no way to use PRU-MII on the x15... that would get you *really* real-time ethernet (far more so than xenomai can ever hope for) Nov 06 16:01:06 rtnet seems like a dead project though? last release was in 2010, and both the "git repository" and "cross reference" links on the homepage are dead Nov 06 16:01:18 Any idea if apart from RTnet, is there something else that can provide real time ethernet support to Xenomai? Nov 06 16:01:40 I know very little about xenomai, it's pretty obscure Nov 06 16:02:00 does linux-rt give you inadequate results? Nov 06 16:02:04 the newer versions of Xenomai ( 3 and above) seems to have rtnet available by default. No additional installation is required Nov 06 16:02:40 I see Nov 06 16:02:52 Preempt-rt provides no support for real time ethernet, it just makes the linux kernel preemptable Nov 06 16:03:44 if the rtnet homepage is obsolete, then presumably the list of supported hardware there is too Nov 06 16:04:42 I'm trying to google, but I keep getting dead links Nov 06 16:04:58 I have posted in their mailing list. But many people have complained regarding similar issue. So it is possible that CPSW is not supported Nov 06 16:06:16 yeah, I found the source code... the list of supported hardware has definitely increased, but CPSW is not among it Nov 06 16:06:22 not even in 'experimental' Nov 06 16:07:29 hmm too bad Nov 06 16:24:21 sakshi: I just remembered I also have some old baremetal C++ code that used CPSW... just to give you a rough illustration of what's involved in a simplistic CPSW driver: https://pastebin.com/MJ3RGKqz Nov 06 16:26:59 (it implicitly assumes the ethernet switch itself has already been initialized (I handled that in forth during early boot), but in your situation you'd be able to make the same assumption since the linux cpsw driver will take care of that before you unbind it) Nov 06 16:28:28 pastebin really needs to update their C++ syntax highlighting code Nov 06 16:41:21 zmatt: thanks Nov 06 18:30:53 Is there a debugger for PRUs on BeagleBone? Nov 06 18:31:30 I know there's at least one but I don't know how well it works Nov 06 18:31:37 How about a debugger for Cortex-M3 on BeagleBone Blue? Anyone? Nov 06 18:32:27 my py-uio code for pru has functions to inspect/modify the core state and do single-stepping, but currently just as part of the API, not a standalone debugger as-such Nov 06 18:33:30 the cortex-M3 ? the wakeup controller of the am335x ? jtag Nov 06 18:34:26 assuming jtag is pinned out somewhere on the blue Nov 06 18:35:07 yeah, it is, just testpoints though (unlike the black with has solder pads for a standard cTI-20 jtag header) Nov 06 18:35:53 Isn't Cortex-M3 on blue an extra micro-controller (not just a wakeup controller)? Is there a debug port for it too? Nov 06 18:36:32 I'm pretty sure the blue does not have a separate microcontroller for anything Nov 06 18:39:19 oh, I'm wondering why blue page lists m3 in addition to a8 proc and two PRUs Nov 06 18:40:42 yeah it probably shouldn't. I mean, it *has* an m3 (like all other beaglebones), but normally it already runs power-management related firmware. it's mostly idle and the firmware is open source so in theory you could add custom functionality to it, but I haven't heard of anyone doing it Nov 06 18:41:02 the wakeup M3 also has pretty limited system access and not much ram Nov 06 18:41:43 (it only connects to the L4-wakeup interconnect, not to the L3 interconnect) Nov 06 18:42:51 @zmatt, that info helps. Thanks. Nov 06 18:43:30 the main situation where it might make sense to add custom code there is for being able to handle some stuff while the system is in suspend, e.g. periodically do adc readouts and use those to decide whether to wake up the system or not Nov 06 18:44:18 having onboard PRUs is awesome. Its like having pi + arduino on the same board. Well, almost. But lack of a PRU debugger makes it hard Nov 06 18:44:36 have you tried prudebug? Nov 06 18:45:37 No, I'm just getting started with PRUs. How is the debug support with prudebug? Nov 06 18:46:03 I've never used it, but I know it exists Nov 06 18:47:19 ohk. any idea if remoteproc has additional debug capabilities vs uio? Nov 06 18:48:00 for the most part remoteproc is more likely to be an obstacle :P Nov 06 18:48:09 I prefer uio myself Nov 06 18:49:08 obstacle... why? learning curve? not stable? Nov 06 18:50:01 restricted access Nov 06 18:50:20 uio lets you directly inspect and interact with the core Nov 06 18:51:07 fuck, I did something stupid and now my bbx15 doesn't boot Nov 06 18:51:21 I get that. On the other hand, did you find pru usable with uio? Nov 06 18:51:36 oops, I guess you need to take care of that first! Nov 06 18:52:37 yeah no worries, I'll fix it again Nov 06 18:52:50 usable? yes, very much Nov 06 18:53:57 recently we started using pru for production-use at work... first some rapid prototyping using my py-uio library, and for production use I then made a small loader in c++ Nov 06 18:54:15 (I don't use libprussdrv, that library is awful) Nov 06 18:59:04 great! that's helpful feedback. Nov 06 19:00:16 py-uio already has all the ingredients needed for debugging, e.g. it has all the necessary core inspection/control features and it can read in the .dbg files produced by pasm Nov 06 19:00:29 it's just missing something that glues it all together Nov 06 19:02:27 got it Nov 06 19:02:56 woop, fixed my x15 again Nov 06 20:06:49 * zmatt added a py-uio example that single-steps through a program while printing each instruction and modified registers Nov 06 20:35:17 i know ya'll must have a solution for versioning system config Nov 06 20:35:40 etckeeper? Nov 06 20:36:05 depending on what you mean exactly Nov 06 20:36:09 hmmm Nov 06 20:36:17 i'm exploring options but i hadn't considered that one Nov 06 20:36:32 it's far from perfect, but still one of the first things I install on any fresh system Nov 06 20:36:34 i'm thinking i'm going to do like, system documentation with README.s in a git repo with tagged versions attached to images Nov 06 20:36:58 but not the images in the gitrepo because thats too much Nov 06 20:37:01 i'll tkae a look at etc keeper Nov 06 20:38:37 btw, check my neat new py-uio example: https://pastebin.com/raw/EtZQ5ZVU :D Nov 06 20:39:34 oh gosh are you building a debugger Nov 06 20:39:50 i know you've been spending too much time in #openocd Nov 06 20:40:20 not really no, it's just a simple example of the capabilities already in py-uio (though I polished them a bit and filled a few gaps while making this example) Nov 06 20:40:34 https://github.com/mvduin/py-uio/blob/master/pru-examples/debugging.py Nov 06 20:42:22 bbiab, shopping Nov 06 20:50:35 interesting bit, nevertheless Nov 06 20:51:09 kind'a tempting to actually make that into an openocd target type, but without gdb support for the PRU it's not worth a lot. Nov 06 20:52:19 on the other hand... Nov 06 20:57:17 right Nov 06 21:36:02 thinkfat_: well there's https://github.com/dinuxbg/gnupru Nov 06 21:37:45 though I'd consider it more useful with pasm support than with gcc support Nov 06 21:50:24 it's unfortunate that debug visibility is incomplete... e.g. you can't inspect the carry-flag or the loop state Nov 06 23:43:40 wow that is something else **** ENDING LOGGING AT Wed Nov 07 02:59:59 2018