| 03:01 | Coburn | IP v6 woot |
| 03:01 | Coburn | Anyway... |
| 03:01 | Coburn | Afternoon (12:01PM) |
| 11:49 | rabeeh | jnettlet: hey - i was off for a while/ |
| 11:49 | rabeeh | what is the incompatibility between hardfp and iwmmxt? |
| 11:49 | rabeeh | is it because works hasn't been done or it's impossible? |
| 11:50 | _rmk_ | rabeeh: did you get your tree updated properly? |
| 11:50 | rabeeh | i'm on 3.6.9 because of openelec |
| 11:50 | rabee | 11:50 * rabeeh stares at sraue |
| 11:51 | _rmk_ | and what about your suspected vfp problem? |
| 11:51 | rabeeh | i have your patch but still i see lots of segmentation fault on geexbox boot (like vdr) which i suspect it's vfp related. |
| 11:52 | _rmk_ | ok, I'm not going to care about the vfp problem then; its been in mainline for quite some time now with no reported failures, and I've seen nothing here either. |
| 11:53 | rabeeh | _rmk_ i guess everyone should be using that patch then. |
| 11:53 | rabeeh | i'm looking at the instructions and trying to figure it out. |
| 11:58 | jnettlet | rabeeh, is the kernel segfaulting or the application? |
| 11:59 | rabeeh | application |
| 12:00 | jnettlet | we found a bug, which is now errata for the Armada 610 to disable the pj4's return stack functionality. It was causing all sorts of odd behaviour for us. Python returning wrong calculations and such. |
| 12:01 | jnettlet | would you like the patch to give it a try? |
| 12:01 | rabeeh | yes |
| 12:01 | rabeeh | hardfp related? |
| 12:02 | jnettlet | not hardfp specific, but we didn't see the problems on our softfp release. |
| 12:02 | rabeeh | oh |
| 12:02 | jnettlet | Marvell is having us apply a similar patch for the mmp3, so it seems to be a recurring problem |
| 12:03 | _rmk_ | kernel patch? |
| 12:03 | jnettlet | yes |
| 12:04 | _rmk_ | something that should go into mainline? |
| 12:04 | jnettlet | http://fpaste.org/67LU/ |
| 12:04 | jnettlet | probably, it has fixed a lot of our weird seg-faults |
| 12:04 | jnettlet | we were going to finish our release, and then push stuff upstream |
| 12:05 | _rmk_ | well, that patch needs some rework |
| 12:05 | _rmk_ | can't have that applied to all v7 CPUs |
| 12:05 | rabeeh | this is my failure - |
| 12:05 | rabeeh | http://pastebin.com/XvH22LgW |
| 12:06 | jnettlet | _rmk_, it would only be applied if the errata was enabled in the kernel config |
| 12:06 | jnettlet | but this is not an upstreamable patch yet. It was just for our testing. We had narrowed the problem down to branch-prediction and then Marvell narrowed it further to the return stack |
| 12:07 | _rmk | 12:07 * _rmk_ wonders what they mean by "return stack" |
| 12:07 | _rmk_ | the rfe instruction which we don't use? |
| 12:08 | _rmk_ | jnettlet: my point is that when that config option is enabled, and you're running a single zImage kernel, it will be applied to any v7 CPU which is wrong |
| 12:09 | rabeeh | agree |
| 12:10 | _rmk_ | and I wouldn't be surprised if the register isn't writable in non-secure mode (which, given the direction we're heading with errata means we don't want it in the kernel anyway) |
| 12:10 | _rmk_ | but I need to check what the c15, c1, 1 register is |
| 12:11 | _rmk_ | rabeeh: here's a bit of fun at Samsung's expense: http://forum.xda-developers.com/showthread.php?p=35469999#post35469999 |
| 12:14 | rabeeh | hehe |
| 12:15 | rabeeh | and they wanted DRM with Android? |
| 12:15 | rabeeh | jnettlet: applied patch - same failures |
| 12:16 | jnettlet | rabeeh, okay different bug :-) |
| 12:16 | rabeeh | :) |
| 12:16 | rabeeh | well. pj4 is mostly backed processor; it's probably a non cpu issue |
| 12:16 | rabee | 12:16 * rabeeh digging |
| 12:17 | rabeeh | "/dev/exynos-mem seems to be used for graphic usage like camera, graphic memory allocation, hdmi." |
| 12:17 | rabeeh | sound like /dev/bmm but without any security feature :) |
| 13:13 | _rmk_ | rabeeh: exactly |
| 16:39 | Morta | b |
| 17:05 | Coolgeek | c |
| 17:07 | _rmk_ | d |
| 17:09 | rabeeh | m |
| 17:10 | _rmk | 17:10 * _rmk_ signals a sequence error |
| 18:57 | rabeeh | CuBox installer with HDMI support release (version 0.2) - http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=1065 |
| 19:29 | rabeeh | Debian hardfp (headless with full 1GB) is on the installer |
| 19:32 | Coolgeek | good job :) |
| 19:56 | rabeeh | anyone - http://wiki.xbmc.org/index.php?title=Hi10P |
| 19:56 | rabeeh | ? |
| 19:56 | rabeeh | i'm decoding those sample at - http://android.tnonline.net/Software/Video/Hi10P%20Software/ |
| 19:56 | rabeeh | without issues. |
| 19:57 | rabeeh | ! |
| 19:57 | rabeeh | for now i'v tried pussinboots-tlr1_h1080p.mp4 and hotd-op-1080p-hi10p.mkv without any issues |
| 19:57 | rabeeh | they claim - Hi10P won't work on ARM or even Intel ATOM processors (maybe one day, but none of the current ones in 2012 would do it) |
| 19:58 | rabeeh | anyone can explain? |
| 20:18 | Coolgeek | maybe they said for hardware decoding |
| 20:51 | jnettlet | rabeeh, perhaps they are encoded with just the basic functionality, which matches normal h264 and the difference is the 8 vs 10 bit depth. Somehow the vMeta decoder is just decoding 8-bit depth and we are just not getting the additional quality? |
| 20:51 | jnettle | 20:51 * jnettlet would be amazed if that is how it works, but it is my only guess based on the wiki page and a quick glance at the specs |
| 20:53 | jnettlet | rabeeh, did you see the include jpegs showing the artifacts in the video if 10-bit isn't supported? |