**** BEGIN LOGGING AT Wed Nov 28 03:00:01 2018 Nov 28 03:42:48 Hello, I am looking for a BeagleBone that can interface with a touch screen, up to 6 pressure/temp sensors and communication with another piece of hardware that has serial and/or contact closures. Nov 28 10:22:29 does the BBW has some serial console port? it's been some time i had one at hand... Nov 28 10:23:17 white? Nov 28 10:23:38 the white has UART and JTAG via USB (FTDI chip) Nov 28 10:25:14 tbr: good, thanks Nov 28 12:30:26 I'm trying to set up non-standard baudrate on BeagleBone Blue (Jessie 7.5). I've cloned the rc_uart_init into rc_uart_init_special which takes baudrate parity, databits and stopbits and modified it to use ioctl for special baudrates, but I'm not succeeding... Anyone know how to get non-standard baudrates for UART4? Nov 28 12:31:02 The protocol I need is 100000 baud even parity and 2 stopbits. Nov 28 12:34:12 My rc_uart_init_special so far: https://pastebin.com/YZUMVNb7 - lines 126 to 137 is the "interesting" ones. Nov 28 12:38:50 It opens the port fine, but it remains at 115200 instead of going to 100000 as the calling code attempts. Nov 28 12:43:14 Knaldgas: i assume that this rc_uart_init is something in userspace? because probably you need to hack the kernel driver to get arbitrary baudrates. Nov 28 12:57:47 LetoThe2nd, It's part of the libroboticscape, but yes it must be a userspace module. Nov 28 12:58:26 Knaldgas: well then, look at the kernel if the driver actually supports non-canonical baudrates. Nov 28 12:59:21 Oh dear, this takes me deeper than I hoped... Nov 28 13:01:02 Knaldgas: yeah it might be easier to modify the other side of the connection Nov 28 13:01:51 LetoThe2nd, I don't think so - It's a FrSky receiver module. It communicates on SBUS protocol, which is defined as this. Nov 28 13:03:10 I'm a bit surprised if non-standard is not directly supported. - Anyway, I have to go for a few hours. Must have a look when I come back. Nov 28 13:26:51 Knaldgas: non-standard baudrates are supported, but I don't immediately recall the way to do so... (the blame here lies with the ancient tty API, not with the hardware) Nov 28 13:31:13 setserial or sthg like that is one of the tools Nov 28 13:33:26 CBAUDEX seems to be the correct way iirc... Nov 28 13:33:57 setserial would also work, there's some way to directly poke into the baudrate divider Nov 28 13:34:05 but for that you need to know (or guess) the base clock Nov 28 13:34:22 something like 'baud_special' or so Nov 28 13:34:27 no, linux actually supports setting arbitrary baudrate in its termios structure Nov 28 13:34:41 it's just the old compat around it that doesn't Nov 28 13:35:35 I'm trying to find the documentation for it Nov 28 13:37:54 https://github.com/npat-efault/picocom/blob/master/termios2.txt Nov 28 13:38:08 as usual, everything to do with the tty layer is a crawling horror Nov 28 13:39:44 https://github.com/torvalds/linux/blob/master/drivers/tty/tty_baudrate.c#L67-L71 Nov 28 13:41:08 it's not clear to me whether glibc doesn't support this or just failed to document it in the termios manpage Nov 28 13:54:50 the glibc termios struct does in fact have c_ispeed and c_ospeed fields Nov 28 14:05:02 so, cbaudex should work but not for arbitrary baud rates. Nov 28 14:05:10 you still need to use a predefined value Nov 28 14:05:16 but B1000000 is there Nov 28 14:05:20 cbaudex just adds a few extra constants Nov 28 14:05:27 yes, but not B100000 Nov 28 14:05:33 which is what Knaldgas wanted Nov 28 14:05:36 ah Nov 28 14:05:59 yes, you're right Nov 28 14:06:21 that's really an odd value to have Nov 28 14:10:35 easiest is to use the kernel api directly: https://pastebin.com/pf4kVN2a Nov 28 14:12:10 use BOTHER as baudrate selector and fill in the actual baudrate in c_ispeed and c_ospeed Nov 28 14:13:19 cfsetspeed() ? Nov 28 14:13:54 B300 not enough for everybody? Nov 28 14:14:02 thinkfat: those take selector values Nov 28 14:14:14 meh Nov 28 14:14:36 thinkfat: more importantly, they're accessors for the struct termios. it doesn't matter what you do with the struct termios if you use the old ioctls, which glibc does Nov 28 14:15:11 so, ioctl it is with TCSETS or something? Nov 28 14:15:27 av500: I heard B640000 is the absolute maximum anyone should ever need. *snerk* Nov 28 14:15:35 https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/tcsetattr.c#L49-L62 Nov 28 15:10:07 Knaldgas: ah, I just noticed you actually already use c_ispeed/c_ospeed, you just use the wrong ioctl (TCSETS instead of TCSETS2) Nov 28 15:11:35 and use the wrong structure (glibc termios instead of kernel termios2) Nov 28 15:12:19 (they have different values of NCCS and are therefore *not* compatible) Nov 28 16:18:03 hi everyone, i'm trying to get a mrf24j40 cape to work with a beaglebone black, i'm using the standard latest headless debian image from the beagleboard website, is there a quick and easy guide around? i couldn't find any on the website Nov 28 16:20:09 cosimone: looks like it should get auto-detected Nov 28 16:23:40 check with lsmod to confirm its driver got loaded Nov 28 16:25:00 Hi guys. Assuming I don't know what kernel and/or image version will be on a BBB when I first get it, is there anyway to set up an SDcard so it will always automatically flash the eMMC with my image without having to press the S2 button? Nov 28 16:25:32 cosimone: do you have a link for that cape, i've never seen it.. Nov 28 16:25:44 rcn-ee[m]: it has an overlay in bb.org-overlays Nov 28 16:26:13 sarahweefolk: the S2 button is almost never needed Nov 28 16:27:30 sarahweefolk: as long as the u-boot present on eMMC isn't some really weird/ancient/incompatible version, it should be able to boot a flasher card just fine Nov 28 16:27:44 that one didn't get ported to u-boot overlays.... Nov 28 16:29:13 sarahweefolk: S2 button is only required to bypass an incompatible u-boot present on eMMC Nov 28 16:32:12 however if it is incompatible then the S2 button may be a hard requirement. for example, we use a custom-built u-boot which ignores the sd card entirely Nov 28 16:32:13 zmatt: the driver doesn't seem to be loaded when using lsmod Nov 28 16:32:49 here is the output of lsmod: https://bpaste.net/show/e47a4f30fc73 Nov 28 16:32:57 rcn-ee[m]: oh, I see it was in an old repo, not in bb.org-overlays, my bad Nov 28 16:33:18 mmm... Nov 28 16:33:27 cosimone: my mistake, I was looking at an old repository. you may want to talk to rcn-ee[m] about this :) Nov 28 16:33:43 17:25 < rcn-ee[m]> cosimone: do you have a link for that cape, i've never seen it.. Nov 28 16:33:55 zmatt: ok, wait a sec Nov 28 16:34:34 i do have it set as a module: CONFIG_IEEE802154_MRF24J40=m Nov 28 16:34:47 mmm... looks like it's a custom made cape, this website, however, has a very similar one: https://wiki.beyondlogic.org/index.php/BeagleBoneBlack_IEEE802154_Microchip_MRF24J40#Using_the_Microchip_IEEE_802.15.4_Radio_on_the_BeagleBone_Black Nov 28 16:34:55 but we need to create a quick spi overlay for this device.. Nov 28 16:35:06 not exactly the same, but it uses the same exact mrf24j40 chip Nov 28 16:35:23 cosimone: that's not sufficient info Nov 28 16:35:49 it either needs to be exactly identical to an existing cape, including pin usage and identification EEPROM contents Nov 28 16:35:54 or it will need a custom overlay Nov 28 16:36:02 let's try something, so give me sec.. But first, update this dir on your board: cd /opt/source/bb.org-overlays/ ; git pull Nov 28 16:37:52 ok, wait a sec Nov 28 16:39:33 ok, i updated the directory via git pull Nov 28 16:39:39 do i run install.sh? Nov 28 16:40:01 zmatt: sorry i'm not able to give you more info, i got this handed over from a coworker Nov 28 16:40:09 that is the closest thing i was able to find Nov 28 16:40:35 cosimone: now rerun 'git pull' i just pushed: https://github.com/beagleboard/bb.org-overlays/commits/master Nov 28 16:40:46 oh, nice Nov 28 16:40:55 then run ./install.sh Nov 28 16:41:39 you'll have to edit /boot/uEnv.txt and use uboot_overlay_addr4=/lib/firmware/cape-bone-mrf24j40-00A0.dtb (not sure if it has eeprom..) Nov 28 16:41:44 cosimone: well if it's genuinely a custom cape then you'll definitely need more info to get it working, preferably schematics but at the very least full details on pin usage Nov 28 16:41:53 rcn-ee[m]: on it Nov 28 16:42:02 rcn-ee[m]: doesn't seem wise to force-load an overlay that might not be compatible with this custom cape Nov 28 16:42:26 zmatt: i'll try to get more info during the following days if this overlay doesn't work Nov 28 16:42:39 cosimone: force-loading an incompatible overlay can damage both the beaglebone and the cape Nov 28 16:42:46 (e.g. due to drive-conflict) Nov 28 16:43:09 so I personally would be inclined to get proper info first rather than just randomly try stuff Nov 28 16:43:26 make sure this pins match https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-bone-mrf24j40-00A0.dts#L24-L31 Nov 28 16:43:34 the thing is, i got another bb with the exact same cape, which however DOES work, so a compatible overlay may have been originally available Nov 28 16:43:45 ok, i'm going to check for the pins first Nov 28 16:44:03 cosimone: if it has an identification eeprom it may be autodetected Nov 28 16:44:07 in which case all is fine Nov 28 16:44:15 *should be autodetected Nov 28 16:44:28 but I wouldn't *force* a specific overlay without checking Nov 28 16:44:40 ok, i get it Nov 28 16:44:40 maybe someone installed a custom overlay on that other bb? Nov 28 16:44:45 zmatt and thinkfat thank you very much, I'm now reading the "prosa" about how easy the termios2 is to use :o) Nov 28 16:45:03 Knaldgas: like my pastebin showed, the ioctls are drop-in replacements for tcget/setattr Nov 28 16:46:00 it's really weird glibc doesn't use them when available, considering it already has ospeed/ispeed fields in the userspace-visible struct Nov 28 16:49:54 there's a 9-year old glibc bug report for this, which has recently seen some renewed activity: https://sourceware.org/bugzilla/show_bug.cgi?id=10339 Nov 28 16:52:35 nope, it doesn't seem to get loaded Nov 28 16:52:50 hold on, i'm going to inspect it and see what info i can gather Nov 28 16:53:02 rcn-ee[m]: is there a script which shows the probe results for all cape eeproms? Nov 28 16:53:09 i'm also going to take a look at the other one that has it working and report anything i can find if possible Nov 28 16:53:41 cosimone: you can probably use my show-pins script to dump the working pin configuration: https://github.com/mvduin/bbb-pin-utils/#show-pins Nov 28 16:55:31 zmatt not really... (there was one.. probally doesnt work) Nov 28 16:56:54 zmatt: oh, good to hear, where can i find this script? Nov 28 16:59:20 ... I just linked to it Nov 28 16:59:37 bbl, work needs my attention Nov 28 17:00:40 zmatt: damn, i'm really not at my sharpest today Nov 28 17:11:13 cosimone: to check for cape identification eeproms: on the beagle running the recent system, you could be able to see them as /sys/bus/nvmem/devices/1-*/nvmem Nov 28 17:11:42 and then hexdump -C PATH | head each one or so Nov 28 17:13:20 I don't know where exactly in the eeprom the relevant identification string is and I'm too lazy to look it up, but at least you'll be able to see if one is present and programmed Nov 28 17:13:44 thanks, i'm going to try soon Nov 28 17:15:45 zmatt: meanwhile, i got the pin configuration on the working one, here it is in case you're interested: https://bpaste.net/show/761f16867e3c Nov 28 17:18:52 seems to match the mrf cape Nov 28 17:19:03 or not Nov 28 17:19:06 hold on Nov 28 17:19:44 actually no, it seems to be different Nov 28 17:21:15 also the cape eeproms are /sys/bus/nvmem/devices/2-*/nvmem not 1-*, sorry Nov 28 17:21:21 zmatt: what is the "mrf cape" you're talking about? Nov 28 17:21:33 no problem, i still had to check Nov 28 17:22:23 the one with "BB-BONE-MRF24J40" identification Nov 28 17:23:00 which is probably the beyondlogic one Nov 28 17:23:57 ok i see Nov 28 17:24:23 is there by any chance a mass produced cape available that has that identifier, as far as you know? Nov 28 17:24:23 rcn-ee[m]: shouldn't the overlay file be named BB-BONE-MRF24J40-00A0.dts ? Nov 28 17:25:36 zmatt i just imported it exactly the way it was named in 3.8.13, if we can find the original hardware online, i'll pick it up to see what the eeprom actually had programed.. Nov 28 17:25:56 (no luck so far..) Nov 28 17:27:12 where's my fake cape, got an eeprom to test: http://wiki.beyondlogic.org/downloads/MRF24J40eeprom.tar.gz Nov 28 17:27:12 http://wiki.beyondlogic.org/downloads/MRF24J40eeprom.tar.gz Nov 28 17:27:20 ah you found the link too Nov 28 17:27:22 lol Nov 28 17:28:20 yeah it contains the string BB-BONE-MRF24J40 Nov 28 17:28:52 anyway, all this is probably of no help here Nov 28 17:29:26 cosimone: so, show-pin is showing your working system configured the same pins for the spi interface (as the beyondlogic cape), but different pins for the three gpios Nov 28 17:29:49 assuming it is correct (check with hardware people if necessary), you'll need a custom overlay for correct operation Nov 28 17:30:11 it is possible you can simply copy it from the working system Nov 28 17:30:45 zmatt: ok, i see Nov 28 17:30:46 if your custom cape has an identification eeprom, then if the custom overlay is correctly named and placed in /lib/firmware, it will get loaded automatically Nov 28 17:31:11 otherwise you'll need to customize /boot/uEnv.txt to forcibly load the overlay (and disable hdmi audio, which is incompatible with its pin usage) Nov 28 17:31:36 the problem is that the other one is running an older kernel (4.1), while i'm using the standard debian image from the beagleboard website, which uses 4.14 Nov 28 17:31:59 I'm not sure if that matters Nov 28 17:32:26 btw, I think it would be wise to explicitly disable hdmi audio right now on the new beaglebone Nov 28 17:32:45 uncomment the disable_uboot_overlay_audio=1 in /boot/uEnv.txt and reboot Nov 28 17:32:53 since it looks like there may be a drive conflict otherwise Nov 28 17:33:05 ok, i'll look it up and see what i can do for now. worst case scenario, i'll make a full copy of the image on the working one onto the other one Nov 28 17:33:07 which your hardware will not appreciate Nov 28 17:33:14 ok, makes sense Nov 28 17:33:25 i think i did read somewhere about that conflict Nov 28 17:33:33 "read somewhere" ? Nov 28 17:34:15 given that it's specific to your custom cape, there aren't many places you could have read that Nov 28 17:34:28 it was an web page about enabling 6lowpan support i came across a while ago, it wasn't about capes Nov 28 17:34:41 found it: https://blog.vcambria.org/?p=13 Nov 28 17:34:47 then it is not related to what I'm talking about Nov 28 17:36:11 okay it looks like there isn't a drive conflict, but putting a 24.576 MHz clock onto either the reset pin or the wake pin of the mrf24j40 is probably not a great idea either :P Nov 28 17:36:26 this is the reason I'm saying this: Nov 28 17:36:27 P9.25 / audio osc 107 fast rx 7 gpio 3.21 0@spi1 (pinmux_mrf24j40_cape_pins) Nov 28 17:36:56 this shows your working system allocated this pin as gpio, but this is also the pin used for the optional audio oscillator, which is enabled if hdmi audio is enabled Nov 28 17:37:05 mmm... ok, that makes sense Nov 28 17:37:30 either way, like I said, I recommend you disable audio in /boot/uEnv.txt and reboot Nov 28 17:37:38 done Nov 28 17:38:07 ok, i need to leave now, i'll gather some more info later if possible and report it later Nov 28 17:38:16 thanks to everyone who helped me so far Nov 28 17:50:25 zmatt, thanks a lot - I now have some kind of connection (The UARTS speak together now) - Now I just have to decode the input. \o/ Nov 28 17:55:40 Knaldgas: \o/ Nov 28 17:56:41 Knaldgas: btw, I noticed your open() calls are missing O_CLOEXEC Nov 28 17:58:47 as a general rule, any syscall that creates an fd should get O_CLOEXEC (or the equivalent for other syscalls, e.g. SOCK_CLOEXEC), and the fact that this isn't default be considered a historical accident Nov 28 18:02:51 also, whenever you do close(fd[bus]) you should set fd[bus] to -1. otherwise, the next time the bus is closed (e.g. "// close the bus in case it was already open") may end up closing some unrelated fd owned by someone else Nov 28 18:04:59 and error opening should probably include the actual path as well as %m for debugging. the remark "device tree probably isn't loaded" should probably be conditional on the specific error you get when the serial port is not enabled (I think that's EIO ?), and for example not if it's EPERM Nov 28 18:05:19 I mean EACCES Nov 28 19:51:07 zmatt, thanks, I will correct the code accordingly - I copied most from the existing library without filtering Nov 28 19:52:16 it's hard to find a library that is well-written in every aspect Nov 28 19:52:34 but O_CLOEXEC is especially important for libraries Nov 28 19:53:06 even if you don't use threading nor fork, you may end up getting used in a program which does Nov 28 19:54:34 I like to write code that just works, and keeps working. Nov 28 19:55:04 Not easy in C or C++ Nov 28 19:55:18 I think most people like to do so... with mixed success ;) Nov 28 19:56:00 Indeed :) Nov 28 19:57:07 or, I guess writing code that's brittle as fuck isn't always a problem if you do so knowingly (e.g. to quickly test something) Nov 28 19:58:12 The biggest problem is when the language and/or API is made in a way where mistakes are easy to make and difficult to find... Nov 28 19:58:24 the thing I hate the most if when APIs make it hard to write .... yeah exactly that Nov 28 19:59:03 Ever tried Ada (language)? Nov 28 19:59:17 the inotify API is a good example of a horrid correctness-repellent API Nov 28 19:59:22 Hehe Nov 28 19:59:29 know about it, never tried it Nov 28 19:59:51 I have played a little bit with rust Nov 28 20:01:04 I really enjoy that language - Especially when I go back to write C (and the like). Whole classes of errors you simply cannot do in Ada (unless you explicitly ask for it) Nov 28 20:01:30 But C is everywhere, so we'll just have to cope with it Nov 28 20:02:26 On the other hand, I *have* seen nicely written C code too Nov 28 20:02:51 languages can help a lot with catching stupid mistakes Nov 28 20:03:36 yep Nov 28 20:03:36 though people who don't understand why their code is broken will be able to write broken code in any language with little effort Nov 28 20:03:45 Indeed :) Nov 28 20:07:38 heh, I found the rant again I once wrote in comments about inotify... https://pastebin.com/MxffwqZi Nov 28 20:10:05 though what I'm saying in the IN_EXCL_UNLINK paragraph makes no sense, now that I read it again, but fortunately there's no reason to care about kernels that old anymore Nov 28 20:10:30 and I'm nowhere near covering all the dumb stuff about inotify Nov 28 20:11:22 inotify is a seemingly endless fountain of facepalms Nov 28 20:12:33 Nov 28 20:12:35 :-D Nov 28 20:12:59 "It seemed like a good idea at the time"... Nov 28 20:16:25 it also doesn't help that inotify doesn't do quite what people care about. it doesn't monitor for file changes, it's basically a packet sniffer on the VFS layer. that's for example why you can observe file changes on the parent directory, which makes a-priori no semantic sense since a file doesn't have a unique parent directory, but file operations on the vfs layer are performed on dirents rather ... Nov 28 20:16:31 ...than inodes Nov 28 20:20:19 ... hmm, I wonder if that's still true if a file is modified via mmap, or if that yields another inotify-gotcha Nov 28 20:22:00 hah, yep, modifying via mmap produces no MODIFY event whatsoever Nov 28 20:22:05 nice **** ENDING LOGGING AT Thu Nov 29 02:59:59 2018