**** BEGIN LOGGING AT Sat Oct 13 02:59:59 2018 Oct 13 07:29:57 How do I get started programming ARM assembly on my Beaglebone Black? Oct 13 07:52:10 you'd think someone using EmacsOS™ would be more patient… Oct 13 09:37:41 i just discovered returning points to static member variables and it makes me ANGRY Oct 13 10:30:16 ? Oct 13 11:43:56 void *foo() { static void *myPointer; return myPointer; } >:-O Oct 13 16:37:05 ayjay_t: I don't understand what you mean Oct 13 16:38:05 that construct Oct 13 16:38:13 where you _return a pointer_ that was declared locally Oct 13 16:38:27 but you can do it because its static so you know its not junk/expired Oct 13 16:38:32 ehm Oct 13 16:38:36 i just have never used that technique Oct 13 16:38:40 you're confused Oct 13 16:38:41 and i saw it for the first time yesterday Oct 13 16:38:55 and i just dont know where i'd use it Oct 13 16:39:04 i mean, it has lifetime outsides that function Oct 13 16:39:21 perhaps you meant something like Foo *foo() { static Foo myobj; return &myobj; } Oct 13 16:39:34 that's a situation where the 'static' makes all the difference Oct 13 16:39:54 in what you just said the 'static' doesn't affect lifetime of anything of relevance Oct 13 16:40:25 just the pointer variable, which is returned by copy anyway so the lifetime of the pointer variable is irrelevant Oct 13 16:40:47 right what you're saying is that whatever it points to isn't necessarily static Oct 13 16:41:00 exactly Oct 13 16:41:01 yeah i didn't think of that but your example is correct Oct 13 16:41:41 still, my sentiment remains the same Oct 13 16:42:36 interesting fact: putting a static variable inside a linkonce function (which is what "inline" means in C++) makes the static variable *also* linkonce. this means both the compiler and linker supported linkonce variables long before they were finally added to the language in C++17 Oct 13 16:42:51 *added them Oct 13 16:43:22 GET OUT Oct 13 16:43:32 because i just saw that when i was reading the docs for FlatBuffer Oct 13 16:44:17 at the time it just looked like a weird waste of code Oct 13 16:44:26 it makes sense Oct 13 16:44:33 FlatBuffer is pretty cool, btw Oct 13 16:46:02 another example is the udev_get() function in my udev++.h header: https://pastebin.com/vZnPu6m3 Oct 13 16:46:31 do checkout flatbuffer tho Oct 13 16:46:55 and another tab to read X0 Oct 13 16:47:12 in C++17 I could instead just have written inline auto const udev_singleton = udev_new(); to have a single shared udev instance for all users of udev++ within a program. (on the other hand using a function avoids having to worry about initialization order) Oct 13 16:47:22 * zmatt google flatbuffer Oct 13 16:47:47 interesting Oct 13 16:50:20 I use dbus value encoding as serialization format for a few things, mostly because those application use dbus anyway so might as well use its serialization for other things. it's a bit of an abomination though Oct 13 16:50:49 X0 ? Oct 13 16:51:18 thats my dead face Oct 13 16:52:02 yeah i think that the point of flatbuffer is that you wont be seralization/deserializing things anymore Oct 13 16:52:34 i can see that being helpful maybe in streaming cases or "big data" type things Oct 13 17:09:36 you still are serializing/deserializing. but if you're only interested in a specific small bit you don't have to deserialize *everything* Oct 13 17:18:24 well theoretically you can search for the value via some function and cast it to the appropriate type when it returns Oct 13 17:18:30 is that deserializing? Oct 13 17:20:21 its not storing values in ascii Oct 13 17:20:45 it just has to reference a vtable to find the value's location instead of having a direct pointer (if you're using C like i would be) Oct 13 17:21:10 i think this is a filesystem, tbh Oct 13 17:28:27 not really Oct 13 17:30:00 btw I noticed in uxmux that you're defining non-inline non-static functions in a header file (uxmux.h). that's a really big no-no :P Oct 13 17:31:41 given that they're substantially big functions, they should simply live in a .cc file (or .cpp as you've weirdly decided to use) Oct 13 18:20:31 yeah i lknow Oct 13 18:20:33 its hillarious Oct 13 18:20:36 its keelin, when he started Oct 13 18:20:52 wicked talented guy, but for the first year i still had to actually go into his code and be like HEY Oct 13 18:20:55 HEY STOP THAT Oct 13 18:21:29 uxmux is again, my architecture, my concept, but an intern's implementation Oct 13 18:21:54 now i'm reading about data structures for spatial indexes which was an unplanned tangent but ill get to uxmux eventual XD Oct 13 18:28:02 ayjay_t: "btw I noticed in uxmux that your intern is defining non-inline non-static functions in a header file (uxmux.h). that's a really big no-no :P" Oct 13 18:28:05 better? Oct 13 18:28:05 :P Oct 13 18:31:58 oh sorry I completely misread you Oct 13 18:32:50 ha yeah Oct 13 18:33:01 my eyes initially fell on "HEY STOP THAT" and I was "wait, what did I do wrong?" Oct 13 18:33:07 the project never made it to market as a commercial solution so it didn't get the same attention Oct 13 18:33:15 my bad Oct 13 18:33:28 no, my bad for not actually reading what you said Oct 13 18:34:26 so, did he in the end understand the purpose of header files and why the linker starts yelling at you if you define (non-static non-inline) functions there? ;) Oct 13 18:36:43 (along with what happens differently if you just stick 'static' or 'inline' on one, and what their downsides are) Oct 13 18:41:43 yeah we've spent a lot of time on C together Oct 13 18:42:05 so i think he understand the role header and content(?) files play in declaring/defining objects Oct 13 18:42:31 but i generally keep people away from C++ because its just too hard to manage, takes too long to teach, changes too quickly etc Oct 13 18:43:01 i can take a talented college student and make them pretty competent in C in ~6 mo, but C++ is going to be a two year struggle Oct 13 18:43:05 sure. apart from 'inline' the story is the same on this part anyway Oct 13 18:43:26 actually thats a reason why golang is awesome, because python/javascript programmers don't fear it like they fear C Oct 13 18:43:36 and it really is very much like C Oct 13 18:44:03 its just impossible to read at first because they changed the order of all the declarations XD Oct 13 18:44:18 var type = value; Oct 13 18:44:24 speaking of 'inline', have you ever seen how C99 'extern inline' works? :) Oct 13 18:44:53 no thats... that's hold on Oct 13 18:44:58 https://github.com/mvduin/inline-not-inlined Oct 13 18:44:59 let me wrap my head around whats going on Oct 13 18:45:31 extern is declaring something but saying "you will link to something outside this scope at link-time" right? Oct 13 18:45:44 i use it when i want to access variables i've declared elsewhere, that much i know Oct 13 18:45:53 extern inline means "here's the definition in case you want to inline it, but if you don't want to inline it then just pretend this is a normal declaration, the actual implementation will be provided at link-time as usual) Oct 13 18:46:16 that optionality is really weird Oct 13 18:46:22 but i guess i can see a use Oct 13 18:46:34 the worst part of inline is that i guess inline is always kind of optional to gcc? Oct 13 18:46:47 there's [[gnu::always_inline]] Oct 13 18:46:54 but normally you want to leave the decision to the compiler Oct 13 18:47:11 in C++ the keyword 'inline' doesn't really have anything whatsoever to do with inlining anymore Oct 13 18:47:17 it just means "linkonce" Oct 13 18:47:23 yeah i mean sometimes i'm writing code where i'm trying to count cycles and stuff, so i might write some assembly block and wrap in an inline function Oct 13 18:47:30 i don't really know what linkonce means Oct 13 18:48:03 so normally if the linker encounters two definitions for a global symbol, it will simply print an error and give up Oct 13 18:48:36 linkonce means the compiler will simply keep one definition, discard the other(s) and fix up any references to them to the definition that was kept Oct 13 18:48:57 O_o Oct 13 18:49:05 so ignoring collisions, basically? Oct 13 18:49:17 that seems better suited for a #pragma than a keyword Oct 13 18:49:21 yes, under the assumptions all definitions are equivalent Oct 13 18:49:23 nono Oct 13 18:49:38 like I said: it's the behaviour introduced by the C++ keyword "inline" Oct 13 18:49:54 im not mad at you, zmatt, i'm mad at C++ Oct 13 18:50:08 i'm mad at zmatt for taking this really intuitive concept, "inline" Oct 13 18:50:16 and just... i mean whateven? Oct 13 18:50:50 sorry if i'm not seeing the benefit of this Oct 13 18:51:10 linkonce is pretty intuitive too: it means you can put such a definition safely in a header that's included by multiple object files, since the linker will clean up the duplicate definitions Oct 13 18:51:38 but don't you think it would be better to have a "linkonce" keyword and an "inline" keyword Oct 13 18:51:56 i mean, sometimes you want inline. Oct 13 18:52:34 * ayjay_t shrugs Oct 13 18:52:36 "inline" is an optimization hint that's ignored afaik by modern compilers. old compilers were too stupid to make such decisions on their own Oct 13 18:52:49 I mean, old "inline" Oct 13 18:52:54 C inline Oct 13 18:52:57 yeah, that's one way of looking at it i guess Oct 13 18:53:07 i _like_ see because if I set -O0 i know _exactly- what my assembly is going to look like Oct 13 18:53:21 and that was an important educational component of C for me Oct 13 18:53:24 -O0 prevents inlining afaik Oct 13 18:53:28 HAHA i said "see" instead of "c" :P Oct 13 18:53:50 or just compile with -fno-inline if you want to prevent inlining Oct 13 18:54:02 to me, the C keywords "enum" and "inline" were basically the C-keyword versions of #define Oct 13 18:54:18 benefits include being scoped. Oct 13 18:54:18 o.O Oct 13 18:54:35 I don't understand what inline has to do with enum or #define Oct 13 18:54:40 i mean, you can effectively acheive the same mechanisms with #define and the "classic" "old" inline, right? Oct 13 18:54:49 no Oct 13 18:54:57 #define someFunction(arguments) actuallyProgrammingBlock;etc; Oct 13 18:55:04 except you don't hvae scoping benefits Oct 13 18:55:19 I have no idea what you're trying to say Oct 13 18:55:37 well, either way, i use #defines in a similiar way to how i intend to use enum and inline Oct 13 18:55:46 ??????? Oct 13 18:55:52 FUNCTIONALLTY Oct 13 18:55:53 what do these things have to do with each other? Oct 13 18:56:06 ill have to find an example later Oct 13 18:56:15 so, let me clarify how 'inline' became to mean 'linkonce' Oct 13 18:56:19 sure Oct 13 18:58:49 https://gist.github.com/ayjayt/120281b87200a594c0a9027d370fafef Oct 13 19:00:00 so, to be able to inline a function, the compiler obviously needs to have the implementation of that function available at the site where that function is called. this means that if you want some function that's used by various code to be inlinable, you need to provide its definition in the header file Oct 13 19:00:31 but doing so normally resulted in failure: it results in duplicate definitions of the function, and hence the linker craps out Oct 13 19:01:27 yeah that does make sense Oct 13 19:01:31 that also explains extern inline Oct 13 19:01:32 one solution often used in C is "static inline", which makes the function a local symbol and avoids the problem Oct 13 19:01:37 wait or maybe... maybe not Oct 13 19:01:42 yeah Oct 13 19:01:45 (it does yes) Oct 13 19:02:19 the downside of static inline of course is that if the compiler can't inline it for whatever reason, a copy of the function ends up being emitted in every .o file that uses it Oct 13 19:02:42 so you'd end up with a lot of pointless code duplication in your binary Oct 13 19:02:43 are we talking about static inline declared in a .h file? Oct 13 19:02:54 yeah Oct 13 19:02:58 okay Oct 13 19:03:23 or just 'static' in a .h since inline is just an optimization hint :P Oct 13 19:03:33 yeah static in .h seems weird to me in general Oct 13 19:03:37 but i guess it has a place Oct 13 19:03:41 extern inline is another solution Oct 13 19:03:52 does that just allow you to forget to define it? Oct 13 19:03:59 it also prevents collisions? Oct 13 19:05:11 extern inline means that if the compiler can't inline it, it will simply leave it as an undefined reference, to be resolved at link time. in other words, *some* .o has to provide the out-of-line definition Oct 13 19:05:41 note that gcc used to have an 'extern inline' as extension that's different from the C99 one Oct 13 19:05:57 interesting and weird Oct 13 19:06:05 and i still just want inlines that inline lol Oct 13 19:06:25 and honestly collisions among similiarly defined functions are no differentw ether they're inline or not Oct 13 19:06:50 if they're exposed in header files Oct 13 19:06:57 * ayjay_t flips over the desk Oct 13 19:07:11 * ayjay_t meant similiarly named functions Oct 13 19:07:49 hold on I was wrong about something earlier Oct 13 19:08:17 'inline' was only introduced in C99 ? Oct 13 19:08:55 okay I was really confused for a bit it seems Oct 13 19:11:34 okay, I think actually C++ introduced 'inline', gnu added an 'inline' keyword as C extension (that behaves differently but serves a similar goal), and finally C99 added 'inline' to the C standard, but did not match GCC's definition (after which GCC dumped their 'inline' in favor of the C99 one) Oct 13 19:11:41 i mean i'm pretty sure that, both `inline` and `volatile` and really well behaved keywords Oct 13 19:12:08 aren't* wow my typing accuracy is terrible right now i need to slow down. Oct 13 19:16:46 https://pastebin.com/TZBNZafT Oct 13 19:18:27 so they're really similar, and they work in the same way (header provides definition for inlining purposes, when not inlined compiler pretends it as a normal declaration and expects some source file to provide a real definition of the function) Oct 13 19:18:43 but the C99 version is smart enough to avoid having the write the function definition twice Oct 13 19:19:02 it looks weird though Oct 13 19:19:28 I mean, the header contains a declaration that looks like a definition, and the C file contains a definition that looks like a declaration XD Oct 13 19:22:43 sooo, anyway, back to C++. they didn't want to deal with manually providing an out-of-line definition of each inline function, and in fact templates make doing so basically impossible, so they just said to compiler vendors "just figure something out" Oct 13 19:27:10 after some experimentation, the solution everyone seems to have gravitated to is: whenever the compiler needs an out-of-line definition for some "inline" function, just emit it, but mark it as "linkonce" to let the linker unify any duplicates (produced when another .o also needed an out-of-line definition of the same "inline" function) Oct 13 19:29:08 the downside is that the compiler may end up doing some pointless work (compiling a defintion that ends up being discarded as "duplicate" by the linker), but it has a huge benefit that it Simply Works(tm) Oct 13 19:31:06 alright i have to get through all these tabs i have open. i have literally 20 tabs on different data structures open. really trying to find the best data structure to represent maps with routes that take up space. Oct 13 19:31:34 trying to solve nearest neighbor and continuity problems since the routes are made up of discrete vector shapes Oct 13 19:38:15 oh right, and the final point I was coming to: the end result is that C++ inline functions are simply function definitions (which the compiler may use for inlining), and the "inline" keyword makes the compiler mark the symbol as linkonce (and the compiler may discard the symbol if it has no need for it in this compilation unit) Oct 13 19:39:16 the word "inline" still refers to the goal of the keyword, even if it doesn't describe the actual effect of the keyword (since that effect was settled on after the keyword was introduced in the first place) Oct 13 19:40:21 and then in C++17 they fully embraced that inline just means "linkonce" by allowing it to be used for linkonce variables (inline int x = 42;) Oct 13 19:40:53 which concludes the journey ;) Oct 13 19:43:28 brb Oct 13 21:00:03 Would a book on ARM assembly atop the RasPi be applicable to the BBB? I can't find anything on assembly for the BBB. Oct 13 21:01:42 dispor: the BBB's cortex-a8 is roughly the same generation as the pi (newer than the pi1, older than the pi2) Oct 13 21:04:55 in general all ARM arch v7 cores (32-bit ARM-cortex) have the same basic instruction set, and just vary in optional instructions (e.g. Neon) and the fine details of system-level programming Oct 13 21:05:30 what's the book about? why does it use an rpi? Oct 13 21:07:00 dispor: hello? Oct 13 21:10:31 Hello! Oct 13 21:11:23 I got my reverse w/ the MotorCape working w/ Adafruit_BBIO w/ a Flask app and HTML! Oct 13 21:11:30 PWM! Oct 13 21:17:08 dispor: note that if you want to learn ARM assembly programming, you don't even need any ARM board. a cross-compiler and qemu-user suffice: https://pastebin.com/raw/9b3bVwv4 Oct 13 21:22:26 Now...onto hardware! Oct 13 21:23:24 Four !'s and no end in sight. Oct 13 21:23:25 Ha. Oct 13 21:25:32 set_ and his toys. Oct 13 21:26:01 Toys to Machines! That has a nice ring to it. Oct 13 21:26:46 I got some angle iron the other day. I am about to get nasty w/ this machine. Oct 13 21:27:10 Tiny bots w/ many uses. I cannot wait. Oct 13 21:28:18 dispor: one important thing to keep in mind is that the original rpi had an ARM architecture v6 core (an arm1176jzf-s), unlike the rpi2 and bbb which have v7 cores. This means for example that it doesn't have Thumb-2, hence you'd probably make little or no use of the thumb instruction set on that Oct 13 21:29:09 mowing, slicing branches, bringing me my laundry. Oct 13 21:29:23 in contrast, on v7 you can and typically would write your whole program in thumb (since the thumb-2 instruction set is basically just as expressive as the original instruction set, but has better code density) Oct 13 21:30:10 there's really no good reason to ever leave thumb mode on an arch v7 core (except some really old cortex-a8 revisions which had buggy thumb) Oct 13 21:30:24 brb Oct 13 21:38:55 zmatt: http://bob.cs.sonoma.edu/IntroCompOrg-RPi/intro-co-rpi.html <- this is the one that I've found Oct 13 21:39:15 I've found multiple RPi tutorials, but none for the BBB. Oct 13 21:39:56 (asm tutorials) Oct 13 21:43:35 for learning assembly it doesn't really matter, except if it's aimed at the old rpi then it'll be teaching you an old dialect for an obsolete architecture Oct 13 21:44:28 also if it does stuff like playing with hardware via /dev/mem, those bits would not be portable to other SoCs Oct 13 21:44:34 oh it does, in chapter 19 Oct 13 21:44:49 ah, it uses unified syntax! Oct 13 21:44:51 never mind then Oct 13 21:45:25 so you're typically not going to find a "Learn ARM assembly using " since the board is largely irrelevant Oct 13 21:45:38 if you want to learn ARM assembly, look for resources on ARM assembly Oct 13 21:46:00 (ARM-v7A specifically) Oct 13 21:47:57 Okay, thanks. Oct 13 21:48:34 and in case you're curious, I actually have a tiny baremetal example for the bbb written in assembly: https://github.com/mvduin/bbb-asm-demo Oct 13 21:49:37 i.e. the beaglebone can load and execute this program directly (instead of loading and executing u-boot's first stage, which then loads u-boot second stage, which then loads linux) Oct 13 21:49:45 zmatt: Awesome, thanks! Oct 13 21:50:04 Will I be fine if I already know C and C++? Oct 13 21:50:13 obviously it's much simpler and safer (and much more portable!) to get started with linux userspace programming Oct 13 21:50:32 if you already know C, assembly is not hard Oct 13 21:50:39 Cool. Oct 13 21:51:25 it's just rather... verbose, and "manual" in compared to typical programming languages Oct 13 21:54:26 why do you want to learn assembly? Oct 13 22:19:33 ah this is a book on computer architecture, it's just using the ARM architecture and Raspberry Pi as examples Oct 13 22:31:20 zmatt: From u-boot (cli), it is possible to execute a bare-metal program loaded in memory? Oct 13 22:31:54 yes Oct 13 22:32:14 I think anyway Oct 13 22:32:15 Neat Oct 13 22:32:44 no idea what it's named though Oct 13 22:32:46 why? Oct 13 22:33:42 just curious, as always Oct 13 22:35:59 the "go" command calls a function at a given address (with the prototype of 'main'. extra arguments to the go command are passed along to the function) Oct 13 22:36:42 I think there might be another command which provides a cleaner environment (but no way to return to u-boot) Oct 13 22:37:06 or maybe not, hmm Oct 13 22:39:41 it is not like set te program counter to that address, is it? Oct 13 22:40:45 I thought it would normally undo its mmu/cache setup, but maybe I'm mistaken Oct 13 22:44:14 yeah, no, it doesn't Oct 13 22:46:37 it only disables data caching when booting qnx or vxworks (since apparently those crap their parts if you boot them up with data cache enabled) Oct 13 22:51:35 mmu is disabled? Oct 13 23:01:07 no Oct 13 23:01:44 (can't enable data cache unless you first configure and enable the mmu) Oct 14 00:45:57 I'm having trouble ssh'ing into my BBB. ssh debian@192.168.7.2 hangs and tells me "connection timed out". Any ideas? Oct 14 01:18:03 diskp: not a lot of time to help, but are you sure it's actually up and that's the right IP? a timeout suggests that the remote endpoint isn't responding at all. Oct 14 01:19:25 diskp: did you tried with 192.168.6.2? Oct 14 01:20:32 Have you tried* Oct 14 01:24:47 can you ping 7.2 ? Oct 14 01:25:27 or 6.2 - whatever your usb ethernet interface is. Oct 14 01:35:15 (7.2 on windows, 6.2 on mac, both should work on linux) Oct 14 01:36:30 CoffeeBreakfast_: strange things happen on the cortex-a8 with the mmu disabled though, as I discovered years ago: https://community.arm.com/processors/f/discussions/3650/cortex-a8-mmu-disabled-behaviour Oct 14 01:40:18 (so I technically lied when I said you can't enable caches while mmu is disabled, you just really don't want to) Oct 14 01:55:58 zmatt: thanks! Oct 14 02:01:18 shame I never got any reply to my open questions, but *oh well* Oct 14 02:06:26 setting up the mmu (in a basic way) is pretty easy though => https://community.arm.com/processors/b/blog/posts/cortex-a8-translation-table-init-example (this sets up the translation table, after which you can enable mmu+caches with one MMU register write) Oct 14 02:06:49 sorry, two writes Oct 14 02:07:24 Imagine having those VHDL/verilog of the Cortex-A8... The CortexM0 is free but obfuscated, and no MMU Oct 14 02:11:28 (good to have that mmu.c) Oct 14 02:15:02 I'd still like to release (some or all) of my baremetal C++ codebase for the am335x as open source Oct 14 02:36:23 CoffeeBreakfast_ zmatt Snert: I tried pinging both 192.168.6.2 and 7.2; both returned nothing back. Oct 14 02:37:29 diskp: what os are you using on your computer? Oct 14 02:38:00 also, you may want to reflash the beaglebone to the latest image to ensure it's not running ancient stuff Oct 14 02:38:45 zmatt: I think it might still be Angstrom, but ssh'ing over on Arch (eventually) told me that the user account was called "debian". Oct 14 02:38:56 o.O Oct 14 02:39:06 in other words it's running something dubious and unknown? Oct 14 02:39:09 ;) Oct 14 02:39:18 Is that a reference to something? Oct 14 02:40:16 Anyways, I'll see if flashing it with a new ISO changes anything. Oct 14 02:40:23 no, I just meant... the beaglebone is apparently old enough that you suspected it might still be running angstrom, but it is in fact running *some* version of debian? and it appers on Arch but not on what OS? Oct 14 02:40:35 Devuan atm Oct 14 02:40:39 yeah it might be a good idea to get the latest stretch-iot image Oct 14 02:40:57 oh wait, if this is an old bbb... what revision? Oct 14 02:41:10 I forget. Oct 14 02:41:21 Let me see if I have something saying which one. Oct 14 02:41:37 wait you can log in anyway... what's the eMMC size? Oct 14 02:43:08 I can't log in to it. Oct 14 02:43:17 And I don't know. Oct 14 02:43:24 I'm new to this. Oct 14 02:43:28 since even the iot image has become too fatso to be flashed onto a 2GB eMMC. so you'd either need to flash the console image or boot from sd instead of reflashing Oct 14 02:43:44 I think it's less than 1GB. Oct 14 02:43:50 Or 1GB. Oct 14 02:43:52 I forget. Oct 14 02:43:54 it's either 2 or 4 Oct 14 02:43:57 Oh. Oct 14 02:44:34 How can an "IoT" image be too big for 2GB of eMMC? I Oct 14 02:44:37 (2 or 4 "gigabytes", i.e. 1.8 or 3.7 ) Oct 14 02:44:41 I don't know Oct 14 02:44:58 I've heard of Forth OSes measured in 10s of KB. Oct 14 02:45:06 but, wait, you got something that told you the log in was debian, but you can't log in ? Oct 14 02:45:14 forth can be pretty small yeah Oct 14 02:45:23 This was on Arch, a week ago. Oct 14 02:45:38 so you were able to log in, but no longer? Oct 14 02:45:44 Yep. Oct 14 02:46:04 have you tried connecting it via ethernet instead of using usb-networking, just in case Oct 14 02:46:17 I don't know what I did to get it to finally work. I thought "ssh 192.168.7.2 -l root" had solved my problem, but I guess not. Oct 14 02:47:03 if it's an older image then it might only have an rndis interface (instead of both rndis and cdc-ecm), and I can imagine devuan to be the sort of jerks to disable the rndis driver in the kernel because "ew it's a microsoft proprietary protocol" :P Oct 14 02:47:17 you can't ssh in as root Oct 14 02:47:50 or rather, you can't ssh in as root using password authentication, only using public-key authentication (this is the default of openssh server these days, and debian keeps that default) Oct 14 02:47:53 I tried a bunch of different things from different forum threads from years ago. One of them worked. Oct 14 02:48:27 If I flash it with a new image, it should have the needed drivers? Would NetBSD be small enough? Oct 14 02:48:38 so, the eMMC as labeled here: https://cdn-images-1.medium.com/max/1135/1*hhZdj1Yvk1ao9n0hvXUmow.png Oct 14 02:49:13 is yours micron with BGA marking JW896 ? Oct 14 02:49:42 needed drivers? drivers for what? Oct 14 02:50:13 if you boot the latest image on the beaglebone, it should work on mac, linux, and windows, without having to do any manual driver installation or such Oct 14 02:50:52 My eMMC is labled Kingston. Oct 14 02:51:03 then it's 4 GB Oct 14 02:51:08 Awesome. Oct 14 02:51:22 cdc-ecm drivers Oct 14 02:52:09 so I'd suggest downloading the latest stretch-iot image and reflash the beaglebone (you can turn a bootable sd card into an eMMC-flasher by uncommenting the line in /boot/uEnv.txt that says something about eMMC flasher, I think it's the last line) Oct 14 02:52:26 those come with the OS, you don't need to worry about it Oct 14 02:53:41 should you choose to continue booting from sd card rather than reflashing eMMC, I highly recommend wiping eMMC (or at least sector 256 of eMMC) to ensure the beaglebone will load u-boot from sd card rather than from eMMC (which can cause issues) **** ENDING LOGGING AT Sun Oct 14 03:00:00 2018