**** BEGIN LOGGING AT Thu Mar 02 03:00:03 2017 Mar 02 06:41:10 mujin: I *think* there should be 1.8 V, but I don't remember for sure Mar 02 11:22:55 Hi Mar 02 11:23:19 I am interested to develop javascript API for SPI Mar 02 11:23:33 similar like this https://github.com/kelly/node-i2c/blob/master/src/i2c-dev.c Mar 02 11:23:40 Any pointer ? Mar 02 12:53:34 how certain and unique are MAC addresses on the BBB? Mar 02 12:54:34 are they addresses reused in certain countries or are they globally unique? Mar 02 12:54:58 They are supposed to be unique globally Mar 02 13:01:33 jjulian_: judging by this http://e2e.ti.com/support/arm/sitara_arm/f/791/t/199705 Mar 02 13:01:46 "unique MAC addresses assigned to each AM335x" Mar 02 13:01:55 they do not overlap Mar 02 13:08:50 thanks. i don't feel so confident about it, as other manufacturer stated similar things and ive seen that break because the recycled only around 1024 unqiue numbers Mar 02 13:21:45 Hi Everyone... where can I find a list of the devies inside the device tree of the BeagleBone black ? I need to konw if the FTDI USB to Serial chip is supported out of the box Mar 02 13:22:49 jjulian_: if you don't want to abuse the mac address as a unique identifier for a device, I don't think it's so relevant if the mac addresses are not globally unique Mar 02 13:23:08 thinkfat: thats actually what im trying to achieve Mar 02 13:24:15 jjulian_: for how many devices must your id be actually unique? Mar 02 13:24:33 20k Mar 02 13:24:45 quite some... Mar 02 13:25:33 thought about using the serial number but thats written at the same time as the mac gets written so if theres a bug in creating the eeprom it expect it in both identifier Mar 02 13:26:07 '... it expect it...' was meant to be ' .. i would expect it ...'' Mar 02 13:28:00 hmm, there's probably no eeprom but some efuses on the chip itself... Mar 02 13:28:58 but problem could be the same, yes Mar 02 13:29:22 the only way (which makes it way more complicated) is to boot the device if it has no unqiue ident get one from a backend write that into the eeprom and that would survive even reflash Mar 02 13:31:25 jjulian_: only there is no eeprom Mar 02 13:31:36 the beagle bone black has of course an eeprom Mar 02 13:31:38 jjulian_: unless you put one Mar 02 13:31:54 jjulian_: but the mac addresses are not in an eeprom Mar 02 13:32:14 Hi Everyone... where can I find a list of the devies inside the device tree of the BeagleBone black ? I need to konw if the FTDI USB to Serial chip is supported out of the box Mar 02 13:32:43 thinkfat: yes you are right they are in the control module. Mar 02 13:32:56 cart_man: USB is a probe capable bus, so it doesn't need to be in the device tree. Mar 02 13:33:06 but i was just thinking about where to store that unique ident as persistent as possible Mar 02 13:33:10 cart_man: it is a kernel loadable module and simply needs to be built. Mar 02 13:33:28 jjulian_: correct Mar 02 13:33:28 it is in the typical out-of-box debian kernel builds. Mar 02 13:33:52 hi. i could use some help understanding how the root filesystem is selected by u-boot/linux: Mar 02 13:34:08 cart_man: for more about the default kernel and the device tree, see https://github.com/beagleboard/linux Mar 02 13:34:33 i have a custom yocto distro running from SD-card on BBBW for a long time. now I've moved everything to eMMC and the kernel boots, but it fails trying to detect what partition to use as root filesystem Mar 02 13:35:06 i tried with "setenv bootargs=root=/dev/mmcblk1p2" in u-boot, followed by "boot", but same error Mar 02 13:35:59 but if i enter "setenv finduuid part uuid mmc 1:2 uuid" in u-boot console it boots correctly, but i'm not sure why... Mar 02 13:36:07 jjulian_: the MAC addresses are indeed globally uniquely allocated and in fuses on the CPU. Mar 02 13:37:02 jkridner: how certain is that? could there be possibly something wrong and i get in a range of 20k devices ordered in blocks in over a year have the same mac? Mar 02 13:37:09 jjulian_: the serial number in the EEPROM is unique within BeagleBoards/BeagleBones as it includes a bit of info regarding model, manufacturer and a serial incrementation. Mar 02 13:37:35 boot log: http://paste.debian.net/917628/ Mar 02 13:38:31 jkridner: infact i had some intel NICs and they claimed its also unique but they where not. for a given number of cards we had collisions Mar 02 13:38:33 jjulian_: well, someone pays for the IDs to be unique. There has been some small doubt if there are 2 or 3 unique IDs per CPU, but it is believed to be 3. Mar 02 13:39:09 jkridner: actually they're not as unique as you might think the MACs are ;P Mar 02 13:40:19 jkridner thinkfat: http://www.inetdaemon.com/tutorials/networking/lan/ethernet/mac.shtml Mar 02 13:40:27 jjulian_: if you get a MAC collision (not due to software override) that implies a pretty bad screw-up somewhere Mar 02 13:41:15 2.8147498e+14 Mar 02 13:41:19 zmattL in our data center we had that issue from time to time Mar 02 13:41:23 is a pretty large number (2^48) Mar 02 13:41:25 jjulian_: manufacturers are *not* allowed to reuse MAC addresses Mar 02 13:41:32 they are not, but they do Mar 02 13:42:12 there are 2 MAC addresses allocated by Texas Instruments stored in fuses on the CPU. Mar 02 13:42:18 i guess not all but they do often per country or continent Mar 02 13:42:41 They are said to be in a "range", so the 3rd can be computed between the two. Mar 02 13:43:06 jkridner: I know it implies a range of three... I just forgot where I picked up on that info (other than that there's always a gap of one address between the two) Mar 02 13:43:29 zmatt: it was discussed on e2e.ti.com Mar 02 13:43:42 ah ok Mar 02 13:43:58 the answer could have been a bit more clear, but I'm reasonably confident that Robert and I have figured out the math to determine #3. Mar 02 13:44:12 #1 and #2 are as easy as reading the memory locations. Mar 02 13:44:26 zmatt: as stated before. People are not allwoed to drink and drive, btu they do. And yes ive seen that in our datacenter way more often then i'd guessed before Mar 02 13:44:26 just increment as big-endian 48-bit integer Mar 02 13:44:53 zmatt: yeah, but we did that increment in bash. :-D Mar 02 13:44:58 ew Mar 02 13:45:00 zmatt: sorry responded to the same message by you twice Mar 02 13:45:18 zmatt: ended up creating a look-up table. Mar 02 13:46:10 well, shit happens sometimes. I know a former employer once had a problem during manufacturing and approximately 1000 mac addresses got reused because of some "problem" on the manufacturing line Mar 02 13:46:52 jkridner: you can probably avoid doing math beyond one byte by taking advantage of having both mac and mac+2 ... either both will be even, in which case you use first mac + 1 (no carry needed), otherwise both are odd and you use second mac - 1 (no borrow needed) Mar 02 13:46:58 jjulian_: I'm not going to swear on an affidavit, but I'm willing to put a bit of trust in my co-workers at TI to go to a suitable body to allocate MAC addresses and then create test scripts to pull from that allocation body in production. It isn't trivial, but they aren't newbs at it either. These devices sell in the millions. Mar 02 13:47:02 s/ probably// Mar 02 13:47:10 and of course when it was detected, the 1000 devices were already packaged for shipment an nobody bothered to reprogram them Mar 02 13:48:33 zmatt: you can check our math: https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L264 Mar 02 13:49:59 you know you can do math in bash right? byte=`printf %02x $(( 0x$byte + 1 ))` Mar 02 13:50:09 but to recall: TI is creating the control module and put its MAC in there. and in the BBB manufcaturing theres an eeprom written with a serial numbers. This serial number is distinct / independent from the MAC adresses and these two steps are independent from each other? because then i would just combine these values and have my unique ident Mar 02 13:50:37 either one should be sufficient to uniquely identify a BBB, combined they will definitely be Mar 02 13:51:14 I'd have more trust in the MAC than in the serial number to be honest :P Mar 02 13:51:25 zmatt: what we decided to do to avoid needing to carry any digits was to use the prefix from the lower MAC if it was even and from the higher MAC if it was odd, so they had to do the carry for us. Mar 02 13:51:39 jkridner: that's exactly what I just said Mar 02 13:52:38 and for the last byte, using bash arithmetic and printf is simpler than that giant case statement Mar 02 13:52:47 jjulian_: the serial number is done with no knowledge of the MAC. we just ask manufacturers to create serialized numbers with a YYWW code, manufacturer code and product code embedded in it (helps us with support) Mar 02 13:53:09 jkridner: you're aware that there have evidently been screw-ups with the BBB wireless? Mar 02 13:53:40 (causing them to be detected as plain BBB by u-boot) Mar 02 13:53:58 zmatt: maybe. never used bash arithmetic before. just learned about it on a Phil Polstra DEFCON video on using BeagleBones as USB hacking devices. Mar 02 13:54:20 zmatt: I'm aware of the issue with EEPROMs not being programmed in some.... Mar 02 13:54:58 hello, i got a very specific PRU problem with a debian BBB kernel 4.4.30 r64. you see, i wanna write to the PRU HW registers as tho it was a microcontroller without an OS. isnt there a convenient way to bypass the linux memory management? i allready tried mmap, but i get a bus error each time for the PRU memory. i can allocate just fine outside of that range, but anything within the 0x80000 on 0x43000000 wont even be readable Mar 02 13:55:08 btw. the pointer returned by mmap will have a legit address Mar 02 13:55:09 zmatt: The issue seems to have been that if the wire was loose, the GREEN blob on beagle-tester would still show up, even if a small red 'eeprom: fail' printed on the screen. Mar 02 13:55:40 d'oh :/ Mar 02 13:55:43 some_desperate_d: you're doing this through /dev/mem ? Mar 02 13:55:46 zmatt: the boards sill passed all the tests, which is a requirement to perform the serial number write, but the EEPROMs didn't get written. :( Mar 02 13:55:53 yes dev mem Mar 02 13:55:57 zmatt: so far, I've heard 2 reports of this occuring. Mar 02 13:56:10 jkridner: I think I've seen more than 2 cases here Mar 02 13:56:55 is there any other way than mmap? Mar 02 13:56:56 zmatt: k. I'm still looking at how I can resolve and how wide-spread that issue is. Have them e-mail me directly. Mar 02 13:57:25 just send them to http://beagleboard.org/about for my e-mail address (don't post here) Mar 02 13:57:29 some_desperate_d: I'd suggest using uio instead (either specifically uio_pruss or the generic uio_pdrv_genirq), then the kernel will take care of the necessary power management when you open the device and make the the subsystem clock remains enabled as long as you got that address spaces mmap(0ed Mar 02 13:57:51 (has usual JavaScript obfuscation to avoid crawlers. Mar 02 13:57:54 ) Mar 02 13:58:13 i tried uio before and failed miserably, even tho having xp with it on kernel 3.8 just fine. which is why i resorted trying it with dev/mem.... Mar 02 13:58:40 jkridner: I think I've told all of them that it's a clear production fault and that they should contact the manufacturer... I'll tell them to contact you direct in the future Mar 02 13:59:03 and yeah, the uios are all there. they are propperly included in the device tree and i see all 8 of them in userspace Mar 02 13:59:26 zmatt: yeah... but if they end up on the GHI forums, they should get help there too... they escalate things to me if they cannot answer. Mar 02 13:59:53 some_desperate_d: uio_pruss *should* work, but I've never really used it. I know uio_pdrv_genirq works fine though Mar 02 14:01:39 i have the same memory allocation error with uios. mmap returns a legit pointer but reading or writing will result in a bus error. Mar 02 14:02:17 uhh, then there may simply be a problem with the specific access you're doing Mar 02 14:02:59 hold on, I have something that may be useful Mar 02 14:07:36 how can the access i am doing be the issue when its the same as reading from shared ram, as i did on kernel 3.8? i should still be able to read that same memory after allocating it, shouldnt i? Mar 02 14:08:37 yes, and I don't know :) it's hard to say why you're getting a bus error when I don't know what exactly you're doing. I'm looking up a piece of code I once wrote that may help with figuring out the root cause of your bus errors Mar 02 14:13:55 ugh, why doesn't this compile anymore Mar 02 14:17:25 some_desperate_d: so, if you think it's useful I have a piece of code that traps SIGBUS, classifies the cause (to some degree), and throws a C++ exception instead of terminating the program.... if you think that would be of any use to you I can try to package it for you Mar 02 14:18:55 some_desperate_d: otherwise you'll have to be more specific about what you're doing, since I can access pruss just fine Mar 02 14:19:00 well, i am sure it cant hurt to try. so, if you could send me that code, that'd be great. Mar 02 14:19:42 you'll need this ingredient to be able to unwind signal handlers on arm -> https://github.com/mvduin/arm-signal-unwind Mar 02 14:20:08 thanks Mar 02 14:20:31 I'm trying to get my sigbus handler to compile without heavy dependencies Mar 02 14:23:11 jkridner if I edit my uEnv.txt file and add cape_enable=capemgr.enable_partno=BB_UART2 to it. It never activates the UART ? Mar 02 14:23:48 although ive ssen some tutorials have the uEnv.txt in the /boot folder and others in the /boot/uboot/ folder Mar 02 14:23:56 share a serial boot log or the output of dmesg via pastebin Mar 02 14:24:08 * jkridner doesn't recall the names of all the overlays. Mar 02 14:24:28 I always edit the one in /boot/uEnv.txt Mar 02 14:25:42 jkridner -> http://pastebin.com/rVLBzeg9 Mar 02 14:27:49 I see it failed ... whuuut ? Mar 02 14:27:51 why? Mar 02 14:30:24 some_desperate_d: https://liktaanjeneus.nl/catch-sigbus.tar.xz Mar 02 14:31:40 * jkridner isn't super happy with "gogoinflight" Mar 02 14:32:44 some_desperate_d: basically just type 'make', link the three .o files into your project, and use the functions in src/device.h to access device memory, and it'll turn any bus error into a BusError C++ exception Mar 02 14:33:18 some_desperate_d: I originally made this to scan a region of /dev/mem for peripherals :) Mar 02 14:33:38 so, this will let me access any memory without any restrictions? Mar 02 14:33:58 no, it will do what I just said, nothing more Mar 02 14:34:19 it lets you catch bus errors as C++ exceptions Mar 02 14:34:29 instead of them terminating the whole application Mar 02 14:34:34 jkridner: bounce, bounce? Mar 02 14:35:14 so, when i read memory with a pointer that should result in bus error, that value wont be whats really in that address? Mar 02 14:35:38 some_desperate_d: eh what? Mar 02 14:36:02 cart_man: is the file BB_UART2-00A0.dtbo in /lib/firmware? Mar 02 14:36:15 * jkridner seems to think it was BB-UART2, not BB_UART2 Mar 02 14:36:35 i am not sure what it will mean if bus errors are C++ exceptions instead, for the memory i am reading and the resulting values Mar 02 14:37:19 :/ I did ask in advance whether you thought it might be of use to you Mar 02 14:37:44 if you didn't even understand what I said, then clearly it won't be Mar 02 14:37:46 yeah, and i am sure it can be. i am just not sure what it means. Mar 02 14:38:08 if you don't know what a C++ exception is, it isn't useful to you Mar 02 14:38:20 it means i can keep reading, even with a bus error occuring, right? Mar 02 14:38:32 you could skip over addresses that give a bus error yes Mar 02 14:39:00 cart_man: yup, you have a _ vs. - typo: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART2-00A0.dts Mar 02 14:39:38 i think i can work with that. at least i'd see if any of the memory is accessable at all by reading the entire thing. Mar 02 14:40:12 beware that you should either use the functions in src/device.h to access device memory, or alternatively compile all your code with the -fnon-call-exceptions Mar 02 14:40:19 .. compiler option Mar 02 14:40:36 src/device.h, got it. Mar 02 14:40:50 -fnon-call-exceptions basically makes gcc prepare itself for the possibility that any memory access might throw an exception Mar 02 14:41:10 (which also means it'll generate less efficient code) Mar 02 14:41:38 well, seeing that this is a test for access, it doesnt need to be efficient at all. Mar 02 14:42:25 yeah true, althoguh -fnon-call-exceptions is kinda icky since it affects *all* memory accesses in the code compiled with it Mar 02 14:42:48 it also doesn't suffice on the Cortex-A15 (used e.g. on the beagleboard-x15) :/ Mar 02 14:43:12 the functions in src/device.h (implemented in src/device.S) are basically just single memory accesses wrapped in a function Mar 02 14:43:13 its a beaglebone black. Mar 02 14:43:16 I know Mar 02 14:43:31 the cortex-a8 fortunately still behaves reasonably sane Mar 02 14:45:30 on the cortex-a15, the cpu uses "asynchronous aborts", which means that any memory access that causes a bus error actually seems to succeed at first sight, and then some variable time later you get a cpu fault saying "some access, to somewhere, some time ago had a bus error. good luck!" Mar 02 14:46:01 so, be very glad you're not trying to debug this on a bbx15 :P Mar 02 14:46:42 that seriously made me want to slap ARM in the face saying "what the HELL made you think doing something like this is okay?!" Mar 02 14:48:03 Can anyone assist in converting the BeagleBone_Black_RevB6 .brd file to the ASCII .alg file for importing into Altium Designer? Mar 02 15:03:04 ok, i get errors on make about a missing terminating ' character... Mar 02 15:13:48 some_desperate_d: I've verified it compiles with the included makefile (and in particular the compiler flags therein) Mar 02 15:14:35 missing terminating ' sounds like it's trying to compile as some ancient dialect of C++ Mar 02 15:15:55 oh, I only tested with g++ 6 though... but I think it should also compile with g++ 5 Mar 02 15:17:02 0b1111'0101'0111'1111'1111'0000'0100'1111; this it had issue with. i replaced it with the corresponding hex numbers and now i'll try again Mar 02 15:17:24 that's what I said, you're trying to compile it with the wrong flags Mar 02 15:17:59 I suggest fixing the flags, not changing the source code Mar 02 15:22:25 -std=gnu++1z in particular is needed Mar 02 15:23:43 -fno-strict-aliasing -fwrapv is highly advisable in general (I don't know if this particular code needs it, but I never compile low-level stuff without it) Mar 02 15:24:02 oh, then i'll have to get that. Mar 02 15:24:20 hello Mar 02 15:25:08 is there anyone here? Mar 02 15:25:09 :) Mar 02 15:25:33 no, this is a desolate wasteland, devoid of life. welcome. Mar 02 15:25:47 how hard is to make computer? Mar 02 15:26:07 the schematics of beagle are open source as I understand. Mar 02 15:26:36 can I make computer from these schematics? are they correct and ready to send to manifacturing for pcb? Mar 02 15:27:11 is it available firmware for the chips? Mar 02 15:27:19 ehm Mar 02 15:27:22 :) Mar 02 15:28:49 I'm not sure what to answer, since your questions are either vague or have obvious answers Mar 02 15:29:24 the schematics and pcb layouts of the various beagleboards and beaglebones are available. based on these you could manufacture your own yes Mar 02 15:29:43 doing that in onesies would be hilariously expensive though, I guess Mar 02 15:30:13 yes Mar 02 15:30:56 is it available firmware for chips? Mar 02 15:32:30 so... how expensive will be to build beagle? Mar 02 15:32:56 some price range? for production.... $? Mar 02 15:33:54 I found the images... Mar 02 15:35:00 Thank you. I found the answer of my questions. Sounds fascinating! :-) bye bye Mar 02 15:35:57 long live self-solving problems Mar 02 15:37:02 darn. seems like thats an issue with the compiler of my QT version. i dont really wanna fiddle around with that, because its the compiler we use at my place of work. Mar 02 15:37:42 ehm Mar 02 15:39:57 I'm not sure I really follow, but I'm running low on energy availability for tech support anyhow :P Mar 02 15:41:13 apparently there is a problem with gnu++1z Mar 02 15:41:33 what gcc and which qt? Mar 02 15:43:19 I know my code compiles with gcc 5, I think it can be made to compile with gcc 4.9 with some changes, I'm not even going to attempt to support anything older Mar 02 15:44:45 its 4.9.2 Mar 02 15:49:22 try -std=gnu++1y Mar 02 15:49:57 err, i am currently installing g++ version 5. Mar 02 15:50:08 that's even better Mar 02 15:50:10 gonna see if that'll work out. Mar 02 15:57:23 gcc 4.8 and 4.9 suck considerably regarding newer C++ Mar 02 15:57:35 some stuff breaks on Qt 5.8 Mar 02 15:57:41 * tbr had to patch some things Mar 02 16:53:35 gcc 5 also generates better code overall on arm than gcc 4.9 Mar 02 16:53:38 iirc **** ENDING LOGGING AT Fri Mar 03 03:00:00 2017