**** BEGIN LOGGING AT Sat Jan 30 02:59:58 2016 Jan 30 03:04:15 if i correctly modified the dt to export uart1 and 2, i should see a /dev/ttyO1 and /dev/ttyO2, right Jan 30 03:04:28 perhaps export is the wrong word Jan 30 03:04:34 expose Jan 30 03:06:47 immediately after boot, that is. Jan 30 03:06:51 right? Jan 30 03:07:37 unlike gpio's, there is no need to do anything at run time such as "exporting" pins or whatnot, right? Jan 30 03:07:49 for a serial port, i.e. Jan 30 03:10:33 maybe Jan 30 03:10:36 depends on your userland Jan 30 03:11:02 just to see it in the devfs? Jan 30 03:11:04 the files /dev/ttyO1 and /dev/ttyO2 are functions of your userland (and kernel version) Jan 30 03:11:20 what do you mean by my "userland"? Jan 30 03:11:28 IIRC - ttyOn went back to ttySn in some versions Jan 30 03:11:37 I mean just that Jan 30 03:12:04 oh, well now i understand... Jan 30 03:12:06 userland folks likes to use tools like devicefs, devfs, mdev, udev, static /dev, etc. bunch of shannigans Jan 30 03:12:24 kernel doesn't care how dev is created Jan 30 03:12:37 it just cares a certain major/minor is referenced in an open() Jan 30 03:13:58 ds2: my goal is to determine if my dt mods were good as quickly as possible, e.g., via the command line if possible. how would you do that? Jan 30 03:14:11 good regarding exposing the uarts Jan 30 03:14:22 for this case, dmesg Jan 30 03:14:37 what would you look for in dmesg? Jan 30 03:14:41 or use a userland you know well Jan 30 03:15:01 lines that said tty[OS]n was created Jan 30 03:15:56 which is it, O or S? Jan 30 03:16:04 look in dmesg Jan 30 03:16:10 i have /dev/ttySx already Jan 30 03:16:11 there is a reason why I used a regexp :P Jan 30 03:16:29 if you have a ttySx, then it is a S Jan 30 03:18:12 ds2: so if i see a ttyS1, then I know that means my serial port 1 is available and ready for use? Jan 30 03:18:22 (for example) Jan 30 03:19:57 e.g., for use with an oepn("/dev/ttyS0", ...) ? Jan 30 03:20:02 s/oepn/open/ Jan 30 03:22:45 here's the reason i'm asking specifically about the "O" vs "S" vs "": there already is a /dev/tty1, but according to zmatt, that is not a device but the virtual terminal for linux. how do i know an "S" device is the real serial port? Jan 30 03:23:40 the prefix indicates the driver Jan 30 03:23:59 also, i believe i will see those "S" devices in dmesg right now, even though the current image's dt doesn't have them exposed explicitly. Jan 30 03:24:37 you will only get ttyS/ttyO devices if you enable uarts in your DT Jan 30 03:24:40 i already see /dev/ttySx devices now Jan 30 03:24:45 i have not! Jan 30 03:25:16 let me restate. Jan 30 03:25:59 can you state your /proc/cmdline ? Jan 30 03:26:23 i have only modified the "out-of-the-box" am335x-boneblack.dts to modify the include to am335x-bone-common-no-capemgr.dtsi and to remove the HDMI/tpa stuff Jan 30 03:26:58 hang on - i gotta switch the sdcard and reboot Jan 30 03:27:30 I'd also like to see grep -P '^\w' /boot/uEnv.txt Jan 30 03:27:57 (actually the latter suffices, /proc/cmdline can be deduced from it) Jan 30 03:28:13 be back in about 2 minutes - gotta take a pause with a cause. excuse me. Jan 30 03:32:02 ok, having a look Jan 30 03:33:17 /boot/uEnv.txt has one and only one line: uname_r=4.4.0-bone2 Jan 30 03:33:54 yes Jan 30 03:34:09 ok a bit of topic, but if i have devtmpfs enable then the kernel populates the /dev/ directory with stuff like ttyS and tty based on the major and minor device numbers, without devtmpfs i would need udev or something like that which would also populate the /dev directory based on major and minor numbers? Jan 30 03:34:14 IIRC - the uarts are all enabled by default regardless of versions Jan 30 03:34:28 here is cat /proc/cmdline: console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait Jan 30 03:34:30 only unknown is if the mux's are setup Jan 30 03:34:47 ds2: that sounds a really weird thing to do Jan 30 03:34:52 some versions have special glue code to handle ttyO to ttyS Jan 30 03:35:05 zmatt: it is a UART and you almost always compile in the drver Jan 30 03:35:08 driver Jan 30 03:35:08 s/some/all/ Jan 30 03:35:29 so are the /dev/ttySx devcies the real uart devices or not? Jan 30 03:35:30 I'm using 3.2 :P Jan 30 03:35:33 ds2: yes, but you normally leave them status = "disabled"; until a board file defines the actual pinmux Jan 30 03:36:01 and why would the console be ttyO0? Jan 30 03:36:26 isn't UART1 wired up to the console? Jan 30 03:36:26 yates: because it's either ttyO0 or ttyS0 depending on which driver is being used, which depends on kernel config and has varied over time Jan 30 03:36:30 ds2: uart0 Jan 30 03:36:48 HW follows software naming now? :D Jan 30 03:37:08 well what are the differences in the "S" driver versus the "O" driver? Jan 30 03:37:22 TI hacks vs 8250 driver Jan 30 03:37:23 ds2: am335x TRM uses 0-based numbering for most things Jan 30 03:37:25 i want my open() to work just like it does under my desktop linux. Jan 30 03:37:36 yates: omap-serial vs some crufty generic 8250 driver Jan 30 03:37:52 zmatt: hw docs don't... i.e. it is PRUSS1 Jan 30 03:37:56 omap-serial is "S"? Jan 30 03:38:06 8250 uses S Jan 30 03:38:08 yates: if you use ttyO0 when it should be ttyS0 then it'll get automatically fixed up Jan 30 03:38:14 other way around not Jan 30 03:38:16 8250 is the standard uart on x86 Jan 30 03:38:19 hence ttyO0 is safer to use Jan 30 03:38:43 except userland can get confused Jan 30 03:38:58 i have no ttyOx devices. Jan 30 03:39:12 ds2: it *is* PRUSS1 ... relatives have two PRUSS instances of which am335x retained only PRUSS1 and not PRUSS0 Jan 30 03:39:50 i have the ttySx devices Jan 30 03:39:56 grrrrrrrrrrr Jan 30 03:40:13 so if i use that device, i will be using the non-8250 driver? Jan 30 03:40:24 back to getting 20MHz ADC sampling to work Jan 30 03:40:50 btw this is an am3352 Jan 30 03:41:02 (only one pru) Jan 30 03:42:05 ds2: aegis (am4-something) has both instances, but pruss0 has less features than pruss1 and connects only to pruss1 (bidirectionally), so you can reach it only indirectly via the pruss1 interconnect Jan 30 03:42:40 so if i use the "S" device, i will be using the non-8250 driver? Jan 30 03:42:48 yates: no, S is the 8250 driver Jan 30 03:42:55 oh. Jan 30 03:43:01 O is the omap-serial driver Jan 30 03:43:22 well shazam. Jan 30 03:43:33 why didn't you just say this in the first place?!? :) Jan 30 03:43:58 ultimately it doesn't matter really Jan 30 03:44:11 let me run my code with the S device and see. Jan 30 03:44:16 ?? Jan 30 03:44:24 ok zmatt im confused, there is the kernel config SERIAL_8250_OMAP with the note "This driver uses ttyS instead of ttyO." so i presume this is the 8250 driver which one is the non 8250 driver, i could not find it? Jan 30 03:44:24 what? Jan 30 03:45:02 yates: just ignore me or you get more confused :D Jan 30 03:45:09 filt3r: CONFIG_SERIAL_OMAP Jan 30 03:45:19 filt3r: not sure how much more i can be... Jan 30 03:45:21 :) Jan 30 03:46:10 yates: just try both, for compatibility Jan 30 03:46:25 actually I don't understand why the omap-serial driver uses a different prefix in the first place Jan 30 03:47:02 i'm going with the first one that works... Jan 30 03:47:09 tick-tock Jan 30 03:47:26 nm, am335x actually has a 8250-compatible non-omap uart (the one in pruss) Jan 30 03:47:42 zmatt: ahhh found it Jan 30 03:48:06 yates: yes I meant try both paths in case you ever end up running a kernel that uses the omap-serial driver instead Jan 30 03:48:51 ewe. Jan 30 03:49:23 so S is the SERIAL_8250_OMAP driver, as filt3r said? Jan 30 03:49:30 i'm documenting this.. Jan 30 03:49:32 SERIAL_8250 in general Jan 30 03:49:34 what a concept, eh? Jan 30 03:51:12 see the gazillion 8250-"compatible" uarts tend to have their own quirks and features and such hence the 8250 driver is in fact a big kludge of special cases glued onto even more peripheral-specific helper code Jan 30 03:51:19 yay for universality :P Jan 30 03:52:06 at least they're not UFARTS. Jan 30 03:52:45 someone back in the 80's (National? Fairchild?) thought that was funny so they put them in their databook. "Universal Fully Asynchronous Receiver/Transmitter" Jan 30 03:53:02 hence you get some dubious code reuse in exchange for not being able to fully use the uart's capabilities and a codebase that I personally wouldn't touch with a ten foot pole since any patch might break things for one of the many many variants Jan 30 03:53:19 what's a lad to do? Jan 30 03:53:41 i'll beware... Jan 30 03:54:41 well I'm still using CONFIG_SERIAL_OMAP :P it seems to work fine, and if it turns out to have trouble I'd probably at least dare to submit patches for it (unlike the 8250 driver) Jan 30 03:56:23 i can understand that. Jan 30 03:57:06 I personally wish that horribly crufty 8250 register interface would get dropped in favor of something *sane* instead of retaining it out of backward (lot of emphasis on that word) compatibility Jan 30 03:57:33 the 8250 goes back to, what, the early 80's? Jan 30 03:58:11 it was part of that Intel family, like the 8251 (programmable interval timer) and 8259 (programmable interrupt controller)? Jan 30 03:58:44 i used those on an actual hardware design back in that day. 8085 processor. Jan 30 03:59:22 yes, and it's still here in all its glory... complete with 5-bit 1.5-stopbits mode in case you need to interface with a old teletype Jan 30 03:59:32 ha ha! Jan 30 03:59:41 just in case. Jan 30 03:59:52 who knows, baudot might become hip again Jan 30 04:00:13 and "the bump" Jan 30 04:01:06 we used teletypes and 5-line paper tape satellite bulletins (ephemeris data) back in that era.. Jan 30 04:01:56 "yes sonny, i can remember the first wheel..." Jan 30 04:02:04 meanwhile you can't change things like flow control settings on the fly since the lovely modal register interface won't let you access the relevant registers without setting the divisor latch bit (which stops the uart even in the middle of a character) Jan 30 04:02:20 do you have a photographic memory? Jan 30 04:02:46 no, I spent a fair bit of time trying to make sense of that awful thing Jan 30 04:02:57 the initialization procedure is like a puzzle-adventure game Jan 30 04:03:02 even the TRM gets it wrong Jan 30 04:03:12 (hence bootrom does too) Jan 30 04:04:37 last time I checked the StarterWare uart example also caused random corruption due to incorrect use of the register interface Jan 30 04:04:44 s/example/driver/ Jan 30 04:05:21 i was aghast a couple of years ago when doing an MSP430 design that the uart modules had no buffering. Zilch. Zero. No FIFOs, nothing. Jan 30 04:05:22 (the example was bogus too, compiling into a deadloop if you enabled optimization, but the corruption was due to driver misimplementation) Jan 30 04:05:39 thanks TI Jan 30 04:05:52 that's not always a problem Jan 30 04:06:19 it was for us. Jan 30 04:06:23 yates: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/379360/1342615#1342615 Jan 30 04:06:50 at least it meant i had to be more careful about handling those interrupts than i initially was. Jan 30 04:08:14 I'd blame the PC compatibles Jan 30 04:08:23 and intel Jan 30 04:08:31 8250, 16450, 16550 Jan 30 04:08:40 and the various embedded in ASIC flavors Jan 30 04:08:52 (I've since that post further simplified by init and use of the uart by taking the shortest path to the "operational / fifo config" state, setting necessary registers along the way, and remaining in that state Jan 30 04:08:56 ) Jan 30 04:09:24 since moving back into config will ruin your serial stream anyway it's easier to reset and redo the config Jan 30 04:09:53 s/by init/my init/ Jan 30 04:10:58 avoid frying hw is time consuming :( Jan 30 04:11:16 fifo config (TLR/TCR) is more useful to keep accessible than MSR anyway... MSR's functionality is easier and better done with gpio anyway Jan 30 04:15:14 oh and I discovered that writing bytes to the uart too fast will corrupt its fifo pointers, even if enough space was available Jan 30 04:16:43 I had made the mistake of making my driver too efficient (something other implementations apparently don't suffer from :P ) Jan 30 04:17:04 inserting dummy writes to an unused register in between data writes fixed the problem Jan 30 04:31:00 anyhow, enough ranting for today, time to catch a bit of sleep Jan 30 04:44:45 I've just installed Jessie onto the EMMC on a beaglebone black Version 4. Jan 30 04:45:19 it seems like it consumes a lot of emmc Jan 30 04:45:36 does anyone have similar experience. Jan 30 04:47:52 if you've downloaded a desktop image .. it will .. if you have a console image .. much less likely :) Jan 30 04:48:14 teh 4gb images contain chrome browser which is quite heavy, and unless I'm mistaken some office apps Jan 30 04:49:11 I just used the recommended file from the web Jan 30 04:49:30 well my uart2 isn't sending an tx when it should Jan 30 04:51:46 is it possible the kernel doesn't take the care to initialize the muxmode on its own? i.e., you must explicity create a "uart2_pins" entry in the am33xx_pinmux? Jan 30 04:52:37 try it and see, you say? i think I will! Jan 30 04:53:18 veremit: is there a lightweight package? Jan 30 04:53:31 i dont' need any gui stuff Jan 30 04:54:22 mph: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console Jan 30 04:54:44 that page has a whole range of more-or-less official images Jan 30 04:56:08 ah. whats the difference between flasher and microsd? Jan 30 04:56:29 flasher images will write their contents to the EMMC .. others will run stand-alone from a card Jan 30 04:56:42 its a subtle difference in the boot config Jan 30 04:57:56 veremit: is that done via uEnv.txt? Jan 30 04:58:04 yeah, thats what i though Jan 30 04:58:21 I am not a fan of running anytign off the sd- Jan 30 04:58:23 anyway. Jan 30 04:58:35 yates: I think so Jan 30 04:58:51 that seems to be how its documented on beagleboard.org Jan 30 04:59:14 mph: why not? if you update images very often (like every hour), the sdcard is great. Jan 30 04:59:34 once things are stable, then sure. Jan 30 04:59:59 yates: use NFS for that. Jan 30 05:00:34 otherwise you wear your uSD cards out just the same as emmc :P Jan 30 05:00:48 only I guess uSD cards are replaceable :D Jan 30 05:01:23 veremit: yeah, i ought to. i never took the time to see how to set that up Jan 30 05:02:53 is it an alternate boot mode? Jan 30 05:03:34 not exactly .. it just fires a script on init Jan 30 05:03:44 instead of booting the OS Jan 30 05:05:52 ah Jan 30 05:49:02 veremit: thanks. thats waht we needed. Jan 30 05:49:13 more minimal install Jan 30 05:49:38 mph: np :) Jan 30 05:49:54 its often a better starting point for an embedded project :) Jan 30 06:01:50 yates, i just checked, per default all uarts expect uart0 are disabled and have no configured pinux, but the beagleboard kernel has an additional dtsi file called am335x-bone-pinmux-ttyS2.dtsi, which seems to setup the pinmux for uart2 and also enables uart2 (by including am335x-peripheral-ttyS2.dtsi) Jan 30 06:01:58 in case you don't have it already running Jan 30 06:03:04 so by just including am335x-bone-pinmux-ttyS2.dtsi in your dts it should work, but make sure nothing else in your dts file overwrites uart2, etc. Jan 30 06:23:12 hey, thanks filt3r Jan 30 06:23:15 no it's not running Jan 30 06:23:23 i'm still scratching my head. Jan 30 06:34:07 hmm. Jan 30 06:34:59 i actually had modified my own dts(i) to add uart2 and it is identical to those files. (i didn't use the bindings but my register offsets were correct) Jan 30 06:41:22 filt3r: if i modify a .dts, and assuming it's been corrected compiled into a .dtb, do i simply copy the new .dtb file into /boot/dtbs// for the changes to be implemented? Jan 30 06:41:40 s/corrected/correctly/ Jan 30 06:42:01 yes you just replace the previous file Jan 30 06:42:22 then we may have something else hosed here. Jan 30 06:42:32 like our rx/tx are swapped on the board... Jan 30 06:43:08 well can you probe both pins with a scope and see if you are getting any data out on either one Jan 30 06:43:11 i need to make a test build that just sends a constant stream of characters so i can get on the line(s) with a scope Jan 30 06:44:16 cat /dev/urandom > /dev/tty... should do the trick Jan 30 06:44:19 except for startup, the device i'm communicating with only transmits data, and quite rarely, like once every 5 minute Jan 30 06:48:20 so i would suggest just hooking up a scope to the rx and tx pin and then just trying to output random data on different ports and look for any activity, but i gotta go to sllep now, so good luck :) Jan 30 06:50:07 thanks! Jan 30 06:50:15 one good sign Jan 30 06:50:32 if i cat random to ttyS1 or ttyS2, it works fine Jan 30 06:50:50 if i try ttyS3 or higher, i get a "Input/Output error" Jan 30 06:51:06 which is good since i only put S1 and S2 into the .dtsi Jan 30 06:51:43 "works fine" meaning no input/output error, but i am still not getting data at the input to our level translator Jan 30 06:51:48 ...probing more... Jan 30 06:58:58 what about hw flow control? is it off by default? Jan 30 07:05:23 we are not using the hw flow control lines Jan 30 07:06:58 Huh? Jan 30 07:07:26 sigh... Jan 30 07:07:34 why not just use yes? Jan 30 07:07:51 i.e. 'yes 12345 > /dev/ttyS0' Jan 30 07:08:04 use stty Jan 30 09:47:10 hello everyone Jan 30 09:47:33 How do i form cluster with BBB ? Jan 30 09:48:06 Any relevent resources are welcome :) Jan 30 09:55:08 oh Jan 30 09:55:13 I had an answer for him Jan 30 09:55:14 https://www.linux.com/community/blogs/133-general-linux/748871-building-a-compute-cluster-with-the-beaglebone-black Jan 30 09:56:39 obviously: you port beowulf to it! Jan 30 15:20:27 root@beaglebone:~# cd/sys/class/gpio -bash: cd/sys/class/gpio: No such file or directory Jan 30 15:21:10 wow. Jan 30 15:21:21 good morning beagle-people. Jan 30 15:21:42 it's 10:21am in North by-God Carolina Jan 30 15:22:30 i am STILL having trouble getting /dev/ttyS2 to work. Jan 30 15:23:14 i was wondering if our hardware is hosed, but it appears to work (at least on the tx side) since i exported and configured that gpio and sure enough I can see the line wiggling Jan 30 15:23:48 Hi all Jan 30 15:24:35 here is my modified am335x-bone-common-no-capemgr.dtsi: http://ur1.ca/ognrn -> http://paste.fedoraproject.org/316584/41674521 Jan 30 15:25:55 does this look right? Jan 30 15:26:02 Where can I download GPIO Library for BBB Jan 30 15:26:06 re: uart1/uart2 configurations? Jan 30 15:26:08 root@beaglebone:~# cd/sys/class/gpio -bash: cd/sys/class/gpio: No such file or directory Jan 30 15:26:53 Vinay_: you need to put a space between "cd" and "/sys..." Jan 30 15:27:05 i wouldn't cd there anyway, but i guess you could Jan 30 15:28:03 Ok Thank you very much Jan 30 15:28:24 wow. Jan 30 15:28:27 ok, bye. Jan 30 15:28:50 in linux, the first word is the command and must be followed by a space. Jan 30 16:34:02 in some devices declared in the device tree, there is a "compatible = " property that, as i understand it, associates a driver with the device. Jan 30 16:34:16 why is there no "compatible" property for the uart devices? Jan 30 16:38:47 there is, in the am33xx.dtsi which gets included Jan 30 16:40:11 filt3r: is am33xx.dtsi the exact file name? Jan 30 16:40:19 let me check Jan 30 16:41:01 yes, there is one there. Jan 30 16:41:14 ye am335x-boneblack.dts includes it Jan 30 16:41:47 right. Jan 30 16:43:12 so the device driver "omap3-uart" puts an "S" in the /dev file names? e.g., /dev/ttyS2 ? Jan 30 16:44:17 how do i use the other driver zmatt was talking about yesterday? Jan 30 16:44:45 i.e., what is the proper name i should substitute for "omap3-uart" in my modified dt? Jan 30 16:45:08 i.e., to get /dev/ttyO2? Jan 30 16:45:17 both the omap3-serial and the 8250-omap driver can work with the "omap3-uart" dts node, you need to disable one of them in the kernel config than the other should work Jan 30 16:45:47 the "kernel config"? Jan 30 16:46:26 yes in your kernel tree you should be able to run ARCH=arm make menuconfig Jan 30 16:46:46 oh yeah, that thing. Jan 30 16:48:03 and then you have the two drivers SERIAL_8250_OMAP (also SERIAL_8250_OMAP_TTYO_FIXUP), and the other driver is SERIAL_OMAP Jan 30 16:48:14 you can search with / in the menuconfig Jan 30 16:50:22 filt3r: since this same code runs on the x86 (fedora) but not here, do you think this is a good thing to try? Jan 30 16:50:36 (i.e., switching drivers) Jan 30 16:50:47 good and quick? time is running out Jan 30 16:52:25 hmm i mean it should not take too long to change the kernel config and test it with the other driver (beware that your buildscripts *might* be changing the config), but my guess is that the issue is somewhere else Jan 30 16:52:58 but i might be wrong, i've never used uart1/2 Jan 30 16:53:05 i don't know what else to check. Jan 30 16:54:04 as a gpio, the tx line for uart2 (SPI0_D0) wiggles on the output of our level translator, and at the device's output connector. Jan 30 16:54:37 i did the export/direction/value thing for pin 44 (1 * 32 + 12, gpio1_12_ Jan 30 16:55:38 wait, no, that is our regulator control output. i meant gpio0_3 Jan 30 16:55:52 ok, let me try to setup the uart2 on my bbb Jan 30 16:56:01 well thanks! Jan 30 16:56:45 note that i'm using am335x-bone-common-no-capemgr.dtsi instead of the standard dtsi Jan 30 16:57:12 in am335x-boneblack.dts, that is Jan 30 16:58:05 here is my serial communication interface class, .cpp file: http://ur1.ca/ogo0p -> http://paste.fedoraproject.org/316606/73062145 Jan 30 16:58:19 here is the include file: http://ur1.ca/ogo0t -> http://paste.fedoraproject.org/316607/17309214 Jan 30 16:59:05 i'll be away for awhile to eat breakfast but will remain on the channel. i appreciate your help, filt3r Jan 30 16:59:11 ok Jan 30 17:22:51 ok yates i got uart2 to work on my BBB, on boot you should get the message "48024000.serial; ttyO2 at MMIO 0x48024000 (irq = 159, base_baud = 3000000) is a OMAP UART2" Jan 30 17:23:36 then i connected another uart<->usb converter to pin21 and pin22 of the P9 header on the BBB Jan 30 17:24:06 can if i run yes 1234 > /dev/ttyO2 on the BBB i will receive the string at 9600 baud on my pc Jan 30 17:24:30 and in reverse if i run cat /dev/ttyO2 on the BBB, i can sand strings from my pc to the BBB just fine Jan 30 17:25:32 the default baudrate seems to be 9600 baud tho Jan 30 17:34:22 wow Jan 30 17:34:25 that was quick Jan 30 17:34:36 so what did you do to get it to work? Jan 30 17:35:55 what did you change? Jan 30 17:36:21 nothing, i just added the uart2_pinmux from your devicetree and the uart2 node from your devicetree http://paste.fedoraproject.org/316584/41674521/ Jan 30 17:36:52 do you get the OMAP UART2 message on boot? Jan 30 17:37:22 yeah, i'm looking at it now. Jan 30 17:38:43 here's a synopsis: http://ur1.ca/ogo67 -> http://paste.fedoraproject.org/316618/45417551 Jan 30 17:39:11 ok so you are using the 8250 driver Jan 30 17:39:32 it probably should work but i havent tested it with the 8250 driver Jan 30 17:40:11 fuck the 8250 driver. Jan 30 17:40:15 what did you use? Jan 30 17:40:40 why is your driver different than mine when you used my same device tree? Jan 30 17:40:52 kernel config Jan 30 17:41:43 disable SERIAL_8250_OMAP and enable SERIAL_OMAP instead Jan 30 17:42:11 filt3r: ok, i'll try that. but where did you get the image you are running? Jan 30 17:42:52 mine is from rcn's custom bb build site. https://eewiki.net/display/linuxonarm/BeagleBone+Black Jan 30 17:43:00 using the default kernel config Jan 30 17:43:53 just a note the 8250 driver also works for me Jan 30 17:44:32 but besides that, i'm building my kernel with a trivial buildscript from the mainline source tree and the rootfs i'm using is made by buildroot Jan 30 17:44:45 sorry Jan 30 17:44:51 don't know why i got cut off Jan 30 17:44:52 just a note the 8250 driver also works for me Jan 30 17:44:53 but besides that, i'm buildin Jan 30 17:44:59 but besides that, i'm building my kernel with a trivial buildscript from the mainline source tree and the rootfs i'm Jan 30 17:45:08 ahh fuc Jan 30 17:45:11 copy and paste Jan 30 17:45:11 but besides that, i'm building my kernel with a trivial buildscript from the mainline source tree and the rootfs i'm using is made by buildroot Jan 30 17:45:14 slow down... Jan 30 17:45:27 also the 8250 driver works for me as well Jan 30 17:45:53 so if you are using the 8250 driver you have to use /dev/ttyS2 for uart2 Jan 30 17:46:13 if you are using the omap driver you have to use /dev/ttO2 Jan 30 17:46:49 can you paste the output of your ls /dev/? Jan 30 17:46:58 sek Jan 30 17:47:20 are you getting both /dev/ttyS2 and /dev/ttyO2? Jan 30 17:47:28 no Jan 30 17:47:28 at the same time? Jan 30 17:47:58 so how did you switch to check the other driver so fast? did you change the kernel config and rebuild/reboot that fast? Jan 30 17:48:13 yes Jan 30 17:48:18 shit Jan 30 17:48:33 i have a simple script which builds the kernel and copies the devicetree and zImage to a tftp server folder Jan 30 17:48:40 what buildscript are you using? Jan 30 17:48:41 and then im booting the BBB with TFT and NFS Jan 30 17:48:43 sek Jan 30 17:48:55 sek? Jan 30 17:49:02 ahh i mean sec. Jan 30 17:49:03 :D Jan 30 17:49:07 ah. Jan 30 17:49:37 https://gist.github.com/pietrmar/c7e6ad1b6c68c221c76d Jan 30 17:50:59 *TFTP Jan 30 17:53:20 hi Jan 30 17:55:27 so for the other driver you ran yes 1234 > /dev/ttyS2 ? (note the "S") Jan 30 17:55:37 can someone tell me which process exports the gpio's after boot on beagleboneblack with debian 8.3 (default) 4.1.12-ti-r29? Jan 30 17:58:04 yates`: "yes" Jan 30 17:58:13 but remember its 9600 baud per default Jan 30 17:58:35 i don't care what baud rate at this point, i just want to see some freakin data on my scope Jan 30 17:58:42 i get nothin Jan 30 17:59:16 maybe that error on uart1 is somehow screwing things up Jan 30 17:59:20 let me fix that. Jan 30 17:59:27 didyou see that in my boot log? Jan 30 17:59:56 uart1 == /dev/ttyS1, right? Jan 30 18:00:03 uartx == /dev/ttySx ? Jan 30 18:00:38 seems to be the case, yes Jan 30 18:02:02 did you notice that the irq for your ttyO2 is 159, while the irq for my ttyS2 is 157? Jan 30 18:02:05 any ideas, who export's the gpio's after boot? Jan 30 18:04:21 Funkrusha_: i have not seen that. where did you get the image that you're running? Jan 30 18:05:31 usually /sys/class/gpio/export doesn't have anything than "export", the gpio contorllers, and "unexport" at boot. Jan 30 18:06:09 have you installed something special? Jan 30 18:06:43 i'm using the default debian img from bone101 Jan 30 18:07:15 http://beagleboard.org/latest-images Jan 30 18:07:27 that looks good. Jan 30 18:07:35 i already disabled all cloud9 and nodejs stuff with systemctl Jan 30 18:07:44 but all gpio's are still exported after reboot Jan 30 18:08:37 what do you see to make you think all gpios are exported? Jan 30 18:09:08 can you paste the result of "ls /sys/class/gpio"? Jan 30 18:09:11 yates`: I can' imagin ethe sysfs for that lol ! Jan 30 18:09:12 ls /sys/class/gpio/ Jan 30 18:09:39 * veremit anticipates flood timeout :D Jan 30 18:09:52 the problem is, they seem to be exported and used, cause i tried to use them in a kernelmodule Jan 30 18:10:05 i can set the values in userspace, but not from kernelspace Jan 30 18:10:05 Funkrusha_: can you paste the result of "ls /sys/class/gpio"? Jan 30 18:10:19 bpaste/pastebin Jan 30 18:10:32 yes, paste in a pastebin Jan 30 18:11:02 http://pastebin.com/4gbgcJKF Jan 30 18:11:43 i already get -16 (EBUSY) when i try to gpio_request(_pin_, "labelx") Jan 30 18:13:08 hm. that's wild Jan 30 18:13:23 i've never seen such a thing. Jan 30 18:13:24 and i have only 2 devicetree's loaded Jan 30 18:13:40 http://pastebin.com/uAqskfTV Jan 30 18:13:58 img is in MMC Jan 30 18:14:12 lmao "gpio-test" Jan 30 18:14:17 aha. Jan 30 18:14:25 yeah, what veremit said ^^^^ Jan 30 18:14:45 doesn't fill me with confidence that's what you're intending to do .. :P Jan 30 18:15:28 that says "test all gpios" to me .. :p Jan 30 18:15:47 hence .. all are exported and reserved :p Jan 30 18:16:07 that's just a devicetree tutorial i tried and loaded in Jan 30 18:16:10 nothing special Jan 30 18:16:20 yates`: can you upload the dtb which you are using somewhere, so i can take a look into it? Jan 30 18:16:20 "nothing special" .. hrm. did you look at it? Jan 30 18:16:29 filt3r: good plan Jan 30 18:16:30 after a fresh boot i have only the first devicetree Jan 30 18:16:59 filt3r: allow me to ask you very specifically: so on a boot with the "S" driver, you simply (immediately, with no intervening steps) do a "yes 1234 > /dev/ttyS02" and it works? Jan 30 18:17:00 damn... the found it Jan 30 18:17:01 maybe your rcn's buildsystem has some patch which does something strange to the uart2 pinmux Jan 30 18:17:02 :D Jan 30 18:17:16 filt3r: sure, hang on. Jan 30 18:17:37 i did a "yes 1234 > /dev/ttyS2" or "yes 1234 > /dev/ttyO2" depending on the driver Jan 30 18:17:39 the default /boot/uEnv.txt has "#cmdline=coherent_pool=1M quiet cape_universal=enable" Jan 30 18:17:42 and it works Jan 30 18:17:48 the default /boot/uEnv.txt has "cmdline=coherent_pool=1M quiet cape_universal=enable" Jan 30 18:17:57 i removed the cape_universal Jan 30 18:18:09 sorry for that, didn't recognized it in uEnv.txt Jan 30 18:18:35 and now i have http://pastebin.com/Dtt3YK9Z Jan 30 18:19:03 yates`: but if you use the wrong one, it instead will crate a file in /dev/ttyS/O2 and fill it up iwith the string Jan 30 18:19:10 you get no error message or anything Jan 30 18:19:23 use the wrong one what? Jan 30 18:19:27 dt? Jan 30 18:19:39 yeah, i think i just found my problem... Jan 30 18:19:50 i fucked up. Jan 30 18:20:00 if you have the 8250 driver you have a /dev/ttyS2 file but if you call "yes 1234 > /dev/ttyO2" then it will create a /dev/ttyO2 file and fill it with the date Jan 30 18:20:10 oh, right. Jan 30 18:20:11 yates`: veremit: thx Jan 30 18:20:22 Funkrusha_: sure, good luck. Jan 30 18:20:38 so you get no error telling you that the device is not here or something Jan 30 18:21:01 i had an include in my modified am335x-boneblack.dts that shouldn't have been there. Jan 30 18:21:21 ohh^^ Jan 30 18:21:26 that erroneously set (reset) uart1/uart2 Jan 30 18:21:49 sheesh. Jan 30 18:23:33 this is more a build / maintenance problem. i gotta get my custom-board-build-fu act together. Jan 30 18:24:33 well for developement i would suggest setting up tftp and nfs boot, i'll probably take some time to set it up but after that you can rebuild and reboot a new kernel pretty fast Jan 30 18:25:26 that's the problem. i don't have the time right now. i've gotten cornered into a "it should have been delivered 4 days ago" situation. Jan 30 18:25:40 but yeah, that's a very good idea otherwise. Jan 30 18:26:18 i just have to be more careful for right now. i've been working very late and getting up eearly, and i don't think that helps. Jan 30 18:27:05 thanks very very much for your help, filt3r Jan 30 18:27:29 sure Jan 30 18:28:11 but ye that "projects" are the best, "when is the deadline?" "as soon as possible" ^^ Jan 30 18:28:18 "best" Jan 30 18:31:35 Yesterday :D Jan 30 18:31:41 thats my boss's normal deadline Jan 30 18:32:22 bored of trying to explain to him that customers can't deal with that level of disappointment in delivery. Jan 30 18:51:06 filt3r: unfortunately it was something i offered and put my name to. Jan 30 18:51:19 i didn't think i'd run into this many stupid mistakes.. Jan 30 18:51:42 filt3r: btw, it is working now. isn't is strange how a valid device tree makes things all better? Jan 30 18:51:43 :) Jan 30 18:52:02 tahts nice to hear :) Jan 30 18:54:35 it helps sooo much to bounce these things off of folks like you, so i'm not operating in such a vacuum. thanks again. Jan 30 19:03:31 further, it is working with the actual device. no other changes required. i'm gathering data and getting it to the cloud. woo-hoo! Jan 31 02:33:18 guys, almost everything is working on our custom board now, including my network interface to the cloud, and two serial interfaces (uart1 and uart2) to on-board TPMS and GPS devices. thanks very much for all of your help, including: zmatt, veremit, filt3r, ds2, rcn, and anyone else i've left off. Jan 31 02:33:36 s/my network/the network/ Jan 31 02:33:59 "pics or it never happened" lol .. great news yates` .. you've come a long way! Jan 31 02:34:20 sure, hang on.. Jan 31 02:38:17 http://www.digitalsignallabs.com/custom-board.png Jan 31 02:39:08 cool .. I see you got one of them telit modules .. Jan 31 02:39:15 yes. Jan 31 02:39:31 i still have to code that up.] Jan 31 02:39:39 on a uart I guess? Jan 31 02:39:40 btw, i have a question on this: Jan 31 02:39:46 yeah. Jan 31 02:39:47 uart0 Jan 31 02:40:07 we're using 3 uarts - i'll have to disable its usage by the console Jan 31 02:40:42 this is somewhat off-topic too, so please ignore if not interested. Jan 31 02:41:32 there are two ways I know of to get a cellular module (e.g., this Telit) to show up as a network interface: 1) via ppp, and 2) via the QMI driver Jan 31 02:41:54 does anyone have knowledge of both and can they suggest one approach over the other? Jan 31 02:42:15 I'd probably take ppp .. depending on what you wanna do I guess Jan 31 02:42:25 its the maturer code Jan 31 02:42:36 for now, just get it to act as a network interface. Jan 31 02:42:40 yeah, that's my take too. Jan 31 02:43:14 do you know of a good example of using ppp to connect to a module like this? Jan 31 02:43:21 i.e., via AT commands? Jan 31 02:43:44 yates`: I've not seen any myself .. but there's bound to be examples .. Jan 31 02:43:50 i will ask Telit too, but I thought I'd tap the knowledgebase here. Jan 31 02:45:05 totally random .. but http://www.zombiehugs.com/2011/04/ppp-with-telit-gm862-att/ ? Jan 31 02:45:41 it shuold be really quite easy .. I did ppp back in the dialup days Jan 31 02:46:21 pretty easy being.. what? a week? Jan 31 02:46:30 a day? Jan 31 02:46:35 less than a week lol Jan 31 02:46:52 don't laugh. Jan 31 02:47:13 if things go well, less than a week... Jan 31 02:47:28 I was a linux noob at the time Jan 31 02:47:53 and then we went adsl and bought a router Jan 31 02:47:54 e.g., no hardware issues, no "oh shit Telit's firmware is hosed on this chip/revision", etc., etc., etc. Jan 31 02:48:06 yates`: ah yes, that b*s factor .. Jan 31 02:48:11 b*s? Jan 31 02:48:13 yes, please explain that one to my boss .. :D Jan 31 02:48:16 bullshit** Jan 31 02:48:30 i just did... lol Jan 31 02:48:44 fecal excrement from a male bpvin. Jan 31 02:48:50 bovin? Jan 31 02:49:03 another word for cattle Jan 31 02:49:04 bovine yes Jan 31 02:49:28 I'm spelling challenged. Jan 31 02:49:32 :D Jan 31 02:52:53 i've been lurking on the libqmi mailing list for a few months now and they seem to have a lot of issues. Jan 31 02:53:19 you mean the people or libqmi? Jan 31 02:53:26 ha ha. Jan 31 02:53:30 no, the libqmi Jan 31 02:53:45 yeah, divorce, STDs, financial, etc.. Jan 31 02:53:45 * GenTooMan had too ask you know. Jan 31 02:54:41 signing off. good night! **** ENDING LOGGING AT Sun Jan 31 02:59:58 2016