**** BEGIN LOGGING AT Sat Jan 26 02:59:57 2019 Jan 26 11:52:21 good morning? is my mic on? Jan 26 11:53:05 ok, I'm trying to share the internet connection from my laptop to my beaglebone (black) using a bridge connection; Jan 26 11:53:19 but whenever the bridge connection is enabled, I can't ssh to the beaglebone. Jan 26 11:54:38 my network connections show up as follows: there's an Ethernet connection (which says "no cable connected"), an Ethernet 2 connection which apparently has a cable connected and is connecting through a ndis-compatible remote. and a wifi. Jan 26 11:54:53 I'm bridging Ethernet 2 with the wifi. Jan 26 11:55:13 (Btw, Ethernet 2 showed up when I installed the ndis network driver.) Jan 26 11:55:31 it might be easier if you'd share/bridge real ethernet instead of the USB network Jan 26 11:55:55 also you should still be able to access the serial console over CDC-ACM Jan 26 11:55:58 uhh yeah, bridging the beaglebone to your wifi is a bad idea with the beaglebone's default network setup Jan 26 11:57:15 my suggestion yesterday was to bridge your laptop's wifi to its ethernet, and then connect that ethernet port to the beaglebone Jan 26 11:58:03 indeed, that's a lot easier as it should not need configuration changes on the BBB side Jan 26 11:58:15 exactly Jan 26 12:01:16 I need to get my nickserv credentials on .irssi or something. Jan 26 12:01:38 https://freenode.net/kb/answer/irssi Jan 26 12:01:40 I keep bouncing to my linux (wsl) username. Jan 26 12:01:44 anyway. Jan 26 12:01:59 I've bridged now the wifi to the ordinary ethernet connection and can ssh to the bbb Jan 26 12:02:05 but the bbb doesn't see the internet. Jan 26 12:02:24 what does 'ip addr' show ? Jan 26 12:02:25 and you connected the BBB ethernet to youer laptop ethernet? Jan 26 12:02:39 I did try a network sharing via usb tutorial that made me change configurations on the bbb side. that may be a problem. Jan 26 12:02:42 do the port LEDs light up? Jan 26 12:03:04 what did you do exactly? Jan 26 12:03:12 also, what image are you running? Jan 26 12:04:17 uname -a returns Linux beaglebone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 armv7l GNU/Linux Jan 26 12:04:30 oh that sounds like an old and weird image Jan 26 12:04:35 rt kernel also? o.O Jan 26 12:04:52 I think that was mistakenly the default for only a brief time Jan 26 12:05:03 the html file that comes in the beaglebone board gives a few links to more recent images. Jan 26 12:05:18 yeah see https://beagleboard.org/getting-started Jan 26 12:05:28 but none of them is the "angstrom distribution". it's just debian. Jan 26 12:05:40 oh god you're still running angstrom? Jan 26 12:06:20 the box the bbb came in says "rev C". I know it's like circa 2013. Jan 26 12:06:56 please just get the latest iot image (first big download link at https://beagleboard.org/latest-images ) Jan 26 12:07:20 I'm not even going to try to support angstrom, that's from before my time :) Jan 26 12:07:59 I know I can in principle just run ubuntu or whatever, but I wanted to stay close to the defaults first. Jan 26 12:08:10 the default is debian nowadays Jan 26 12:09:03 and has been for a looooong time Jan 26 12:09:05 if you *really* want to run angstrom, you're in for a learning curve that's like the slopes of the himalaya and you won't get a free sherpa Jan 26 12:09:29 nah. as I said, I want to be close to the defaults. Jan 26 12:10:07 Except I want to skip "bonescript" as much as possible and just use python. From what I've seen there are actually multiple "bbio" libraries for python. Jan 26 12:10:16 by default the beaglebone gets shipped with the latest debian lxqt image, but unless you really want to run a graphical desktop environment on your beaglebone (hint: you don't) you should grab the latest iot image instead Jan 26 12:10:23 (libraries to use the GPIO "pins") Jan 26 12:10:25 which is why that's the first big download link Jan 26 12:11:17 Basically my experience is that I made a simple robot with Arduino once (like ten years ago) and now I want to do something physically similar but on manifolds. Jan 26 12:11:56 the sysfs gpio interface is pretty trivial to use even with pure python, but yeah there are libraries too Jan 26 12:12:11 I mean, with some reinforcement learning. not deep Q-networks or anything like that, but I'm working out what to do with online linear learners and maybe some representation learning. Jan 26 12:13:08 zmatt: since it's python, the icky bits are quickly abstracted away. if the bbio libraries are, uh, bad in some way I might as well learn the hard way to do things and write my own thing. Jan 26 12:13:47 I don't necessarily need to stay close to the arduino/processing style. Jan 26 12:14:10 I don't hold adafruit's python libraries in particularly high esteem, but they usually do work I think Jan 26 12:14:48 anyway, step one now is grabbing the debian iot image and reflashing the beaglebone Jan 26 12:15:17 already in my arduino days people were, uh, reticent about adafruit. I never bought any of their things but might want like a small alphanumeric display in the near future. Jan 26 12:15:22 yes, I'm working on that. Jan 26 12:52:28 re: this https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Jan 26 12:52:57 is this to be done on the current bbb OS, or after booting from the flash card? Jan 26 12:53:06 after booting from the flash card Jan 26 12:53:28 or you can also change the flash card's uEnv.txt in advance, but that might be tricky on windows Jan 26 12:54:23 you can find that line all the way at the bottom of the file btw, iirc Jan 26 13:04:14 I have stupid problems ssh-ing to the flashed image. I feel like I should know how to handle problems like this already. Jan 26 13:04:55 https://pastebin.com/mtnwZdSB Jan 26 13:05:14 it literally tells you how to fix it Jan 26 13:05:53 it tells me two things: 1) to use a ssh-keygen command to remove the offending line. Jan 26 13:06:31 oh crap. I was removing 192.168.*8*.2. Jan 26 13:06:54 and that's why you copy-paste those things instead of typing them over ;) Jan 26 13:09:27 I have to use the windows terminal application/"anaconda prompt" at times :/ then the keyboard shortcuts are all different. Jan 26 13:09:40 I used to have to use "git bash" as well. Before finding out about wsl. Jan 26 13:10:12 try selecting a line of text and then right-clicking twice Jan 26 13:11:26 if you have the same terminal that my wsl-using coworkers do, that should work (right-click while text has been selected copies it, right-click when no text has been selected pastes) Jan 26 13:11:53 it's a bit like primary selection on linux, except more awkward Jan 26 13:19:55 I sort of know the conventions for each. It's just that I have to use windows python because I have scripts that use excel and word. Jan 26 13:21:23 (fully off-topic: https://github.com/asemic-horizon/stanton ) Jan 26 13:29:42 I don't understand why wsl's terminal requires that extra right-click to copy text though, instead of doing e.g. what putty does by default (select to copy, right-click to paste)... I mean, there's really no reason to select text in the terminal other than to copy it Jan 26 13:33:42 something like xcopy would be nice enough. Jan 26 13:36:53 ok... the OS that came with the board let me login as root without a password. Jan 26 13:37:28 now it wants a password and it's not either an empty string nor "temppwd". Jan 26 13:37:39 it should say right there that the user is 'debian' Jan 26 13:37:41 now = after flashing. Jan 26 13:38:00 fair enough. Jan 26 13:38:26 Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018 armv7l GNU/Linux is this better? Jan 26 13:38:28 root does not have a password set and thus does not allow login Jan 26 13:38:31 syntaxfree: there's typically no good reason to log in as root, the debian user has the privileges needed for most normal use Jan 26 13:38:44 (including accessing gpio and such) Jan 26 13:38:52 zmatt: ordinarily, yes. but that was how the board came. the OS originally with the board, Angstrom. Jan 26 13:39:24 yes I know, I'm just saying that not being able to log in as root by default on current images is a feature, not a bug ;) Jan 26 13:39:33 :) Jan 26 13:40:05 also, even if a root password is configured, by default openssh server doesn't accept root login using password authentication, only using e.g. public-key authentication Jan 26 13:40:07 anyway, do I have the (or "a") correct OS now? Jan 26 13:40:16 it'a actually better to 'forget' everything you know about the angstrom image Jan 26 13:40:49 oh cool. this has numpy already. Jan 26 13:41:07 does the ethernet connection work btw? what does 'ip addr' output? Jan 26 13:41:13 (I still need to figure out networking if I'm going to use something off the shelf like scikit-learn, but I can live with numpy.) Jan 26 13:41:57 do yourself a favor and make sure it's python3 Jan 26 13:42:10 if bridging wifi to ethernet doesn't work you could also try internet connecting sharing to ethernet instead, that should definitely work Jan 26 13:42:17 yeah, I did "pip3 freeze" Jan 26 13:42:29 bridging is nicer though, if it works Jan 26 13:43:10 bridging to wifi is a bit tricky though so I'm not actually sure how windows does it... just that it simply worked when I tried it Jan 26 13:43:22 this is "ip addr" https://pastebin.com/9jNjkV1z Jan 26 13:44:00 in theory I'm bridging, althout ethernet says "network cable disconnected". it's not impossible that the ethernet on this laptop is an ex-parrot. Jan 26 13:44:02 ehh, no carrier? Jan 26 13:44:05 NO-CARRIER - do the LEDs on either side light up? Jan 26 13:44:36 are you sure the cable is okay? Jan 26 13:44:39 does the BBB automdi? Jan 26 13:44:45 of course Jan 26 13:45:03 there's a led that's always (presumably power), and two blinking leds on the other side of the ethernet metal.. box. Jan 26 13:45:04 are there any devices manufactured in the last decade that don't? Jan 26 13:45:19 the cable yes, the ethernet card on the laptop no. Jan 26 13:45:21 tbr means the leds on the ethernet connector itself Jan 26 13:45:57 green ones? no. Jan 26 13:46:20 and you can't simply connect the bbb to your internet router? (if it's on your lan then you don't need it connected to your laptop physically, as long as you have some way to power it) Jan 26 13:47:01 I have wifi repeaters with an ethernet jack. let me see. Jan 26 13:47:21 (I have a 5V power supply somewhere.) Jan 26 13:47:57 mhm, sounds like a windows side problem if it doesn't bring up that port Jan 26 13:49:10 it does. Jan 26 13:51:05 can I find something that connects to USB and does wifi? Jan 26 13:51:44 sure, a usb wifi stick (one that has a working driver in mainline linux preferably ;) Jan 26 13:52:12 you could also just try the internet connection sharing tutorial again, since it probably failed before because you were using an ancient angstrom image Jan 26 13:52:20 which one did you use? Jan 26 13:53:22 https://www.digikey.com/en/maker/blogs/how-to-connect-a-beaglebone-black-to-the-internet-using-usb Jan 26 13:53:26 it may be useful to check if you can connect to the usb serial port e.g. using putty, then you'll have a shell that works independently of any networking, which is useful when messing with networking Jan 26 13:53:37 but my problems following it screen by screen were more on the windows side. Jan 26 13:54:05 I'm not sure if configuring it to manual ip on the windows side is actually needed though Jan 26 13:54:20 I thought enabling internet connection sharing was enough, but maybe I'm wrong Jan 26 13:54:31 is the usb serial port the smaller one? shows up as COM3 on windows? Jan 26 13:55:12 "the smaller one" ? there's only one usb device port, and it makes the beaglebone appear as three devices: a storage device, a network device, and a serial device Jan 26 13:56:00 actually two types of network device, but windows only supports one of them. the other one is the USB standard compliant one for other OSes that did actually bother to implement the USB standard Jan 26 13:56:13 yes. but then there's a larger usb port on the other side that says "usb host". I didn't even try that. Jan 26 13:56:29 that's the usb host port, you can't connect that to your computer Jan 26 13:56:39 it's for connecting usb devices to the beaglebone Jan 26 13:57:05 using the usb port that also makes it appear as a storage device, etc. I'm able to ssh to the BBB on wsl. Jan 26 13:57:19 Are we talking about something else with putty? Jan 26 13:57:29 yes, putty can also connect to serial ports on windows Jan 26 13:57:35 and the beaglebone should appear as one Jan 26 13:58:04 you already said it showed up as COM3 ? Jan 26 13:58:15 in the device manager. Jan 26 13:58:35 windows is really confusing nowadays. Jan 26 13:59:09 putty does connect to the serial port. Jan 26 13:59:16 use speed 115200 Jan 26 13:59:47 you should get a login prompt if you press enter Jan 26 14:00:01 yes. I did at speed 9600 and then at 115200 too. Jan 26 14:00:25 oh never mind, I'm being silly, the "speed" is irrelevant and ignored Jan 26 14:00:44 if you ever need to use the serial console via a usb-serial cable, you will need to configure 115200 :P Jan 26 14:01:24 but anyway, now you have a way to log in on the beaglebone that doesn't depend on networking, so you can mess with settings without worrying whether it'll be the last command you can send ;) Jan 26 14:02:05 could I in principle commandeer the BBB from a 1980s PC-AT with RS232 COM ports or something? Jan 26 14:02:20 the beaglebone has no rs232 port Jan 26 14:02:40 I'd have to hack something USB. yes, yes. Jan 26 14:03:16 using an rs232 transceiver connected to the debug serial port would be more convenient than anything involving usb :P Jan 26 14:03:32 I'm not going out in high noon right now but I think plan A is to get a usb wifi stick. Jan 26 14:03:36 for the purpose of connecting it to a 1980s PC-AT Jan 26 14:04:04 well, beware that usb wifi sticks on linux are pretty hit-and-miss Jan 26 14:04:14 plenty of manufacturers don't bother with linux drivers Jan 26 14:04:43 this new OS has numpy already. besides I was having problems reading analog input from a potentiometer from the beaglebone tutorial. I'll move on to that front. Jan 26 14:05:59 numpy is the hardest thing because it's not really-really python. scikit-learn etc. can at the limit be copied over. pieces of code can be cut-and-paste. Jan 26 14:06:19 hmm, what do you mean? Jan 26 14:06:28 numpy is just a collection of python modules Jan 26 14:08:36 https://en.wikipedia.org/wiki/NumPy#The_ndarray_data_structure Jan 26 14:09:25 I used to have a version of numpy that was buggy and would crash the machine trying to allocate arrays that were too large for system memory. You simply can't do that with huge lists. Jan 26 14:11:25 I still have no idea what you're trying to say... if you try to allocate an array that's way too large then you'll probably crash one way or the other, with or without numpy. if numpy had a bug that caused inexplicably large allocations for no good reason then just upgrade numpy assuming the bug has been fixed Jan 26 14:23:41 zmatt: yes, but Python will catch that usually. Raise an exception. Or segfault. Jan 26 14:24:38 unfortunately running out of memory on linux can also just mean your process gets shot down by the OOM killer Jan 26 14:24:55 segfault would be immediate grounds for a bug report Jan 26 14:24:59 as it should be. Jan 26 14:25:05 it was an old version. Jan 26 14:25:27 I'm using it as illustration that numpy isn't really subject to the usual rules of python memory allocation. Jan 26 14:25:48 if you try to allocate a dictionary that's too large you'll get caught in python. Jan 26 14:25:51 I still don't understand what you mean by that or what argument you're trying to make Jan 26 14:26:10 I don't think that's true unless python imposes some artificial limits Jan 26 14:28:09 actually, there's probably ways to write non-memory managed code in python. it's not "idiomatic" python though. Jan 26 14:29:02 at any rate it probably needs to be linked with LAPACK and such ancient stuff. Jan 26 14:29:58 I'm probably repeating common misconceptions. Jan 26 14:30:31 I expect numpy and python to behave similar w.r.t. out of memory conditions, and if not then that's probably a bug Jan 26 14:31:20 I'm out of my depth here. Jan 26 14:31:24 though like I said, relying on graceful handling of OOM conditions on linux is a tricky thing in the first place. the only way to be sure you can always do so is by disabling overcommit Jan 26 14:31:38 I'm a mathematician, Jim, not a computer... mathematician. Jan 26 14:33:07 you're the one who was trying to make some sort of point I think, I was just trying to figure out what Jan 26 14:33:38 that as long as numpy is preinstalled I feel safe. Jan 26 14:33:39 brb. Jan 26 14:35:35 sure, like I said yesterday, major python modules will typically be packaged for most distros Jan 26 15:53:11 well, good news is I have a working ethernet connection to a wifi extender. so I'm getting all the libraries I wanted. Jan 26 15:55:31 next step in my project is reading the raw input from a three-pin pot and learning to filter it, etc. Jan 26 16:36:46 :) Jan 26 17:03:58 I reimplemented the mrf24j40 driver from scratch Jan 26 17:04:18 it seems to work Jan 26 17:04:32 https://pix.watch/1H1a48/njF_0w.png Jan 26 18:21:07 mawk: woot! Jan 26 18:30:46 in userland Jan 26 18:32:46 I'm not able to use level-triggered interrupts from userland with GPIO it seems, but apart from that it's pretty fine Jan 26 18:38:54 it's easy enough to emulate them Jan 26 18:41:17 you can either make the gpio trigger on both edges, then have its event handler check the actual level and use that to enable or disable a continuously-firing event source Jan 26 18:41:30 or you can use an uio device to actually deliver a level-triggered interrupt to userspace Jan 26 18:41:52 yeah Jan 26 18:42:16 well I don't mind spurious interrupts I think, I just watch for falling edge and check the interrupt status register Jan 26 18:42:25 it can't hurt to check, if there's nothing Jan 26 18:42:42 but I was more worried about missing edges, but that can't happen right ? Jan 26 18:43:55 it actually might, depending a bit on the details Jan 26 18:44:45 basically, you need to ensure the irq line to the beaglebone is actually deasserted, e.g. by doing { read isr, handle interrupts } in a loop until isr indicates no interrupt is pending Jan 26 18:45:46 though I'll admit that since this is a clear-on-read register, the race window (if any) would probably be a single clock cycle of your module Jan 26 18:46:58 this is assuming the bits in the isr are all events and will definitely clear on read Jan 26 18:48:32 it's clear on read yes Jan 26 18:48:41 and I handle the interrupts in a loop Jan 26 18:48:42 yes, but... Jan 26 18:48:50 ehm, how do I explain this Jan 26 18:49:00 you mean you already read isr again? Jan 26 18:49:01 but since it's not in IRQ context I can't be the one making the kernel miss an edge no ? Jan 26 18:49:05 yes Jan 26 18:49:45 the kernel won't miss an edge, the problem would be that the interrupt line might remain asserted despite an isr read Jan 26 18:49:51 while ((intstat = get_reg(fd, MRF24_INTSTAT)) != 0) { ... } Jan 26 18:49:59 ah Jan 26 18:50:06 hmm Jan 26 18:50:17 actually the interrupt *line* isn't deasserted on the IRQ status register read Jan 26 18:50:27 it's deasserted once I settle the event Jan 26 18:50:34 uhhh Jan 26 18:50:35 eg read the incoming frame for a RX event Jan 26 18:50:55 okay that sounds like the interrupt status bits are not clear-on-read but are in fact level status bits Jan 26 18:51:03 well I'm not sure about that actually Jan 26 18:51:20 the module won't send new interrupts if I don't settle the event, that's what I'm sure about Jan 26 18:51:25 you could check by reading INTSTAT again at the top of your interrupt handler, before doing anything Jan 26 18:51:39 what do you mean by "send new interrupts" here? Jan 26 18:51:56 assert the irq line again Jan 26 18:52:05 if the interrupt line remains low, the module *is* still sending you interupts Jan 26 18:52:24 I don't check that, I only check for falling edge Jan 26 18:52:29 yeah it's really clear-on-read, sorry Jan 26 18:52:48 "The INT pin will continue to signal an interrupt until the INSTAT register is read." Jan 26 18:52:56 that contradicts what you said Jan 26 18:53:01 yes Jan 26 18:53:18 well it will release the interrupt line, but not assert it again if I don't settle the event Jan 26 18:53:25 but the irq line is released as soon as I read the interrupt status register Jan 26 18:53:26 okay that's not the same thing! Jan 26 18:53:31 that's a pretty big difference Jan 26 18:53:32 yeah I made a mistake Jan 26 18:56:11 so there can't be missed interrupts that way I guess ? the kernel will register a falling edge as soon as it arrives, and (I guess) put them in the queue of incoming edges for me to read from the event file descriptor Jan 26 18:56:37 there's a single interrupt line for all the different events but that shouldn't matter, the interrupt line will stay asserted as long as there are interruptions to take care of in INTSTAT Jan 26 18:58:21 you can presumably also first ensure you consumed all intstat bits and then handle them: https://pastebin.com/RqvBy9uR Jan 26 18:58:21 and even without reading in a loop I fail to spot a race condition here Jan 26 18:58:38 I don't read INSTAT in a loop but I check for every single event possible in INTSTAT Jan 26 18:59:00 it's a read-only register, it clears on read Jan 26 18:59:00 if you don't read in a loop, then a new interrupt bit might be set on the same cycle as the read-and-clear-intstat you do Jan 26 18:59:06 ah Jan 26 18:59:09 I see Jan 26 18:59:17 in which case the interrupt line never goes high Jan 26 18:59:25 yeah Jan 26 18:59:56 ah ok I thought you were setting instat in your code Jan 26 19:00:04 yeah that's a good code idea Jan 26 19:00:16 I'll admit I don't completely know how the POLLPRI thing of sysfs works Jan 26 19:00:47 it's not sysfs, it's /dev/gpiochip1 Jan 26 19:00:51 the new interface apparently Jan 26 19:01:08 oh you're using that... I don't know anything about that interface, it seems very annoying to me Jan 26 19:01:23 and requires hardcoding gpio numbers in applications, which is awful Jan 26 19:01:44 you have a few tricks to not hardcode them Jan 26 19:01:50 but I didn't check for the reliability Jan 26 19:01:53 at least on the BBB it works Jan 26 19:02:13 if you're curious, this is how you can declare an uio device to deliver an interrupt to userspace: https://github.com/mvduin/py-uio/blob/master/dts/gpio-irq.dtsi Jan 26 19:02:22 you can just get "49", then loop through all the /dev/gpiochipX, query for the pin range (eg 32-63 for /dev/gpiochip1) then compute if 49 is in that range Jan 26 19:02:23 this example is edge-triggered, but level-triggered is supported too Jan 26 19:02:45 that sounds horrible Jan 26 19:02:48 lol Jan 26 19:02:58 some things are like that already in some tools Jan 26 19:03:09 eg for the /dev/loop devices before the master /dev/loop-ctl was invented Jan 26 19:03:11 in our applications we declare gpios in DT (including direction and, for outputs, initial state) and label them Jan 26 19:03:12 or for ttys Jan 26 19:03:16 an uio rule then creates symlinks Jan 26 19:03:23 I see Jan 26 19:03:25 and our application can simply open /dev/gpio/adc-reset Jan 26 19:03:26 or whatever Jan 26 19:03:43 without having to know or care about which gpio controller or pin it is Jan 26 19:03:51 yeah Jan 26 19:03:52 and without the security risks of having access to a whole gpio controller Jan 26 19:04:05 yeah that sounds nice Jan 26 19:04:45 it is, and it's a puzzle to me why an new mechanism was introduced that's obviously inferior Jan 26 19:05:16 maybe for the ability of setting several gpio lines at once ? Jan 26 19:06:17 I guess, but I've never really seen an application that needs that yet doesn't care about gpio performance (which is still shit if you have to perform a kernel call each time you want to toggle gpios) Jan 26 19:06:27 yeah Jan 26 19:07:18 if you do care about performance over safety, you just mmap the gpio controller, after which you can read all 32 inputs of the controller with a single load instruction and modify any subset of the 32 outputs with a single store instruction Jan 26 19:07:30 yes Jan 26 19:08:19 so it feels to me like the new interface combines the performance of the sysfs interface with the safety and convenience of the low-level interface :P Jan 26 19:08:32 lol Jan 26 19:09:02 I have trouble feeling enthausiastic about it Jan 26 19:09:26 maybe you can't set open drain or open source with sysfs also ? Jan 26 19:09:37 and active low Jan 26 19:10:29 they say the sysfs will be removed after 2020 Jan 26 19:10:31 open-drain/source isn't really supported by the hardware, it requires toggling direction between output and input (which you can via sysfs), you can configure active_low Jan 26 19:10:54 I feel like I need to write an angry rant to some mailing list then Jan 26 19:11:03 because the new interface sucks compared to the old Jan 26 19:11:32 as long as I can't expose single gpios to userspace, it is not a useful replacement Jan 26 19:11:33 lol Jan 26 19:11:45 yeah maybe they'all add a security mechanism Jan 26 19:11:52 with the new interface you request the GPIOs you want to use Jan 26 19:12:06 maybe that request could be denied at some point according to the device tree and the caller UID, or whatever Jan 26 19:12:21 you'd still need to know what gpio and what gpiochip Jan 26 19:12:26 yeah Jan 26 19:12:38 and right now I can setup privileges using udev, like usual Jan 26 19:12:55 maybe a centralized daemon that hands over the specific GPIO file descriptor over an unix socket or dbus or whatever Jan 26 19:13:00 but it's ugly Jan 26 19:14:47 I think I'd sooner just forward-port the sysfs interface Jan 26 19:14:59 the doc is contradictory Jan 26 19:15:13 they say they will continue maintaining it, but they also say they will remove it Jan 26 19:15:36 btw, in case it's useful, a C++ snippet for uio interrupts: https://pastebin.com/PKbN6BqZ Jan 26 19:16:13 sounds like the eventfd API Jan 26 19:17:29 yeah except for uio_genirq_pdrv you need to explicitly enable the irq again (after uio_wfi() for edge-triggered interrupts, or after handling the interrupt for level-triggered interrupts) Jan 26 19:18:10 I see Jan 26 19:22:06 https://pastebin.com/HQMsdRFX Jan 26 19:26:46 there, maybe better: https://pastebin.com/tarLaht8 Jan 26 19:27:30 edge-triggered interrupts generally require a bit of care to ensure correctness Jan 26 19:38:45 thanks Jan 26 19:40:59 the fd doesn't become readable immediately ? Jan 26 19:41:05 that's strange Jan 26 19:41:25 why would it? Jan 26 19:41:40 it becomes readable when the interrupt is enabled and gets triggered Jan 26 19:42:01 you put the wfi() call after it becomes readable Jan 26 19:42:18 oh yeah, wfi is badly named in this case Jan 26 19:42:21 wfi contains the read Jan 26 19:42:21 ah Jan 26 19:42:27 I see Jan 26 19:42:28 since we already know it's readable, it won't wait Jan 26 19:42:43 so I can just block on wfi if that's in a thread or something Jan 26 19:42:48 yes Jan 26 19:42:51 but ew, threads Jan 26 19:42:57 lol Jan 26 19:43:01 I don't use them usually Jan 26 19:43:06 I use epoll Jan 26 19:43:09 ditto Jan 26 20:01:37 hey, I'm looking to build my own MLO file. I downloaded the copy that is in the provided images and am trying to learn how raw mode on the SD card works with it (it seems the default images use raw mode and the linux partition is offset). Looking at the MLO file header, I see it includes a table of contents as the TRM describes. However, it does not seem to be 512 bytes long like the TRM says it has to be Jan 26 20:02:31 anyone have any idea why that is? Or how it works without having the header the full length? The TRM says it looks for execution code after the 512 byte TOC. It says anything after the 32 byte TOC should be filled with 0's until the 512th byte offset. But it's not Jan 26 20:03:10 Here's a hex dump where each row is 4 bytes long: https://i.imgur.com/CQoEmBH.png It's clear to see the TOC but then random values are after that point Jan 26 20:04:29 uhh, it is 512 bytes Jan 26 20:05:18 https://i.imgur.com/P2GXlkT.png Here's the TRM saying all other bytes MUST be 0 after the TOC Jan 26 20:05:23 you seem to be overlooking that * means a bunch of stuff is skipped Jan 26 20:05:26 specifically 0 bytes Jan 26 20:05:37 I thought that only meant 1 row was skipped Jan 26 20:05:44 if that's the case then oops. Jan 26 20:05:46 no that would be pointless Jan 26 20:06:02 That clears it up for me thank you :) Jan 26 20:06:04 use hexdump -C, it shows the actual offset in the first column Jan 26 20:06:44 https://pastebin.com/raw/chqzDG9p Jan 26 20:06:59 I see. Thank you very much :) Jan 26 20:07:22 Do you know how the header is created for the executable? I have my own executable but I need to add this TOC header to it Jan 26 20:07:49 Some people online say just cating a printf does the trick, just was wondering if there was a better way Jan 26 20:08:52 u-boot normally already prepends the header Jan 26 20:08:56 during compilation Jan 26 20:09:21 (i.e. the "MLO" file it produces isn't actually an MLO, it's the configuration header + MLO) Jan 26 20:10:05 ah okay. Last question for you, I was looking at the scripts used to create the SD card file system here https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/functions.sh Jan 26 20:10:58 If I'm understanding right, the base provided image from beagleboard does [MLO file in raw mode at block 0 - GPT Parititon Table - ext4 linux file system] Jan 26 20:11:43 Line 1237, the start offset for the GPT and ext4 file system is 4 bytes from 0x0 of the SD card Jan 26 20:11:52 uhh, I just checked the latest image, it doesn't seem to be GPT Jan 26 20:12:43 hmm. What's the format of it then? All i know is to the user you just see a single ext4 partition when you boot into linux and the MLO file is nowhere to be found Jan 26 20:12:44 MLO is at offset 256 (sectors), u-boot.img at offset 768 (sectors), partition for ext4 rootfs starts offset 8192 sectors Jan 26 20:14:34 This script seems different then. I thought this was what was used to create the images Jan 26 20:14:35 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/functions.sh#L1133 Jan 26 20:14:45 If you look at that line, the default for the MLO/SPL is 128kb offset Jan 26 20:14:59 (because of the seek=1) Jan 26 20:15:22 which is the same as 256 sectors Jan 26 20:16:28 oh? Sorry, perhaps I lack some knowledge but I thought a sector size was usually some x amount of bytes Jan 26 20:17:21 512 Jan 26 20:17:32 i.e. 0.5K Jan 26 20:17:36 hence 256 sectors = 128K Jan 26 20:17:45 holy fuck i'm retarded ya sorry Jan 26 20:17:48 https://pastebin.com/raw/VTJcEsY2 Jan 26 20:17:52 forgot it was kb for some reason Jan 26 20:18:39 so u-boot sort of ignores anything before 00400000 on the SD card? Jan 26 20:18:52 uhh, no? Jan 26 20:19:06 I mean, the partition table says the rootfs partition starts at offset 4 MB Jan 26 20:19:20 which is normal since it's a good idea to have it 4MB aligned, and it can't start at offset 0 Jan 26 20:19:50 MLO and u-boot.img are placed at fixed offsets in the otherwise empty space in between the partition table and the rootfs partition Jan 26 20:21:42 (the ROM bootloader looks for the configuration header + MLO at a few fixed offsets, and u-boot SPL hardcodes the offset where it looks for u-boot.img ) Jan 26 20:31:29 Very interesting. The DOS header is the one that tells it rootfs starts at the 4mb offset? Jan 26 20:32:06 DOS partition table* Jan 26 20:49:03 yes, that's the purpose of a partition table Jan 26 20:55:16 I'm going to work on making my own MLO for fun. Do you know what initialization it does for the board that the ROM doesn't do? The wiki is vague on the subject Jan 26 20:55:37 I assume maybe it sets up the DDRAM, do you know where in the TRM that init process might be described? Jan 26 21:33:16 I'm going to work on making my own MLO for fun. Do you know what initialization it does for the board that the ROM doesn't do? The wiki is vague on the subject. I assume maybe it sets up the DDRAM, do you know where in the TRM that init process might be described? Jan 26 21:37:38 don't repeat your question, just have patience Jan 26 21:38:06 setting up the ddr3 memory controller is indeed one of the things it does Jan 26 21:40:33 though if you want to try baremetal programming, I'd suggest leaving the memory controller for later... how about you first get a "hello world" (on the serial console) working? :) Jan 26 21:41:42 The end goal is to have a very basic kernel done so the memory will be needed :) But you're right I plan to write a basic MMC driver (since one will be needed for the MLO to load my kernel into RAM) and a basic UART driver so i can have a serial console Jan 26 21:42:15 there's 127KB of internal sram you can run in (0x402f0400 - 0x4030ffff), so that's plenty for a long time Jan 26 21:42:19 Creating a kernel is pretty well documented and I feel more confident about that, it's the bootloader process that is harder to find information about Jan 26 21:42:28 you won't need an MLO/kernel split probably Jan 26 21:42:37 just have rom load the kernel directly Jan 26 21:43:05 unless you expect to not be able to fit in 127 KB... but that would be a pretty big project Jan 26 21:43:15 That is one idea but wouldn't be nearly as fun ;) Jan 26 21:43:30 I doubt my kernel will be > 127kb, but I would like it to work with the actual DDR memory Jan 26 21:43:52 sure, but how about step 1: hello world Jan 26 21:44:27 That'll be done, the UART driver I'm not too worried about doing since I've done one for the RPi awhile ago Jan 26 21:44:28 (step 2: set up MMU and enable caches :P ) Jan 26 21:45:15 I'm asking about the memory because I'm pretty unsure about what needs to be done. I have been reading the u-boot source. board/ti/beagle/beagle.c has a get_board_mem_timings but that's the only beagleboard specific memory stuff I've seen so far Jan 26 21:45:18 (for that, in case it's useful: https://community.arm.com/processors/b/blog/posts/cortex-a8-translation-table-init-example ) Jan 26 21:45:26 Oo thanks Jan 26 21:45:59 also, in case it's interesting as example: https://github.com/mvduin/bbb-asm-demo Jan 26 21:46:20 (there's no good reason for it to be assembly, it was just something someone asked for a long while back) Jan 26 21:47:17 in my own baremetal tests, this is the only assembly source file I use: https://liktaanjeneus.nl/start.S.html (the rest being C++ with bits of inline asm) Jan 26 21:49:31 You use this as your secondary bootloader? I note comments about coming from the ROM code Jan 26 21:50:03 initializing the memory controller is not much more than writing the right values into the right registers. these are board-dependent hence you should fish them out of u-boot Jan 26 21:50:39 I don't have a secondary bootloader, just application code loaded directly by the internal ROM bootloader (baked into the SoC) Jan 26 21:51:10 And you don't bother with setting up the DDR memory in your application? I guess it's small enough? Jan 26 21:51:29 the ROM bootloader already takes care of some important early initialization, such as setting up the PLLs (even if not at max performance) Jan 26 21:51:51 yeah I haven't bothered with ddr so far Jan 26 21:51:59 and sounds good I'll keep digging through the u-boot source code. The get_mem_timings has a switch case for the differnt board revisions I'm not familair with the code base so I'm trying to see where they are set rather can just 'got' :P Jan 26 21:52:29 I have done ddr controller initialization on a similar board but it was a loooong time ago Jan 26 21:52:31 I think for this basic test I'll only need the MLO to init some UART registers (the TRM has a good amount of details on those) and get the DDR setup Jan 26 21:53:16 the uart docs are not that great though, and iirc the recommended procedure in the TRM was not great Jan 26 21:53:47 I've written a long forum post about uart initialization a long time ago, lemme see if I can find it Jan 26 21:54:21 That would be handy if you did Jan 26 21:55:34 http://e2e.ti.com/support/processors/f/791/p/379360/1342615#1342615 this thread seems to be the one Jan 26 21:56:03 a bit further down on that page I give an explicit example initialization sequence Jan 26 21:56:37 Thank you! I'll save this with my notes Jan 26 21:58:58 also, in case it's useful: https://pastebin.com/raw/BjJirieR Jan 26 22:04:11 Your links are really helpful thanks. With kernel development a lot is taken for granted when a stack is created for you already and it calls 'main' it's nice to see what you did before jumping into your C++ codebase Jan 26 22:07:12 TRM section 7.2 is all the DDR pin mapping information but yea no real info on an initialization process for it Jan 26 22:07:42 most of it is in 7.3 Jan 26 22:07:51 actually, all of it is Jan 26 22:08:06 7.2 OCMC-RAM is unrelated to ddr3 Jan 26 22:08:29 whoops ya you're right Jan 26 22:11:00 arch/arm/mach-omap2/omap3/sdr.c in the u-boot source is the only location that the beagle specific get_mem_timings is called Jan 26 22:11:28 are you sure you're looking at the right things? because that sounds wrong Jan 26 22:11:29 from what I read, the omap family of boards is TI specific so that would make sense that beagle's u-boot might run through there right? Jan 26 22:11:43 hm alright Jan 26 22:11:50 note that "beagle" most likely refers to the old omap3-based beagleboards Jan 26 22:12:11 the beaglebone uses target am335x_evm Jan 26 22:15:23 Thanks I think I found it in boards/ti/am335x/board.c -> sdram_init does a board revision check and calls config_ddr() Jan 26 22:22:03 Thanks for being patient with me matt, you've been really helpful. I'm not usually playing around at this low of a level so this is pretty interesting for me Jan 26 22:22:22 I even see in some of your comments about syscall context switching, which I'll have to do for the kernel eventually so that's nice to see too Jan 26 22:26:31 yeah, although in my codebase currently handlers use the same stack as top-level code, so although syscalls can be used there's no actual isolation between caller and callee... Jan 26 22:27:36 ah lol Jan 26 22:29:32 I have no idea what changes are needed to use separate process and handler stacks, it's been a long time since I've touched or even looked at this codebase Jan 27 02:16:19 (beaglebone black rev. c here) I bought the one wifi usb stick I managed to find that said "linux support". Jan 27 02:17:11 it appears in lsusb -t as: |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M Jan 27 02:17:36 or if just lsusb, "Bus 001 Device 005: ID 0bda:f179 Realtek Semiconductor Corp." Jan 27 02:17:56 I'm trying to follow instructions from https://github.com/lwfinger/rtlwifi_new but obviously way over my head. Jan 27 02:18:32 to begin with that "lspci" is not a command on the bbb. which is only fair because it doesn't have pci devices. Jan 27 02:20:11 oh joy, out-of-tree drivers Jan 27 02:20:50 RTL8188FTV Jan 27 02:21:35 this is the actual full output of lsusb -t https://pastebin.com/ZpsX0i78 Jan 27 02:21:42 wait what? how? Jan 27 02:21:52 "Note: If your kernel is 4.17 or newer, AND your card is not an RTL8723DE, then you should NOT be using the external driver. The built-in one is the same. Jan 27 02:22:04 hmm Jan 27 02:22:16 I don't see the RTL8188FTV listed there anyway Jan 27 02:23:35 yeah. I went in basically blind, hoping the things I don't understand would move me along. Jan 27 02:23:46 works in detective shows. Jan 27 02:24:08 I haven't found any evidence on the internet that this chip actually has a linux driver at all Jan 27 02:25:30 if you search a bit you can find people trying to track which usb wifi sticks work on the rpi, which should be a pretty solid indication they'd work on the beaglebone => https://elinux.org/RPi_USB_Wi-Fi_Adapters Jan 27 02:27:17 what information I gave you led to the conclusion "RTL8188FTV"? I'm mystified. Jan 27 02:27:19 oh yeah... "A Wi-Fi adapter will probably need more power than the Raspberry Pi USB port can provide, especially if there is a large distance from the Wi-Fi adapter to the Wi-Fi Access Point, or it is transferring large amounts of data. Therefore, you may need to plug the Wi-Fi adapter into a powered USB hub." I think that problem might occur on the bbb too, especially if the stick requires high ... Jan 27 02:27:25 ...power in bursts Jan 27 02:27:34 the usb vid/pid you listed, 0bda:f179 Jan 27 02:28:08 was easy enough to find using google Jan 27 02:28:34 interesting. Jan 27 02:29:17 anyway, I'm moving on many fronts. I'll have to leave convenient networking for later. Jan 27 02:29:29 getting internet sharing working via usb would probably be the most convenient Jan 27 02:29:58 I unearthed a wifi extender thing that had an ethernet jack. That does work. Jan 27 02:30:08 ok good, so problem solved? Jan 27 02:30:19 usb networking would probably still be more convenient Jan 27 02:30:31 yeah. I had already bought the wifi stick so I thought I'd give it a try. Jan 27 02:30:48 you mentioned you had problems following the guide's steps on the windows side? Jan 27 02:31:29 on pain of saying "my windows looks different", it does. non-english. Jan 27 02:32:46 anyway, I already have the libraries I need on the bbb. Jan 27 02:33:26 I can't imagine a different language windows would be a big problem, especially since the tutorial has screenshots? Jan 27 02:33:48 to paraphrase jeff goldblum, windows finds a way. Jan 27 02:34:20 if you have trouble following a specific step, make a screenshot and I'll see if I can provide a guess Jan 27 02:35:22 maybe I'll come back to that later. I was having trouble earlier on trying to follow the very basic tutorials on blinking a led, reading an analog input. but that was before upgrading the OS, etc. Jan 27 02:35:54 (I was able to blink leds, but not use the adafruit library to read from an analog input. Jan 27 02:36:06 I can imagine you had trouble following tutorials while you were running that ancient os Jan 27 02:36:20 ) I'll make sure I have the basics right before moving on. Jan 27 02:37:30 also, I found other guides which say you set windows to configure ip automatically... which actually matches what I remember Jan 27 02:37:39 no need to meddle with manual ip config on windows Jan 27 02:37:55 (I had a robot of sorts powered by an Arduino like a decade ago. I have to remember that kind of knowledge.) Jan 27 02:38:13 you're very helpful, thanks :) Jan 27 02:38:18 https://billwaa.wordpress.com/2014/08/03/beaglebone-black-enable-usb-internet-sharing-from-windows/ **** ENDING LOGGING AT Sun Jan 27 02:59:57 2019