**** BEGIN LOGGING AT Tue Mar 31 02:59:59 2015 Mar 31 03:29:45 hi , why beaglebone used musb_hdrc driver and not use uhci_hcd or xhci_hcd ? Mar 31 05:23:28 hello Mar 31 05:25:36 i have beaglebone black board.i am having issues in hardware.power led blink once and board is boot Mar 31 05:26:34 is board damaged completely? Mar 31 05:29:38 hello Mar 31 05:29:53 i am having issues with beaglebone black Mar 31 05:30:17 power led blink once Mar 31 05:30:31 and board is not booting Mar 31 07:01:58 panto: hi, i am trying to get dynamic dt overlays working on a recent 4.0 kernel on my bbb. i have applied your v3 patch (semi-manually) but that's apparently not enough, or it needs to be refined or i failed. it doesnt compile: http://dpaste.com/19DFH3K any hints? Mar 31 07:02:12 hi stefanct Mar 31 07:02:26 yeah, use my mainline tree Mar 31 07:02:49 branch dt-ng4/gcl-bbb-rebase5 Mar 31 07:04:36 948 commit ahead? ambitious :) Mar 31 07:05:21 thanks, ill look into it Mar 31 07:05:42 stefanct, don't be worried :) Mar 31 07:05:58 it's only a couple dozen commits over mainline Mar 31 07:06:05 I haven't pushed master for a while Mar 31 07:06:13 yes, i see Mar 31 07:06:23 thanks, bbl Mar 31 09:03:27 Morning Mar 31 12:09:43 sigh, why do people ask questions and then not stick around to get an answer Mar 31 12:14:17 zmatt because the question was not worth to wait Mar 31 12:15:38 i guess Mar 31 12:16:48 hmm, quite a few people manage to fry their bbb it seems... (we also have one with the power-led-blinks-briefly syndrome) Mar 31 12:33:13 lol, fun, the rpi interconnect doesn't maintain ordering for reads with the same tag, and arm11 can issue up to two reads and doesn't support tagging, with as result that doing x = ACCESS_ONCE( periphA->x ); y = ACCESS_ONCE( periphB->y ); can end up with the values of x and y swapped Mar 31 12:34:16 (if peripheral B responds before peripheral A does) Mar 31 12:51:55 zmatt, need better programming :P Mar 31 12:54:44 ? Mar 31 12:57:14 need better soc Mar 31 12:57:47 that Mar 31 13:00:12 or better cpu... the main (VideoCore) cpu doesn't have this problem since it tags its requests and therefore accepts out-of-order responses Mar 31 13:02:40 I can understand they didn't want to design their interconnect to support multiple outstanding transactions with the same tag, but then they shouldn't have hooked up an arm1176 core without some logic some tag requests and reorder responses :P Mar 31 13:02:50 *some logic to ... Mar 31 13:05:31 (especially funny is that Broadcom in their docs seem to pretend this situation is perfectly normal and even somewhat insinuates it is an inherent problem of AXI) Mar 31 14:50:23 Hello Mar 31 14:53:49 I'd need some help Mar 31 15:02:24 we all ned help Mar 31 15:02:34 Can I help you all ? Mar 31 15:03:02 I do not know Mar 31 15:15:25 +1 woglinde Mar 31 15:46:36 can anyone point me a relatevely new flasher image of debian with lxde for bbb rev A5C (2G!) pls? Mar 31 15:47:15 i only seem to find BBB-eMMC-flasher-debian-jessie-lxqt-4gb-armhf-2015-03-08-4gb.img which is 4GB Mar 31 15:55:01 https://rcn-ee.net/rootfs/bb.org/testing/2015-03-15/lxqt-2gb/ ? Mar 31 15:56:23 see also https://rcn-ee.net/rootfs/bb.org/testing/2015-03-08/ Mar 31 15:57:10 there's lxde and lxqt-2gb subdirs there Mar 31 16:07:00 zmatt: thanks Mar 31 17:50:25 I mistook the drive and accidentally formatted the beaglebone black flash memory. It´s a BBB rev A5C, I never managed to make it boot from an SD. Any sugestion/tutorial of how to restore it? thxx Mar 31 17:53:00 do you have a serial console cable? Mar 31 17:56:29 Nap, only the usb cable Mar 31 18:00:48 so get one Mar 31 18:00:59 to see whats going on, instead of guessing Mar 31 18:16:26 funkIsReady_: linux host system available? Mar 31 18:19:10 since if so, then https://github.com/ungureanuvladvictor/BBBlfs lets you flash the BBB directly via usb Mar 31 18:21:00 though it's odd you can't get sd boot to work... (but I never use the SD slot really, so if there are issues there I probably wouldn't know about it) Mar 31 18:29:06 uSD flasher image doesn't work? Mar 31 18:29:35 you will need to unplug the beagle, insert uSD, Hold boot button (next to uSD slot) THEN apply power Mar 31 18:30:17 or hold boot button, then hold power button long enough to cause it to power cycle Mar 31 18:30:46 or that :) Mar 31 18:30:51 (my version is less convenient, but always good to have options) Mar 31 18:30:52 ;) Mar 31 18:31:26 options are indeed good Mar 31 18:37:37 or connect P8.43 to ground (while powered off), then power up, avoids those annoying buttons altogether Mar 31 18:39:42 (if you also pull P8.45 to +3.3V then it'll netboot instead, all you have to do is setup a BOOTP/TFTP server with a suitably built u-boot and an NFS server with the desired root filesystem) Mar 31 18:55:31 zmatt, that's good to know .. had no idea soem of th eboot pins were brought out like that. Very handy. Mar 31 18:55:47 all of the boot pins are Mar 31 18:56:03 lcd data 0-15 == sysboot 0-15 Mar 31 18:56:03 well hell. Mar 31 18:58:09 see also the BBB2 tab of my am335x pins spreadsheet -> https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view Mar 31 18:58:47 (also, the Boot tab documents the boot modes concisely) Mar 31 20:14:09 hi, i need help , i have this gps http://s1.electrodragon.com/wp-content/uploads/2013/06/EDXGPS-Ublox-NEO-6-GPS-Module-w-Active-Antenna-EERPOM-Battery3.jpg , but the beaglebone black not recognized Mar 31 20:47:11 luchopam, the gps will never detect the beaglebone black :) Mar 31 20:51:03 stt_michael: why? Mar 31 20:53:06 luchopam: check this site (I provide the translated link) http://translate.google.com/translate?hl=en&sl=pt&u=http://dronespersonalizados.blogspot.com/2014/03/teardown-ublox-neo-6m-gygps6mv1-gps.html&prev=search Mar 31 20:53:21 make sure you have the UART wired up correctly Mar 31 20:58:13 moto-timo: ok , but, why in my laptop is recognized automatically Mar 31 20:58:16 ? Mar 31 20:59:41 moto-timo: and why beaglebone black used musb-h driver and not used xhci or uhci ? Mar 31 21:02:15 luchopam, xhci or uhci doesn't suport "otg".. Mar 31 21:05:02 luchopam: I dont' know the Ublox Neo, but all modules I have used have had a UART. Mar 31 21:05:24 Making sure the UART works (correct baud rate, polarity of wires) is step one Mar 31 21:19:48 moto-timo: But not even is recognized in the " lsusb " , however, in my laptop is recognized with 1546:01a6 : "U-Blox AG" Mar 31 21:26:37 luchopam: the device you posted a picture of is not a USB device, what exactly are you hooking to your laptop via USB? Mar 31 21:33:30 luchopam: actually, I take that back, the u-blox neo-6 does support USB, but it's not obvious to me how you'd hook it up from that picture, those look like UART pins Mar 31 21:36:37 smurray: this is datasheet : https://www.u-blox.com/images/downloads/Product_Docs/NEO-6_DataSheet_%28GPS.G6-HW-09005%29.pdf Mar 31 21:36:48 smurray: i use the pins 5 and 6 Mar 31 21:37:25 smurray: look page 12 Mar 31 21:37:43 okay Mar 31 21:38:04 what linux distribution are you running on your BBB? Mar 31 21:38:39 could just be a matter of a different version of the kernel compared to your desktop machine Mar 31 21:39:26 smurray: in BBB , i use archlinux-arm with linux 3.14 Mar 31 21:39:43 in my laptop i use archlinux 3.19 Mar 31 21:41:31 it's possible there's been a change to the cdc_amc driver between those two versions Mar 31 21:42:42 do you see anything in the kernel messages ("dmesg") when the neo-6 is attached to the BBB? Mar 31 21:42:52 smurray: look http://lxr.free-electrons.com/source/drivers/usb/class/cdc-acm.c, in nowhere is the definition of gps ublox Mar 31 21:43:14 yes, it's a generic driver Mar 31 21:43:39 it's possible some piece of behavior was changed that affects your use case Mar 31 21:44:11 another possibility is that your BBB is not supplying enough power to it Mar 31 21:46:30 though from the datasheet it doesn't look like it needs that much Mar 31 21:49:01 smurray: I use the pc to give energy at gps Mar 31 21:52:40 luchopam: any chance there's a grounding issue from that? Mar 31 21:54:28 smurray: I do not think , because in my laptop works Mar 31 21:56:07 the issue would be if you're powering it from your PC and it's ground level is different than the BBB Mar 31 21:57:54 smurray: smurray , can be Mar 31 21:58:14 it looks like it could be powered from the BBB's 3.3V, I'd probably try that Mar 31 21:58:44 you could also just hook up the UART pins to one of the BBB UARTs instead of using USB Mar 31 21:58:56 or at least try doing that to see if it works Mar 31 22:00:52 luchopam, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650774 Mar 31 22:00:58 luchopam, do you have gpsd installed? Mar 31 22:02:26 oh that's right your on arch, well, same package.. Mar 31 22:03:21 rcn-ee: the problem is that not even recognize my gps udev Mar 31 22:04:21 well, test with the factory os... then you can verify if arch messed up their 3.14.. Mar 31 22:06:57 rcn-ee, smurray , ok thanks ! Mar 31 22:08:24 luchopam: I agree with rcn-ee... test with factory OS. Also, I did not realize you are using USB. Like smurray says, I would try UART first. Mar 31 22:08:40 USB can be a world of hurt. Mar 31 22:10:54 luchopam, "specially" with that picture you shared, there's no usb connector on their! ;) Mar 31 22:20:28 * moto-timo nods at rcn-ee Mar 31 22:21:11 nbd, e2fsprogs still broken on mvebu (armv7) Mar 31 22:21:14 ack misfire Mar 31 22:27:22 https://www.facebook.com/MCMElectronics/posts/10153038334588941:0 Mar 31 22:43:38 both good for different things, have both on my desk atm Mar 31 22:43:48 bbb crushes it for external io Mar 31 22:43:58 but pi2 is quad core for cpu intensive stuff Mar 31 22:44:15 i should port my lib to pi one of these days Mar 31 22:44:45 and pi only power over usb port is ghetto Mar 31 23:07:33 If you are going for that use this instead http://www.parallella.org/board/ Mar 31 23:58:53 nerdboy, you got a sec? Apr 01 00:05:10 sure, one sec Apr 01 00:09:18 stt_michael: whadaya got? Apr 01 00:09:45 pm? Apr 01 00:10:04 ok Apr 01 00:11:59 that's kinda vague... Apr 01 01:07:02 ..... the CMAC, XTS, and GCM modes of AES all use the same polynomial base for GF(2^128) arithmetic, but CMAC is big-endian, XTS is little-endian, GCM is also little-endian but reverses the bits of each byte Apr 01 01:07:07 nicely done Apr 01 01:12:29 reversing the bits can really make for a bad day :P Apr 01 01:14:19 uhuh, its representation of the number 1 is (u8[16]){ 0x80, 0, 0, ..., 0 } Apr 01 01:15:16 very convenient Apr 01 01:17:40 you can use bit shifting in terms of the processor but it is easier to support the bits reversed directly no? This reminds me of the way TI made the CITT CRC hardware in their processors backwords bit wise and you had to figure out that they had to create a second set of registers for it to be calculated normally (sigh). Apr 01 01:18:21 well fortunately I'm not implementing GCM, I was just playing with the GCM mode of the AES accelerator and trying to understand what I was seeing Apr 01 01:18:35 (armv7 actually has a bit-reverse instruction btw) Apr 01 01:19:11 (MSP430 does not unfrotuantely :D) TI has the MSP432 which is an ARM core with MSP430 hardware (weird). Apr 01 01:19:39 I once had a run-in with some i2c rtc which used opposite bit-endian for commands and data Apr 01 01:20:05 like... how... Apr 01 01:20:16 that's ... weird. wait was that a seiko part? Apr 01 01:20:35 don't remember Apr 01 01:21:25 yep, it was Apr 01 01:21:50 or maybe not Apr 01 01:22:52 ah yes, it was Apr 01 01:23:56 LOL I may have "seen" that one and avoided (dodged the bullet). :D Apr 01 01:25:47 big-endian is such an annoying historical mistake -.- and we'll probably never get rid of it Apr 01 01:27:08 if only someone back in the 15th century had realized that, since we have opposite writing direction compared with the arabs, the order of the digits should also be reversed when adopting their numeral system Apr 01 01:27:24 but noo Apr 01 01:28:25 thus we ended up with a notation for numbers where, to do arithmetic, you end up using right-to-left writing :/ Apr 01 01:30:06 Hmmmm I remember reading why each group did what they did. I don't think it had to do with notation. Intel used little endian for something to do with the stack Motor used big for a reason to do with registers. Apr 01 01:30:51 However large word sized machines existed in the 60's and 70's so it's a bit vague in the head. Apr 01 01:31:10 I'm pretty sure big endian is mostly popular because we write numbers in big endian Apr 01 01:32:22 You don't use little endian in the internals of the machine I think is why. Apr 01 01:32:35 eh, you do Apr 01 01:32:53 IE your ALU doesn't have temporary registers that are little endian. Apr 01 01:33:06 Speaking from a microinstruction level that is. Apr 01 01:33:20 "endian" only applies when breaking a number up in chunks, often an ALU receives all bits in parallel Apr 01 01:33:35 but when it *is* broken in chunks (i.e. to do bigger arithmetic than the ALU's width), it's little endian Apr 01 01:34:08 e.g., double-size addition first adds the low words, then add-with-carry of the high words Apr 01 01:34:11 Seems too me it makes little difference in the end but that might be just me. Apr 01 01:34:12 little end comes first Apr 01 01:34:24 the endians justify the means? :D Apr 01 01:35:06 beagle bone (heh) Apr 01 01:35:07 every bignum library in existence also uses little-endian word ordering (even on machines with big-endian byte ordering) Apr 01 01:35:53 Hmmm I wonder if the PRU's could be used for bit swaping and AES encryption kind of stuff? Apr 01 01:36:56 sure, if you want a really slow AES engine and a waste of PRU :D (that's assuming it has enough code space) Apr 01 01:38:08 the hardware AES engine does it in 32 cycles per (16-byte) block Apr 01 01:38:26 (or 33, depending on selected mode) Apr 01 01:55:15 You just spoiled my madness. darn it. Actually I would be more curious about FT1248 or fifo into something like an FTDI245R type device. Apr 01 02:04:36 sadly study the x protocol is not nearly as fun as AES encryption :( **** ENDING LOGGING AT Wed Apr 01 02:59:58 2015