| 00:09 | _rmk_ | definitely weird. reboot sorted it out, but resetting the ipu manually and then rebinding the driver didn't. |
| 01:40 | _rmk | 01:40 * _rmk_ kicks shesselba hard |
| 01:41 | _rmk_ | for commit eb6b036dde364c528807f53ee8c8e5c9b0e46c34 |
| 01:41 | _rmk_ | which is a duplicate of b9b5ab11ea221a9f2d5af41da639e0898675c34c already merged into mainline post -rc3 |
| 01:41 | _rmk_ | and the first wasn't signed-off by shesselba, which is requried when committing. |
| 01:42 | _rmk_ | anyway, the result is one 100+ line merge conflict I have here, and very little idea at the moment what the right answer is |
| 06:55 | HotTinyBox | . |
| 08:43 | shesselba | _rmk_: sorry for that, it must have happened when ojn pulled in the arm-wide of_clk_init stuff.. anything I can do about it? |
| 10:11 | rabeeh | _rmk_: so is there any issue with 1080p60? |
| 10:28 | shesselba | _rmk_, ojn: prepared a new branch based on v3.12 for the of_clk_init patches without the offending patch |
| 10:29 | shesselba | shall I reply to the original PR and ask others to rebase on the new one instead? |
| 10:29 | shesselba | then send a new PR? |
| 10:42 | _rmk_ | shesselba: I think ojn said that its not worth worrying about because he's fixed the conflict |
| 10:44 | shesselba | _rmk_: ok, but I remember Shawn Guo mention to base some of his patches on my branch.. if somebody pulls his branch, eb6b036dde will pop up again? |
| 10:44 | shesselba | anyway, sorry for messing your branch up |
| 10:45 | _rmk_ | eb6b036dde is already in arm-soc |
| 10:49 | shesselba | *sigh*, sorry again, I do understand what went wrong and will take more care next time |
| 11:49 | jnettlet | the penitent ARM developer kneels before _rmk_ |
| 12:15 | _rmk_ | I require no kneeling, it's very bad for the knees. |
| 12:15 | _rmk_ | you'll understand later in life when they've gone. |
| 12:16 | MikeSeth | the bitterness |
| 12:21 | _rmk_ | I had two options last night: give up, disable the nightly build, and sort it out sometime today, delaying the pushing out of my tree by 24 hours since it couldn't be build tested, or try to find the right answer - and more importantly highlight the problem so it doesn't happen again. |
| 12:23 | _rmk_ | given the proximity of the weekend, sfr's schedule for creating linux-next, and the merge window opening on about Sunday, and the requirement for stuff which is to be submitted in the merge window to pre-exist in linux-next, it was rather fundamentally important that the latter happened. |
| 12:25 | _rmk_ | it can take 24 to 48 hours for stuff I put in my tree to show up in linux-next. |
| 12:28 | jnettlet | all understandable. can't hold up the linux train |
| 12:29 | Bluerise | hmm? what did I miss? |
| 12:29 | shesselba | jnettlet: not only in front of _rmk_, what I caused with applying that patch directly was horribly wrong - I should have known better as I was already aware of the problem with that no-tree-available-to-merge-with-that-patch thing |
| 12:30 | jnettlet | kneel before git! |
| 12:31 | Bluerise | Heh. |
| 12:31 | Bluerise | Last time someone told me he was on his knees, he really had some pain afterwards. |
| 12:32 | Bluerise | (to be more precise: on knees between legs, on the hard bathroom floor) |
| 12:32 | _rmk_ | git can cope when a patch is applied independently to two different trees and there's no other changes afterwards which interfere with the patch - the problem happens when there's changes on top which change the patched code - git can't work it out. |
| 12:33 | _rmk_ | git can also cope of the patch is committed into one tree, and that commit is then pulled into the other tree and built on independently there. |
| 12:33 | _rmk_ | s/of/if/ |
| 12:36 | _rmk_ | bluerise: hence the expression "knees weren't made for kneeling" |
| 12:36 | shesselba | the latter wasn't available when that patch set was ready. Mike was very busy back then, but I should have waited with the PR until it appeard somewhere |
| 12:37 | _rmk_ | bluerise: and yes, I've experienced that recently - re-plumbed the bathroom earlier this year and it took something like three weeks for the knees to recover |
| 12:37 | Bluerise | ouch :/ |
| 12:46 | lioka | _rmk_: c1 dts from carrier-1-v3.12-rc7-all.diff: 'usbhc2' seems like typo for me |
| 12:47 | lioka | _rmk_: should it be usdhc2 ? |
| 12:50 | _rmk_ | lioka: good catch |
| 12:50 | _rmk_ | thankfully that's just a label so it doesn't have a functional effect |
| 12:52 | lioka | seems so, because usb doesn't work for me in both cases :] |
| 12:53 | lioka | maybe i should try with =y for them instead of =m |
| 12:53 | jnettlet | _rmk_, sorry I patched that locally and forgot to send it your way. |
| 12:54 | _rmk_ | lioka: hmm, you're referring to the gang of two usb sockets, neither of them working? |
| 12:54 | lioka | _rmk_: no, to both original and tweaked dtbs |
| 12:55 | _rmk_ | which socket are you trying to use for USB? |
| 12:56 | lioka | i have both used, with usb keyboard and usb flash, neither showed up |
| 12:56 | _rmk_ | when you load the module, you should see something like this: |
| 12:57 | _rmk_ | ci_hdrc ci_hdrc.0: doesn't support gadget |
| 12:57 | _rmk_ | ci_hdrc ci_hdrc.0: EHCI Host Controller |
| 12:57 | _rmk_ | ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 |
| 12:57 | _rmk_ | ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 |
| 12:57 | _rmk_ | hub 1-0:1.0: USB hub found |
| 12:57 | _rmk_ | hub 1-0:1.0: 1 port detected |
| 12:57 | _rmk_ | and a similar sequence for the other socket |
| 12:57 | lioka | yep, and additionally i see ci_hdrc ci_hdrc.0: doesn't support host |
| 12:58 | _rmk_ | ergh, that's the problem then |
| 12:58 | lioka | seems i've screwed my config, again |
| 12:58 | lioka | okay, got direction to dig |
| 13:00 | _rmk_ | what did you change? |
| 13:03 | lioka | _rmk_: well i've started with multi_v7_defconfig (i'm trying to have c1 in multiplatform kernel) |
| 13:05 | _rmk_ | ah, I started from imx_v6_v7_defconfig |
| 13:05 | jnettlet | I don't think we are at the multi_v7 working point. I found a couple of issues that needed to be fixed but until we have the hardware working the way we want I saw no point in fixing them yet. |
| 13:07 | lioka | jnettlet: i see |
| 13:07 | jnettlet | lioka, if you want to fix them have at :-) |
| 13:12 | _rmk_ | I just stuck the xorg.conf I'm using there too, but I think it may take some hand-holding to get xf86-video-armada-0.0.0 to build (since it depends on libdrm-armada and the GAL libraries) |
| 13:15 | jnettlet | _rmk_, I have made some significant progress moving vivante acceleration into an xorg extension. This will let just about any soc with an xorg ddx to easily use your vivante acceleration. |
| 13:16 | jnettlet | they will just need to pass at least a single front buffer and a wait_for_vsync function. |
| 13:27 | _rmk_ | ok, there's now a rough readme there giving rough steps to getting Xorg up and running with my stuff. |
| 13:28 | liok | 13:28 * lioka DOWANT |
| 13:28 | _rmk_ | it assumes some level of experience with building stuff though :) |
| 13:28 | _rmk_ | and the readme may be buggy :) I'm not great at writing instructions. |
| 13:29 | _rmk_ | feel free to take the readme and mail back improvements to it |
| 13:29 | liok | 13:29 * lioka bet getting thru old marvell blobs was much worse |
| 13:30 | _rmk_ | I basically wrote it just now from memory |
| 13:30 | _rmk_ | back in a while. |
| 13:46 | jas-hacks_ | On the C1 at 720p glmark-es2 score is |
| 13:46 | jas-hacks_ | ======================================================= |
| 13:46 | jas-hacks_ | glmark2 Score: 143 |
| 13:46 | jas-hacks_ | ======================================================= |
| 13:57 | rabeeh | jas-hacks_: hey |
| 13:57 | rabeeh | which distro are you running that at? do you have ubuntu up and running? |
| 13:58 | jas-hacks_ | rabeeh: Yes, ubuntu 13.04 |
| 13:59 | rabeeh | jas-hacks_: god damn it; bring me the image :) |
| 13:59 | rabeeh | xfce i believe? |
| 13:59 | jas-hacks_ | rabeeh: Yes xfce, it will work better on a imx6q |
| 14:00 | rabeeh | yeah; 512MB is a bit low on this too |
| 14:00 | rabeeh | maybe matchbox? |
| 14:00 | rabeeh | which kernel? |
| 14:02 | jas-hacks_ | rabeeh: I patched up yours, in my repo (I just need to check in more changes) https://github.com/mtx512/linux-imx/tree/imx_3.0.35_4.1.0-solidrun |
| 14:02 | rabeeh | ok. |
| 14:04 | jas-hacks_ | surprisingly 'neverball' 3D ball game plays ok |
| 14:05 | jnettlet | is that running accelerated via Vivante's hacked libGL.so ? |
| 14:05 | jnettlet | could you post the output to glxinfo please? |
| 14:06 | jas-hacks_ | jnettlet: yes |
| 14:07 | dv_ | yeah whats with that libGL? |
| 14:09 | jnettlet | dv_, they are mapping libGL extensions and calls to GLESv2 hardware instructions |
| 14:09 | dv_ | yes |
| 14:09 | dv_ | but that lib came out of nowhere, and only sort of works |
| 14:10 | jnettlet | oh Vivante wrote that with Marvell for the v4 drivers. |
| 14:11 | jas-hacks_ | jnettlet: http://pastebin.com/ezuRjWqE |
| 14:11 | _rmk_ | ok, instructions updated a little. I've also included some instructions for the dove cubox too |
| 14:11 | dv_ | btw. wumpus, would etnaviv+mesa give us accelerated GL through libGL automatically? |
| 14:11 | dv_ | in other words, does mesa's libGL use the gallium backend? |
| 14:14 | rabeeh | jas-hacks_: there is a small patch i'm putting on the git tree that looks at 'gpumem=xMB' kernel command line |
| 14:14 | rabeeh | i'm using it in the Android builds; with gpumem=96M i'm left with ~411MB usable memory on boot |
| 14:15 | dv_ | btw rabeeh, with DMA memory config set to 96M I have ran out of memory for transcoding a few times |
| 14:16 | dv_ | because some h264 videos require the decoder to keep up to 17 frames in memory for decoding the B frames |
| 14:16 | jas-hacks_ | rabeeh: I could try it, but normally I've left the drivers to work out how much they need |
| 14:17 | rabeeh | 17x1920x1080x2byte = 70MB |
| 14:17 | dv_ | yeah but the encoder also needs memory |
| 14:17 | lioka | _rmk_: url please ? |
| 14:18 | dv_ | 1920*1080*2*(17+5+2)/1048576 ~ 94 M |
| 14:18 | dv_ | (encoder requires at least 5 frames, and decoder + encoder both have 1 frame to handle some corner cases) |
| 14:18 | dv_ | but the real reason I think is that there is a fixed set of fixed-size memory bins for DMA buffers |
| 14:19 | rabeeh | jas-hacks_: patch pushed |
| 14:20 | dv_ | anyway, with the CMA, things should get much better |
| 14:20 | jnettlet | dv_, are you planning on adding CMA support to the VPU driver? |
| 14:20 | dv_ | once its available, yes |
| 14:21 | dv_ | I'd need a way to detect its presence though. both at build and at runtime |
| 14:21 | jnettlet | it is available in the 3.10 kernel |
| 14:21 | rabeeh | jas-hacks_: please provide an image once you have it; do you have also a cookbook script that gathers the packages around and creates and image? |
| 14:21 | jnettlet | in the kernel you can just check to see if CONFIG_CMA is defined |
| 14:21 | dv_ | so should I change my meta-fsl-arm-extra fork to use your 3.10 fork? |
| 14:22 | dv_ | also, I meant detection as in "detect CMA presence in the build script configuration phase" |
| 14:22 | jnettlet | dv_, I think that is what we are shooting for. |
| 14:22 | jnettlet | rabeeh, are we focusing on 3.10 for launch? |
| 14:22 | rabeeh | 3.10 is not released by Freescale, yet |
| 14:23 | jas-hacks_ | rabeeh: which repo are u using? |
| 14:23 | dv_ | jnettlet: also, you derived yours from the boundarydevices kernel |
| 14:23 | dv_ | otavio wants you to use the freescale one, right? |
| 14:23 | jnettlet | dv_, my branch is based on freescale one. |
| 14:23 | jnettlet | I rebased already. |
| 14:23 | dv_ | ah, great |
| 14:24 | dv_ | then I'll switch |
| 14:24 | rabeeh | jas-hacks_: https://github.com/SolidRun/linux-imx6 |
| 14:24 | dv_ | jnettlet: so any ideas on how a build script can detect if CMA is present? |
| 14:24 | jnettlet | dv_, if you want to use KMS it will be a bit. I still have to pull in _rmk_'s latest patchset |
| 14:25 | dv_ | perhaps a header that is only present if CMA support is there? |
| 14:25 | jnettlet | dv_, parse the /boot/config file? |
| 14:25 | jnettlet | this is just for the VPU driver? |
| 14:26 | dv_ | ok wait. detection is split into compile-time and runtime. runtime can look up the config in /proc for example. compile-time would ideally look for CMA headers that arent around in 3.0.35 . |
| 14:26 | dv_ | for VPU and IPU |
| 14:26 | jnettlet | does userspace need to care? Couldn't we just handle this all in the kernel? |
| 14:27 | dv_ | well I can also live with some ioctls |
| 14:27 | rabeeh | jnettlet: i wish we could already switch to 3.10; but i'm worried of hanging between 3.0.35 and 3.10 where neither are ready for prime time |
| 14:27 | rabeeh | on the other hand 3.0.35 is really really old |
| 14:28 | jnettlet | yep. All of rmk's work is based on 3.12+, I am backporting pieces to 3.10 along with required upstream patches. |
| 14:28 | dv_ | jnettlet: currently there are three sets of allocators: for the encoder https://github.com/Freescale/gstreamer-imx/blob/master/src/vpu/encoder/allocator.c the decoder https://github.com/Freescale/gstreamer-imx/blob/master/src/vpu/decoder/allocator.c and the IPU https://github.com/Freescale/gstreamer-imx/blob/master/src/ipu/allocator.c |
| 14:29 | dv_ | ideally, I could do something like #ifdef WITH_CMA ... #endif and use one common allocator set instead |
| 14:29 | dv_ | oh, and perhaps a runtime check before if necessary |
| 14:31 | jas-hacks_ | rabeeh: Is the 26 pin header mapped out anywhere (are there some GPIO lines)? |
| 14:32 | jnettlet | dv_, oh right we need this in userspace. |
| 14:32 | jnettlet | dv_, I remember talking about this now. I will branch it to github, but any chance we can just extend and use. http://dev.laptop.org/git/users/dsd/libphycontmem/tree/ |
| 14:33 | jnettlet | Then I will merge the ION mm code and CMA helpers into my 3.10 kernel |
| 14:34 | dv_ | jnettlet: as said, one extra header for ioctl constants would be enough for me |
| 14:34 | dv_ | but truthfully, I dont care ,as long as I have some alloc and free function |
| 14:35 | jnettlet | well the bonus of using ION is that is supported by android and is supposed to be making it to mainline at some point. |
| 14:36 | dv_ | but remember, i need something that gives me physical and virtual addresses |
| 14:36 | dv_ | its the age old design flaw |
| 14:36 | jnettlet | dv_, yep. I have added an ION module that includes a custom IOCTL that allows the physical address to be passed back to userspace. |
| 14:37 | jnettlet | I had to do that for vMeta |
| 14:38 | dv_ | ok. then I will wait until _rmk_'s patchset is pulled in, then I will change the recipes to use your 3.10 version |
| 14:38 | dv_ | btw listening to _rmk_'s cursing, I think not waiting for pengutronix to finish their stuff wasnt a bad decision :) |
| 14:38 | jnettlet | I agree |
| 14:40 | jnettlet | dv_, is the other platform you are working on a wandboard? |
| 14:40 | jnettle | 14:40 * jnettlet has such a bad memory with all this hardware floating around. |
| 14:41 | dv_ | jnettlet: sabre SD duallite |
| 14:41 | dv_ | not doing much with it now though, since (a) it is not mine, it is property of a customer (b) the c1 is good enough |
| 14:42 | jnettlet | dv_, ah okay. |
| 14:43 | jnettlet | They don't seem to be doing much dev work for that hardware. |
| 14:43 | dv_ | it is developer hardware |
| 14:44 | dv_ | it is not sold that much |
| 14:44 | dv_ | thats also why it is so expensive |
| 14:45 | jnettlet | they have a quad-core board for $129, but it has an enormous heat sink on it |
| 14:46 | dv_ | jnettlet: its this one http://at.farnell.com/freescale-semiconductor/mcimx6dl-sdp/eval-i-mx-6-sabre-6duallite/dp/2253178 |
| 14:46 | dv_ | although in this case, the display with touchscreen makes up 2/3rd of the price |
| 14:47 | jnettlet | sure. |
| 14:47 | jas-hacks_ | they all need a big heatsink because the quad can get really hot, I've blown a couple of gk802's |
| 14:48 | dv_ | but, from what rabeeh said once, the gk802 has a really lousy heat dissipation design |
| 14:50 | _rmk_ | lioka: http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-readme.txt |
| 14:50 | jnettlet | yeah those sticks are bad news. My mk808 based on the rockwell soc gave in to heat stroke a while back. |
| 14:51 | jas-hacks_ | yep, the gk802 had a lousy design, but even the wandboard needs a heatsink completely covering the SOM |
| 14:52 | jnettlet | _rmk_, I need to get you a compat-api patch for xf86-video-armada so it will work with newer Xorg servers. |
| 14:56 | _rmk_ | ok |
| 15:01 | lioka | _rmk_: is libGAL the same for both cubox and c1 ? |
| 15:03 | _rmk_ | yes, that's just because xf86-video-armada doesn't have a way to turn that off, and it was developed against the cubox. |
| 15:20 | otavio | Hi |
| 15:20 | otavio | :) |
| 15:23 | dv_ | otavio: I will first change the kernel version to jnettlet's 3.10 before sending patches to your meta-fsl-arm-extra repo |
| 15:23 | dv_ | (actually, in github, I could use pull requests instead) |
| 15:24 | dv_ | plus, rabeeh is renaming the carrier one. so the machine config will be renamed eventually too |
| 15:31 | _rmk | 15:31 * _rmk_ is useless at picking names so I'm not bothering to try |
| 15:32 | otavio | dv_: has the name been choosen already? |
| 15:33 | dv_ | afaik no |
| 15:33 | otavio | k |
| 17:21 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-v3.12-all.diff |
| 17:22 | _rmk_ | ^^^ now has audio included |
| 17:22 | lioka | wow |
| 17:26 | jnettlet | _rmk_, is that safe to merge or are you going to drop another thousand lines of code soon? |
| 17:29 | _rmk_ | jnettlet: depends if I merge the imx-drm prime patches today or not. |
| 17:29 | jnettle | 17:29 * jnettlet will wait then. |
| 17:29 | _rmk_ | ahem, it would help if it builds :p |
| 17:31 | _rmk_ | there. |
| 17:32 | _rmk_ | eek. 75 commits in all there. |
| 17:34 | Coolgeek | are all your change commit to the mainline kernel ? |
| 17:34 | jnettlet | yes mainline |
| 17:35 | _rmk_ | individual patches if you're interested: http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-v3.12/ |
| 17:35 | _rmk_ | 74 commits sorrt. |
| 17:36 | _rmk_ | bah. let me teach apache about .patch extensions |
| 17:36 | _rmk_ | or I'll just rename them all to .diff |
| 17:37 | _rmk_ | there you go, now browsable in your web browser without it being told it's mhtml |
| 17:40 | _rmk_ | also provided my .config file too there |
| 17:40 | _rmk_ | (the readme has the URL) |
| 17:42 | neofob | hi everyone, so what is the latest kernel version that can run cubox now? |
| 17:49 | jnettlet | neofob, mainline with _rmk_'s patch is the latest, but that doesn't include any of the patches that haven't been upstreamed by freescale yet. |
| 17:50 | _rmk_ | neofob: cubox or carrier-1? |
| 17:51 | neofob | cubox |
| 17:51 | neofob | i notice there is no default cubox config in mainline |
| 17:51 | _rmk_ | and what do you want from it? video/gpu acceleration? |
| 17:52 | _rmk_ | or are you using it more as a NAS or similar? |
| 17:52 | neofob | no, i just need an headless config to run nas |
| 17:52 | neofob | i'm running 3.5.7 patched from vdorst for now |
| 17:53 | neofob | where can i get rmk patch? |
| 17:53 | _rmk_ | mainline should run on it then, it's part of the multiplatform stuff, and you'll need to use a DT blob with it. I suggest shesselba helps with that. |
| 17:54 | _rmk_ | I've never actually run mainline on my cubox... yet. |
| 17:54 | neofob | thanks, i want to try 3.12 over weekend so i want to know what patch and other things i need to do |
| 17:54 | _rmk_ | no patch should be required for what you want to use it for. |
| 17:54 | tazou | hi |
| 17:55 | _rmk_ | roughly what's required is: |
| 17:55 | _rmk_ | - build the kernel with the appropriate configuration |
| 17:55 | tazou | is an already compiled version of uImage of the installer with /dev/mtd support enabled please ? http://www.solid-run.com/mw/index.php?title=CuBox_Installer_Developer_Page |
| 17:55 | _rmk_ | - append the cubox dt blob (.dtb) file to the kernel zImage |
| 17:55 | neofob | ok, that sounds good; my other goal is to confirm that mainline works on cubox then i will try to submit a pull request for jumbo frame support |
| 17:55 | _rmk_ | - use mkimage to convert that to something uboot will understand |
| 17:56 | _rmk_ | - don't forget to install any modules as well :) |
| 17:56 | neofob | https://gist.github.com/neofob/3158055 |
| 17:57 | _rmk_ | and if you have an initramfs too, don't forget to tell that to create a new initramfs for the new kernel (normally via -u -k replace-me-with-new-kernel-version) |
| 17:58 | neofob | _rmk_: do i need to upgrade my uboot with this new setup? |
| 17:59 | _rmk_ | given the amount of issues people seem to have with uboot upgrades, I'd suggest using the appended-dt blob method of booting at the moment - it gives you an easy way back if it all goes wrong. |
| 18:01 | neofob | also, does the mainline kernel support the crypto engine in cubox now? |
| 18:02 | _rmk_ | that I don't know off hand |
| 18:08 | jnettlet | okay the first semi-working version of the libvivante-accel.so xorg extension is loading. |
| 18:08 | tazou | neofob, you seems aware about kernel compilation. Could you help me please for the compilation of http://www.solid-run.com/mw/index.php?title=CuBox_Installer_Developer_Page with /dev/mtd support please ? :) |
| 18:14 | neofob | tazou: on mtd, i dont know much about that; my kernel compilation is very simple |
| 18:15 | neofob | i cross-compile the kernel using Linaro's gcc; see http://www.solid-run.com/mw/index.php?title=Building_Linux |
| 18:15 | jnettlet | tazou, from what I saw yesterday you are compiling the entire cubox-installer not just the kernel |
| 18:16 | tazou | ok neofob |
| 18:16 | tazou | ha ok jnettlet |
| 18:18 | tazou | in fact i just would like to burn the u-boot on the cubox device |
| 18:19 | tazou | but the installer I use, print this error "/dev/mtd" no suck device or something like that |
| 18:19 | tazou | so rabeeh tells me to build a new kernel, i did it with cross compilation, but i get a kernel panic on booting the installer |
| 18:19 | tazou | so rabeeh tells me to buidl the installer with debootstrap , and with this i have the "-crypt" error |
| 18:20 | tazou | so I don't know how to do ti solve the problem :( |
| 18:20 | tazou | there is somewhere an installer aleardy builded with the feature "burn u-boot on the cubox" ? |
| 18:24 | tazou | please :) |
| 18:31 | tazou | i must go, see you soon (: |
| 18:33 | _rmk | 18:33 * _rmk_ feels awkward with this end user stuff here. |
| 18:34 | jnettlet | _rmk_, no worries. I will get him straightened out next time he pops up. |
| 18:35 | neofob | the joy of debugging user's problem(s)! |
| 18:36 | Coolgeek | s/problem// |
| 18:38 | jnettle | 18:38 * jnettlet is definitely adding triple buffering to the acceleration pipeline. |
| 18:38 | _rmk_ | while helping one person, rabeeh was saying that there's a way to reboot the cubox with the button pressed remotely... surely that would be a useful script for people to use to reflash stuff, rather than having to go around the "you are pressing the button while plugging the power in?" questions |
| 18:39 | _rmk_ | I can't help but feel that the whole reflashing business on cubox is harder than it needs be it's possible to do the reset-with-button-pressed remotely |
| 18:40 | _rmk_ | +if |
| 18:52 | jnettlet | _rmk_, we should be able to write a uboot script that checks the sdhc card/u-boot for a new u-boot image and if it finds one flashes it and then deletes it from the card./usb stick |
| 18:52 | jnettlet | of course if a users uboot script is in place none of this would happen |
| 18:53 | jnettlet | no remote button pushing necessary |
| 18:56 | jnettlet | _rmk_, have you put in your submission for the carrier-1 renaming contest? |
| 18:57 | _rmk_ | I haven't because I'm useless at thinking up names :p |
| 18:59 | jnettlet | 90% of the suggestions are either Pi something or Fruit something |
| 18:59 | _rmk_ | wow. there's a 6502 in space. |
| 19:00 | jnettlet | is India using that for their new Mars satellite? |
| 19:01 | jnettle | 19:01 * jnettlet assumes you are talking about the microprocessor |
| 19:01 | _rmk_ | yep. |
| 19:02 | jnettlet | _rmk_, and your V for Vendetta suggestion has put me on a Graphic Novel Movie tear. V for Vendetta, last night was Sin City and tonight will probably be The Watchmen |
| 19:03 | _rmk_ | reshared the 6502 post on g+ |
| 19:03 | _rmk_ | I have a bunch of those here |
| 19:08 | jnettlet | send them up to space. |
| 19:33 | _rmk_ | jnettlet: I suspect these wouldn't last very long |
| 19:34 | _rmk_ | now, I do have some CDP1802s |
| 19:34 | _rmk_ | http://en.wikipedia.org/wiki/RCA_1802 |
| 19:35 | _rmk_ | I've seen those (1802s) in aircraft radios |
| 19:37 | _rmk_ | probably one of the CPUs which have a SEX instruction :) |
| 20:42 | taz_ | hi |
| 20:42 | taz_ | rabeeh: are you here please ? |
| 21:12 | neofob | rabeeh: i just wonder if there will be a cubox version in future with A15 |
| 21:18 | _rmk_ | jnettlet: that patch set you sent me earlier also has DRM plane support :) |
| 21:18 | _rmk_ | jnettlet: sorry, url you sent me earlier |
| 21:19 | _rmk_ | wish it had a "download raw message" off mail-archive tho |
| 21:22 | _rmk_ | and... it works. okay, update the patches and instructions :) |
| 21:30 | dv_ | neofob: I'd rather skip that one and go for an ARMv8 SoC |
| 21:31 | dv_ | btw _rmk_ , you are Mr.ARM here. :) your opinion on armv8 ? |
| 21:34 | Bluerise | probably "give me some hardware and I'll like it" *hide* |
| 21:34 | Bluerise | At least that is my opinion... |
| 23:43 | _rmk_ | heh, people are still +1'ing my early carrier-1 posts. |