**** BEGIN LOGGING AT Fri Jul 24 02:59:59 2015 Jul 24 06:56:06 mornin' Jul 24 14:40:52 jkridner: could you beaglbone img in that ,, https://cloud.githubusercontent.com/assets/4296272/8876857/9346253e-3222-11e5-8712-79d33fbfff4c.jpg Jul 24 14:42:06 jkridner: I'll work on the buttons and other layers, but for the beaglebone to save its ratio it should appear like that, is it ok? Jul 24 14:45:19 ebadawy: is this the same size of the other cards? https://cloud.githubusercontent.com/assets/4296272/8876857/9346253e-3222-11e5-8712-79d33fbfff4c.jpg Jul 24 14:45:40 yes, it is. Jul 24 14:46:28 could it be possible to do it some pixels bigger? or it's to complicated Jul 24 14:47:04 yeah sure, but for the beaglebone img it shouldn't be the case Jul 24 14:47:21 yes, talking about the left size Jul 24 14:47:30 the analog, digital Jul 24 14:47:33 panel Jul 24 14:48:16 yeah, this one is not the final work for sure Jul 24 14:48:35 the buttons and btn panal will be resized Jul 24 14:48:40 but you're doing great! Jul 24 14:48:50 moto-timo: are you coming to Honduras? Jul 24 14:49:12 what about beaglebone img? Jul 24 14:49:39 is it ok to appear small like that? Jul 24 15:04:36 ebadawy: I see it fine for me Jul 24 15:09:10 DiegoTc: ok. Jul 24 16:08:17 DiegoTc: sadly, no. My current project got extended and I cannot get away. Jul 24 16:14:16 moto-timo: to bad, but take in consideration Honduras if you come to vacations to Costa Rica, just send me an email and I can go pick up you on the airport or give you a phone number of a cheap and good taxi Jul 24 16:14:28 you have a friend here Jul 24 16:27:24 DiegoTc: gracias, si los dios quieren :) Jul 24 16:58:45 ds2 alexanderhiam :ping Jul 24 17:44:22 yes? Jul 24 17:44:56 cheap taxi? is that a recipe for getting kidnapped? Jul 24 17:45:11 apaar: pong Jul 24 17:47:12 ds2 :facing a issue looks like after i exceed ~4000 bytes the buffer seems to be corrupting on the driver side.Could it be related to ioremap not being able to allocate more than page size(4096) ?? Jul 24 17:47:46 apaar: sounds like it. this is a PRU - ARM buffer right? Jul 24 17:49:06 yes ,will splitting the buffer in 3 and doing multiple ioremaps help?? Jul 24 17:49:31 yes Jul 24 17:49:40 probally the pages weren't continous Jul 24 17:50:02 so the address the PRU was writing to was to the wrong physical page after byte 4096 Jul 24 17:50:33 ds2 :this seems to be only on the driver side for now :P Jul 24 17:51:21 same thing applies Jul 24 17:51:33 if the 2nd page is not continous, the PRU would read garbage Jul 24 17:51:42 again after byte 4096 Jul 24 17:51:57 i was assuming it was more to do with the kernel virtual memories .ah ok got it Jul 24 17:52:15 this is virtual memory Jul 24 17:52:29 i have coded a 3 buffer implementation and testing now :) Jul 24 17:52:37 addresses allocated in the kernel are virtual addresses. ioremap gets you the beginning address of the first page Jul 24 17:52:55 beginning physical address Jul 24 17:54:31 ds2 say i ioremap the control channel(100 odd bytes) and then i try to map a 4096 byte buffer. the kernel will allocate seperate pages for them right?? Jul 24 18:20:34 apaar:sort of Jul 24 18:20:44 ds2 :i split it into 3 buffers still exactly when i exceed 4096 bytes in the first two ioremap's the data starts corrupting(ie even if i write to that location from the driver and print contents of the location i get junk) :() Jul 24 18:20:52 apaar: Jul 24 18:21:38 those would be page table entries since ioremap assumes you have some kind of physical addresses underneath Jul 24 18:21:52 hmm? Jul 24 18:22:18 are you using PRU DRAM/SRAM? or you using DDR mem for the buffers? Jul 24 18:22:35 PRU shared memory 12KB Jul 24 18:24:31 hmmm with that, it shouldn't matter. thought you were on DDR Jul 24 18:24:35 hmmm Jul 24 18:24:39 is the length correct? Jul 24 18:24:56 i have accessed the full 12K before Jul 24 18:25:36 i think so...maybe it is some other issue Jul 24 18:25:57 since when i write to the location and immediatly printk i get junk Jul 24 18:26:05 write from ARM? Jul 24 18:26:10 yes Jul 24 18:26:19 is the PRU trashing it? Jul 24 18:26:36 and you made sure it was mapped with no writeback, no cache? Jul 24 18:26:45 i dont think so i am not loading any firmware Jul 24 18:27:36 i did try ioremap_nocache that did not seem to help but let me recheck how do i disable writeback? Jul 24 18:27:37 try loading a firmware that does while(1); Jul 24 18:27:54 donno the wb stuff off the top of my head for the later kernels. Jul 24 18:28:09 ok cool i will have a look thanks :) Jul 24 18:28:09 make sure it isn't the memory acting wierd cuz the PM stuff had the PRUSS disabled. Jul 24 18:28:50 how do i check the memory? Jul 24 18:29:20 or a firmware that does something like memset(SRAM, 0xdeadbeef, sizeof(SRAM)); while(1); let it run for a while then read the SRAM with a for(); printk loop Jul 24 18:29:31 you indirectly check it Jul 24 18:29:41 hence you run the firmware to force things to enable the PRUSS Jul 24 18:30:07 ok let me try that Jul 24 18:34:57 bbiab - lunch Jul 24 20:56:10 neemo: got anything new to look at? **** ENDING LOGGING AT Sat Jul 25 02:59:58 2015