**** BEGIN LOGGING AT Sat Nov 23 02:59:57 2019 Nov 23 03:51:18 this gave me a grin https://xkcd.com/2208/ Nov 23 03:54:28 GenTooMan: the mouse-over text too XD Nov 23 04:12:33 You know it almost sounds like they actually did that. :D Nov 23 04:25:41 Is there any way to access a Beaglebone Black's TTY besides SSH if I don't yet have a TTL cable? Nov 23 04:26:07 I have a spare monitor, but can't find a micro HDMI (planning to pick up one of those too, for posterity's sake) Nov 23 04:27:22 I'm trying to load a different Linux distro from a microSD. I already changed the sshd_config so that it should be accessible via 192.168.7.2:22. Nov 23 04:27:32 hdmi and serial console are not interchangeable anyway... why do you need access to it? did you break networking such that you're unable to log in? Nov 23 04:27:35 ah Nov 23 04:27:38 ehh Nov 23 04:27:41 normally you never configure an ip address in sshd_config Nov 23 04:27:51 Just a temporary measure Nov 23 04:27:57 for what? Nov 23 04:28:15 I want to get everything working, then make it secure afterwards Nov 23 04:28:49 (going to use it for a home server, but I don't have much hardware experience) Nov 23 04:28:56 ?? binding the listener to a fixed ip doesn't decrease (and usually doesn't increase) security, it just reduces the probability of things working Nov 23 04:29:19 How do I bind it to an IP I can ssh to? Nov 23 04:30:02 by default sshd (like almost any server) will listen on all IPs, hence you'll be able to ssh in on any IPv4 or IPv6 address of any interface of the beaglebone Nov 23 04:30:26 How do I find the interfaces? Nov 23 04:30:43 (connecting via USB) Nov 23 04:33:10 that depends on how your system is configured. the default debian distro from beagleboard.org uses dhcp on ethernet while also setting up two usb networking interfaces (one RNDIS for Windows and one CDC-ECM for Mac, Linux, and other platforms that bothered to properly implement the USB standard) with fixed IPs: 192.168.7.2 for the RNDIS one and 192.168.6.2 for the CDC-ECM one Nov 23 04:33:58 it also has avahi-daemon installed so on Mac or most Linux systems you'll be able to reach the beaglebone as "beaglebone.local" (assuming its hostname is "beaglebone") Nov 23 04:35:45 How can I emulate a BBB on my desktop? Nov 23 04:35:48 while if you connect it via ethernet to a residential network, most home internet routers will ensure you'll be able to reach the beaglebone using the hostname "beaglebone" so you don't have to figure out its DHCP-assigned IP Nov 23 04:35:52 you can't Nov 23 04:36:03 That seems strange Nov 23 04:36:25 why? who would have written an emulator for the AM335x SoC on the beaglebone and why? Nov 23 04:36:32 that would be a ton of work Nov 23 04:37:15 There are CPU emulators. Do they target non-real, simplified ones? Nov 23 04:38:26 I think the only TI SoC that can be partially emulated is the omap3, and iirc that work was done in a custom qemu branch and never reached mainline qemu, and is now abandoned Nov 23 04:38:38 the CPU is a small part of the SoC Nov 23 04:38:47 ah Nov 23 04:39:46 there are lots of modules you'd need to emulate sufficiently well to be able to successfully boot even the most barebone linux system Nov 23 04:41:56 (including some modules outside the SoC, such as the power management IC) Nov 23 04:43:25 btw, why would you use a beaglebone for a "home server" .. that sounds like an application that would use none of the unique features that the beaglebone offers, and instead mostly depends on the weakest parts of the beaglebone Nov 23 04:45:41 It's what I have around Nov 23 04:45:52 I originally got it to libreboot my T400, but that seems rather daunting Nov 23 04:45:57 fair enough. anyway, in that case I'd recommend you just get the debian console image Nov 23 04:46:06 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Buster_Console_Snapshot Nov 23 04:46:14 What would you recommend for a home server SBC? Nov 23 04:46:20 (wrong channel?) Nov 23 04:47:10 Maybe a Freescale SBC? Nov 23 04:47:27 Something fully libre would be nice Nov 23 04:48:04 dunno, depends on the requirements I guess, but there's probably a fair bit of options with better value/money for that. depending on what sort of server it would probably be nice to have better cpu, storage, ram (size and performance), and/or networking than the beaglebone Nov 23 04:48:17 especially storage and networking Nov 23 04:48:34 College student, so not much leeway in cost tbqh Nov 23 04:48:50 eMMC is slow and wears out, SD is slower and wears out even faster Nov 23 04:49:04 I do have an SSD which I was going to hook it up to Nov 23 04:49:27 to USB? on the BBB? oh boy Nov 23 04:49:32 what? Nov 23 04:49:40 have you done performance tests with that? :) Nov 23 04:49:47 * refusenick is hardware-illiterate Nov 23 04:49:48 I'd be curious to know the results Nov 23 04:50:43 I've seen people run Pleroma off of old smartphones Nov 23 04:50:56 I'm sure a BBB would work fine for that and a static blog page Nov 23 04:51:16 (and a Gitolite repo on the SSD) Nov 23 04:51:43 The SSD is more for the Postgresql install which Pleroma needs Nov 23 04:51:52 the usb controller on the BBB (and various other SoCs) is a weird little thing called musbhdrc, which is really more meant as an OTG controller for mobile devices, and it kinda has a history of issues on the bbb (not all of which are due to musb itself probably) Nov 23 04:53:14 I wonder if DMA is enabled nowadays, it used to be disabled which means that all data transferred via usb was being manually copied (by the kernel driver) between ram and the usb controller Nov 23 04:54:02 but maybe it all works fine nowadays, I wouldn't know since I generally just don't use usb on the bbb :) Nov 23 04:55:59 although, for a while a colleague of mine used a BBB as an usb-to-ethernet dongle for his laptop (until the wifi network in our office was improved to actually be usable) and I think that worked fine Nov 23 04:57:49 refusenick: anyway, as far as getting the bbb to work, just download the debian buster console snapshot eMMC flasher, write it to SD card and boot the BBB from that to reflash eMMC, after that you should be able to ssh into it via usb networking and ethernet like I described above Nov 23 04:58:51 the console image is a pretty lean debian system, which is the best starting point if you want to use the BBB as a server instead of like a BBB ;) Nov 23 05:00:53 refusenick: still here/ Nov 23 05:03:17 yeah, sorry Nov 23 05:04:08 and then maybe before sinking too much time into it, hook up the ssd and see if it seems to behave well enough with postgresql Nov 23 05:04:22 (or some other test software) Nov 23 05:35:11 I just tried to post a thing about the BBBlue and ArduCopter but the machine will not work any longer. The blades, man, are not spinning. Nov 23 05:35:33 Was something updated that would break a set up, i.e. overlays or anything else? Nov 23 05:36:13 I am asking b/c I used journalctl and received some odd export denials for gpio80. Nov 23 05:36:54 you're the only one who would know whether something was updated, since you'd be the one who installed the updates :P Nov 23 05:39:15 Right. I updated and upgraded only w/ apt. Nov 23 05:39:58 I'm considering taking apart my old Toshiba Satellite laptop (broken hinge, and no reason to use it anyways) and turning it into a server attached to my router. What would be the right place to ask about that kind of stuff? Nov 23 05:40:38 refusenick: ehm, that's such a generic and off-topic question it really doesn't belong here :P Nov 23 05:41:08 Right, not here. Is there a place where it would make sense? Nov 23 05:43:14 it seems quite probable that there exist places where you might be able to get feedback on such a topic (assuming you'd be more specific) Nov 23 05:43:29 (but I don't have any suggestions) Nov 23 05:43:31 https://paste.debian.net/1117526/ is a paste of journalctl. Pastebin is acting up again. Nov 23 05:45:58 set_: that mostly just looks like the wrong device tree overlay is used for what arducopter is expecting... it's also crashing with a bus error, most likely because it's expecting pru firmware to be running (loaded by remoteproc-pru) which however isn't (and it doesn't bother to check) Nov 23 05:46:29 so this probably doesn't have anything to do with updating and everything with configuration Nov 23 05:46:36 I know. Nov 23 05:46:49 Oh. Nov 23 05:47:04 Okay. No issue. Nov 23 06:00:29 I think they, the ardupilot porters to arm, stated we were using UIO. Nov 23 06:00:45 that seems unlikely Nov 23 06:00:52 Okay. Nov 23 06:01:32 Well, I guess I will start from scratch again. Aw! Nov 23 06:01:39 or rather, I know they used to use uio but switched to remoteproc Nov 23 06:01:53 I mean, most likely the only thing you changed that broke the system is /boot/uEnv.txt Nov 23 06:02:03 Okay. Nov 23 06:02:04 that broke ardupilot I mean Nov 23 06:02:08 Right. Nov 23 06:43:48 From scratch again. There was this nice lady who wanted a video of the drone moving around. I am going to make it happen! **** BEGIN LOGGING AT Sat Nov 23 15:43:14 2019 Nov 23 21:01:24 I'm writing a bit of code for the PRU, and I'm not clear on what assembler to use. There seems to be GCC support for the PRU, does that mean I could use (correctly cross-targeted) gas? I also found https://github.com/beagleboard/am335x_pru_package which contains an assembler, are there any caveats for or against using that? Nov 23 21:03:47 pasm is probably still the best assembler Nov 23 21:05:46 there's one caveat related to how you load code: there are two kernel interfaces, the older uio-pruss (still preferred by plenty of people including myself) which allows userspace to load code directly and the newer remoteproc-pru which uses an ELF loader in the kernel Nov 23 21:06:19 uio-pruss with the libprussdrv C library only supports raw binaries as produced by pasm Nov 23 21:06:40 remoteproc-pru only supports ELF executables as produced by TI's code generation tools (CGT) for pru Nov 23 21:07:51 uio-pruss with my py-uio python library supports both types of executbles (although I do not yet support the resource table in ELF executables) Nov 23 21:08:27 I don't really know anything about the pru gcc stuff other than that it exists Nov 23 21:08:33 if one directly uses the build artifacts from pasm, that seems like a winner heh. Nov 23 21:11:01 so, a benefit of pasm is that it has some interesting features like support for structs and for variable scopes (basically you can declare some struct-type variables that are bound to certain registers and then "enter" those variable scopes in parts of your program where these bindings apply. iirc the assembler will double-check that you don't have conflicting bindings to a register) Nov 23 21:12:30 but it only produces a raw binary image for the instruction ram, it does not support multiple sections (in particular it has no support for managing symbols in a data section) Nov 23 21:14:41 btw pru support will be part of gcc 10, which isn't released yet Nov 23 21:21:15 thanks for your advice, I'm gonna go with pasm for now, is the https://github.com/beagleboard/am335x_pru_package.git repo the canonical source of pasm? Nov 23 21:22:23 yep Nov 23 21:22:25 afaik Nov 23 21:23:24 beware of the "example" apps, they're.. not great, in some cases really bad (writing to a fixed location in ram that isn't reserved for pru kind of bad) Nov 23 21:23:56 I do have a bunch of examples in https://github.com/mvduin/py-uio Nov 23 21:25:07 thanks! Nov 23 21:25:23 I imagine the docs aren't great so examples are really helpful Nov 23 21:26:18 my peripherals won't get here until monday but maybe I can be ready for them ;-) Nov 23 21:29:57 the same repo that contains pasm has a decent reference guide of pruss, the pru core, and pasm syntax Nov 23 21:30:07 (am335xPruReferenceGuide.pdf) Nov 23 21:30:40 unless you meant docs for py-uio, which are unfortunately quite lacking ;) I should really work on that Nov 23 21:32:12 ah cool, yeah I meant pasm syntax, so that's good to hear Nov 23 21:32:26 (for py-uio, besides the README there's a wiki page on github, the examples, the source code, and just asking me ;) I'm around often enough) Nov 23 21:33:49 I already sketched out most of it in pseudo-asm using the TI-provided instruction set reference in the OMAP technical reference manual, so hopefully this will be primarily an exercise in squashing assembler complaints and figuring out how to get the fscking thing to load ;-) Nov 23 21:34:24 omap technical reference manual? you mean the omap-L1xx ? Nov 23 21:35:04 yeah, OMAP-L138 Technical Reference Manual (spruh77c.pdf) Nov 23 21:35:19 some beagle-related wiki sent me there Nov 23 21:36:16 the am335x on the BBB has newer pru cores with more instructions, embedded in a PRU subsystem that's quite different from the one in the omap-L1xx Nov 23 21:36:49 oh? hrm. Does that mean I get that LOOP instruction I've seen teased in some of my googling? Nov 23 21:36:57 yep Nov 23 21:37:40 nice! although honestly, I'm pretty sure I'm already well under my cycle budget already Nov 23 21:39:38 the MVIx instructions are also new Nov 23 21:39:46 oh! and most importantly XIN/XOUT Nov 23 21:40:18 (including the pseudo-instructions ZERO and FILL to set any contiguous byte-range of the register file to all-zeros or all-ones in a single cycle) Nov 23 21:40:38 wow Nov 23 21:42:35 XIN/XOUT can also be used to transfer any contiguous byte-range between the register file and one of the three "scratchpads" (shared between the two cores), again in a single cycle Nov 23 21:44:01 or directly from core to core (which requires one to perform an XIN and the other an XOUT, which again takes a single cycle excluding the stall time of whichever of the two was first and needs to wait for the other) Nov 23 21:44:30 XIN/XOUT is also used to access the multiplier (32x32 unsigned multiply with 64-bit result and optional accumulator) Nov 23 21:51:13 hrm, I wonder if I can get any use out of that... I'd have ~1000 cycles in my current plan, to try and do some preprocessing before the sample data makes it back to the arm core for the real processing. Nov 23 21:51:44 one thing at a time though... Nov 23 21:56:07 the multiplier is not super convenient to use because the arguments and results use fixed registers, e.g. in non-accumulate mode: https://paste.debian.net/plain/1117636 Nov 23 21:58:02 (you're not required to load all 8 bytes of the product if you don't need all of them of course, although the xin only takes one cycle regardless) Nov 23 22:07:42 I'm trying to understand the MAC instructions, XOUT with r25 is just "magical" in that it configures the multiplier and/or triggers a MAC? Nov 23 22:08:35 ah nvm the diagram literally says "every XOUT of r25" so I guess yeah Nov 23 22:10:07 yes, https://paste.debian.net/1117639/ Nov 23 23:32:25 okay the MAC has some fascinating edge-cases w.r.t timing **** ENDING LOGGING AT Sun Nov 24 02:59:58 2019