**** BEGIN LOGGING AT Sat Jan 21 03:00:01 2017 Jan 21 06:58:46 Could anyone recommend a cross-compilation toolchain known to work on fedora type machines? Angstrom seems obsolete what should I be using? With reference to [http://beagleboard.org/linux] Jan 21 06:58:47 thanks Jan 21 06:59:35 the toolchain should match your target Jan 21 07:03:40 tbr: yes targetting arm specifically beaglebone black Jan 21 07:03:55 but want to cross-compile on different machine and have run into lots of problems Jan 21 07:04:35 cannot find any newer angstrom toolchains besides the one from 2011 Jan 21 07:04:42 mentioned on page i linked to Jan 21 07:05:34 btw have also tried linaro toolchains Jan 21 07:12:45 are you targetting a board running angstrom? Jan 21 07:16:54 tbr: i think i understand better what you mean by targetting no Jan 21 07:16:59 targetting debian Jan 21 07:17:07 no = now Jan 21 07:19:01 then you should match its toolchain (gcc/etc) Jan 21 07:19:56 unless ofc you are only building static binaries Jan 21 07:20:14 attempting to build custom kernel Jan 21 07:20:45 ah, then any toolchain will do Jan 21 07:20:56 as kernel and userspace are separate thins Jan 21 07:20:59 things Jan 21 07:21:18 ok so every toolchain i have tried ends up giving me a compilation error Jan 21 07:21:27 i can build on the beaglebone itself Jan 21 07:21:45 but have no luck cross compiling the same kernel source tree and .config as on beagle Jan 21 07:22:07 always dies at some point with obscure error Jan 21 07:22:35 old angstrom actually gets the furthest into compilation Jan 21 07:23:33 dunno which toolchain rcn uses Jan 21 07:26:17 linaro Jan 21 07:26:22 if you mean robert c nelson Jan 21 07:26:26 jj_: https://github.com/beagleboard/linux/blob/4.4/build_on_x86.sh Jan 21 07:26:43 that should work also for you Jan 21 07:29:49 include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory compilation terminated. Jan 21 07:29:59 or gcc6 with a newer linaro is what i get Jan 21 07:30:18 thanks for your help btw Jan 21 07:32:05 that sounds weird Jan 21 07:32:24 which kernel are you building? Jan 21 07:34:26 git clone git://github.com/beagleboard/kernel.git -b 3.8 Jan 21 07:34:35 ./patch.sh'ed Jan 21 07:34:50 oh dear, that's a rather ancient kernel Jan 21 07:34:52 http://beagleboard.org/linux from here instructions Jan 21 07:35:01 its what i have on my beaglebone atm Jan 21 07:35:18 and it works there have succesfully built along with dtb etc Jan 21 07:35:35 i just did a make distclean and got to a different error now Jan 21 07:35:36 hmm Jan 21 07:37:26 which gcc does it use there? Jan 21 07:37:40 oh duh my config went missing back to gcc5 error Jan 21 07:37:53 gcc version 4.6.3 (Debian 4.6.3-14) Jan 21 07:38:06 Target: arm-linux-gnueabihf Jan 21 07:39:19 try for a linaro arm gcc 4.6 then? Jan 21 07:39:46 though, I'd presonally switch to a newer kernel, unless you have very good reasons to stay on it Jan 21 07:40:45 stable beagleboard.org seems to be 4.4 and there is also a 4.9, which is the next LTS kernel Jan 21 07:45:29 oh man Jan 21 07:45:42 i think linaro 4.8 might work Jan 21 07:46:19 makes total sense Jan 21 07:46:24 you cleared up a lot of confusion for me Jan 21 07:46:50 so much jargon for me :) thank you very much Jan 21 08:13:46 you're welcome, good luck on your journey Jan 21 08:55:35 tbr: everything is working perfectly with this 4.8 toolchain I appreciate your time and knowledge, journey just begun)) good night. Jan 21 08:55:53 :) Jan 21 08:56:00 glad you got that working Jan 21 11:50:09 4.8 ... that's pretty ancient Jan 21 12:12:54 Hello, i am a newbie on bb black. I m not able to flash it. I waited for about half an hour after pressing s2. nothing happened. Only USR0 led id blinking. Jan 21 12:13:04 Can anybody help Jan 21 12:31:30 zmatt: 4.9 is latest 'stable' I use .. :P Jan 21 12:32:10 Girish: you will probably need a serial debubg cable to find out what's going on/wrong Jan 21 12:32:24 what image are you using for flashing? Jan 21 13:55:56 zmatt the person who asked about powering up and down the BBB was wanting to know if it could be done without using the push button (IE mechanical interaction) Jan 21 13:56:43 zmatt granted that was ~12 hours ago but that seems like a FAQ too me. Jan 21 14:02:17 right I should have included in my answer-into-the-void that "power button" includes anything that pulls the PWRBTN signal to ground, regardless of whether that's a physical button Jan 21 14:03:39 dunno if it's a FAQ, I don't specifically recall having seen it asked before Jan 21 14:06:00 lol what, that price... https://www.ghielectronics.com/catalog/product/566 Jan 21 14:56:38 Size matters the smaller it is the more expensive. Jan 21 14:57:05 As for the power button I remember it being asked a few times before actually just with different wording each time. Jan 21 14:59:22 zmatt Sometimes it was "can the RTC turn the system on" but similiar kind of questions. Jan 21 16:13:09 any ideas how to enable the wifi on BBBW ? Jan 21 17:15:59 GenTooMan: that's no problem, just remove regulator U4, tie VDD_3V3B to VDD_3V3A, remove R8 and place R9 instead Jan 21 17:16:18 GenTooMan: rtc-only mode works then Jan 21 17:17:06 moving R8 to R9 is no fun patch though Jan 21 17:20:20 zmatt: is that with an iron or hot-air? Jan 21 17:20:49 the usual problem is everything goes "walkies" its no fun Jan 21 17:21:42 my colleague did the patch using rework-tweezers or whatever they're called to remove and a fine-tipped iron to replace Jan 21 17:22:08 yeah that sounds feasible :) Jan 21 17:22:21 they're in a quite obnoxious location too, between the 5V DC and ethernet jacks Jan 21 17:23:17 eww lol Jan 21 17:23:26 you see them? Jan 21 17:23:43 not easily right now lol Jan 21 17:23:51 it also was his first time soldering components *this* tiny but he did it :) Jan 21 17:25:27 R7/R8/R9 are side by side, near the fatso C1 Jan 21 17:25:37 bashrc: it should be enabled by default afaik Jan 21 17:25:58 what about setting ssid/etc? Jan 21 17:26:08 zmatt: yeah I See them Jan 21 17:26:13 they're only 0402's though? Jan 21 17:27:09 bashrc: I don't know much about the wireless setup in default images, I think they're in access point mode by default and with a bit of luck a setup thingy via web interface? I dunno, I'd *hope* they come with quickstart instructions of some sort :P otherwise shame on them Jan 21 17:27:42 bashrc: if you're already in via ssh, wifi is managed by connman, which can be configured via the connmanctl utility Jan 21 17:28:01 ok I'll try that Jan 21 17:28:11 you might be right about it being an ap Jan 21 17:28:24 veremit: I didn't say they were the smallest components in existence Jan 21 17:29:00 zmatt: lol yeah just not like mrs25's :D Jan 21 17:32:38 I've made yet another library for accessing the I/O https://github.com/bashrc/libbbb Jan 21 17:32:48 https://www.youtube.com/watch?v=ONEm1ph3MP4 damn they picked a nice site Jan 21 17:34:19 thank you for the hilight *g* Jan 21 17:35:51 bashrc: please avoid using GPIO_OE directly (instead of going through the kernel) whenever possible, and include a warning that doing so is subject to race conditions if multiple processes try to do the same thing Jan 21 17:36:47 Hi - I just booted from an SD card with Debian 8.6 2016-11-06 4GB SD LXQT . I've got it connected to my mac via USB. I used to be able to ssh with root and no password. Now I can't get in. I've tried debian/debian and debian/temppwd. Jan 21 17:36:54 also, map the stuff you need *once* in an init routine and then close /dev/mem, to allow the program to drop privileges afterwards Jan 21 17:37:00 anyone know what the u/pwd should be? Jan 21 17:37:25 ddc: debian/temppwd should work Jan 21 17:37:59 hmm Jan 21 17:38:24 its odd, all the docs say it should have ip 192.168.7.2, but it got a self assigned 169.x.x.x address Jan 21 17:39:09 bashrc: also keep in mind that bypassing the kernel means you're also responsible for PRCM... if you try to access a gpio controller while the kernel has no active use for it (i.e. no gpios requested on that bank) then if you neglect to enable the gpio controller yourself you'll get a bus error on access Jan 21 17:39:12 zmatt: ok Jan 21 17:39:37 oh you're relying on cape-universal Jan 21 17:39:47 well then everything and the kitchen sink is enabled anyway Jan 21 17:40:02 so that should be ok? Jan 21 17:40:35 if you don't mind depending on the monstrosity that is cape-universal Jan 21 17:40:42 also, EW EW EW Jan 21 17:40:45 :) Jan 21 17:40:52 https://github.com/bashrc/libbbb/blob/master/src/bbb.c#L207-L212 Jan 21 17:41:08 I think that was the default with the latest image Jan 21 17:41:30 seriously, you're spawning a shell process just to write a value to a file Jan 21 17:41:57 is there another way to do it? Jan 21 17:42:26 open, dprintf, close Jan 21 17:42:46 yes I suppose I could do that instead Jan 21 17:42:48 or if you intend to write to it with some regularity, keep the fd open as long as you need it Jan 21 17:43:54 also hardcoding those sysfs paths is a bad idea, they're absolutely not guaranteed to be stable Jan 21 17:44:09 ok Jan 21 17:44:21 I could use find Jan 21 17:45:14 the right way to find devices is libudev Jan 21 17:45:24 or use an udev rule to make a symlink in a well known location Jan 21 17:46:30 wait, if you're using sysfs for gpios also (e.g. digital_input()), why are you also mucking about with /dev/mem ? Jan 21 17:48:23 it seemed like the most reliable way to activate an output Jan 21 17:48:51 ehm, no, sysfs is Jan 21 17:49:12 using /dev/mem is for when the performance gain is absolutely needed and outweighs the sacrifice in safety Jan 21 17:53:50 the safest and most elegant way to do gpio (imho) is declaring the gpios in DT and use an udev rule to setup symlinks (based on DT node name) and permissions, e.g.: https://hastebin.com/usipicepax.txt Jan 21 17:54:06 though I'll admit that's more suited for final applications than quick experimentation Jan 21 17:54:41 direction and, for outputs, initial value are then automatically setup by the kernel during boot Jan 21 17:55:11 it also avoids hardcoding gpio-numbers in applications Jan 21 17:56:26 physical pin numbers make more sense Jan 21 17:58:47 apart from the ambiguity of what you mean by "physical pin numbers", I definitely prefer assigning names to gpios than using any sort of numbering directly Jan 21 17:59:06 especially since I already have cases where the same signal is located on different pins depending on the external hardware connected Jan 21 17:59:16 I wanted something where I could reference the pin numbers and not care about gpio numbers Jan 21 18:01:05 (note btw that the sysfs gpio numbers are not actually guaranteed to be deterministic... they're just numbered sequentially in the order the kernel probes the gpio controllers) Jan 21 18:01:28 ah, even worse Jan 21 18:01:46 that's another reason I assign names to them in DT Jan 21 18:02:31 surely the /dev/mem way must be better then if the gpio assignments are not necessarily reliable Jan 21 18:05:13 not really no, since /dev/mem has a whole bunch of other problems Jan 21 18:06:27 like requiring root privileges, race conditions w.r.t. changing direction, and increased risk to hardware if you make any mistake Jan 21 18:07:03 it has advantages too, but I stil avoid it if sysfs has adequate performance (which it usuaully has) Jan 21 18:07:22 but if the gpio numbers can't be relied upon... Jan 21 18:08:03 you can map (gpio controller, local pin number) to global pin number with a tiny bit more effort Jan 21 18:08:33 do you have an example? Jan 21 18:09:02 not readily, since I avoid the issue entirely by assigning names to gpios, hence applications don't have to know any numbering scheme whatsoever (nor do they have to export pins manually, hence again no need for root perms) Jan 21 18:09:24 but basically: each gpio controller has attributes indicating what global gpio number range they use Jan 21 18:10:04 so once you've identified the gpio controller it's simply global gpio number = local number + base Jan 21 18:12:49 note I do get what you're trying to do and why... and I agree all this should be a lot easier than it is right now Jan 21 18:13:02 yes Jan 21 18:13:29 though my primary wish in that regard would be a utility (preferably with gui) to allow *easy* creation of device trees Jan 21 18:15:06 instead they introduced cape-universal, which I think is an abomination :) and once you run into its limitations you have to toss it entirely since it basically conflicts with pretty much anything you might add to the DT Jan 21 18:15:35 (that's why iirc the bbb will implicitly disable cape-universal if any overlays are loaded at boot) Jan 21 18:15:39 it just enables all the things? Jan 21 18:16:14 it enables everything it can yes, and then just hands pinmux control to userspace Jan 21 18:17:17 not only is that a waste of power, but it means you can't provide DT configuration anymore to those peripherals (since that is only consulted when the driver loads) Jan 21 18:18:12 also, it claims all pins in the kernel's view, the conflict with any other DT addition Jan 21 18:18:40 (well, any other DT addition that either needs a pin or needs one of those peripherals) Jan 21 18:24:13 http://pastebin.com/K0FpZHwz this is the DT fragment corresponding to the named gpios I showed earlier btw Jan 21 18:25:01 (being able to specify ACTIVE_LOW/HIGH in the DT is also nice, we've already had a case where this changed for some signal in a pcb revision) Jan 21 18:25:29 it definitely could still be considerably nicer than this I think Jan 21 18:26:56 note also lines 84/85 showing a minor problem with using BBB expansion header pins for identification Jan 21 18:28:48 I'm not sure this works in the latest 4.4 kernels btw, I don't know whether rcn-ee backported my fixes/patches from 4.8 Jan 21 18:31:48 ok Jan 21 18:33:31 also, tip: if you write something like int big_table_of_constants[] = { ... }; in C inside a function, you're asking the compiler to allocate and initialize that table every time the function is called, which is probably not what you want Jan 21 18:33:51 prepend "static const" to fix Jan 21 18:34:29 I was hoping there would be a article on recommended sd cards for the beaglebone black revC. However, I can't find nothing. I was hoping to use a 8G or 16G card versus the standard 4G. Any guidance? Jan 21 18:35:17 sy: 4G is the minimum... the size you need obviously depend on what you're going to do with it Jan 21 18:35:24 I'd also pay attention to card speed Jan 21 18:35:56 a slow sd card is no fun Jan 21 18:36:05 card speed beats capacity for most uses Jan 21 18:36:08 i'm grad student and our class is going to involve some heavy projects. specs/details on these projects I have no idea but I want to be prepared Jan 21 18:36:27 sy: with GUI ? Jan 21 18:36:42 I'm currently using 32GB sandisk class 10 Jan 21 18:36:45 yes Jan 21 18:37:12 sy: ok, then using more than 4GB would be wise (or invest time in trimming crap from the default lxqt image) Jan 21 18:37:34 32GB sounds excessive for most applications Jan 21 18:37:45 of course, excessive is better than running out of space Jan 21 18:38:35 in regards to speed. how is that ranked? is that what you mean by class? If a card provides higher speeds than what "for example" my i2c bus can give will this cause issues or is that only when the card speed is lower? Jan 21 18:40:46 ehm, if your sd performance is low enough to be compared to i2c, I'd throw that card away Jan 21 18:41:18 cool! thanks guys Jan 21 18:41:28 speed classes are defined by the SD association Jan 21 18:41:51 got ya i'm looking at the now. hey thanks for help everyone! Jan 21 18:41:57 class 10 is the highest class when ignoring UHS (which isn't supported) Jan 21 20:22:13 Well at least SD cards are relatively fast these days. Although I find the '66x" speed designation kind of useless. Personally I prefer the actual speed instead of some relatively (useless) defined value. Jan 21 20:35:53 class 10 means min 10 MB/s write speed... seems pretty defined to me Jan 21 23:18:45 cool, an actual diagram of the am57xx L3 interconnect Jan 21 23:34:41 hi which is the difference between beaglebone black and green wifi? why is more expensive black? Jan 21 23:36:17 black or black-wifi ? Jan 21 23:37:04 normal black Jan 21 23:37:28 the green and green-wifi omit hdmi, also the green-wifi has been designed stupidly and sacrifices a whole bunch of expansion I/O for their wifi (the black-wifi doesn't make that mistake) Jan 21 23:37:45 the normal black has ethernet, no wifi Jan 21 23:37:55 (ditto the normal green) Jan 21 23:38:11 thanks a lot Jan 21 23:38:17 i will buy normal green Jan 22 01:59:59 hello Jan 22 02:00:10 pls help me Jan 22 02:00:27 lan yarraklarım Jan 22 02:00:32 cevap verin Jan 22 02:01:13 help help help Jan 22 02:01:25 yardım edeni sikiyim **** ENDING LOGGING AT Sun Jan 22 03:00:00 2017