**** BEGIN LOGGING AT Fri Jun 26 02:59:58 2015 Jun 26 14:40:55 av500: vvu: praveendath92: please take a look if you have time. https://gist.github.com/azizulhakim/e2e143b2bbbb91771553 Jun 26 14:43:48 azizulhakim: check which machanism of handling pages is on the BBB and on ur vm Jun 26 14:43:56 mechanism Jun 26 14:47:28 maybe that is different Jun 26 14:51:47 azizulhakim: are you sure you ran the test right ? why are the # of pages the same for ubuntu and arch..weren't ur system doing anything else at the moment ? Jun 26 14:53:41 vvu: thats surprised me also, but I'm sure the test was right. and the VM was not doing anything else at that time. Jun 26 14:54:21 how were you checking for page faults ? kept a counter in the video driver ? Jun 26 14:55:07 yes, the counter is incremented each time you try to read a page from LRU list in deferred_io function Jun 26 14:56:17 i will think today about this...if my bags arrive from amsterdam in time i will give it a try on the beagle Jun 26 14:56:33 delta forgot my bags in ams...lucky me Jun 26 14:57:45 that's too bad. anyway let me know if you face any trouble running in beagle Jun 26 15:00:59 azizulhakim: check the page replacement strategy...that should make a lot of difference Jun 26 15:01:05 that would be my 1st guess Jun 26 15:01:45 but your playtime is longer on the bone Jun 26 15:01:51 you were looping the video Jun 26 15:01:57 do you think they might use something else other than LRU? Jun 26 15:02:11 have no clue...depends on the kernel Jun 26 15:02:36 grab rcn s sources and compile it yourself...i think you can change that Jun 26 15:03:11 or better just compare .config from the kernel to see which options were enabled or not...i think it is stored there the page replacement strategy Jun 26 15:03:29 at this point we have audio and input working with no issue, right ? Jun 26 15:05:05 right Jun 26 15:05:19 we are on track if so Jun 26 17:20:13 av500: Did you have a look at the new F7 Discovery board? Looks really cool Jun 26 17:20:30 (STM32F7 - cortex M7) Jun 26 17:28:40 Abhishek_: you tried the overlay Jun 26 17:28:57 hope the presentation went well Jun 26 17:29:09 ^^ *? Jun 26 17:54:17 ebadawy: got time to try a few things today? Jun 26 18:27:37 shubhangi: I'd probably only be able to try it next week, carry on with your work and make sure to fill up your student evaluation when it opens. Jun 26 18:46:56 scared-y cat... Jun 26 19:44:08 rcn-ee: ping Jun 26 19:44:26 vvu, pong Jun 26 19:44:35 so what did you do with bbblfs ? Jun 26 19:44:59 those days i was on the road and did not really follow the logs Jun 26 19:45:17 current hacks here: https://github.com/RobertCNelson/BBBlfs/blob/bbb-flasher/bin/bbb_flash_script.sh Jun 26 19:45:50 2 things... control of the bbb's usb host and support for: http://builds.beagleboard.org/builders/build-image Jun 26 19:46:28 the usbhost control isn't 100% yet, you can reset a downstream bbb twice, before the usb1 goes nuts, but the builds *.img support is ready.. Jun 26 19:46:31 ah ok Jun 26 19:46:35 so no code modifications Jun 26 19:46:37 to what happens Jun 26 19:47:22 then jkrinder and i where trying to see if we could force usb boot without holding down the sd pin.. Jun 26 19:47:44 that is the issue everybody is asking Jun 26 19:48:12 i think we are just going to make a shim cape and run reset/sd/gnd out to a header we can controll.. :(" Jun 26 19:49:29 i should spend some time to make like a debug interface to the client beagle... Jun 26 19:49:37 maybe this will enable some nice testing ideas Jun 26 19:50:26 the x15 has the same style of usb boot ? Jun 26 19:50:31 or it changed again ? Jun 26 19:50:42 jason wants to string a whole bunch of bbb's in a master -> slave -> next slave -> etc... where we flash each bbb and test a cape down the line.. Jun 26 19:51:12 sadily the x15 has a jumper for either microSD or serial... it's bootloader is dumb, one and done style.. Jun 26 19:51:30 yes, he told me about this idea a while ago Jun 26 19:51:37 that is why i was thinking about a debug interface Jun 26 19:51:46 to control each beagle from it's host Jun 26 19:52:35 the big problem is the boot pin Jun 26 19:52:42 last week, we had everything working thru one usb cable, just no sd control... Jun 26 19:52:45 av500 : For PRU bridge, I don't fill the mentor form, right ? only ds2 , or all mentors related to the project? [Asking cause the mentor form popped up in my melange page] Jun 26 19:53:40 the master->slave->etc thingie ? Jun 26 19:54:29 vvu, yeap.. bbb-master reset bbb-slave, flashed it, then reboot it.... Jun 26 19:54:53 but still stuck on microSD boot, and the usb-host would crash on the next "unbind/reset".. ;) Jun 26 19:55:10 reset as in remove usb power ? Jun 26 19:55:18 yeap.. Jun 26 19:55:25 yep...this is what i'm talking Jun 26 19:55:42 make that into a software thing...not raw on/off :) Jun 26 19:55:47 usb-hub reset: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/dev-USB-PWR-CTL-00A1.dts Jun 26 19:55:55 yeah i looked over the script Jun 26 19:56:34 so, yeah after alll that testing... external gpio control is the way to go.. Jun 26 19:56:50 so it has to be a 2 cable solution.. Jun 26 19:57:02 can't we do everything over one usb cable ? Jun 26 19:57:20 and talk from u-boot ? extend u-boot a bit to have like a gserial and listen for commands Jun 26 19:57:40 plus the bootpin cape or whatever thingie Jun 26 19:57:57 looked last week, we need to port g_serial from kernel to u-boot.. ;) Jun 26 19:58:27 ah...u-boot has nothing like this Jun 26 19:58:45 but we can ditch gserial and just caputre raw usb info Jun 26 19:59:12 not yet, most of u-boot usb stuff is just a port of the kernel gadget's stack.. Jun 26 19:59:16 g_ether for example.. Jun 26 19:59:25 yep...i remember this a bit Jun 26 19:59:55 this bootpin screwes up everything :) Jun 26 20:00:03 so if we could talk to u-boot thru usb, we could tell it microSD/eMMC.. that's one problem solved. ;) Jun 26 20:00:13 yep Jun 26 20:00:29 but in that case why not use g_ether from uboot Jun 26 20:00:31 and send stuff to it Jun 26 20:00:46 does it really matter if it is gserial or gether...still we have host support for both Jun 26 20:01:30 just as long as we can direct it.. could even just be a fake usb-input device, as u-boot have usb-keyboard support.. then just link the two.. Jun 26 20:02:03 (on sunxi targets, the serial is redirected to the hdmi, and all usb keyboard events get eched both places) Jun 26 20:03:20 i'll take a look what we can do to speak to uboot Jun 26 20:03:45 that would be ideal Jun 26 20:03:52 and we would get rid of some problems Jun 26 20:04:16 btw, u-boot also has usb-flash-drive emulation, so we could even drop booting to kernel. ;) Jun 26 20:04:38 anyway brb...lunch time :) Jun 26 20:04:48 no problem! Jun 26 20:22:50 rcn-ee: i still have link to your big diff but i lost the other one Jun 26 20:23:16 didn't you also have separate patches/tarball link? Jun 26 20:23:37 nerdboy, there's the big patch, a git tree and a patch script. ;) Jun 26 20:23:44 * nerdboy smells sandwich meats Jun 26 20:23:45 which do you want? :0 Jun 26 20:24:19 something i can retrieve via package src_uri and apply Jun 26 20:24:39 one big diff is fine as long as it goes on correctly Jun 26 20:25:44 it was diffed against 4.1.0.. otherwise: https://github.com/beagleboard/linux/tree/4.1-bone9 Jun 26 20:26:24 my build system requires it to be 100% diffed on kernel release.. Jun 26 20:36:00 that should work Jun 26 21:23:51 rcn-ee: back Jun 26 21:24:01 so i will take this weekend to look into uboot stuff Jun 26 21:24:07 will get back to you next week Jun 26 21:24:33 vvu, take your time, it's no rush.. Jun 26 21:35:36 yeah...but free time needs to be assigned to something **** ENDING LOGGING AT Sat Jun 27 02:59:58 2015