**** BEGIN LOGGING AT Fri Jan 18 02:59:57 2019 Jan 18 03:04:50 you can factor the initialization code Jan 18 03:05:45 and use the constants Jan 18 03:08:36 Oh. Do you mean for number variables instead of using the actual words? Jan 18 03:10:37 no I mean you can use ClockWise instead of 1 at line 16 for instance Jan 18 03:10:39 and so on Jan 18 03:11:35 Oh. Jan 18 03:11:37 Okay. Jan 18 03:11:40 I got you. Jan 18 03:12:22 I would rather not if that is okay. Do you think I should do anything to change it outside of what you stated? Jan 18 03:12:51 additions or subtractions? Jan 18 03:14:16 For instance, I was going to put in a couple of software examples for handling other libraries. Jan 18 03:14:58 i.e. Flask and/or some "IoT" stuff. Jan 18 03:15:27 pub/sub stuff maybe? Jan 18 03:15:31 Who knows? Jan 18 03:22:24 why wouldn't you use constants ? it's better for documentation Jan 18 03:22:46 I never used flask but I kinda like the idea of this kind of lib Jan 18 03:22:53 I'm a fan of tornado, and more generally asyncio Jan 18 03:22:59 I did this with tornado: Jan 18 03:23:00 https://paste.serveur.io/ Jan 18 03:23:03 https://pix.watch/ Jan 18 03:23:06 https://maths.serveur.io/ Jan 18 03:28:30 Those look cool. Did you type up that software for the look of those sites? Jan 18 03:29:36 tornado is good stuff. I never really got into it. I did use it once for some software but only once. Jan 18 03:40:19 Well, tornado works well. Jan 18 03:40:29 even w/ py3. Jan 18 03:41:23 I just ran their ideas on the BBG. Jan 18 03:41:49 yeah I did the design too Jan 18 03:41:56 sometimes using bootstrap, sometimes foundation Jan 18 03:43:59 I have a real funny page online w/ bootstrap and motors. I control the motors via an online page w/ bootstrap software. Jan 18 03:44:21 Well...that and Flask. Jan 18 03:44:55 I never heard of foundation. Jan 18 03:45:23 w3chools has these free templates. I have been trying to learn from their templates and info. Jan 18 03:52:13 yeah Jan 18 03:56:22 They use a lot of bootstrap on their sites. Jan 18 03:57:28 Cloudy and puffy. Jan 18 04:12:18 rcn's script for building the bbb kernel makes fine .tar.gz with dtbs and modules, but not with kernel headers, that's strange Jan 18 04:12:22 nor with userspace kernel headers Jan 18 04:12:26 I have to package that myself it seems Jan 18 04:14:57 Oh. I guess you can pick and choose which Debian Distro you want or which Ubuntu image you want? Jan 18 04:15:36 For instance, I found it helpful just to have the minimal image he has already shopped and done. Jan 18 04:15:57 ... Jan 18 04:16:14 BBB, right? Jan 18 04:16:31 yeah Jan 18 04:16:37 Check digikey's eewiki for BBB stuff. Jan 18 04:16:42 yeah I'm using the debian image he made Jan 18 04:16:43 They have stuff for the BBB and BBBlue. Jan 18 04:16:48 Oh. Jan 18 04:16:53 but it's the kernel I need to update Jan 18 04:16:59 Oh. Jan 18 04:17:05 it has the kernel in the repos but I'd like to try a different config Jan 18 04:17:14 so I built it with the script he made Jan 18 04:17:14 Aw. Jan 18 04:18:06 link it! Jan 18 04:18:47 What kernel do you want for your BBB? Jan 18 04:19:10 I think 4.14.x is the one w/ the most support right now. Jan 18 04:20:51 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options Jan 18 04:20:58 https://github.com/RobertCNelson/bb-kernel/tree/am33x-v5.0 Jan 18 04:21:00 5.0 Jan 18 04:21:05 Oh. Jan 18 04:21:06 it built fine Jan 18 04:21:11 I just have to install now Jan 18 04:21:35 Hmm. More power to you. Did you have any communication errors w/ that board, e.g. networking? Jan 18 04:21:50 the ethernet is fine, SPI too Jan 18 04:21:53 for the rest I didn't try Jan 18 04:22:05 there are strange warnings about clock for the PRU but I don't use it Jan 18 04:22:05 Oh. Ethernet. Okay. Jan 18 04:22:09 but I guess it's concerning Jan 18 04:22:15 Ha. Jan 18 04:22:27 that's a bug to be fixed I guess Jan 18 04:23:02 I was building on another board for some reason. I got into emergency mode in u-boot. Aw! Jan 18 04:23:39 I cannot wait to build on my BBB. I know I may screw things up but I plan on putting the MachineKit image on one of them. Jan 18 04:24:11 So, if all else fails. I will promote the MachineKit stuff onto the board w/ a flash. Jan 18 04:25:21 mawk: Did you get it yet? Oh, are you writing the image to the board now w/ SD Card or on eMMC? Jan 18 04:25:55 it's not an image, I'm updating just the kernel Jan 18 04:25:58 so I transfer it with ssh Jan 18 04:26:23 and install it and the device tree in /boot, its modules in /lib/modules/$VERSION, the overlays in /lib/firmware Jan 18 04:26:55 then rebuild the out-of-tree modules, install the kernel headers in /usr/src, install the userspace headers in /usr/include/linux Jan 18 04:26:58 and that's pretty much it Jan 18 04:27:07 I can point to the new version in /boot/uEnv.txt and reboto Jan 18 04:27:16 Oh. Jan 18 04:27:17 Okay. Jan 18 04:28:07 Did you see that it is easier than that on the link I provided? Oh, I got it now. You cannot get those items on the board w/ the 5.0.x kernel w/out rebuilding. Jan 18 04:28:10 Sheesh. I am slow. Jan 18 04:29:06 well I tried the method in your link Jan 18 04:29:09 but I wanted to modify the config Jan 18 04:29:21 disable the realtime patches and the kernel preemption Jan 18 04:29:25 But mawk: There is not a real system for help w/ that kernel yet. I think that is why the BBB.io people are leaving it be for now. Jan 18 04:29:33 yeah Jan 18 04:29:47 it's just to try a specific networking module with the very latest code from linux people Jan 18 04:29:51 I'm fine if not everything works Jan 18 04:29:56 Oh. Jan 18 04:30:01 I got you. Jan 18 04:30:02 I'm trying 6LoWPAN networking Jan 18 04:30:04 it's some wireless thing Jan 18 04:30:07 Oh! Jan 18 04:30:15 low power encrypted IPv6 for IOT, or something like that Jan 18 04:30:24 Coolness stuff, mate. Jan 18 04:30:57 mawk: Why are you doing it again? Jan 18 04:31:14 for patching? Jan 18 04:31:15 because I have a project that is porting a 6LoWPAN stack to a realtime OS that is named RTEMS Jan 18 04:31:23 Oh. Jan 18 04:31:29 Even better of a reason. Jan 18 04:31:29 also yeah incidentally I'll probably patch the linux 6LoWPAN implementation if it's really not working Jan 18 04:31:39 because I need linux on a RPi as the border router of my setup with RTEMS on BBB Jan 18 04:31:50 Good lawd. That sounds difficult. Jan 18 04:31:55 Good luck, mawk. Jan 18 04:31:59 it'd be a network of >=2 BBB running RTEMS and talking with 6LoWPAN, and a central node running linux acting as the gateway to the intenret Jan 18 04:32:05 we're 4 in that project Jan 18 04:32:08 I'm doing the hardware stuff Jan 18 04:32:18 and the low-level code Jan 18 04:32:25 Oh. Jan 18 04:32:26 Nice. Jan 18 04:33:05 Teams! Jan 18 04:33:16 yeah Jan 18 04:36:58 I've got to go, good night ! Jan 18 04:37:33 Later. Jan 18 04:39:20 http://events17.linuxfoundation.org/sites/events/files/slides/6lowpan-openiot-2016.pdf. This is some insight. Jan 18 04:41:56 http://wpan.cakelab.org/ is the updated versioning of the 6LoWPAN stuff. Jan 18 04:42:01 i.e. for Linux. Jan 18 04:43:28 https://github.com/search?q=linux-wpan is something else I found. Good luck. Jan 18 10:22:34 hi all Jan 18 10:23:01 i'm having some trouble understanding tait-brian angle (roll/pitch/yaw) Jan 18 10:23:44 i thought roll was around the x-axis and pitch around the y -axis Jan 18 10:24:14 yet i see in the headers of libroboticscontrol ... Jan 18 10:24:29 include/rc/mpu.h:#define TB_PITCH_X 0 ///< Index of the dmp_TaitBryan[] array corresponding to the Pitch (X) axis. Jan 18 10:24:30 include/rc/mpu.h:#define TB_ROLL_Y 1 ///< Index of the dmp_TaitBryan[] array corresponding to the Roll (Y) axis. Jan 18 10:24:30 include/rc/mpu.h:#define TB_YAW_Z 2 ///< Index of the dmp_TaitBryan[] array corresponding to the Yaw (Z) axis. Jan 18 10:33:55 charlie5: that's just a matter of how you define your coordinate system I'd say ;) For a plane, X is typically forward/aft, Y is port/starboard and Z is, well, obvious. Jan 18 10:34:21 charlie5: and I got it wrong of course Jan 18 10:34:43 X is port/starboard, Y is forward/aft, Z is orthogonal to X/Y Jan 18 10:35:36 the last bit seems redundant, even though using non-orthogonal axes is no doubt hilarious Jan 18 10:37:50 thinkfat: thanks, i'll play with it a bit and see if i understand better now Jan 18 10:38:24 but yeah those definitions of x/y/z seem consistent with what charlie5 pasted, since pitch is around the port/starboard axis, roll around the forward/aft-axis, and yaw around the vertical axis Jan 18 10:39:36 angles suck anyway, long live quaternions :) Jan 18 10:46:44 :) Jan 18 15:19:17 ROFL quarternions Jan 18 15:19:42 i thought there was an r Jan 18 15:19:43 hmm Jan 18 15:33:29 m Jan 18 15:46:56 x+iy+jz+kt Jan 18 16:43:45 haha yeah mawk Jan 18 16:46:09 quaternions are a great tool for meditation Jan 18 16:46:28 it's like extracting roots of cubic polynomials by hand Jan 18 16:55:24 ij = -ji = k, jk = -kj = i, ki = -ik = j, i² = j² = k² = ijk = -1 Jan 18 16:55:35 then multiply two arbitrary quaternions and relax Jan 18 17:10:44 Fri. Fun Day! Jan 19 00:42:07 I still have unknow relocation errors with the bone kernel zmatt Jan 19 00:42:09 and I built it myself Jan 19 00:42:28 what was the compiler mismatch thing you were talking about ? Jan 19 00:46:37 export CC=`pwd`/gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf- <----- try that if you are on a Linux Desktop w/ your linaro tool chain. Jan 19 00:47:02 yeah I used that Jan 19 00:47:06 but I booted the kernel and everything Jan 19 00:47:06 Yea! Jan 19 00:47:07 it works Jan 19 00:47:09 OH? Jan 19 00:47:12 except for some modules I built Jan 19 00:47:16 Oh. Jan 19 00:47:18 it says "exec format error" I don't understand why Jan 19 00:47:27 it something was very wrong like this the kernel wouldn't boot at all Jan 19 00:47:49 Right. There is this funny thing I learned called fsck. Jan 19 00:48:07 I need to learn more about it but it helps resolve broken, corrupted kernels. Jan 19 00:48:15 it's about the filesystem Jan 19 00:48:23 fsck = filesystem check, I think Jan 19 00:48:27 Oh. Jan 19 00:48:29 Okay. Jan 19 00:49:03 Well, maybe zmatt will come through one day. Jan 19 00:49:27 Oh and I have been using Tornado more in during today. Jan 19 00:49:57 nice ! Jan 19 00:49:57 I learned how to create .html files and make them work so far. Jan 19 00:50:05 Lists and things. Jan 19 00:50:13
    Jan 19 00:50:28 with the templates Jan 19 00:50:32 Yea. Jan 19 00:50:34 that tornado provides Jan 19 00:50:35 nice Jan 19 00:50:37 Right. Jan 19 00:50:44 Those things. The templates. Jan 19 00:50:55 mawk: unknown relocation errors? Jan 19 00:50:59
      {% for x in lst %}
    • something
    • {% end %}
    Jan 19 00:51:01 mawk: pastebin? Jan 19 00:51:17 there's just one thing: [22945.097111] wireguard: unknown relocation: 102 Jan 19 00:51:30 o.O Jan 19 00:51:30 when I insmod Jan 19 00:51:38 I have never in my life seen that Jan 19 00:52:05 brb Jan 19 00:54:25 me neither Jan 19 00:54:55 oh I thought I was using the debian gcc-arm-linux-gnueabihf, but apparently not: Jan 19 00:54:57 Linux version 4.14.78-bone17-dd22 (root@bob) (gcc version 7.1.1 20170707 (Linaro GCC 7.1-2017.08)) Jan 19 00:55:12 how do you see that ? Jan 19 00:55:26 I'm using arm-linux-gnueabihf yes Jan 19 00:55:52 yes but this is a linaro cross-toolchain, not debian's cross-toolchain Jan 19 00:56:07 cat /proc/version Jan 19 00:56:31 Linux version 5.0.0-rc2-bone-nopreempt0 (builder@builder) (gcc version 8.2.0 (Debian 8.2.0-11)) #1xross Fri Jan 18 16:34:17 CET 2019 Jan 19 00:56:52 yeah, so I've had misbuilds using debian's toolchain Jan 19 00:56:55 never figured out why Jan 19 00:56:59 ah, I see Jan 19 00:57:01 but using linaro's toolchain fixed the problem Jan 19 00:57:03 even with the matching version ? Jan 19 00:57:09 debian gcc-7 vs linaro gcc-7 Jan 19 00:57:11 "matching" ? Jan 19 00:57:18 the same version on both sides Jan 19 00:57:18 not sure which version I was using Jan 19 00:57:23 ah Jan 19 00:57:25 I don't think 8 was around yet Jan 19 00:57:52 and it's not arm-none-eabihf in linaro ? Jan 19 00:57:58 it's arm-linux-gnueabihf Jan 19 00:58:35 I'm actually not sure it matters for the linux kernel, but I'm using arm-linux-gnueabihf Jan 19 00:58:56 right Jan 19 00:59:14 I'm pretty sure that since the kernel doesn't use any standard libs or startfiles and probably overrides most options, the difference between arm-linux-gnueabihf and arm-none-eabihf disappears Jan 19 00:59:21 yeah Jan 19 00:59:26 but the arm-none-eabihf is probably more targeted at microcontrollers Jan 19 00:59:42 just the kernel people must make sure to not miss any option like -nostartfiles -nodefaultlibs -nostdinc and stuff Jan 19 01:00:07 Stuff! Jan 19 01:01:03 also, building a 5.0.0-rc2-bone0 kernel sounds rather bleeding edge Jan 19 01:01:12 also, nopreempt? o.O Jan 19 01:01:26 it's just a local version string I added because I already have a 5.0.0-rc2 kernel installed Jan 19 01:01:35 I called it nopreempt because I disabled kernel preemption Jan 19 01:01:45 to match the 5.0.0-rc2 config I've put on the RPi Jan 19 01:01:57 disable preemption? why? Jan 19 01:02:09 to match the raspberry pi config Jan 19 01:02:10 that's like, optimized for batch processing systems Jan 19 01:02:23 throughput at the expense of latency/responsiveness Jan 19 01:02:27 because I ran out of ideas to determine why 6LoWPAN doesn't work correctly on BBB Jan 19 01:02:35 so I began matching the two kernel .config Jan 19 01:02:47 ah, the same module works on the rpi? Jan 19 01:02:52 yeah Jan 19 01:02:54 I suspect so Jan 19 01:03:01 suspect so or confirmed so? Jan 19 01:03:07 when the RPi sends a large packet it is correctly fragmented on arrival to the BBB Jan 19 01:03:18 but with the reverse that's not true, around 7 bytes are set to zero after the fragmentation Jan 19 01:03:28 that sounds bizarre Jan 19 01:03:42 so I don't know if it's the RPi egress that's working and the BBB egress that's not, or the reverse Jan 19 01:03:47 but I assumed it was the RPi working and the BBB not Jan 19 01:04:04 I swapped the two transceivers to rule out a hardware problem Jan 19 01:08:04 lots of other possibilities of course, like signal integrity issues (definite option if the connections are long enough), a bug in the omap2-mcspi driver, or a bug in the 6lowpan module driver exposed by differences between the omap2-mcspi driver and whatever is used on the pi Jan 19 01:10:30 what clockspeed are you running at ? Jan 19 01:11:37 it might be an option to sniff the spi bus e.g. using PRU, to get a better idea of whether data is already corrupted when it exits the bbb Jan 19 01:14:08 I think it's unlikely the data is corrupted at the PHY level Jan 19 01:14:15 but it's the most plausible option so far Jan 19 01:14:24 because the upper level code is virtually identique on both devices Jan 19 01:14:31 I'm running at max speed, 5 MHz Jan 19 01:17:52 also an interesting idea might be to see what happens if you disable dma for the mcspi device by deleting the 'dmas' and 'dma-names' properties of the spi device using: https://pastebin.com/raw/aHTxJmzC (this can't be done in an overlay, it has to be in the main dts) Jan 19 01:18:25 nice Jan 19 01:18:29 let me try this Jan 19 01:18:38 lemme see if I could easily whip up an spi sniffer using pru Jan 19 01:18:54 that's for finding a bug in omap2-mcspi ? Jan 19 01:18:56 which spi mode are you using? Jan 19 01:19:02 0 Jan 19 01:19:17 for debugging in general, it might also give a clue of what's going on Jan 19 01:19:48 right, thanks Jan 19 01:20:17 if you have a scope, checking the waveform of the signal (especially the clock signal at the 6lowpan module's side of the connection) might also be a good idea Jan 19 01:20:56 ah, right Jan 19 01:20:59 I forgot I had a scope Jan 19 01:21:05 lol Jan 19 01:21:06 I can try it Jan 19 01:21:31 I'm supposed to edit am335x-boneblack-uboot-univ.dtb for the device tree ? Jan 19 01:21:35 if the universal cape is enabled Jan 19 01:22:02 I don't know which dts is the relevant one nowadays, I don't use u-boot overlays myself Jan 19 01:22:17 yeah I remember you saying it Jan 19 01:22:22 you only edit the root device tree then Jan 19 01:22:36 if you have access to the serial output you can see which dtb is loaded by u-boot Jan 19 01:22:43 yeah I use a custom dtb Jan 19 01:22:45 ah, yes Jan 19 01:25:29 as for signal integrity, if your connection has non-negligible length you may be experiencing overshoot/ringing, in which case it'll help to insert a small series resistor at the driving side of the line (i.e. 6lowpan module for MISO and the beaglebone for the other lines). it would have to be pretty bad to actually cause data corruption, but it's probably good to prevent it anyway Jan 19 01:26:38 what module are you using? Jan 19 01:26:42 MRF24J40MA Jan 19 01:26:53 it's a module that microchip is doing themselves Jan 19 01:27:00 so I don't have to design a pcb antenna Jan 19 01:27:34 I soldered it on a piece of prototype board then soldered 2.54mm male headers Jan 19 01:30:22 the wires are pretty short, 8" / 20cm Jan 19 01:33:27 yeah, unfortunately that's not short enough to be negligible :) especially since it doesn't matter that you're running it at only 5 MHz, what matters is the rise/fall time of the signals Jan 19 01:34:16 also lol, issue 4 sounds fun: http://ww1.microchip.com/downloads/en/DeviceDoc/80000299D.pdf Jan 19 01:34:42 lol Jan 19 01:34:47 the best kind of issue Jan 19 01:36:02 the MAC doesn't seem to be used on linux anyway, they have a softMAC implementation Jan 19 01:36:10 I don't know why Jan 19 01:36:26 they say the device doesn't fully support the 802.15.4 MAC, but they say the same for every single supported device Jan 19 01:36:36 seems like they just don't have the correct interfaces for hardware-offloaded MACs Jan 19 01:39:55 I'll also admit I don't really know what the behaviour of the mcspi driver is exactly for cpha=0 (spi modes 0/2), I've only ever used cpha=1 (spi modes 1/3) Jan 19 01:40:23 isn't it just a flag to switch at the spi chip level ? Jan 19 01:40:28 shouldn't change much in the driver itself Jan 19 01:40:46 well, mcspi itself behaves differently for cpha=0 Jan 19 01:40:51 the task of the driver is to fill the tx fifo Jan 19 01:40:51 ah Jan 19 01:41:07 yeah Jan 19 01:42:03 cpha=1 means data is latched on the second clock tick iirc Jan 19 01:42:40 yes, data shifted out on leading clock edge and latched on the trailing clock edge Jan 19 01:43:15 cpha=0 means the data has to be made available immediately when cs is asserted since it will be latched on the leading clock edge Jan 19 01:43:28 yes Jan 19 01:43:49 for a slave Jan 19 01:44:29 afaik mcspi works basically the same for master and slave, apart from controlling the clock in master mode Jan 19 01:44:45 right Jan 19 01:45:47 so normally in cpha=0 mode it will load a word into the shift register on cs, and requires cs to go high again to load the next word. I'm pretty sure however that linux doesn't use the auto-managed cs so I don't know how that changes things exactly Jan 19 01:46:56 to be fair, the mcspi docs are not entirely clear on everything either Jan 19 01:47:28 (nor my own notes for that matter) Jan 19 01:49:05 so linux is using cs as a gpio ? Jan 19 01:49:16 and takes care of it manually Jan 19 01:49:30 no.. I mean, it supports that too, but normally it still goes through the mcspi peripheral, but forced Jan 19 01:50:23 ah Jan 19 01:50:45 I'm just musing though... I mean, it evidently works. if it were unable to transfer multiple words in spi mode 0/2 the effects would have been rather more spectacular than 7 bytes corrupted ;) Jan 19 01:51:16 yeah that's why I thought fragmentation may be the issue Jan 19 01:51:22 and these 7 bytes are always at the same location Jan 19 01:51:26 around byte 0x40 Jan 19 01:51:36 hmmm Jan 19 01:51:42 and that position changes with the address method, if I use a link-local address it goes to 0x70 or something Jan 19 01:51:55 as the RFC is dictating, a link-local address IPv6 header can be compressed Jan 19 01:52:38 in the device tree: / { aliases { spi1 = &spi0; spi2 = &spi1; }; }; that's not confusing at all Jan 19 01:55:57 yeah really annoying, done due to bugwards compatibility Jan 19 01:56:07 bugwards lol Jan 19 01:56:45 basically rcn had to because people were relying on the broken spi bus numbering in older kernels Jan 19 01:57:01 yeah Jan 19 01:58:00 I don't see the dmas property in am335x-bone-common-univ.dtsi or others, I should still use that /delete-property/ thing ? Jan 19 01:58:07 it's because it's included in some file I missed ? Jan 19 02:00:15 ah yeah it's included from somewhere Jan 19 02:00:28 if I decompile the actual dtb I see it in &spi0 Jan 19 02:03:36 it's in am33xx.dtsi Jan 19 02:04:57 I found it in am33xx-l4.dtsi in the 5.0.0-rc2 tree Jan 19 02:06:25 okay then they've been restructuring things in recent kernels Jan 19 02:06:56 if I use a fragment inside the main device tree it will work ? Jan 19 02:07:01 it's not an overlay overall Jan 19 02:07:05 correct Jan 19 02:09:25 so in l4_per->segment@0->target-module@30000->spi@0 I should disable dmas and dma-names Jan 19 02:09:30 but that thing is aliased to spi0 Jan 19 02:09:48 which is what the syntax spi0: spi@0 { /*...*/ }; is saying, right ? Jan 19 02:13:08 the @0 in this case is referring to address offset within the parent device. in earlier kernels you'd have seen the full address of the peripheral there Jan 19 02:13:25 ah, right Jan 19 02:13:29 spi0: is a global label, which lets you reference the node using &spi0 Jan 19 02:13:44 and channel@0 for instance is an address offset too ? Jan 19 02:13:49 I thought it was just like an index Jan 19 02:14:00 &spi0 { channel@0 { /*...*/ }; }; Jan 19 02:14:47 it is an address, however not an address on a memory-like bus but an "address" on the spi bus, which is just the chip select number Jan 19 02:15:09 ah, I see Jan 19 02:19:34 I just flashed my Beaglebone Black to the latest Linux version (Debian 9.5 2018-10-07 4GB SD LXQT ) and find that now there seems to be a password required for superuser login. I have no problem logging in as "debian." Can someone tell me what the default root pw is? Jan 19 02:20:14 root password is not enabled by default, nor does ssh allow root login using a password by default anyway Jan 19 02:20:56 the debian account has sufficient privileges for pretty much any normal use, and for the rare occasion you need root privileges you can use sudo Jan 19 02:22:06 Thanks for the response, zmatt, but it asks for a password. I answer with just the enter key and that doesn't do it. Any ideas? Jan 19 02:22:37 you mean sudo? sudo simply wants the password of the debian account (it should actually say so) Jan 19 02:23:57 No, this is initial login as soon as bootup completes. My ssh session asks "login as:" and as I said, using debian and the advertised password for that works fine. Jan 19 02:24:28 so log in as debian Jan 19 02:24:46 it's the account created for normal use Jan 19 02:25:15 But I need superuser privilages to create users, do device tree overlays, etc. Jan 19 02:25:42 as I already said, "for the rare occasion you need root privileges you can use sudo" Jan 19 02:26:23 That doesn't work either, it wants a password and all that I've tried fail. Jan 19 02:26:58 as I said, "sudo simply wants the password of the debian account (it should actually say so)" Jan 19 02:27:42 Yes, it does say so and it returns "authorization failure" Jan 19 02:27:54 you sure you typed it right? Jan 19 02:28:00 because that should definitely work Jan 19 02:28:48 Tried it several times. Anyway, maybe I should just try reflashing and hope for better luck. Thanks for the help. Jan 19 02:29:23 that's really weird, sudo uses the same password as for the account that invokes sudo Jan 19 02:29:57 there's a default password Arjaytee Jan 19 02:30:01 temporary I think Jan 19 02:30:03 it's said in the motd Jan 19 02:30:04 temppwd Jan 19 02:30:07 temppwd yes Jan 19 02:30:11 but he already said he can log in as debian Jan 19 02:30:23 ah Jan 19 02:30:32 but how do you become superuser Arjaytee ? Jan 19 02:30:41 you're using su I guess ? Jan 19 02:30:47 you shouldn't, you don't know the root password Jan 19 02:30:54 I thought that to use sudo the username must be included in sudoers, maybe debian is. Jan 19 02:30:55 well I said sudo Jan 19 02:31:04 yeah but he didn't confirm Jan 19 02:31:06 correct, debian is a sudoer Jan 19 02:31:08 ah yes he did sorry Jan 19 02:31:23 the username must be included, or the user must be in the correct group Arjaytee Jan 19 02:32:35 wait wth Jan 19 02:32:47 Anyway, many of the exercizes in "Exploring Beaglebone" expect one to be logged in as root, otherwise it's kind of messy. Jan 19 02:32:54 RCNNNNNNNNNNNNNNNNNNNNNN Jan 19 02:33:06 if you can't do sudo with the temppwd password for some reason Arjaytee then you can mount the sd card then modify sudoers Arjaytee Jan 19 02:33:22 how the fuck can an image be on the site for months without anyone noticing the debian account somehow isn't in the sudo group anymore Jan 19 02:33:27 lol Jan 19 02:33:34 unless I'm missing something Jan 19 02:33:43 well I noticed it too now that I think of it Jan 19 02:33:46 (I'm just inspecting the image since I'm too lazy to flash it to sd card) Jan 19 02:33:53 but it was just a matter of mounting the image and adding myself to sudoers Jan 19 02:34:03 then flashing it Jan 19 02:34:11 false alarm! Jan 19 02:34:17 debian is a sudoer Jan 19 02:34:28 in the sudoers group ? Jan 19 02:34:43 or hardcoded in the sudoers file Jan 19 02:35:03 the admin group, and /etc/sudoers.d/admin has: %admin ALL=(ALL:ALL) ALL Jan 19 02:35:15 ah Jan 19 02:35:23 that's strangely non-standard Jan 19 02:35:50 yes that's why I was confused for a moment Jan 19 02:36:13 no idea what the point is, but debian is definitely a sudoer Jan 19 02:36:18 yes Jan 19 02:37:00 before flashing I anyway edited /etc/sudoers with `%sudo ALL=(ALL:ALL) NOPASSWD:ALL' because I didn't find the admin stuff Jan 19 02:37:12 yikes Jan 19 02:37:18 lol Jan 19 02:37:24 typing passwords is time-consuming Jan 19 02:37:30 Maybe I'll try using the other version (without the GUI) and see if that works better for me. Jan 19 02:37:38 IOT ? Jan 19 02:37:42 oh I checked the iot image, not the lxqt image Jan 19 02:37:48 nobody uses the lxqt image ;) Jan 19 02:37:55 the lxqt image has that admin file Jan 19 02:37:59 but it's empty, as I edited it before flashing Jan 19 02:38:05 well I have the lxqt image Jan 19 02:38:09 but I have no screen for the bbb Jan 19 02:38:15 maybe that's why it takes ages to boot now that I think of it Jan 19 02:38:18 so why do you use the lxqt image? Jan 19 02:38:19 lol Jan 19 02:38:23 I should change the systemd target Jan 19 02:40:28 Thanks guys, leaving the chat. Jan 19 02:47:05 disabling DMA doesn't change anything Jan 19 02:47:09 nor lowering the SPI speed Jan 19 02:49:55 at least now I have 73 bytes before it fails Jan 19 02:50:05 so weird Jan 19 02:50:08 and even more if I use IPv6 prefix compression Jan 19 02:50:16 around 90 iirc Jan 19 02:50:37 but it's kind of a hack, I need to use the debugfs interface to the 6lowpan module for that Jan 19 02:51:45 you've checked whether signals look okay? Jan 19 02:52:47 I'm willing to make a small pru program to capture the spi bus for you, if you don't have any better tools for analyzing what's going on Jan 19 02:53:11 my scope is analogic so I don't think it qualifies as a good tool Jan 19 02:53:56 with increased intensity and setting CS as trigger maybe I can see something Jan 19 02:54:01 and repeatedly send packets Jan 19 02:54:38 yeah if you don't mind, that way I can learn how to use the pru Jan 19 02:54:48 simplest would probably be something that captures up to 8 pru inputs (simultaneously) into a single byte and writes it into a ringbuffer whenever any signal changes Jan 19 02:55:07 which could be turned into spi bus data with relatively little effort in linux userspace Jan 19 02:55:19 yes Jan 19 02:55:36 and the pru can read from the spi pins at the same time they're in their SPI function ? Jan 19 02:56:04 no, you'll need to patch some (short!!) wires to suitable pins Jan 19 02:56:09 uh ! Jan 19 02:56:13 I think the DMA thing changed something Jan 19 02:56:20 I was pinging from the BBB to the RPi, nothing changed Jan 19 02:56:30 then I pinged from the RPi to the bbb, it magically worked Jan 19 02:56:34 hum Jan 19 02:56:38 then now from the BBB to the RPi it works as well Jan 19 02:56:49 I don't know if it's the disabled DMA or the lowered speed, maybe a combination of the too Jan 19 02:56:49 that's disturbing Jan 19 02:56:52 yes Jan 19 02:57:04 that's the best result I've achieved since I started this Jan 19 02:57:06 Test it! Jan 19 02:57:16 disabling dma of course also changes things because it keeps the cpu busy during the transfer Jan 19 02:57:30 while the use of dma means other stuff can happen during the transfer Jan 19 02:57:34 yes Jan 19 02:57:58 it's not perfect either, now I can use packets of size 150 (which means fragmentation takes place, the mtu is 123) Jan 19 02:58:09 but if I use size 200 I have a new issues, stuff is corrupted differently Jan 19 02:58:47 I wonder if there's a way to sniff the spi transfers issued by the driver Jan 19 02:58:54 in the kernel Jan 19 02:59:05 using kprobes maybe Jan 19 02:59:54 let me keep the same lowered size but re-enable DMA **** ENDING LOGGING AT Sat Jan 19 02:59:56 2019