**** BEGIN LOGGING AT Tue Jan 03 03:00:01 2017 Jan 03 09:39:19 dear all, hope someone can give me some hints. I'm playing with the PRU and I have a weird issue, for some reason the pru-to-cpu interrupt sometimes is not send ... to workaround this I just need to build the app again comenting some lines run this new app Jan 03 09:39:45 and then the first app magically starts to work Jan 03 09:40:38 overflow? someone had a similar issue ? Jan 03 12:58:49 Anyone out there know about lightdm ? Jan 03 12:59:00 Im getting startup error **** BEGIN LOGGING AT Tue Jan 03 13:47:11 2017 Jan 03 14:06:44 eballetbo: uh Jan 03 14:09:48 zmatt: ah :) Jan 03 14:10:07 eballetbo: I assure you the hardware irq line doesn't know whether you recompiled your app ;-) Jan 03 14:11:33 though working with irqs does usually require a bit of care in doing things in the right order, although I think the uio_pruss driver already takes care of most of it... haven't really looked at it in much detail Jan 03 14:14:24 zmatt: hm, I'm not sure I understand what you would mean Jan 03 14:14:56 that's because what I said is really vague. what you asked however was even more vague, so it should cancel out nicely Jan 03 14:15:08 lol Jan 03 14:15:12 lol Jan 03 14:15:33 right, I did not explain really well Jan 03 14:26:10 I don't have much time to pay attention right now anyway :) but maybe someone does, or I might take a peek later Jan 03 14:26:51 I'm not really familiar with the two pru frameworks provided on the linux side anyhow, more with the hardware itself Jan 03 14:27:19 zmatt: thanks really appreciated Jan 03 14:27:31 The code is here: https://github.com/eballetbo/pdi-pruss Jan 03 14:28:59 Basically what does is; the PRU is polling a cpu-pru shared memory, the cpu writes a cmd to the shared memory and the pru handles it Jan 03 14:29:24 when finishes it sends and interrupt to the cpu saying that he has finished Jan 03 14:29:31 but this interrupt never happens Jan 03 14:30:25 curiously if I comment some parts of the code (e.g put a #if 0 block in some switch cases) the app starts to work Jan 03 14:30:41 and after this the original app continues working Jan 03 16:33:55 eballetbo: the way you're using the shared ram from the cortex-a8 is definitely not safe Jan 03 16:34:42 in pru.c at least Jan 03 16:34:49 zmatt, that sound a good reason why things doesn't work Jan 03 16:35:00 i'm newbie so probably i'm wrong Jan 03 16:36:06 it might be safe in pdi.c Jan 03 16:37:13 try changing the type of shared_ram to volatile unsigned int * Jan 03 16:38:30 sorry, pru.c isn't "from the cortex-a8" of course, the remark however is still true Jan 03 16:40:04 https://github.com/eballetbo/pdi-pruss/blob/master/pru.c#L59-L65 that comment and the test performed don't seem to agree with each other Jan 03 16:40:30 using shared ram for a8->pru signalling is fine, but then at least update the comment :) Jan 03 16:41:30 I would also be inclined to clear shared_ram[0] on the pru side immediately after you've noticed it is non-zero Jan 03 16:41:56 right, sorry this is because my first version wrote to shared ram and the the a8 signalled to pru, then I changed to poll directly shared_ram[0] Jan 03 16:42:19 yeah, either of those should work Jan 03 16:43:52 ah, but then on the cortex-a8 side you definitely need a volatile qualifier on shared_ram[] or a suitable barrier before writing shared_ram[0] Jan 03 16:44:10 right now the compiler is allowed to swap the write to shared_ram[0] and shared_ram[1] Jan 03 16:47:15 in general, when you're in the interrupt-ain't-happening state there are lots of things you can do to figure out what's going on, e.g. inspect shared_ram, check the pru core PC, or halt the core and dump its registers Jan 03 16:51:23 (in case it's useful, here's my own header for the pru core/debug registers, which has some details not in the TRM -> https://hastebin.com/lidixibumo.cpp ) Jan 03 16:59:20 let me try Jan 03 17:07:58 Hi, I have a new BBB and have some trouble mounting a sd card as extra storage. Jan 03 17:08:12 I guess this is outdated: http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage Jan 03 17:08:26 I'm using the current debian image Jan 03 17:10:19 If i manually mount the sd card with: Jan 03 17:10:56 sudo mount /dev/mmcblk0p1 /mnt/sdcard/ Jan 03 17:11:13 the folder sdcard is owned by root Jan 03 17:11:19 zmatt: no luck, I added the volatile qualifier in pdi.c and init shared_ram[0] to 0 on startup on both sides but still is blocked waiting for the interrupt from PRU Jan 03 17:11:36 But I would use it as the default user 'debian' Jan 03 17:16:43 newtobeagle: you can configure an entry in fstab Jan 03 17:18:39 newtobeagle: https://hastebin.com/raw/deporopomu Jan 03 17:20:36 "users" should probably be changed to "user" actually Jan 03 17:20:40 well, to taste, I guess Jan 03 17:21:00 (same with the permission masks) Jan 03 17:25:52 gonna try, thx Jan 03 20:48:23 I settled on 1280x720 resolution because I guess that's my monitor's actual resolution Jan 03 21:01:14 I forgot what the "e" at the end means. "(e)xplodes if you don't set it right"? Jan 03 21:33:05 hi all Jan 03 21:33:34 how can i go about purchasing the SandCloud BeagleBone Enhanced? Jan 03 21:33:57 it seems the indiegogo campaign has ended and i cant see any obvious leads to how to buy one Jan 03 21:42:00 you can try e-mailing marc at SanCloud. Jan 03 21:48:38 i shall do that, thank you Jan 03 22:55:23 Has anyone used pcie on the x15? Jan 03 23:45:35 Chris__: I don't think the probability is very high, given that afaik there aren't that many x15 boards out there yet and pcie is a rather advanced topic Jan 03 23:46:23 I've looked a bit at the subsystem on a previous SoC, but mostly just out of curiosity Jan 04 01:49:38 Hello everyone Jan 04 02:04:44 hmz, weird I can't get my bbe to associate with my home wlan, even though it worked earlier on a different wlan **** ENDING LOGGING AT Wed Jan 04 03:00:01 2017