**** BEGIN LOGGING AT Sun Jul 16 03:00:01 2017 Jul 16 08:18:19 fasle: if you're using a recent image then you shouldn't need an overlay at all Jul 16 08:18:24 I think Jul 16 08:18:38 hmmwait nm Jul 16 08:19:51 can you check your pinmux with my show-pins script? https://github.com/mvduin/bbb-pin-utils Jul 16 08:19:55 also, kernel log? Jul 16 09:04:31 yes will do again thanks, you helped me last time. This time I also think I got it down to the pin config. Will run this tomorrow Jul 16 09:22:31 fasle: "everything works but I get zeros" sounds symptomatic for pinmux issues Jul 16 09:22:50 you may need to disable cape-universal (line 43 of your /boot/uEnv.txt ) Jul 16 09:28:54 Will try. I wanted to set it up along this email from the mailing list. Is that method still the right one? https://www.irccloud.com/pastebin/9WD5P5N8/ Jul 16 09:30:33 I have no idea, but it's a very recent post Jul 16 09:30:51 sounds like beaglelogic could use an update Jul 16 09:32:13 yeah the author is currently porting the driver to kernel 4.9 from what I could understand. Jul 16 09:37:55 this is cool... https://www.youtube.com/watch?v=GZxK_0OSoFk Jul 16 12:50:39 hi all, what is the architecture for am335x in linux ? is it armel? or armhf? or Jul 16 12:54:15 From what I understand, since it has a FPU you could run both hf and sf Jul 16 12:54:32 And from this (https://e2e.ti.com/support/arm/sitara_arm/f/791/t/274171) I'd say that little endian is the way to go Jul 16 12:54:44 But I don't understand to what extent what they say is a limitation Jul 16 12:54:49 am335 is armv7, so it can do both armhf and armel Jul 16 12:56:16 That's what I thought too, but "everything silicon-wise in the AM335x is tied-off for Little Endian. This includes the host A8, the wake-up M3, and the ICSS as well as the peripherals. " Jul 16 12:56:42 Now half of this is chinese to me, but it doesn't look so simple for this chip Jul 16 12:58:08 Sorry, I read "armeb and armel". But yeah it can do both armel and armhf as Humpelstilzchen said Jul 16 12:59:26 * Humpelstilzchen was beginning to wonder where the endianness came from Jul 16 14:15:59 we copied our numeral system from the arabs, who write right-to-left. we should have reversed the order of digits to account for this difference, but we didn't. and thus "big endian" was born. Jul 16 14:16:26 this is why you have to write from right to left when manually adding big numbers Jul 16 14:16:54 (since little-endian is actually the order in which you need digits when doing addition, subtraction, and multiplication) Jul 16 14:19:14 if we hadn't gotten used to seeing numbers in big-endian order on paper, we would never have even considered using big endian order in computers Jul 16 14:28:28 cyberguy: armhf Jul 16 14:30:04 armel is softfloat, which is slow and ABI-incompatible with armhf (i.e. an armel program also needs armel libc and other libraries) Jul 16 14:32:13 (the cortex-a8 is btw also capable of operating in big-endian mode. you can switch between the two at runtime.) Jul 16 14:35:22 Hmm, so armel si used to specifically talk about the soft fload little endian architecture? Jul 16 14:35:40 My bad then, I though that it was just reffering to the endiannes Jul 16 14:36:45 Where does the armhf/armel distinction apply to anyway? The hardware? The kernel? The userspace? Jul 16 14:38:00 userspace. technically, "armel" and "armhf" are names of debian architectures actually Jul 16 14:38:10 Yeah that's what I was looking at Jul 16 14:38:12 https://wiki.debian.org/Multiarch/Tuples Jul 16 14:38:21 the full tuple is arm-linux-gnueabihf Jul 16 14:38:45 That makes more sense to me, I was used to see armel and armel for the architecture Jul 16 14:38:51 and linux-gnueabihf for the OS Jul 16 14:39:23 except I've never seen the term 'armel' except to mean debian's arm little-endian softfloat architecture Jul 16 14:39:51 I saw it the other day using QEMU on a fedora arm distribution Jul 16 14:40:34 strange Jul 16 14:40:35 But I wasn't supposed to, from what I understood Jul 16 14:40:38 Yeah Jul 16 14:42:24 On an unrelated note, I'm having an issue with the elinux wiki Jul 16 14:42:27 http://elinux.org/Beagleboard:BeagleBone_Black_Serial#FTDI_3_Pin_Cable Jul 16 14:42:47 So basically from looking at the datasheet of the cable and the wiki, the TX and RX are inverted Jul 16 14:43:04 But there is this note :"The naming of the signals reflect those of the cable. The swapping of TX and RX takes place on the board." Jul 16 14:43:12 So what am I not understanding here? Jul 16 14:43:18 lemme see Jul 16 14:43:55 I saw the same "mistake?" for the cable that's under this one, and I corrected it Jul 16 14:44:03 But now I'm thinking maybe I missed something Jul 16 14:44:09 tx/rx labeling on a connector is always annoying, like from whose perspective? Jul 16 14:44:31 Yeah the note under says that it's from the cable Jul 16 14:45:00 I was thinking of copying the tables that are in the same page, but the note confused me Jul 16 14:45:10 Like what inverts the Tx and Rx? Jul 16 14:45:23 Am I just overthinking this? Jul 16 14:45:24 then it's indeed wrong. the olimex 3 pin cable section says it right Jul 16 14:45:42 Because I "fixed" it an hour ago Jul 16 14:45:50 ah Jul 16 14:45:53 Rx and Tx were inverted too Jul 16 14:46:13 And since that's the cable I ordered, I got it to work with the fixed table Jul 16 14:46:45 So is there any reason that both were inverted? Like some new cables or a new pinout on the board maybe? Jul 16 14:46:47 weird for such a mistake to have existed for so long on this page Jul 16 14:46:56 no, just a fuck-up Jul 16 14:47:26 Well, I'll fix the table for the FTDI 3 Pin Cable too then Jul 16 14:47:33 a table like the one in the Olimex section is clearest Jul 16 14:47:37 I hope I won't fry anyones board Jul 16 14:47:55 Haha I copie the one that was in the "Adafruit 4 Pin Cable (PL2303)" section Jul 16 14:48:09 Looked clean and more explicit with the Tx/Rx labeling on each side Jul 16 14:50:27 There we go Jul 16 14:50:42 And what happens if someone inverts the two pins? Jul 16 14:50:46 I wonder why 115200 is still the default these days. one day I had to use the serial console for a while to debug something and suddenly I got tired of the slow as fuck output (especially in things like vim). Jul 16 14:50:48 Is it dangerous for the board? Jul 16 14:51:09 and guess what... configuring a 4 times higher bitrate... makes the console 4 times faster! Jul 16 14:51:51 not sure, depends on the specs of the buffer ic Jul 16 14:54:27 it would probably have been smarter to include a series resistor on the txd Jul 16 14:56:24 but iirc the ftdi is only able to source/sink limited current Jul 16 14:57:01 less than the max recommended current for the buffer ic on the beaglebone Jul 16 14:57:15 if something similar is true for other serial cables, there is no harm in swapping the pins Jul 16 18:21:00 hi Jul 17 02:06:15 heelo little mc pussys Jul 17 02:06:32 crab apples for all of you Jul 17 02:06:55 znc? Jul 17 02:07:04 anyone reads this??? Jul 17 02:07:14 I'm alone in this place? Jul 17 02:07:37 its only me and my beatifull raspberry pi ?? Jul 17 02:35:04 ... Jul 17 02:45:20 wow Jul 17 02:45:28 that was ... different ... **** ENDING LOGGING AT Mon Jul 17 03:00:03 2017