**** BEGIN LOGGING AT Wed Jul 26 03:00:03 2017 Jul 26 10:40:32 Hi, I am not getting desktop UI after flashing BBB Jul 26 10:40:59 I followed the steps give in beaglebone.org Jul 26 10:56:47 which image did you flash? Jul 26 11:43:25 Hi all. Question. I have some beaglebones with 3G modem, no Ethernet. After registering to the provider, actual time will be read from a provider-request. After this, I put those in a tm struct. Then I use timeval and settimeofday to update bb;s time. It then shows the correct time. But systemtime still is the default startuptime updated with the runtime Jul 26 11:43:38 Anyone knows how to update systemtime via c++? Jul 26 11:46:39 JohnPia: system("hwclock -w"); :-) Jul 26 11:48:28 Thanks. Manually I use hwclock --systohc and hwclock --hctosys; But this will be enough? Jul 26 11:49:33 i think so (TM) Jul 26 11:52:18 or use timedatectl Jul 26 11:52:58 (or a dbus call to org.freedesktop.timedate1 ) Jul 26 13:57:39 Hi, how do I become a distributer? Jul 26 13:59:49 by distributing somethig ? Jul 26 15:37:09 Hi Jul 26 15:37:52 There is somebody? Jul 26 15:39:32 no. there is nobody. Jul 26 15:39:40 (also, see /topic :-) ) Jul 26 18:13:59 Hello all, I'm trying to get a basic PRU assembly program that toggles pins. I'm working on BeagleBone Greens. My /ID.txt says "BeagleBoard.org Debian Image 2017-03-19", uname -a says Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l GNU/Linux Jul 26 18:14:17 There are tons of examples out there, and none of them seem to work Jul 26 18:15:04 I'm happy to share what I've tried, but don't want to dump a bunch of random information Jul 26 18:16:54 I will offer up this: I've gone through Molloy's book. I read (but did not try) his final chapter on PRU stuff Jul 26 18:17:27 I tried creating DTOs following this guide: https://credentiality2.blogspot.com/2015/09/beaglebone-pru-gpio-example.html Jul 26 18:21:07 I modified it to use different pins, but when I tried to load the assembly, I got "prussdrv_open() failed" Jul 26 18:29:52 dcmertens: can you pastebin your /boot/uEnv.txt ? Jul 26 18:30:12 you don't actually need to make a dtbo anymore nowadays Jul 26 18:30:17 for pru Jul 26 18:30:48 zmatt, I'd gathered that I could just use config-pins Jul 26 18:31:00 in the latest images you can enable one of the two pru drivers (uio-pruss and remoteproc-pru) in /boot/uEnv.txt and indeed setup pinmux using config-pin Jul 26 18:31:19 * dcmertens checks uEnv.txt Jul 26 18:32:00 any pointers on what to add where? Is it an entry in cape_enable? Jul 26 18:32:46 that's why I asked if you could pastebin it... I don't know the names of the options exactly, and /boot/uEnv.txt has also changed quite a few times over time Jul 26 18:32:47 I see /lib/firmware/uio_pruss_enable-00A0.dtbo Jul 26 18:32:49 :) Jul 26 18:33:12 Sorry, I didn't see the request for the pastebin Jul 26 18:33:21 * dcmertens digs up file Jul 26 18:33:40 I also don't know 100% sure if 2017-03-19 is recent enough to have the easy options for enabling pruss Jul 26 18:35:15 Here ya go: https://gist.github.com/anonymous/495060734ec3060d65f78a78a49e0383 Jul 26 18:35:53 All minimum versions I have seen posted have referred to linux kernels that are older than mine Jul 26 18:36:14 there is a *lot* of obsolete info out there unfortunately Jul 26 18:36:37 ok, and this image doesn't yet have the easy switches for enabling pruss Jul 26 18:37:19 Hold on, let's see what happens when I load the uio_pruss_enable... Jul 26 18:37:25 * dcmertens reboots bb Jul 26 18:37:59 it might work if you install a -bone kernel instead of a -ti kernel Jul 26 18:39:01 but if it's not too much fuss you might want to consider reflashing to a 2017-07-01 image Jul 26 18:39:33 I might do that... but at the moment I have some hope this'll fix it... Jul 26 18:40:22 it should be possible yes Jul 26 18:40:56 iirc the right overlay had a different name though, maybe check ls /lib/firmware | grep -i pru Jul 26 18:41:26 oh, I see Jul 26 18:41:45 we have am335x-pru0-fw, am335x-pru1-fw, and uio_pruss_enable Jul 26 18:41:56 the first two sound remoteproc-related Jul 26 18:42:05 ok, maybe it is the right one then Jul 26 18:42:40 if it doesn't work with the -ti kernel, try a -bone kernel Jul 26 18:43:01 since iirc the -ti kernels came with DT preconfigured in a way that only supported remoteproc-pru Jul 26 18:43:51 oh. *sigh* Jul 26 18:43:56 also, I strongly suggest updating the kernel to the latest 4.4- or 4.9-bone/ti to catch recent bugfixes Jul 26 18:44:00 well, I'm not opposed to using remoteproc-pru Jul 26 18:44:36 zmatt: I'm just using whatever Debian distributes. I try to keep things fairly up-to-date Jul 26 18:45:09 remoteproc-pru and uio-pruss are very different Jul 26 18:45:35 I don't really "get" remoteproc-pru... my superficial impression is that it's a more complicated way to accomplish more limited functionality Jul 26 18:45:57 unless you want to make a kernel driver that cooperates with firmware on the pru cores, then it might make sense Jul 26 18:46:27 hmm, I feel like those are exactly the discussions I've read about where people praise it Jul 26 18:46:45 Every time people start talking about PRU, my mind first goes to wondering if the Prussian Empire is making a comeback Jul 26 18:46:50 I don't much care, I am at step 1 out of 100 on my way to writing some nontrivial PRU code Jul 26 18:47:39 the first thing that I get to work will probably be the one that I use Jul 26 18:47:39 dcmertens: well, both ways are supported, and in the latest images you can trivially switch between the two Jul 26 18:48:51 Ah, so I wasn't crazy. I *am* using the latest Debian Jessie image found here: https://beagleboard.org/latest-images Jul 26 18:49:00 dcmertens: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28iot.29_.28All_BeagleBone_Variants.29 Jul 26 18:49:05 :) Jul 26 18:49:18 there's always "latest" vs latest Jul 26 18:50:09 ... ah right Jul 26 18:52:07 so, with uio-pruss you can simply mmap() the whole pru subsystem's address space into a linux process (similar to /dev/mem), and you can receive irqs from pruss, so that gives a lot of freedom Jul 26 18:52:53 remoteproc-pru seems much more rigid and tries to keep pruss out of userspace's hands Jul 26 18:53:59 and apparently expects you to use some overcomplicated message-passing protocol to interact with code running in pruss Jul 26 18:54:42 Oh, hmm. That' the first time I've heard about the actual communication between the two in remoteproc Jul 26 18:55:37 If uio-pruss is going to continue to be supported, then I'll go with that Jul 26 18:55:53 it seems cleaner for my purposes. Jul 26 18:58:21 you can just block reading on class/uio until receiving an irq? Jul 26 18:58:34 cuba__: the fd becomes readable on irq Jul 26 18:58:46 so you can include it in any style of event loop Jul 26 18:58:56 so even epoll2() Jul 26 18:59:01 ? Jul 26 18:59:19 blocking read, select, poll, epoll, whatever Jul 26 18:59:50 is TI still working on it? Jul 26 19:00:11 no idea, probably not, but the UIO framework is mainline linux Jul 26 19:01:00 ah sweet wasnt aware of that Jul 26 19:01:02 in fact you could also just use the generic uio driver (uio_pdrv_genirq) instead of uio_pruss with minor modifications to userspace code Jul 26 19:01:23 the only limitation is that it doesn't have any way to allocate a chunk of DDR3 memory for pru use Jul 26 19:01:44 for shm? Jul 26 19:02:08 for when you need more than the local SRAM and don't care about the penalty to performance and determinism Jul 26 19:03:37 LOL... I just checked the simplest example for using that remoteproc message-passing crap, a tiny pru program that just echoes back the messages it receives Jul 26 19:04:19 compiled with optimization, 1232 bytes of code... out of the 8KB that a pru core has Jul 26 19:04:33 or wait, is it 8 Kwords? I always forget Jul 26 19:04:47 lxr.linux.no is down :( Jul 26 19:05:08 no it was indeed 8 KB Jul 26 19:05:23 zmatt: do you know anything about the Debian packages hosted by rcn? Jul 26 19:05:41 dcmertens: uh, vague question? Jul 26 19:05:54 I just looked at my apt sources list and see it is pulling down packages from http://repos.rcn-ee.com/debian/ Jul 26 19:05:55 it's where the kernel you're running comes from, for one Jul 26 19:06:19 and other beagleboard/beaglebone-specific stuff Jul 26 19:06:21 so if I've apt-get update/upgraded recently, I should be at the latest debian packages hosted there Jul 26 19:06:32 kernel won't auto-upgrade Jul 26 19:06:37 what? Jul 26 19:06:46 oh, I'm used to Ubuntu Jul 26 19:06:50 there's no versioned metapackage for the kernel Jul 26 19:07:01 so I have to manually select the (new) kernel version, then? Jul 26 19:07:21 * dcmertens checks debian docs Jul 26 19:07:21 yeah, or there's a script I think Jul 26 19:08:02 not sure why rcn doesn't also make a metapackage per kernel series Jul 26 19:08:20 then again, kernel upgrades are something you probably want to do consciously Jul 26 19:09:03 heck the image at elinux is 4.4.68, I can get 4.4.75! Jul 26 19:09:31 I'd suggest 4.9.x actually Jul 26 19:09:50 ( 4.9.39-ti-r50 or 4.9.39-bone6 ) Jul 26 19:10:17 what are the key differences? Jul 26 19:10:59 Here we go, instructions for kernel upgrade: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Upgrade Jul 26 19:11:06 do youve code online that uses the mmap/uio irq handling zmatt? Jul 26 19:11:35 * dcmertens would also like to see such code Jul 26 19:11:37 or know of any projekct that applies it for real time stuff? Jul 26 19:12:01 dcmertens: I don't remember off the top of my head, but I do know that there's just one obscure thing that didn't work on 4.9 yet hence they're still stuck on 4.4, otherwise 4.9 would have been the default already Jul 26 19:12:20 cuba__: uhh, grab any random uio-pruss example? Jul 26 19:13:18 I also made some pru-unrelated uio examples in python a while ago... https://github.com/mvduin/py-uio Jul 26 19:15:13 https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_memAccessPRUDataRam/PRU_memAccessPRUDataRam.c this uses both mmap and irq Jul 26 19:18:46 thanks so much Jul 26 19:20:24 ditto the above, zmatt++ Jul 26 19:20:24 beware that example code isn't necessarily set a *good* example... using shared memory correctly is non-trivial Jul 26 19:20:35 true Jul 26 19:20:42 I was just looking at the wrong code before Jul 26 19:21:21 https://github.com/izaakschroeder/uio_pruss/blob/master/uio_pruss.c Jul 26 19:21:31 not much of an interface for userland here Jul 26 19:21:53 most of that code is actually superfluous Jul 26 19:22:25 yes Jul 26 19:22:32 I was just sitting on my brain really Jul 26 19:22:35 sorry for all the noise Jul 26 19:22:44 here's the version in the latest 4.9-bone kernel btw -> https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.39-bone6/drivers/uio/uio_pruss.c Jul 26 19:22:45 :) Jul 26 19:22:57 including some remarks by me in comments XD Jul 26 19:23:06 (search for "complete garbage") Jul 26 19:23:47 lol Jul 26 19:26:11 as for "wrong code" ... I still can't help but remember the idiotic code I've seen in TI's "Starterware" sdk for baremetal dev, which included an uart echo example that compiled to a deadloop if optimization was enabled, and after fixing that bug still tended to cause random data corruption Jul 26 19:26:16 :) Jul 26 19:27:11 you should read telco drivers from china, world r/w devices Jul 26 19:27:23 with arbitrary 8byte read/write via ioctl Jul 26 19:27:29 can be much worse :) Jul 26 19:28:57 not quite the same as *example* code that, when it works at all, does so only by accident Jul 26 19:29:24 what you're describing just sounds like a lazy solution to Get Stuff Working™ Jul 26 19:29:59 I think quite a lot of bbb users do basically everything as root, so *shrug* Jul 26 19:31:28 oh on that topic, if you do care about system security, do be mindful that the ability to run code in pruss is more than sufficient to own the whole system Jul 26 19:48:57 zmatt: on recent builds, you have to be root to run pruss Jul 26 19:49:02 afaict Jul 26 19:52:53 unrelated question: does the BB have an "elevated heart rate" during the boot process? Jul 26 19:53:16 I notice that my BB's hr light beats much faster than others right after I reset it Jul 26 20:13:03 zmatt: I found the problem with the firmware file, it's AM335X-PRU-UIO-00A0.dtbo Jul 26 20:13:06 not lower-cased Jul 26 20:13:52 or, at least, there is such a named file, which I had missed before Jul 26 20:14:07 (still failing at prussdrv_open, thought) Jul 26 20:25:19 zmatt: hi Jul 26 20:34:52 dcmertens: that does sound more familiar. can you pastebin kernel log? Jul 26 20:37:22 zmatt: Remember my bus errors? It seems I get bus errors when I write to stdout or to a network socket. Sometimes it runs for 20 seconds, sometimes just for 1 second. Jul 26 20:37:55 that sounds very implausible Jul 26 20:37:59 When I write the data I receive from my FPGA over the PRU directly to a file there is no bus error. Jul 26 20:38:40 gotta run, hopefully I'll pick this back up tomorrow Jul 26 20:38:40 o/ Jul 26 20:41:03 zmatt: Why sounds this plausible? Or were you talking to dcmertens? Jul 26 20:42:06 bus errors will almost certainly be caused by (attempted) accesses to pruss, not any code related to stdout or network Jul 26 20:42:36 but it should be easy enough to see where it's going wrong using gdb Jul 26 20:43:14 (fortunately the cortex-a8 has precise bus errors in nearly all cases) Jul 26 20:44:54 of course if you're printing stuff to stdout in your program then whether output is redirected to file or network will impact the timing of your code, which might perhaps be relevant somehow Jul 26 20:45:28 but it's silly to speculate when you can just see where the program crashes exactly Jul 26 20:45:59 oh no. I get a dpkg error while installing gdb... Jul 26 20:46:08 o.O Jul 26 20:46:13 log? Jul 26 20:46:29 okay, works now. I don't know wthat the problem was Jul 26 20:46:48 ... ookay Jul 26 20:47:31 https://hastebin.com/odekecacex.txt Jul 26 20:47:37 That's the error of gdb Jul 26 20:48:04 I have to make a restart and then I can try it again until the bus error happens for the first time. Jul 26 20:48:33 and kernel log, since it got a bus error while trying to open the device Jul 26 20:48:42 or rather, on the first access after opening it Jul 26 20:52:02 zmatt: https://hastebin.com/doxaceniba.txt Jul 26 20:52:14 This was after a fresh restart of the beaglebone Jul 26 20:56:00 that looks pretty fucked up Jul 26 20:56:48 also, when I ask kernel log I meant whole kernel log... although it may not be as relevant since this shows something completely different from the previous paste Jul 26 20:57:23 This is all from dmesg: http://paste.debian.net/978336/ Jul 26 20:58:03 ok, pretty uneventful Jul 26 20:58:21 ;-) Jul 26 20:58:47 that looks like maybe some massive corruption went on in your program Jul 26 20:59:16 hm Jul 26 20:59:30 or Jul 26 20:59:48 hmm, it would definitely be useful to know where in libc it's crashing... Jul 26 21:00:19 but then I need libc with debug symbols enabled, right? Jul 26 21:00:39 you can try installing libc6-dbg yeah, but iirc it's pretty big so keep an eye out for that Jul 26 21:01:44 Also I was irritated about the internal problem GDB has detected Jul 26 21:02:05 yes there's something really fucked Jul 26 21:02:15 And in the stack trace there is stack number -1? Jul 26 21:03:43 I also wonder what exactly it tried to access Jul 26 21:05:38 zmatt: This is my C code: https://hastebin.com/iqoguqaliw.c But I understand that you don't have so much time to read and understand the whole code. Jul 26 21:06:43 I copied it from a project on github and modified it. This is the original code: https://github.com/google/prudaq/blob/master/src/prudaq_capture.c Jul 26 21:09:54 it would be useful to add this: https://hastebin.com/kebuwemefa.c Jul 26 21:10:37 just to check if the access that got a bus error was to pruss Jul 26 21:12:34 it can't have been to the shared ddr3 ram, since the bus error was at (virtual address) 0xb6e7c000 while your program mentions the ddr3 buffer was mapped at 0xb6e14000, and 0xb6e7c000-0xb6e14000 = 0x68000 which is considerably bigger than the size of the buffer reported (262144 = 0x40000) Jul 26 21:18:46 I'd strongly suggest adding a check that write_index is valid, to catch the possibility that pru writes a bogus value to "shared_ptr" Jul 26 21:19:05 e.g. https://hastebin.com/ohifibitid.c Jul 26 21:19:29 That was also my idea. Jul 26 21:21:01 the bus error is still a strange thing to get though Jul 26 21:23:57 uh, yes Jul 26 21:24:08 you're right: write index (306688000/65536) out of bounds! Jul 26 21:24:28 I guess it has something to do with race conditions Jul 26 21:24:49 uh, no Jul 26 21:25:14 the PRU writes the write index but the host code reads the variable before it has written it completely or something like this Jul 26 21:25:26 aligned 32-bit writes are atomic Jul 26 21:25:30 hm Jul 26 21:25:47 besides, even a non-atomic update to the write pointer would not be able to produce that value Jul 26 21:25:57 right Jul 26 21:26:41 strange Jul 26 21:27:50 actually, that's not true, a non-atomic write could result in a really bogus address Jul 26 21:28:03 but aligned 32-bit writes are still atomic Jul 26 21:28:25 Makes sense. So I should try to align the memory Jul 26 21:28:45 struct fields are aligned by default Jul 26 21:29:38 just curious... I don't see anything here informing the pru cores what the size of the buffer is... Jul 26 21:30:39 never mind Jul 26 21:30:42 I was looking with my nose Jul 26 21:31:25 ^^ Jul 26 21:31:49 the structure only contains uint32_t fields Jul 26 21:32:07 yeah like I said, those will definitely be aligned Jul 26 21:33:04 yes. And the memory begins definitely at a 4 byte border (or what you are calling it in english) Jul 26 21:33:32 Do you also want to see the PRU code? Jul 26 21:33:34 and actually the buffer itself is aligned to its size (0x9e940000 is a multiple of 262144), which means even if updates to the write-pointer were non-atomic then you still wouldn't be able to get an out-of-bounds pointer Jul 26 21:33:49 yes Jul 26 21:34:00 well I suggest you first try debugging this yourself... Jul 26 21:34:15 you now know pru is writing a bogus pointer shared_ptr Jul 26 21:34:41 which might also mean it has been writing to random ddr3 memory that belongs to the kernel or other processes Jul 26 21:39:53 debugging the PRU code will be interesting... Jul 26 21:41:39 lemme see if I can quickly look up how to at least configure the EMIF firewall to prevent pruss from writing to ddr3 ram other than the shared buffer Jul 26 21:41:54 that should at least help with system stability while debugging this :) Jul 26 21:44:55 At least I get no bus error anymore since I check for a invalid write_index Jul 26 21:45:16 On the second run I get the same wrong index: 306688000 Jul 26 21:45:28 seems to be deterministic Jul 26 21:48:28 I can read up to 1834976 bytes until the error happens. Jul 26 21:49:14 So it loops nearly 28 times through the whole buffer Jul 26 21:51:31 that's so weird Jul 26 21:51:38 you're using their pru code without modification? Jul 26 21:52:43 I also modificated it to match my hardware Jul 26 21:52:56 can I see the code? Jul 26 21:52:58 But its commented in german Jul 26 21:53:10 I mean, the original code is really tiny Jul 26 21:53:50 zmatt: https://hastebin.com/ecifudebar.p Jul 26 21:54:14 I don't understand why they put the physical address in shared_ptr though Jul 26 21:54:34 using a byte-offset would be safer, faster, and more convenient Jul 26 21:55:24 using the clr instruction on r31 has no effect Jul 26 21:55:33 I am not sure. I did not understand the C code completely with that whole virtual and physical address mappings. Jul 26 21:55:58 you're right ;-) Jul 26 21:56:07 copy paste error ;-) Jul 26 21:57:52 same error as before on index 306688000 Jul 26 21:58:22 also, you store WRITE_POINTER to Params.shared_ptr after incrementing it but before wrapping it, so that already allows it to become out of bounds... but only by 1, not by a huge amount Jul 26 21:59:37 try dumping pparams->ddr_len after you catch the index error, just to verify it hasn't been clobbered somehow Jul 26 21:59:50 and pparams->physical_addr Jul 26 22:01:12 there really doesn't seem to be any plausible way for pru to mess this up though Jul 26 22:04:31 I moved storing the WRITE_POINTER below DIDNT_WRAP: Jul 26 22:04:44 ah I was actually probably wrong about that Jul 26 22:05:03 depends a bit on the arm-side C code actually, lemme see Jul 26 22:05:45 actually it should make no difference I guess Jul 26 22:05:48 yeah, doesn't matter Jul 26 22:06:16 strange. At the moment the program runs without problems... Jul 26 22:06:48 I already read more that 16777216 bytes Jul 26 22:07:59 nice, but I don't know why Jul 26 22:08:25 unfortunaly I also have to leave now because I have to get my train Jul 26 22:08:28 that's never fun, since then the bug will probably return to bite you at some particularly inconvenient time Jul 26 22:08:42 ok Jul 26 22:10:21 Thank you! Jul 26 22:10:27 good night Jul 26 22:10:32 good night! Jul 26 22:45:20 So, my custom board will play nice and recognize my SDCard right off the bat, right zmatt? Jul 26 22:45:27 Don't crush my dreams here. Jul 26 22:46:01 Us lowly iMx people need all the reassurance we can get. **** ENDING LOGGING AT Thu Jul 27 03:00:01 2017