**** BEGIN LOGGING AT Wed Jul 24 02:59:57 2019 Jul 24 03:00:15 uh oh, looks like I broke something Jul 24 03:03:43 and it's un-broken! Jul 24 03:04:22 it seems roboticscape have an issue with node 10, I can only get it to work on node 6 Jul 24 03:06:24 Aw! Jul 24 03:09:23 GenTooMan: Where is this LED example you were discussing? Jul 24 03:10:43 Skalwalker: I think the person that owns that github page for roboticscape npm thing had come across an issue. Jul 24 03:11:07 Did you look online for GitHub and the updated versions on it? Jul 24 03:13:05 https://github.com/jadonk/node-roboticscape is the page, right? Jul 24 03:13:54 yes Jul 24 03:14:20 Skalwalker: nodejs does have a tedency to break their API every major release Jul 24 03:14:46 (mostly due to v8 rather than nodejs itself) Jul 24 03:15:15 I need to use ES6 async keyword, what should I do? Jul 24 03:16:29 report an issue I guess Jul 24 03:16:52 =( Jul 24 03:17:08 with a bit more information than http://paste.debian.net/1092820/ if you can... this output doesn't seem to be showing any errors, other than the fact compilation failed for some reason Jul 24 03:18:01 one sec Jul 24 03:19:49 http://paste.debian.net/1092843/ Jul 24 03:20:16 yeah those are errors due to API changes in the V8 engine Jul 24 03:20:31 actually most of these are warnings Jul 24 03:21:21 maybe updating to a newer version of nan would help Jul 24 03:22:29 since the actual error occurs in nan Jul 24 03:22:37 ../node_modules/nan/nan_maybe_43_inl.h:112:15: error: ‘class v8::Object’ has no member named ‘ForceSet’ Jul 24 03:22:50 hmmm in the package.json? Jul 24 03:23:55 try "npm install nan" Jul 24 03:24:31 that will install the latest version of the nan package (into the node_modules directory) and update package.json accordingly Jul 24 03:24:50 of course it's possible that that will break everything, but it's at least worth a shot Jul 24 03:25:56 unfortunately until the introduction of the "nodejs native api' (NAPI), keeping modules working with each nodejs release required constant effort Jul 24 03:26:25 now it just requires one-time effort, to switch to using NAPI :P (which has a stability guarantee) Jul 24 03:31:26 rebooting with a kernel that actually supports my SD card reader this time... Jul 24 03:31:49 what kind of obscure card reader do you have that it needs a particular kernel? Jul 24 03:31:58 Sometimes node breaks my cloud9 Jul 24 03:32:06 it loses all my routes Jul 24 03:32:15 hope not Jul 24 03:32:21 I know absolutely nothing about cloud9, I've never used it Jul 24 03:32:53 you connect only through ssh? Jul 24 03:33:17 yeah I don't normally run a webserver on beaglebones Jul 24 03:35:21 hmm upgrading nan did not work Jul 24 03:36:05 yeah unless you already have experience with getting nodejs C++ modules to work, you probably don't have much hope of fixing this yourself Jul 24 03:36:13 just open an issue on github Jul 24 03:37:58 the best solution would be to switch to using NAPI, although that will require more effort than doing just the bare minimum to get things working in nodejs 10... (having said that, doing just the bare minimum to get it working with nodejs 10 will pretty much guarantee that it will stlil be horribly broken for nodejs 12) Jul 24 03:37:59 I will, I don't have much hope though Jul 24 03:38:48 maybe I'll look at it if I have a moment of motivation... I unfortunately have a fair bit of experience with nodejs C++ modules (which is not really experience I'd wish onto anyone) Jul 24 03:39:38 Ha! Jul 24 03:40:14 at some point I even ended up digging through the bowels of the V8 engine's garbage collector to figure out how certain GC callbacks worked (which, like pretty much all of the V8 api, are of course completely undocumented) Jul 24 03:41:08 lack of documentation and breaking changes in every release make the V8 API truly a delight to work with Jul 24 03:43:01 the non-stop breaking changes are probably also why nodejs perpetually uses an old V8 release... so whenever you read about cool new features in the V8 engine, you can think to yourself "awesome! I can't wait until I get the benefit of these in my nodejs application 10 years from now!" Jul 24 16:38:38 Hi all. I'm searching for the filepath to access the bmp sensor information on the beaglebone blue. I need the temperature data that's returned by rc_test_bmp in the command line. Where can I find it in the system directories? Jul 24 16:52:52 On the same note, is there a reference sheet that tells where to find various sensor data files on the blue? Jul 24 17:05:48 Hi all, I am trying to load a RS485 driver using dt overlays. Jul 24 17:05:57 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts Jul 24 17:06:45 I have one question here that why are we using gpio3_19 as de and re pin Jul 24 17:08:05 And why not gpio0_9 Jul 24 17:08:20 which is the pin for UART4_RTSN Jul 24 17:09:22 What changes do I need to make if I want to use this pin ( gpio0_9 ) for de/re Jul 24 18:59:02 hi Jul 24 18:59:31 how do I get beaglebone back drive in a zip file? Jul 24 18:59:37 drivers Jul 24 19:00:55 why? latest default image uses all the major OS's built-in drivers.. Jul 24 19:02:36 how do I update the latest image? Jul 24 19:03:22 sorry, i'm new to beagle Jul 24 19:04:22 NVM. I found the link for it Jul 24 19:04:23 please read: https://beagleboard.org/getting-started#update Jul 24 19:04:30 thanks Jul 24 19:17:59 Does someone know where a C example of blinking an LED would be located online? Jul 24 19:18:07 I will check my books again while I wait. Jul 24 19:18:41 I checked the beagleboard google groups and came across: https://github.com/piranha32/IOoo Jul 24 19:18:42 ... Jul 24 19:19:02 make does not work in that directory. Jul 24 19:19:04 Aw! Jul 24 19:42:57 How can I change, in C/C++ source, a path to make my GPIO understand it is being called on to make my external LED light? Jul 24 19:43:08 Wait for the paste. Jul 24 19:44:36 https://pastebin.com/8NLGkcEr is the PATH for an internal LED but I am trying to hamper down on the external LED. I got this #define from a Molloy book. Jul 24 19:44:37 ... Jul 24 19:49:00 I mean...is this it? "/sys/class/gpio/xxxxx/xxxxx/" where /xxxxx/xxxxx/ is the export of the gpio I need to export? Jul 24 19:56:03 Okay. Jul 24 19:56:38 I have /sys/class/gpio/gpio60/ turning on and off w/ direction and value. Jul 24 19:57:12 Now, is my new PATH this PATH of /sys/class/gpio/gpio60 or should I try something else? Off to test? Jul 24 20:06:52 https://pastebin.com/A6ztsqVP is the update. Please hold for the source. Jul 24 20:09:34 https://pastebin.com/Rm3tv1Gc is the source from the Molloy book but changed to suit my needs of this external LED w/ the specific PATH. Jul 24 20:12:45 I added #include , too. Jul 24 20:12:49 No go so far. Jul 24 20:13:32 maybe you should check if the path exists? Jul 24 20:14:05 that is parse the path (in sw) until the path fails then throw a fit out stdout to that affect. Jul 24 20:14:22 Okay. Jul 24 20:14:43 Hey GenTooMan: I have been reading up here ---> https://android.googlesource.com/kernel/omap/+/glass-omap-xrr02/Documentation/gpio.txt. Jul 24 20:15:15 you have used standard C library file path stuff before? Jul 24 20:15:28 Not really. Jul 24 20:15:38 I am a boon's farm on this one. Jul 24 20:16:09 echo 60 > export Jul 24 20:16:20 That is how I made the P9_12 pin available. Jul 24 20:19:05 Oh ... that would help a LOT. What you have to do is split up the path directory for directory and find each section this isn't so simple but it will tell you if it's there. Jul 24 20:19:32 Okay. Jul 24 20:20:04 you should generally not manually construct (let alone hardcode) paths into /sys, except in very specific cases Jul 24 20:20:32 Oh. Jul 24 20:21:15 ex /proc/cpuinfo you parse out /proc find if it exists then parse out cpuinfo and see if it exists. zmatt is correct hard coded paths is always problematic. Every system is different. Jul 24 20:21:18 easiest way to deal with /sys is to use udev rules to detect devices you care about and create convenient symlinks Jul 24 20:22:42 for the most part, the directory structure of /sys is not stable hence hardcoding paths may result in an application that will break on a different kernel version, or sometimes even just if the device tree is modified subtly Jul 24 20:23:17 Okay. Jul 24 20:23:54 for examples, for gpios I use an udev rule that creates /dev/gpio/$NAME? symlinks where the $NAME is determined by the gpio's declaration in DT Jul 24 20:24:37 Okay. Jul 24 20:24:43 in case you're using cape-universal, those names would be of the form P8_xx and P9_xx for various values of xx Jul 24 20:25:07 I am using P9_12 right now for one GPIO triggered LED. Jul 24 20:25:28 however I also saw you mention , in which case none of this is relevant since it's a completely different API with completely different problems Jul 24 20:25:40 Oh. Jul 24 20:26:05 I can try to remove that linux/gpio.h include from my C source. I changed it up to test things. Jul 24 20:27:11 Okay. The include was useless thus far. Jul 24 20:27:12 It is removed. Jul 24 20:27:21 gpio.h has been removed. Jul 24 20:27:51 if you don't have /dev/gpio/, try creating /etc/udev/rules.d/gpio-symlink.rules with the following contents: https://pastebin.com/REyzQrYX (and reboot) Jul 24 20:29:01 I have gpiochipX in /dev/ only. Jul 24 20:29:16 that's a different thing Jul 24 20:29:18 0 - 3 Jul 24 20:29:24 Okay. Jul 24 20:29:34 I will try this udev rule. Jul 24 20:29:38 brb Jul 24 20:30:24 How can I access the BMP temperature data on blue? Jul 24 20:31:58 I found some items that help people read the BMP sensor on the BBBlue. Please hold. Jul 24 20:32:03 student: I don't have a blue, but my guess would be it shows up as an iio device? Jul 24 20:32:37 try looking around in /sys/bus/iio/devices/ Jul 24 20:34:33 @zmatt: Okay. I rebooted. Jul 24 20:35:46 student: https://github.com/MXET/SCUTTLE/tree/master/software/python/basics has some nice info. in it. It may prove useful. Jul 24 20:36:35 set_: how is any of this remotely relevant to student's question? Jul 24 20:37:03 http://strawsondesign.com/docs/librobotcontrol/rc_test_bmp_8c-example.html may be more useful. Jul 24 20:37:04 Sorry. Jul 24 20:37:16 It is not but it has articles of ideas relating to the BBBlue. Jul 24 20:37:47 no, it was a random directory of python source code for some robot Jul 24 20:37:54 the second link is more relevant though Jul 24 20:37:58 For the BBBlue, though. Jul 24 20:38:02 Use the second link. Jul 24 20:38:04 student: yeah I guess you can use librobotcontrol Jul 24 20:38:32 Do I need to enable my symlink? Jul 24 20:38:56 student: though this example seems specific to the barometer in the BMP, presumably there's a similar example for the thermometer Jul 24 20:39:27 set_: ? Jul 24 20:39:40 @zmatt: I tried that udev rule. Jul 24 20:39:43 I rebooted. Jul 24 20:39:54 What should I do now? Nothing is different. Jul 24 20:39:56 set_: do you have cape-universal enabled? (It should be enabled by default) Jul 24 20:40:03 Let me go and check. Jul 24 20:40:48 I got what happened. Jul 24 20:41:18 I used the RoboticsCape set up on my hardware and this is not the BBBlue nor do I have a RoboticsCape. Jul 24 20:41:19 ... Jul 24 20:41:20 Oops. Jul 24 20:43:22 I was wondering why the dang P9.12 pin was not configurable by config-pin. Jul 24 20:43:24 Sheesh. Jul 24 20:43:26 now, I know. Jul 24 20:44:11 I still got it to work but not in software, just by changing the value and direction in /sys/class/gpio/gpioXX/. Jul 24 20:46:14 https://pastebin.com/mg2tp3ts is my uEnv.txt file for some reason. I have a backup. Jul 24 20:46:16 Yikes. Jul 24 20:48:58 time to restore that backup I think :P Jul 24 20:49:03 you've lost most settings Jul 24 20:49:32 I know. Jul 24 20:49:40 How do I restore a backup? Jul 24 20:50:13 sudo cp /boot/uEnv.txt.bak /boot/uEnv.txt (assuming the backup is /boot/uEnv.txt.bak ) Jul 24 20:50:28 got it. Thank you. Jul 24 20:51:16 Okay. Jul 24 20:51:43 I rebooted. I will see how this udev rule works. The cape_universal was present in the uEnv.txt file. Jul 24 20:52:00 w/out the #. Jul 24 20:52:12 I mean, it wasn't if https://pastebin.com/mg2tp3ts was your /boot/uEnv.txt Jul 24 20:53:00 Oh. So, I might not need that udev rule now since my uEnv.txt file was goofed up. Jul 24 20:53:24 Oh and all three of my LEDs are now lit. Jul 24 20:53:29 Yikes. Jul 24 20:53:42 it is conceivable rcn has a similar udev rule, but I don't think he has Jul 24 20:53:56 ah, so like I said: leds were just a software configuration issue Jul 24 20:53:58 told ya Jul 24 20:54:05 You were right. Jul 24 20:54:58 I am going to have to work on that software more. Jul 24 20:55:12 That external LED will not light the sky w/out me. Jul 24 21:03:05 @set_ the command rc_test_bmp will print live temperature data to the command prompt but I would like to access the data with a python program. Jul 24 21:03:38 Oh. Jul 24 21:03:49 Okay. Let me see if I have an older model that you can update. Jul 24 21:04:05 The example http://strawsondesign.com/docs/librobotcontrol/rc_test_bmp_8c-example.html says that the data is stored as: Jul 24 21:04:12 data.temp_c Jul 24 21:04:15 Oh. Jul 24 21:04:26 Did you look at .temp_c? Jul 24 21:04:30 But, I don't know if I can access that variable mid-program Jul 24 21:04:37 Oh. Jul 24 21:05:02 Yikes. I know sometimes real-time is not so easy. This is my case. Other people may specialize in this area. Jul 24 21:05:08 student: it's filled in by the call to rc_bmp_read(&data) Jul 24 21:05:59 after which you can examine data at your leasure Jul 24 21:06:05 I presume I cannot call that function in a python program, right? Jul 24 21:06:32 BMPdata=open('/root/BMP_data/BMP.txt', 'w') Jul 24 21:06:37 Something like this could help. Jul 24 21:06:37 depends on whether there's a python wrapper for librobotcontrol Jul 24 21:06:42 set_: it doesn't Jul 24 21:06:43 Oh. Jul 24 21:06:52 There is, it is called rcpy I think. Jul 24 21:07:09 Let me check again. Jul 24 21:07:22 student: alternatively you can probably use the sysfs interface to read the iio device, which you can probably do with a one-liner in python Jul 24 21:09:03 I have tried to learn how to call the temperature using this document https://guitar.ucsd.edu/rcpy/rcpy.pdfhttps://guitar.ucsd.edu/rcpy/rcpy.pdf Jul 24 21:09:18 https://guitar.ucsd.edu/rcpy/rcpy.pdf Jul 24 21:09:25 https://github.com/mcdeoliveira/rcpy is the info. I found that may be helpful but i have not used it personally. Jul 24 21:11:34 https://github.com/mcdeoliveira/rcpy/blob/master/rcpy/mpu9250.py is all that person has now. I think it is a process he is working to create. Jul 24 21:12:01 set_: uhh, no? Jul 24 21:12:06 In Python2, things were already done and working. Jul 24 21:12:08 What? Jul 24 21:12:31 The mpu is not the bmp? Jul 24 21:12:39 set_: as the pdf shows, there are bindings for a ton of functionality, and based on the commit log it looks like he mostly finished work last year Jul 24 21:12:46 also, the mpu and bmp are completely unrelated Jul 24 21:12:49 Oh. Jul 24 21:12:50 Okay. Jul 24 21:13:32 @zmatt: I remember you showed me a python3 library that handled the BMP on the BBBlue. Jul 24 21:13:38 This was about a year back. Jul 24 21:14:15 I should have written it down. I did find a BMP library in C/C++ from Boch. Jul 24 21:14:44 student: it's hard for me to give concrete suggestions since I don't have a blue to test on. my first idea would still be to look for an iio device in /sys/bus/iio/devices, which is the advice I gave 40 minutes ago Jul 24 21:15:07 student: What exact bmp is on the BLUE? Jul 24 21:15:16 I will look it up. Jul 24 21:15:18 Please hold. Jul 24 21:15:36 (there are probably multiple iio devices, but presumably only one will have a temperature reading) Jul 24 21:16:05 bmp280 Jul 24 21:18:12 Oh. Jul 24 21:18:13 Okay. Jul 24 21:19:40 @zmatt I am exploring the sys directories Jul 24 21:19:42 https://github.com/BoschSensortec/BMP280_driver is what I found a year back but I have been unable to use it thus far. Jul 24 21:20:51 There is just 1 directory in iio/devices, it's iio:device0 Jul 24 21:20:55 debian@scuttle:/sys/bus/iio/devices/iio:device0$ lsbuffer in_voltage2_raw in_voltage6_raw powerdev in_voltage3_raw in_voltage7_raw scan_elementsin_voltage0_raw in_voltage4_raw name subsystemin_voltage1_raw in_voltage5_raw of_node uevent Jul 24 21:21:02 hmm, that's the adc Jul 24 21:21:22 weird, I thought the bmp280 had a working kernel driver Jul 24 21:21:31 let's make one Jul 24 21:21:58 "let's make one" ? Jul 24 21:22:19 a working kernel driver. ...Just kidding, I have no idea how to do that Jul 24 21:22:26 I'm pretty sure there is one Jul 24 21:22:44 but it seems like the beaglebone blue's device tree just doesn't even declare the bmp's existence Jul 24 21:23:10 I remember there was a couple of Libraries in Python2 but i have not found anything just yet in Python3. Jul 24 21:23:29 so my guess is that some userspace libraries (e.g. librobotcontrol) made things working by manually doing i2c transactions from userspace Jul 24 21:23:39 instead of configuring the DT correctly to use the kernel driver Jul 24 21:24:03 hence now they're incompatible with configuring the DT correctly to use the kernel driver, since that would interfere with userspace doing manual i2c transactions to the bmp Jul 24 21:24:05 https://pypi.org/project/bmp280/ is something you can try, student. Jul 24 21:24:19 so now for bugwards compatibility the declaration is kept out of the DT Jul 24 21:24:30 :D Jul 24 21:25:23 yeah with a bit of luck you can find pure-python bmp280 code (written to use direct i2c transactions) Jul 24 21:26:13 pimoroni was the homepage of this one. I remember it now. Jul 24 21:26:23 it was the person's shop or something. Jul 24 21:27:12 you'll just need to specify the correct i2c bus and slave address to use, which for the beaglebone blue are bus 2 address 0x76 Jul 24 21:28:37 brb...outside is calling once again. Jul 24 21:34:12 https://pypi.org/search/?q=BMP280 is what pypi has right now. Jul 24 21:34:35 Anyway...I will bbl. It is news time at the old house. Jul 24 21:48:54 student: oh weird, looks like am335x-boneblue.dts in the 4.14-ti and 4.19-ti kernel series doesn't declare the bmp and mpu, yet the 4.14-bone and 4.19-bone kernel series do Jul 24 21:49:58 rcn-ee[m]: why are the DT declarations missing for the sensors (bmp, mpu) on the blue's i2c2 in the -ti kernel series? bugwards compatibility with librobotcontrol bypassing the kernel? Jul 24 21:51:50 I have to step away but I will try these tips in the morning! Jul 24 23:04:31 zmatt, one the blue, librobotcontrol wants full control of those, has he had his own user-space driver.. "something about i can do it better and faster yada..yada..yada.yada.."... Jul 24 23:05:03 so the blue on *-ti kernels is crippled, and it's expected to use the librobotcontrol.. Jul 24 23:05:51 hehe, exactly as I suspected Jul 24 23:06:47 of course librobotcontrol could just unbind the kernel driver Jul 24 23:07:03 allowing the kernel driver to stil be used by default Jul 24 23:11:18 librobotcontrol, could do a lot of things better.. but he graduated, i'm really hoping this next semester they assign a new phd student.. Jul 24 23:11:31 hah Jul 24 23:32:52 how do I ensure mosquitto is running before I start some things with systemd ? Jul 24 23:33:19 i don't think mosquitto as such is a target Jul 24 23:33:22 use a flyswatter? Jul 24 23:33:36 if it gets something, it must be(en) running :D Jul 24 23:33:38 i think that would ensure it was stopped Jul 24 23:33:43 :) Jul 24 23:34:08 depends on where you get your fly swatters Jul 24 23:34:41 mosquittos would go through the holes in most of them Jul 24 23:34:58 (FYI, flyswatter is the name of a jtag debugger ;)) Jul 24 23:35:13 oh cool, didn't know that Jul 24 23:35:55 https://www.tincantools.com/flyswatter2/ Jul 24 23:35:56 =) Jul 24 23:40:27 the last answer here might be what i need https://community.home-assistant.io/t/systemd-needs-to-start-mosquitto-before-ha/14771/8 Jul 24 23:44:02 IMO - avoid systemd Jul 24 23:44:24 rc.local works fine for simple things Jul 24 23:44:31 what are you using mosquitto for? Jul 24 23:44:56 i have much sympathy with that view, but it's there and I could do with understanding it better Jul 24 23:45:22 IIRC, there is still a hook to create something like rc.local Jul 24 23:45:23 a pool of slow data for a robot control Jul 24 23:45:59 oh you have a MQTT subscriber on the robot and MQTT publishes are commands? Jul 24 23:46:07 yeah there is, but let's see how the .service scripts go before I write a load of daemon scripts Jul 24 23:46:27 all the bits on the robot communicate with mqtt Jul 24 23:46:45 how are you using MQTT? mosquitto_sub/pub or? Jul 24 23:47:11 could be done with ROS but too much learning. might change it some time Jul 24 23:47:39 mostly with clients that pub/sub themselves but mosquitto_pub fdor a few shellscripts Jul 24 23:48:29 it's really nice for subbing test topics from another machine Jul 24 23:49:58 couldn't you just use mosquitto_sub to wait for the broker to appear? Jul 24 23:51:11 actually, do you really have to wait? if you set a qos, it should retry Jul 24 23:51:14 sure, if I started everything from shellscripts. or poll ps. But since i'm starting the other c-coded things with systemd I wanted to put the dependency there Jul 24 23:51:37 it's the initial registration though Jul 24 23:53:02 i guess i coujld loop until the registration works but seems a nasty way to do it Jul 24 23:53:27 qos settings should force it loop Jul 24 23:53:29 as well as adding to the startup load. init dependencies are much more rational Jul 24 23:53:39 yes Jul 24 23:54:09 you can do a dumb dependency by having the broker as a seperate systemd script. the tricky part is how do you determine when the broker is ready (esp if you have it reload its state) Jul 24 23:54:18 i'll try what it says in that link. plenty of fallback options if it doesn't work Jul 24 23:55:09 that says I can do After=mosquitto.service which I hadn't seen in other examples Jul 24 23:56:01 but that doesn't necessarily guarantee the server is ready Jul 24 23:56:53 true, could be a problem. Jul 24 23:57:21 there seem to be various ways to solve that sort of thing Jul 24 23:58:54 I presume the number of options in systemd scripts will asymptotically approach daemon start scripts Jul 24 23:59:05 because Henry Spencer says so Jul 25 00:01:28 and Henry Spencer > Leonard Poettering Jul 25 00:03:45 I seem to have accidentally filled up the entire flash memory Jul 25 00:04:12 I'm not sure with what Jul 25 00:05:22 the "'Flasher' Debian images" are the ones I can replace it with, right? Jul 25 00:09:11 the website says "flashing via microSD card" Jul 25 00:09:14 what does that mean? Jul 25 00:09:48 if I connect the board to another computer, isn't the device that appears the flash memory? Jul 25 00:11:28 no, that's some other 40 MB drive? Jul 25 00:12:27 `df` on the board doesn't report any drives of that size Jul 25 00:15:37 and I don't see any other block devices that could be it Jul 25 00:17:30 ksft: it means you install that image to a "microSD", stick it in teh BBB, and then "it" flashes the "eMMC".. Jul 25 00:17:43 I can't do it from another computer? Jul 25 00:18:25 my microSD adapter for my laptop doesn't seem to be working Jul 25 00:18:36 you can do it from anywhere that has a microSD reader.. Jul 25 00:19:04 I can flash the eMMC from anywhere? Jul 25 00:19:46 The eMMC is flashed by a microSD card.. You can flash the microSD anywhere.. Jul 25 00:20:11 but I can't plug the BBB into my laptop and put an image directly onto the eMMC from there? Jul 25 00:20:38 Not with the current default images.. Jul 25 00:20:50 patches welcome Jul 25 00:21:43 what is the drive it seems to present to my laptop? Jul 25 00:22:15 it's a "virtual" flash drive to show a few documents.. Jul 25 00:24:39 ahh Jul 25 00:31:55 do I write the eMMC image to the whole SD card device or to its only partition? Jul 25 00:32:36 ...or do I put it on the SD card as a file? Jul 25 00:32:44 Follow the directions and use etcher.. Jul 25 00:32:52 https://www.balena.io/etcher/ Jul 25 00:33:35 I'm asking about flashing the eMMC image Jul 25 00:34:18 Doesn't matter: https://beagleboard.org/getting-started#update Jul 25 00:34:23 and I'm having trouble using my SD card with my laptop, so I'm hoping to use the BBB as an SD card reader for now Jul 25 00:35:27 does Etcher do something more complicated than decompressing the image and writing it to the SD card? Jul 25 00:35:37 Then use dd and dump it to the drive: "xzcat file.img.xz | sudo dd of=/dev/sdX" Jul 25 00:42:50 once I've put the eMMC image on the SD card, I boot from it, modify /boot/uEnv.txt, and reboot, right? Jul 25 00:43:13 No, just flash it and reboot.. Jul 25 00:43:52 : /boot/uEnv.txt was to hard for people to edit the file. Jul 25 00:44:23 so I boot from the eMMC image on the SD card and flash the eMMC from there? Jul 25 00:44:57 After writing the "flasher" image to a microSD, that microSD will procede to flash teh eMMC on the next power up.. Jul 25 00:45:13 oh, okay Jul 25 00:46:12 and the lights stop flashing when it's done? Jul 25 00:46:38 you should see the cylon pattern and it'll shutdown when done.. Jul 25 00:47:27 er, what's the cylon pattern? Jul 25 00:47:44 https://www.youtube.com/watch?v=4bV9P_vbFdE Jul 25 00:48:34 got it, thanks Jul 25 01:18:40 rcn-ee[m]: I wonder how hard it would be to make a script that lets you flash eMMC from sd after booting normally from sd card... I think it should be possible with a systemd service that pulls in the right units to more-or-less perform a shutdown. I know systmd can even pivot the root back into the initramfs and fully unumount the root filesystem Jul 25 01:19:53 then there'd be a lot more freedom in deciding when to trigger flashing to sd card... it could even be controlled via the web interface Jul 25 01:19:57 you just need to call the current script thru /bin/bash.. Jul 25 01:20:11 that's how it started out.. Jul 25 01:20:35 I thought the script needed to run in initramfs? Jul 25 01:20:42 I've never examined it really Jul 25 01:21:46 There was a high percentage of microsd -> eMMC copy failures, moving to a read-only root, cut that down drastically.. Jul 25 01:21:54 exactly Jul 25 01:22:40 hence me wondering out loud how hard it would be to enter into such a state from a running system, rather than requiring /boot/uEnv.txt to be modified Jul 25 01:22:42 if we did btrfs, we could lock the live image down and copy that snapshot, but ext3/ext4 doesn't have a feature like that Jul 25 01:23:18 sudo /bin/bash /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh Jul 25 01:23:41 it'll detect what mode it's in, initramfs or live, and do everything possible to flash the eMMC.. Jul 25 01:24:40 I mean, not good enough apparently, since like you said "There was a high percentage of copy failures" Jul 25 01:25:27 whereas I know systemd can shut down to a state where the rootfs is unmounted since I've read the post that celebrated it (a long long while ago) Jul 25 01:25:52 Well my error reports where: So we flashed 1000, we have 50 failures, please fix it.. Jul 25 01:26:07 can i get a serial log of what happened? we don't have taht... here's a few boards that failed.. Jul 25 01:26:12 i flash them, they are fine.. Jul 25 01:26:17 yeah that sucks Jul 25 01:26:30 moving to 'ro' elimated 99% of those failures.. Jul 25 01:27:29 We rely on rsync to copy everything (i think 2 passes), but if your system is active, well... Jul 25 01:36:59 2 passes should be pointless when the source is ro Jul 25 01:37:36 I'm pretty sure 1-pass also complains if anything has modified while it was doing the transfer? but I don't know if that's an error (nonzero exit code) or merely a warning (zero exit code) Jul 25 01:44:52 hmm, only some changes I guess Jul 25 01:49:44 what's the difference between the two images? Jul 25 01:49:58 which? Jul 25 01:49:59 ksft: one character: # Jul 25 01:50:19 the "Recommended Debian Images" and the "'Flasher' Debian Images" Jul 25 01:50:40 ksft: the one with "flasher" in the name is a flasher, the other is not :P Jul 25 01:50:59 because that line isn't commented out? Jul 25 01:51:11 exactly Jul 25 01:51:11 that's an implementation detail Jul 25 01:51:16 but yes Jul 25 01:51:19 got it Jul 25 01:51:29 I'm trying to put the other image on the SD card now Jul 25 01:51:42 so if you want to reflash emmc, you want the flasher image Jul 25 01:52:02 something must have changed with the new image, because I can't seem to use sudo the way I did before Jul 25 01:52:19 like type in a password? yes... Jul 25 01:52:26 nothing has changed w.r.t. how sudo works in years I think Jul 25 01:52:30 ? Jul 25 01:52:40 (nopasswd was enabled years ago) Jul 25 01:52:47 at the same time as blank root.. Jul 25 01:52:56 ah, ancient lore from before my time Jul 25 01:53:06 I used `ssh bbb 'sudo dd of=/dev/mmcblk0' < image` before Jul 25 01:53:13 but now I can't use sudo like that? Jul 25 01:53:20 you can Jul 25 01:53:32 we had to make it easy for angstrom users to move to debian. Jul 25 01:53:34 well, you may want to add the -t option to ssh Jul 25 01:53:51 since I don't think sudo can ask for a password otherwise Jul 25 01:54:04 that doesn't seem to work when stdin is coming from the image file Jul 25 01:54:10 hence the -t option Jul 25 01:54:14 to make sure ssh allocates a tty Jul 25 01:54:23 "Pseudo-terminal will not be allocated because stdin is not a terminal." Jul 25 01:54:33 what, stupid ssh Jul 25 01:54:53 just use the terminal as terminal, dumbass ssh -.- Jul 25 01:55:03 (for terminal i/o I mean) Jul 25 01:55:22 yah Jul 25 01:55:23 yeah* Jul 25 01:56:15 before I flashed the new image to the eMMC, it worked without u-t Jul 25 01:56:17 -t* Jul 25 01:56:45 you probably had some ancient (many years old) image which had no regard for security whatsoever Jul 25 01:57:24 though to be fair, I'm not sure having sudo ask for a password really matters much when everone leaves that password at the default anyway Jul 25 01:58:07 and it hasn't changed in 10 years. Jul 25 01:58:10 I'm not doing anything super sensitive or exposing the ssh port to the Internet Jul 25 01:58:35 I bought it a little less than a year ago, I think Jul 25 01:59:00 then it's been sitting on a shelf for 9 years before you received it :P Jul 25 01:59:06 possibl Jul 25 01:59:07 e Jul 25 01:59:27 anyway, I'm trying to think which of the many solutions is easiest for your current situation Jul 25 01:59:44 ssh in as root? Jul 25 01:59:59 that's dislabed Jul 25 02:00:04 I can enable it Jul 25 02:00:04 probably ssh target 'sudo chown debian /dev/mmcblk0*' Jul 25 02:00:15 oh, that seems easier Jul 25 02:00:23 and then do your normal command without sudo Jul 25 02:00:25 or ssh in, then run the command like normal.. Jul 25 02:00:37 can't, he's using ssh to pipe the image from your local computer Jul 25 02:00:51 ah. Jul 25 02:00:52 *from his Jul 25 02:01:33 maybe eMMC has enough space for the xz compressed image, but it would still be a bit silly Jul 25 02:01:36 oh just use the "bonescript" updater: http://beagleboard.org/updater Jul 25 02:01:37 (runs and hides) Jul 25 02:01:57 lol, speaking of security.... Jul 25 02:02:34 security, what's that.. anyone know of bbb on the internet open, just stick in teh ip addres and click run.. Jul 25 02:02:41 does it matter whether I use cat or dd? Jul 25 02:02:55 ksft: not really no Jul 25 02:03:29 I always wondered why my BBB took a left that day. Jul 25 02:03:44 if I wanted to use a bbb as sd card reader, I'd probably just expose the /dev/mmcblk0 to the host using g_mass_storage Jul 25 02:04:00 I don't expect I'll need to do this very much Jul 25 02:04:07 then the host can flash it like a normal usb flash drive Jul 25 02:14:47 all right, I put the image on the SD card! Jul 25 02:15:01 now how do I boot from it? Jul 25 02:16:04 so, can you clarify what you're doing right now exactly? because if I understand correctly you've already reflashed your emmc? Jul 25 02:16:17 I probably just missed some bit of explanation earlier Jul 25 02:16:20 yeah, I want to boot from the image I just put on the SD card Jul 25 02:16:55 just (re)boot with the sd card inserted Jul 25 02:16:59 oh Jul 25 02:19:24 with one caveat: if there's a bootloader present on eMMC and it's not of similar age as the image on sd card, then it *may* be necessary to force bootrom to use the bootloader on sd card instead of the one on eMMC to make the image on sd card work correctly (otherwise it might still boot, but it may have weird issues). since you've just reflashed emmc (which also replaces the bootloader) I'm assumimg ... Jul 25 02:19:30 ...that's not an issue right now. Jul 25 02:19:41 it seems to have booted from the eMMC Jul 25 02:20:33 if you do ever need to force this, you do so by powering on (not merely rebooting) while holding down the S2 button (i.e. the button closest to the sd card slot). You can (and should) let go of the button once the power led has turned on Jul 25 02:20:49 oh, no Jul 25 02:20:59 it did boot from the SD card Jul 25 02:21:06 but it's reporting that it's 3.4 GB, not 16 GB Jul 25 02:21:30 yeah, it doesn't auto-expand the filesystem to cover the entire sd card, although there's a script that will fix that Jul 25 02:22:02 /opt/scripts/tools/grow_partition.sh I think Jul 25 02:23:47 if you intend to boot from sd card from now on, I'd normally now recommend you to wipe eMMC using sudo blkdiscard /dev/mmcblk1 to avoid any potential for bootloader version mismatch issues in the future Jul 25 02:24:01 but I'm guessing you want to keep a working system on eMMC to be able to use the beaglebone as sd card reader Jul 25 02:25:36 I'd like to be able to good from the eMMC if I need to in the future Jul 25 02:25:42 to boot from* Jul 25 02:27:30 ah, what a useful script! Jul 25 02:30:06 why are you not just working on eMMC entirely? you really need 16GB of space for what you're doing? that seems... excessive. our primary development beaglebone is currently using 3.0G out of 3.5G, but 1.5G thereof is /home (roughly 0.5G/developer). our production beaglebones use 422M out of 1.8G (less space total due to eMMC reconfiguration for reliability at the expense of space) Jul 25 02:31:04 I tried to install py-uio, and the eMMC seemed to have been filled up Jul 25 02:31:15 and I already had a 16 GB SD card Jul 25 02:31:24 by default it's filled up, use the console/iot image.. Jul 25 02:31:24 what?does the iot image have that little free space nowadays? Jul 25 02:31:55 (or did you start with the lxqt image? in which case... please consider not doing so) Jul 25 02:32:27 apparently, I started with a ten-year-old image Jul 25 02:32:36 but I didn't know that until a few minutes ago Jul 25 02:32:39 well yeah but you replaced that now Jul 25 02:33:11 I was assuming you meant you ran out of space after trying to install py-uio *after* reflashing Jul 25 02:33:20 no, that was before Jul 25 02:33:31 I didn't bother reflashing it until I ran into that problem Jul 25 02:33:35 oh Jul 25 02:33:44 because I assumed it was recent Jul 25 02:33:46 which would have been teh default lxqt image.. Jul 25 02:33:48 so now that you've reflashed eMMC, why meddle with sd card? Jul 25 02:33:59 yeah, an ancient lxqt image probably Jul 25 02:33:59 I don't know Jul 25 02:34:03 I guess I should stop Jul 25 02:34:23 I wouldn't suggest booting from sd card unless you really have no option but to Jul 25 02:34:30 oh, okay Jul 25 02:34:44 like if eMMC is fried, or you need to work with huuuuuge datasets or something Jul 25 02:35:09 or you absolutely want the additional pins available Jul 25 02:35:11 rebooting from eMMC again... Jul 25 02:36:22 the system reference manual says this: Jul 25 02:36:59 "For Feasibility Evaluation Only, in Laboratory/Development Environments. The BeagleBone Black is not a complete product. It is intended solely for use for preliminary feasibility evaluation in laboratory/development environments by technically qualified electronics experts who are familiar with the dangers and application risks asso ciated with handling electrical mechanical components, systems and Jul 25 02:37:01 subsystems. It should not be used as all or part of a finished end product. Jul 25 02:37:03 " Jul 25 02:37:07 yada yada yada Jul 25 02:37:21 nobody cares Jul 25 02:37:25 :D Jul 25 02:37:29 okay, just wondering Jul 25 02:38:07 it just means that if you're going to integrate it into a a product, it's *your* responsibility, don't try to pin anything on beagleboard.org Jul 25 02:38:31 make sense Jul 25 02:38:48 but there aren't major practical problems with integrating it into a product, are there? Jul 25 02:39:04 we have hundreds of units shipped Jul 25 02:39:08 with a beaglebone inside Jul 25 02:39:15 so, I really hope not XD Jul 25 02:39:19 who does? Jul 25 02:39:23 the company I work for Jul 25 02:39:29 ah Jul 25 02:39:54 we are working on a custom design (based on the osd335x) to replace our current hardware Jul 25 02:40:09 but I think that'll still take a while Jul 25 02:42:08 I can write bytes directly to the PRU's memory with py-uio, right? Jul 25 02:42:20 yep Jul 25 02:44:56 you can get python memoryview objects for the various PRUSS memories (or even pruss in its entirety), and there are also convenience methods for mapping shared data structures as a "ctypes" object or an "array" object Jul 25 02:45:11 or if you prefer you can just read/write bytes at some offset Jul 25 02:49:44 does pasm not come with the image? Jul 25 02:50:21 oddly, no, but installation instructions are in the py-uio readme Jul 25 02:50:49 rcn-ee[m]: why isn't pasm included with the default images? Jul 25 02:56:50 what is "default code origin of 8"? Jul 25 02:57:52 undesirable, which is why all my examples start with #include "common.h", which sets the code origin to 0: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/common.h#L7-L8 Jul 25 02:57:57 does pasm run a C preprocessor or something? Jul 25 02:58:19 not quite no Jul 25 02:58:42 but it does support a subset of C preprocessor features Jul 25 02:59:43 why is the default value such a bad choice that the assembler warns you if you use it? **** ENDING LOGGING AT Thu Jul 25 02:59:57 2019