**** BEGIN LOGGING AT Wed Apr 06 02:59:58 2016 Apr 06 03:06:20 hi there! How do I tell what revision my beaglebone is? I searched the FAQ, Wiki, and board and can't seem to figure it out. I doubt I have a Rev C, but I'd like to confirm what rev this beaglebone black is Apr 06 03:07:49 I got it at Radio shack for like $20ish and I had forgotten about it till I dug it up the other day Apr 06 03:08:00 head -c 16 /sys/bus/nvmem/devices/$something/nvmem | hexdump -C Apr 06 03:08:12 I forgot the $something but there's probably only one dir there Apr 06 03:08:25 so I have to plug it in and then run that command? Apr 06 03:08:35 there's not a sticker or chip that tells me? Apr 06 03:08:43 there might be Apr 06 03:09:01 if I ask it, it just looks at me funny Apr 06 03:09:30 I don't see any obviously visible marking of the revision here Apr 06 03:09:50 I know, that would be too easy Apr 06 03:10:55 head -c 16 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C Apr 06 03:11:07 (as root, or prepend sudo) Apr 06 03:11:29 for revision C you get: Apr 06 03:11:30 00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 |.U3.A335BNLT00C0| Apr 06 03:12:00 how many different revisions are there for BeagleBone Blacks? just B and C? Apr 06 03:13:17 http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Revisions_and_Changes Apr 06 03:15:15 ohhhhhhhh. my sticker says A6 at the end Apr 06 03:15:22 there ya go Apr 06 03:15:49 is 2GB still enough to run an OS, or should I just plan on an SD card? Apr 06 03:16:50 BTW love the fact that there's a manual and that wiki page is awesome. Not sure how I missed it Apr 06 03:17:00 people had OSes long before the term "gigabyte" was something you could use without being considered a loony Apr 06 03:17:03 :P Apr 06 03:17:30 more practically, yes there are images available that fit in 2 GB, even with GUI Apr 06 03:18:00 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28lxqt-2gb.29_.28BeagleBone_Black_2GB_eMMC.29 Apr 06 03:18:04 2GB is fine but maybe the Debian images are pretty fat these days Apr 06 03:18:43 aw sweet. l33t hax0r-land here I come Apr 06 03:18:44 that one looks pretty good Apr 06 03:18:50 for some reason the IOT image, even though it is smaller than the lxqt-2gb image, hasn't been made to fit in 2 gb (although that is fixable by using resize2fs before flashing) Apr 06 03:19:03 but bed must come first Apr 06 03:19:17 thanks for all the help! Apr 06 03:19:27 the (very minimal) console image is about 70 MB compressed last time I checked Apr 06 03:20:12 about 300-something MB uncompressed (which includes the space reserved for emergency use by root) Apr 06 03:20:40 where have all these images been i've been putting up with having node and stuff installed Apr 06 03:21:03 they've been available since ancient times Apr 06 03:21:10 i suppose so Apr 06 03:21:15 I've always started with a console image Apr 06 03:21:27 then remove crap (yes even the console images manage to have some) Apr 06 03:21:33 i was in a hurry for this project so i got the one that worked first Apr 06 03:21:34 then upgrade to stretch Apr 06 03:22:07 switch to systemd-networkd, remove more packages that are made unnecessary by it (ifupdown, *dhcp*) Apr 06 03:22:27 and then start installing packages needed Apr 06 03:22:57 i wonder how tough it is to put something like alpine on bbb Apr 06 03:24:40 i never put much effort into it so i legitimately don't know Apr 06 03:25:58 seems like you figure out how to run uboot and then put your kernel and maybe device file in place and it works Apr 06 03:26:05 could there be more to it? Apr 06 03:28:21 if it's already available for armhf systems then an appropriate /boot/uEnv.txt might be all that's needed (recent mainline arm kernels support the beaglebone black already) Apr 06 03:28:48 a beaglebone-specific kernel may be useful to enhance functionality and/or improve performance Apr 06 03:30:25 maybe that can be the next step for this project Apr 06 03:31:26 smaller is always possible... I also run code on the bare metal occasionally... such applications tend to be around 6-10 KB and run entirely in on-chip SRAM :P Apr 06 03:31:36 although maybe if i cared enough about security to want a minimal system and grsec kernel i'd change the default password too Apr 06 03:32:03 lol Apr 06 03:32:19 baby steps Apr 06 03:32:28 I commonly use crappy password but only allow SSH access using public keys Apr 06 03:32:51 i.e. to log in with that crappy password you'd need to hook up a serial cable Apr 06 03:32:57 right Apr 06 03:59:27 thank god for the am335x starterware Apr 06 03:59:37 these headers are a godsend Apr 06 04:43:58 kremlin: beware that whenever I've inspected any starterware code, I've found it to be buggy as shit Apr 06 04:44:09 uh oh Apr 06 04:44:19 yeah, im noticing some flaws off the bat w/r/t how they name things Apr 06 04:44:20 some basic example failed to produce working executables if compiled with optimization enabled Apr 06 04:44:28 at least they are inconsistant with the am335x TRM & BBB SRM Apr 06 04:44:40 with linaro? Apr 06 04:44:48 any compiler Apr 06 04:44:52 ah Apr 06 04:45:38 at least any that's not completely braindead will compile while( ! some_global_var ) {} into a deadloop if that global var isn't marked volatile Apr 06 04:46:29 oh uh Apr 06 04:46:36 i had a quick question for you if you've got a moment Apr 06 04:47:02 note that my views may be biased since I've only inspected starterware code in response to problems other people had with it Apr 06 04:47:50 uh oh Apr 06 04:48:05 i was about to ask you about setting the pin mode through the starterware libs Apr 06 04:48:19 like mode 1/2/3/4/5/6/7 for pinmuxing Apr 06 04:48:24 I have no idea Apr 06 04:48:34 I've made my own header for baremetal code Apr 06 04:48:40 i'm looking at it ;) Apr 06 04:48:45 the one you linked before Apr 06 04:48:51 really excellent stuff, btw Apr 06 04:48:52 in jbang ? Apr 06 04:48:58 wish it compi;ed with the TI compilers Apr 06 04:48:59 yes Apr 06 04:49:06 ?? why would you use TI's compiler? Apr 06 04:49:19 because i'm debugging in CCS Apr 06 04:49:20 they don't even install it by default anymore when you install CCS Apr 06 04:49:24 err, linaro Apr 06 04:49:25 CCS uses gcc also by default Apr 06 04:49:35 yes, linaro Apr 06 04:49:37 whoops Apr 06 04:49:40 that's what i meant to say Apr 06 04:50:06 you can make CCS use a different gcc toolchain also... linaro doesn't have a gcc 5 yet? Apr 06 04:50:22 I'm pretty sure you can also convince my headers to work in gcc-4.9 with minor changes Apr 06 04:50:35 they used to work in gcc-4.9 anyway Apr 06 04:50:35 no it's still on 3 Apr 06 04:50:37 4* Apr 06 04:51:10 I think the main problem is that gcc-4.9 is much stricter about what you can or cannot do in a function declared constexpr Apr 06 04:51:31 i've never really poked around on recent gcc's Apr 06 04:51:40 which may be fixable by simply removing the "constexpr" keyword, or the entire function if it is unused Apr 06 04:51:41 i'm used to openbsd's fork of like 4.whatever Apr 06 04:52:17 I can really recommend using a recent gcc Apr 06 04:52:28 also since its code generation quality for ARM has improved much Apr 06 04:52:29 that is going to be a tough sell my friend Apr 06 04:52:37 it used to output really dumb stuff Apr 06 04:52:43 indeed Apr 06 04:53:13 is the optimization any less dumb? Apr 06 04:53:30 over the years i have seen gcc just go more gung-ho with heuristic optimizations Apr 06 04:54:14 my impression is that the code output is much better than it used to be, but I haven't specifically benchmarked it or anything Apr 06 04:55:22 however last time I checked, I no longer needed this thing to prevent gcc from doing stupid stuff with constant folding -> https://github.com/dutchanddutch/jbang/blob/master/include/util/device.h#L104 Apr 06 04:55:46 i'm not really too concerned with performance so much as i am the compiler misinterpreting how i want my code to work and handing me broken objects/executables Apr 06 04:55:52 but i'll take your word for it and give it a go Apr 06 04:55:57 ahhh, that's mostly a problem with C Apr 06 04:57:56 for that I use compiler barriers (listed earlier in the linked file) or volatile, preferably in a wrapper class that makes the registers looks like methods to make sure it's clear there are funny side-effects going on Apr 06 04:58:18 hmm. Apr 06 04:58:49 but there are still things that I can't explain to the compiler no matter how much I wish I could Apr 06 04:59:16 like "this stuff may only be accessed using str/ldr and no other kind of load or store" Apr 06 04:59:29 (necessary for the L3 interconnect configuration registers) Apr 06 05:02:51 I copied a struct of volatile u32... resulting in ldm... resulting in bus error Apr 06 05:03:49 that is heavily arch-specific stuff it seems Apr 06 05:03:59 which is hard to get around via the language itself Apr 06 05:04:42 C/C++ are pretty much the primary languages for low-level/kernel/embedded programming... it should have attributes to declare such things Apr 06 05:05:28 of course also shame on Arteris for making the FlexNOC config register space incapable of coping with multi-word accesses Apr 06 05:05:42 I've never encountered registers which are *that* fussy Apr 06 05:06:27 most peripheral registers on the AM335x support accesses of any size (even when the TRM warns they don't) Apr 06 05:08:52 (the main exception being that write-1-to-clear registers don't support partial writes, but there's never any reason to do so anyway) Apr 06 05:09:09 the problem with that is, in another 5 years when we get C22 or whatever (when such specification we needs becomes available for a comittee to promulgate) Apr 06 05:09:17 it'll be another 40 years before regular toolsets have that capability Apr 06 05:09:19 also, be sure to compile with -fno-strict-aliasing and -fwrapv Apr 06 05:09:54 oh yeah? Apr 06 05:10:12 toolchains seem to do fine jobs with keeping up with the standards... in fact they often already implement features while the standards are still in draft Apr 06 05:10:20 at least in case of gcc and clang Apr 06 05:10:29 I'm not considering cruft like TI's compiler :P Apr 06 05:10:42 clang, oh yeah, forgot about that Apr 06 05:10:57 that's interesting, this is really my first foray into using proper toolchains Apr 06 05:11:05 god, i really really wish CCS wasn't eclipse-based Apr 06 05:11:12 but rather that fancy IDE that jetbrains puts out Apr 06 05:11:16 CLion something-or-other Apr 06 05:11:22 I recommend against using clang for low-level programming btw Apr 06 05:11:23 only have heard positive things about that Apr 06 05:11:29 really? Apr 06 05:11:58 its optimizer is much crazier than gcc Apr 06 05:12:51 good for numerical stuff, but if you do anything that even remotely touches "undefined behaviour" according to the C standard it'll happily take advantage of that to miscompile your code to hell Apr 06 05:15:08 it also doesn't support -fnon-call-exceptions, which is required if you want to turn SIGBUS into C++ exceptions Apr 06 05:15:16 (the other required ingredient being https://github.com/mvduin/arm-signal-unwind ) Apr 06 05:15:27 i am becoming more and more a -O0 person Apr 06 05:15:36 it seems like opts are only good for like Apr 06 05:15:39 userspace C Apr 06 05:16:00 no, you really do want optimization Apr 06 05:16:23 a pointless load in userspace typically takes 1 cycle Apr 06 05:16:35 a pointless load from a peripheral typically takes ~150 cycles Apr 06 05:17:22 you do however need to understand the liberties the compiler has and when/how to restrain it Apr 06 05:19:03 -O0 also makes the compiler output awful to inspect at assembly level... while that's exactly what you need to do to investigate a miscompilation issue Apr 06 05:20:57 but for example peripheral configuration may look something like dev.control = ...; dev.config1 = ...; dev.config2 = ...; write_barrier( dev ); dev.control |= ENABLE; Apr 06 05:21:20 the write_barrier making sure that all configuration is sent to the peripheral before it is enabled Apr 06 05:21:29 (defined in my util/device.h ) Apr 06 05:22:27 the compiler will still be smart enough to notice you wrote dev.control earlier so it can turn that last statement into dev.control = ... | ENABLE; hence avoiding a pointless load Apr 06 05:24:17 my wait_until/wait_while macros however contain a full compiler barrier in the loop body to make busy-waiting on conditions work even without marking stuff 'volatile'... the barrier used is overkill but I was lazy :P Apr 06 05:26:06 it's hard however to contrain the optimizer sufficiently without overly constraining it... like I mentioned I really crave a decent set of attributes to inform the optimizer of the relevant constraints on memory-mapped registers Apr 06 05:27:54 it again seems like i need to spend more time in the baremetal microcontroller world Apr 06 05:28:29 well that or the liberties of the C compiler Apr 06 05:28:37 basically, it expects memory to behave memory-like Apr 06 05:28:48 what is memory like? Apr 06 05:29:07 and more specifically to be like memory accessed by only one thread, the current one Apr 06 05:29:45 memory is just something that responds when the right combos of A[0....], /WR, /RD fire Apr 06 05:30:21 memory-like is: reads have no side-effect and are safe to perform speculatively. reads return the last value written. writes that are overwritten are not important. memory does not change other than due to writes. memory supports reads/writes of any side supported by the architecture in general Apr 06 05:30:44 the order of non-overlapping accesses is unimportant Apr 06 05:31:02 s/any side/any size/ Apr 06 05:31:04 strictly speaking, that is hard pressed to find nowadays Apr 06 05:31:29 no, it's how most memory behaves Apr 06 05:31:31 DRAM as a group would fail those conditions Apr 06 05:31:40 why? Apr 06 05:31:58 reads have side effects on DRAM - it changes timing, causes implicit refreshes, etc Apr 06 05:32:11 that's completely irrelevant Apr 06 05:32:13 reordering ops can change the behavior Apr 06 05:32:19 refreshes are handled transparently by the memory controller Apr 06 05:32:30 timing is not considered semantically important here Apr 06 05:32:50 it is if that causes memory loss Apr 06 05:33:03 it never should unless your memory or memory controller is broken Apr 06 05:33:04 there was that exploit a few months ago... the row hammer stuff Apr 06 05:33:07 yeah okay Apr 06 05:33:32 but the fact that row hammering is possible should be considered a hardware failure Apr 06 05:33:42 or rather, that row hammering can cause bit flips Apr 06 05:34:01 it isn't semantically part of proper DRAM operation Apr 06 05:34:11 expecting everything to behave nicely like SRAM seems outdated Apr 06 05:34:31 all of the aforementioned properties *are* part of the definition of how DRAM is expected to behave Apr 06 05:35:40 expected but in reality.... Apr 06 05:36:02 note that at least SRAM on the am335x fails one of the properties above: the SRAM in the Ethernet subsystem intended for DMA descriptors apparently doesn't have byte-enables, hence any partial write of a word will clobber the rest of that word with garbage Apr 06 05:36:16 (silently, no bus error) Apr 06 05:36:41 hence my claim that is hard to find nowadays Apr 06 05:36:54 to add insult to injury, the registers in that subsystem fully support accesses of any size Apr 06 05:36:58 :P Apr 06 05:36:58 rather then assume those idealized properties.... Apr 06 05:37:07 the compiler *does* assume those properties Apr 06 05:37:24 and can and will reorder instructions under those assumptions Apr 06 05:37:26 one would argue the compiler is broken Apr 06 05:37:40 <-- has often find assembly more sensible then "compilers" Apr 06 05:37:53 argue all you want, I'm just stating the current reality Apr 06 05:39:21 so am I.... HW is a more realistic reality then compilers ;) Apr 06 05:40:10 being forced to code in asm is pretty stupid though... I should be able to have compilers take care of the more obvious drudgery without having to live in fear of miscompilation at the same time Apr 06 05:40:59 especially since optimized code may be awful to write manually Apr 06 05:40:59 'should' but that crumbles away if you work with toolchain guys who seem to be always fixing compiler "bugs" :( Apr 06 05:43:10 -fnon-call-exceptions probably makes gcc quite "safe"... but it's also awful for the code generation quality Apr 06 05:43:23 since it makes gcc assume any load/store can potentially throw an exception Apr 06 05:43:53 (and ditto for some other instructions I think) Apr 06 05:44:34 ah yeah, also all floating-point instructions Apr 06 05:47:54 lol, if you really want to be scared, read the description of -finhibit-size-directive in the gcc manpage Apr 06 05:50:55 I also managed to creep out an intern by exposing him to the existence of __attribute__((returns_twice)) Apr 06 05:51:21 see, compiler guys *do* make attributes or flags to constrain the compiler in the face of Magic(tm), but only when they need it themselves :/ Apr 06 05:55:18 heheh Apr 06 06:11:27 -finhibit-size-directive made me wonder whether I wanted to see what goes on in crtstuff.c or whether I'd be scarred for life Apr 06 06:48:59 wonder if linaro supports -fplan9-extensions Apr 06 06:57:19 linaro's gcc is just a gcc branch, it doesn't deviate from gcc in any major way Apr 06 07:13:28 Can someone tell me what is the difference between "ti-linux-kernel-dev" and "bb-kernel", because both of them clones the stable kernel branch Apr 06 09:17:45 i need help Apr 06 09:18:06 is in the cpuinfo file a serial number available? Apr 06 09:18:46 is anybody available? Apr 06 09:18:47 hello? Apr 06 09:19:04 juergen_: give it a minute Apr 06 09:19:34 im guessing It can't be true that you have a deadline to deliver this info in the next minute, right? Apr 06 09:20:57 ah, sorry! it wasn´t my intention to make stress! ;-) Apr 06 09:21:15 is in the cpuinfo file a serial number available? <--- /proc/cpuinfo ? Apr 06 09:22:20 yes I know this Apr 06 09:22:30 but is already a serial number in this file? Apr 06 09:22:42 in my beagle bone is always the number 000000000 Apr 06 09:22:47 is this ok? Apr 06 09:23:21 I do have the revision A6a Apr 06 09:23:28 of the beagle bone Apr 06 09:23:48 is this also the same in the latest revision? Apr 06 09:23:50 ah so you're asking whether someone has fixed the serial number obtaining Apr 06 09:24:02 was this a bug? ;-) Apr 06 09:24:24 well, if it's _supposed_to_ report a serial number and reports 0 ... Apr 06 09:25:42 that means there is a bug available? And is he fixed? Apr 06 09:26:31 its also possible that there just isn't a serial number available easily Apr 06 09:27:41 the bug can also be that the field shows up despite the information not being there. Apr 06 09:28:19 ;-) that could also be a fix! Me reason for this question is, I need this serial number. Apr 06 09:28:32 juergen_: and i need a steak sandwich. Apr 06 09:28:40 ;-P Apr 06 09:28:46 Me too Apr 06 09:28:47 mjam Apr 06 09:28:48 ;-) Apr 06 09:29:04 juergen_: seriously, i'd say your best bet ist to check if something is stored in the u-boot environment or eeprom. Apr 06 09:29:10 juergen_: maybe for uniqueness purposses you can use something else like the mac address? Apr 06 09:29:36 mac adress, hmmm...where is this adress available? Apr 06 09:29:40 where can I find it? Apr 06 09:29:54 I am really new in the beagle bone world Apr 06 09:29:59 so sorry for my questions! ;-) Apr 06 09:30:06 juergen_: its at the same place it is on any linux system Apr 06 09:30:21 aaahhh, hihihihi ;-) Apr 06 09:30:22 sorry Apr 06 09:34:48 I am also not the pro in linux! ;-) Apr 06 09:35:17 one can always learn something new. :-) Apr 06 09:35:54 ;-))) Apr 06 09:36:09 so, is for this a bugnumber available? Apr 06 09:36:26 which revision of beaglebone is the latest? Apr 06 09:36:54 revision C is in may available? I am right? Apr 06 09:37:54 juergen_: cat /sys/class/net/eth0/address for the mac of eth0 Apr 06 09:48:49 serial number can easily be obtained from eeprom: Apr 06 09:48:51 head -c 128 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C Apr 06 09:49:45 serial number at offset 0x10, manufacturer-specific serial number may also be at offset 0x50 Apr 06 10:00:23 many thanks in advance!!! Apr 06 11:01:12 Hey ! I have installed latest ti kernels on my BBB, and was trying to get PRU-framework (https://github.com/shubhi1407/PRU-framework) working on it .. And I noticed this pru_rporc.c (https://github.com/beagleboard/linux/blob/4.1/drivers/remoteproc/pru_rproc.c) .... and I am getting confused .. So how the 2 ie pru_rproc.c and pruss_remoteproc from RPU-framework different ? Apr 06 11:01:52 *PRU Apr 06 11:25:47 does someone know whether debootstrap 1.0.80 breaks https://github.com/beagleboard/image-builder as it wants to install 1.0.79 or is it just that nobody has tested the 1.0.80? Apr 06 12:40:51 arrrg ... i hate u "BUG: scheduling while atomic" Apr 06 12:52:19 Well, this is interesting, but somehow I broke some part of the kernel I think. Actually the output to lsmod is an empty list, though it was absolutely fine before the last reboot. Is there a way to fix it or I will have to reinstall linux onto it ? Apr 06 12:53:27 ZeekHuge: what did you do prior to this Apr 06 12:55:40 kremlin: I was trying to get pruss_remoteproc.ko working on it. I just modprob-ed it and it came out of lots of alert messages. Then It was being used by something ( the name of that something was not listed in lsmod ) so I rebooted it. and then this was the result. Apr 06 12:55:57 :) Apr 06 12:56:01 we are working on very similar things Apr 06 12:56:06 let me check my board real quick Apr 06 12:56:08 Cool ! Apr 06 12:56:15 Sure Apr 06 12:56:30 yes, i get a lot of output for `lsmod` Apr 06 12:56:53 yep .. thats the normal thing to have . Apr 06 12:56:58 however i am loading the PRU module just fine Apr 06 12:57:12 ahh .. PRU module ? Apr 06 12:57:20 pruss_remoteproc.ko ? Apr 06 12:57:20 after unloading the (hdmi i think) conflicting pinmux overlay Apr 06 12:57:53 I am running 4.1.18-ti-r55 kernel . Apr 06 12:58:15 oh no, i am loading something like prussdrv.ko Apr 06 12:58:23 not the remote processor one Apr 06 12:58:33 are you trying to do remote online debugging? via jtag or some other Apr 06 12:58:33 yeah .. that the uio based module for pruss Apr 06 12:58:56 No .. I just have an ethernet cable . Apr 06 12:59:04 ah Apr 06 12:59:20 strange that its doing that, then Apr 06 12:59:25 and persisting through boots Apr 06 12:59:39 do you get any weird text over the FTDI after uboot kicks off linux Apr 06 12:59:41 Inface it was through usb earlier but since the modules are not loading automatically, I had to connect it through ethernet Apr 06 13:00:14 isn't the USB just an ethernet-over-usb thing? Apr 06 13:01:12 Yes .. but I think the usb_gadget module enables BBB to do that .. and since the module isnt loading, It wont connect to the ethernet-over-usb. Apr 06 13:01:35 gotcha. but regular ethernet works Apr 06 13:01:53 this is super strange Apr 06 13:02:21 unless you want to poke around over the FTDI serial console i guess the fastest solution would be to reinstall Apr 06 13:02:31 are you using an SD card or the onboard NAND Apr 06 13:04:10 maybe usb_gadget is as loadable-module and ethernet one as the in-kernel module ? Apr 06 13:04:19 kremlin: onboard NAND Apr 06 13:04:37 oof Apr 06 13:04:56 if you'd like, i can give you a list of the modules i get with an unmodified kernel Apr 06 13:05:18 im not sure how linux does this but i'd bet there some boot or /etc/ file that lists kernel modules to attempt to load Apr 06 13:05:40 i mean if the ethernet is still working and you're logging in over ssh it can't be super screwed up Apr 06 13:06:57 kremlin: well .. lets try to fix it ? If you are not busy ? Apr 06 13:07:06 sure Apr 06 13:07:37 output ? ls -l /etc/modprobe.d/ Apr 06 13:08:39 maybe I have, unknowingly messed up with those files there? Apr 06 13:08:56 just a blacklist.conf file Apr 06 13:09:30 btwilink-blacklist.conf dkms.conf fbdev-blacklist.conf modesetting.conf Apr 06 13:09:31 ^^ mine Apr 06 13:09:46 Though i remember that they were already there . Apr 06 13:09:55 what your kernel version ? Apr 06 13:09:58 i only have fbdev Apr 06 13:10:10 Linux arm 4.1.17-ti-rt-r47 #1 SMP PREEMPT RT Thu Feb 11 20:54:17 UTC 2016 armv7l GNU/Linux Apr 06 13:10:23 btw, here's my lsmod output: http://kremlin.cc/buf.txt Apr 06 13:10:48 yours an 'rt' . Apr 06 13:11:02 realtime Apr 06 13:11:33 yeah but loading all the modules every time i login .. ahh .. thats exhaustive task. Apr 06 13:11:47 yep real-time. Apr 06 13:11:55 add it to the end of /etc/rc.conf.local Apr 06 13:12:03 err Apr 06 13:12:12 whichever the linux equivalent is for startup runtime procedures Apr 06 13:12:44 (im more used to bsd) Apr 06 13:13:19 ohk .. its /etc/rc.local Apr 06 13:13:42 it might be beneficial you have nothing auto-load Apr 06 13:13:57 since for me, the HDMI module that was loading took some pins i needed for PRU work Apr 06 13:14:02 and unloading it caused a panic Apr 06 13:14:20 why shouldnt I install new image to it ? Apr 06 13:14:37 U can edit the uEnv file to prevent HDMI from loading. Apr 06 13:16:32 you can if you want Apr 06 13:16:44 it just is annoying Apr 06 13:19:46 Yeah .. it is . Apr 06 13:22:25 kremlin: what the output of ls -l /lib/modules/$(uname -r)/kernel/drivers/remoteproc on your system ? Apr 06 13:22:40 are pruss.ko and pru_rproc.ko there ? Apr 06 13:24:44 ZeekHuge: http://kremlin.cc/buf.txt Apr 06 13:29:33 yp .. guessed so .. my version of kernel is missing pruss_remoteproc and have pruss.ko and pru_rproc.c there . Apr 06 13:30:13 aha Apr 06 13:30:17 pru_rproc.ko and pruss_remoteproc.ko have same description. Apr 06 13:30:30 same checksum? Apr 06 13:30:55 they have different source code. Apr 06 13:31:00 strange Apr 06 13:31:05 but the same descr? Apr 06 13:31:12 and seemingly same name Apr 06 13:41:59 yes .. so the checksums too differ a lot Apr 06 13:42:16 they should if the two differ by even a bit Apr 06 13:42:33 where are you getting these remoteproc modules? Apr 06 13:43:15 PRU-framwork ( https://github.com/shubhi1407/PRU-framework ) GSoC 15 project. Apr 06 13:43:20 clear Apr 06 13:43:25 ahh .. sorry .. Apr 06 13:43:48 hm Apr 06 13:44:54 Does anyone here find that when running Linux 4.4 on a bbb/bbw that when unplugging a wifi USB card that a memory leak occurs? Apr 06 13:46:19 * bradfa sees about 450 MB of ram get eaten by the kernel, but I can only make it happen on am335x, trying to reproduce on an x86 box does not show the same result, so I am suspecting that musb is at least partly to blame Apr 06 13:53:33 bradfa: the one i was using about a year ago would totally crash the OS on disconnect Apr 06 13:53:45 it wouldn't even power on unless it was connected at power-on Apr 06 13:53:59 but that is probable due to how much current it pulled Apr 06 13:57:34 kremlin: ah, ok, well not quite the same issue :) Apr 06 13:58:08 kremlin: my issue is with rtl8188eu, worked fine before, but on 4.4 has issues on disconnect. I need to do more digging as to why... Apr 06 13:59:08 bradfa: `uname -a` ? Apr 06 13:59:20 ZeekHuge: I ditched remote proc in favor of uio_pruss. It's vastly simpler. I know kremlin mainly said that, but I'm seconding it. (grin) Apr 06 13:59:27 kremlin: custom kernel, not bbb kernel :) Apr 06 13:59:40 ah, ok Apr 06 14:00:54 other usb devices, like a mouse or usb flash drive, do not have the issue, so there's some interaction going on, and it only happens if the card is configured, if I plug in and don't give it an IP address or bring it up, then I can unplug without issue, and if I first unload the r8188eu driver module then unplug also no issue (probably due to being deconfigured when unloading the module) :) Apr 06 14:01:16 Ragnorok: yeah its simpler. But I need to use remoteproc for my project. Apr 06 14:02:15 ZeekHuge: Sorry. My xp is it's tragically f'd for development. Would be it possible to use uio_pruss for dev and remoteproc to deploy? Apr 06 14:38:43 Beep beep (I'm a jeep ) Apr 06 16:32:07 Hello. I downloaded the latest debian image and write to a 4g SD card, booted on BBB, then modified the uEnv.txt on SD, power down BBB, then power up with the SD card. The user leds flashing in s,equence then after a while, all 4 blinking at the same time, not steady on or off Apr 06 16:32:29 does it mean it failed to write to the eMMC? Apr 06 16:33:52 that may depend on the image at hand Apr 06 16:33:58 some behaved differently Apr 06 16:39:18 Alec_, I had to use a flasher image Apr 06 16:39:26 even editing uEnv.txt didnt work for any image Apr 06 16:39:42 I had to download a specifically labelled flasher image to fet it to write the emmc Apr 06 16:43:38 hi there Apr 06 16:44:32 hi there channel Apr 06 16:45:48 can't change my keyboard to spanish .... :-( Apr 06 16:47:01 the keyboard is connected by bluetooth or wireless Apr 06 16:47:17 to the beaglebone black Apr 06 16:47:57 did my best install locales and all that Apr 06 16:48:28 change to es and can't get it Apr 06 16:49:07 did also loadkeys es and not success Apr 06 16:49:54 Hi crond, how do you use the flasher image? Apr 06 16:50:08 can anyone help me please Apr 06 16:50:27 Hi Dury Apr 06 16:51:18 wireless keyboard connected to BBB logitech K400 Apr 06 16:51:49 can't configured in spanish Apr 06 16:52:14 Alec_, how are you Apr 06 16:53:10 bad, not able to work it out Apr 06 16:53:23 running openbox desktop manager Apr 06 16:53:49 how did you alert me with a beep sound? Apr 06 16:54:49 Alec_, who..? me? Apr 06 16:55:40 yes, when you write to me, your name is red Apr 06 16:55:59 dury, does this work? Apr 06 16:57:04 Alec_, yours too mate.... it's like that Apr 06 16:57:38 crond, how do you get the flasher image? Apr 06 16:57:54 dury, get it. ty Apr 06 16:58:47 Alec_, no worries :-) Apr 06 16:59:17 tbr, are you there? Apr 06 17:00:14 Alec_: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-04-03 - flasher images are here Apr 06 17:01:15 thank you guys Apr 06 17:02:02 dury: man setxkbmap Apr 06 17:05:04 tbr, thank you i am going to try it now. Apr 06 17:08:52 tbr, I'm as a root in console and I did setxkbmap -config es nothing happened still can't get my keyboard layout Apr 06 17:09:18 dury: you need to do that as the user who is logged into the x-session Apr 06 17:10:00 gtg, bbl Apr 06 17:10:10 tbr, all right see what's happened Apr 06 18:41:21 Does beaglebone black support Gigabit ethernet? Apr 06 18:45:29 no Apr 06 19:19:11 Hi, I can't update the system image, and I have followed the instructions provided. The 4 LED's doesn't stay ON Apr 06 19:20:28 MCastany, I had to use a flasher image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-04-03 Apr 06 19:25:12 the led pattern depends on the version of the flasher image Apr 06 19:27:36 basically if the pattern changes after 5-15min, then the flasher is done Apr 06 22:00:30 Anyone here know about forcing hdmi resolutions on the Beagle? Apr 06 22:01:04 Having some difficulty with 1920x1080@24hz, even though it's mentioned as supported in the faq Apr 06 22:32:41 24hz?! sounds a bit low Apr 06 22:33:04 what video= line you got for your cmdline= ? Apr 06 23:48:52 Hello. After I installed the new released flasher 16-04-03, my computer lost the usb connection to it. Apr 06 23:50:18 I can hear the connected sound and I can see it is connected in the device manager. but I can not ssh or visit 192.168.7.2 Apr 06 23:50:36 Does anyone has any ideas? Apr 07 00:09:12 Alec__, what about 192.168.7.2:3000 Apr 07 00:27:50 Hello! Do you know a good pru using remoteproc_pruss? I used http://exploringbeaglebone.com/chapter13/ to learn how to use the PRU, but it uses uio_pruss that is only on bone kernels. I wanted to find a similar tutorial using remoteproc_pruss Apr 07 00:28:39 pedrohbtp_: ive only had trouble with remoteproc_pruss Apr 07 00:28:51 honestly the best solution ive found is the JTAG debugging through ccs Apr 07 00:28:56 if that is an option for you Apr 07 00:30:32 I saw the TI tutorial using CCS and JTAG. I didn't really try it because didn't think it was as friendly as the one I had for the uio_pruss, but I might try. Would you know a way of making uio_pruss on bone kernels? Apr 07 00:31:41 I mean uio_pruss working on TI kernels* Apr 07 00:46:53 pedrohbtp_: i wouldn't, sorry Apr 07 02:25:19 oh man Apr 07 02:25:41 so you know how register 30 on the PRU maps directly to outputs on the expansion header? Apr 07 02:25:48 i have everything set up properly for doing that Apr 07 02:26:07 when i set the bit in r30 i go from 0V on my meter to 0.36V Apr 07 02:34:47 aaaand nevermind. faulty meter Apr 07 02:39:08 lol. happens. **** ENDING LOGGING AT Thu Apr 07 02:59:58 2016