| 00:01 | rabeeh | this is really strange |
| 00:01 | rabeeh | on a gig link, running iperf shows ~410Mbps with no error packets |
| 00:02 | rabeeh | forcing link to 100Mbps via mii-diag and rerunning shows 82Mbps with few hundreds of received error packets |
| 00:02 | rabeeh | CuBox-i |
| 02:11 | cbxbiker61_ | cubox-i is definately getting more press than the original cubox did, it's even on tomshardware and that site mostly covers windows/intel developments |
| 04:13 | dbsx | wifi: the 3.11 kernel has CONFIG_BRCMFMAC and CONFIG_BRCMFMAC_SDIO which I glean from the documentation supports AP mode. Firmware is required (no big deal). Monitor mode (new), IBSS supported. |
| 10:17 | rabeeh | dv_: so you got it working? https://github.com/dv1/gst-fsl/commit/ac1dc7a8f27d2827cd92f27ab74e88ab989227e1 |
| 10:17 | rabeeh | the deinterlacing? can u tell about the quality? |
| 10:34 | dv_ | rabeeh: how much of my response did go through? |
| 10:58 | _rmk_ | dv_: I saw nothing after rabeeh's comments on the channel, apart from joins/parts |
| 10:58 | dv_ | ah |
| 10:58 | dv_ | alright |
| 10:58 | dv_ | rabeeh: there are two deinterlacing modes. both are described as "motion-adaptive". one is the "slow-motion" mode, the other is the "fast-motion". there seems to be a third one, but I havent seen it documented anywhere. |
| 10:59 | dv_ | the fast mode uses 1 input frame for 1 output frame. as the name says, it is better suited for scenes with fast motion. the slow mode uses 2 input frames for 1 output frame, in a rolling fashion. that is, you always take the current and the previous input frame and use them for deinterlacing. better suited for slow motion scenes. |
| 10:59 | dv_ | the slow mode tends to deliver better quality (fast mode can introduce interpolation-like artifacts between lines), but looks a bit weird in fast scenes, although I havent done much with it. currently, only the fast mode is in the code. I am working on integrating the slow mode properly. |
| 10:59 | dv_ | thats about it. |
| 11:00 | rabeeh | dv_: and that part is not programmable - right? it's not a firmware. |
| 11:00 | dv_ | I am not sure. it may be. but I do not know how. |
| 11:01 | dv_ | I stumbled upon a HUGE PDF for the imx6. 51 MB, over 5000 pages. |
| 11:02 | dv_ | hmm okay, it doesn mention "programmable" in the deinterlacer |
| 11:04 | dv_ | here: http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf |
| 11:05 | rabeeh | :0 |
| 11:05 | rabeeh | that pdf should be with special request :) |
| 11:06 | dv_ | hm? |
| 11:06 | rabeeh | i mean you create a username, then ask specifically for the user manual and then you get the link. bravo fsl :) |
| 11:06 | dv_ | ah :) |
| 11:06 | dv_ | well I found it through google. |
| 11:07 | dv_ | if access is supposed to be restricted, then their IT department needs to learn a thing or two about security :) |
| 12:24 | rabeeh | really strange things happening here with the ethernet phy |
| 12:24 | rabeeh | if i connect gig; works without issues; if i force to fast ethernet, i get tons of receive errors |
| 12:25 | rabeeh | if i connect a fast ethernet (i.e. without forcing to fast) then works without issues |
| 12:25 | rabeeh | i wonder if mii-diag is buggy? |
| 13:04 | jnettlet | rabeeh, is duplexing not being re-negotiated properly? |
| 13:08 | jnettlet | I would also suggest testing with another switch preferably from another manufacturer just to make sure it isn't specific to the current combo |
| 13:25 | _rmk_ | dv: there's bugs in the vivante GPU MMU code which could be a cause of AXI bus errors (it can corrupt its own free list) |
| 13:26 | _rmk_ | I just got sick of that code, and replaced it with a Linux bitmap based allocator |
| 13:27 | _rmk_ | you can't end up with a corrupted linked list with a bitmap :) |
| 13:28 | jnettlet | Is that a challenge? |
| 13:29 | _rmk_ | yes, and good luck with it... a bitmap where a '1' indicates used and '0' free doesn't have any linking so there isn't a linked list to corrupt |
| 13:33 | dv_ | _rmk_: bummer |
| 13:33 | jnettlet | how many bits are you using to track state? |
| 13:33 | dv_ | _rmk_: does this make the GLES video sink output a no-go? |
| 13:33 | dv_ | (without modifications like the bitmap you mentioned) |
| 13:59 | _rmk_ | jnettlet: one bit per entry, which with the standard mmu size of 128k, means a bitmap size of 16k |
| 14:00 | _rmk_ | its just a bitmap of which entries in the table are in-use |
| 14:00 | _rmk_ | and we have functions which find areas of contiguous zero bits (bitmap_find_next_zero_area) |
| 14:01 | jnettlet | interesting. I haven't run across that before. |
| 14:03 | jnettlet | always something new and fun to find out about in the kernel |
| 14:06 | _rmk_ | it all started because when the MMU search wraps around, it doesn't reset "previous" which then causes it to corrupt its linked list |
| 14:07 | _rmk_ | so I was getting "MMU table correcupted at index ..." messages |
| 14:08 | _rmk_ | that's because the heapList pointer ended up pointing at an allocated entry |
| 14:11 | _rmk_ | personally, I think if Vivante didn't spend so much time writing functions with all the crap argument verification all over the place, and spent more time thinking about the algorithms, their code might be a whole lot better. (by that I mean... better mmu handling, ineffectual signal waits in the presence of signals, races in the event code, abusing the kernel APIs to name a few...) |
| 14:12 | _rmk_ | and I can't understand why they insist on using their abstracted functions in OS specific code |
| 14:12 | _rmk_ | it's... OS specific code, there's no point abstracting OS specific functions in OS specific code. |
| 14:13 | _rmk_ | and why they use GFP_ATOMIC all over the place, which eats into the "safe" memory pools designed for handing out memory for interrupt handlers and the like, where page reclaimation is difficult... |
| 14:13 | _rmk_ | its not like any of these places is allocating memory from such contexts |
| 14:15 | _rmk_ | my overall view of the vivante GPU code is its standard vendor crap designed to look like they have a software quality process, but because they're soo caught up in that, it blinds them to writing good code to start with |
| 14:21 | jnettlet | All this reminds me of a lot of the Chinese development teams I have worked with. They have a process and one way to things and that is just how it is done. |
| 14:22 | jnettlet | When one way is found to work that is just how it is used until it doesn't work any longer. |
| 14:35 | dv_ | perhaps somebody over there is enforcing coding guidelines and standards no matter how stupid they are |
| 14:36 | _rmk_ | have you ever heard of a memory copy which can return an error? |
| 14:36 | dv_ | "its in the rule book, you must do it! logic and reason are not mentioned in the rule book!" |
| 14:36 | _rmk_ | vivante seems to require every function they wrap to be able to return a gceSTATUS, including memcpy and memset |
| 14:36 | dv_ | well, I guess thats another rule that defies reason :) |
| 14:37 | dv_ | anyway, I'll continue with my gles work, AXI bus error or not |
| 14:38 | _rmk_ | dv: I feel that there's a gceSTATUS value appropriate here... gcvSTATUS_TOO_COMPLEX :) |
| 14:38 | dv_ | :) |
| 14:38 | dv_ | you know what would be perfect? a gceStrerror which also returns an error code |
| 14:39 | dv_ | gcvSTATUS_ERRROR_NO_ERROR |
| 14:40 | _rmk_ | dv: you should know full well that would be implemented as: gceSTATUS gckKERNEL_StrError(IN gceSTATUS Status, OUT gctSTRING String); |
| 14:41 | _rmk_ | and String must be large enough to hold the error string, which will be copied using gckOS_MemCopy() which might fail, so obviously this has to return an error. :) |
| 14:42 | dv_ | russian error dolls |
| 14:42 | Coolgeek | yo dawg, I heard you like checking error... |
| 14:42 | jnettlet | bwahahaha |
| 15:09 | rabeeh | jnettlet: duplex negotiated ok |
| 15:10 | rabeeh | it's only when forcing a link of 100mbps on a 1gbps switch makes those weird received packets. |
| 15:12 | jnettlet | Is the switch trying to use jumbo packets still? |
| 15:12 | rabeeh | nop |
| 15:12 | rabeeh | 1.5k mtu |
| 15:12 | rabeeh | it's as follows - |
| 15:12 | rabeeh | link 1gbps; iperf works ok |
| 15:12 | rabeeh | mii-diag -P 100baseTx |
| 15:13 | rabeeh | link 100mbps; but iperf looses lots of packets due to errorneous received packets on the i.MX6 side |
| 15:13 | rabeeh | maybe mii-diag is doing more than just forcing the speed. |
| 15:13 | _rmk_ | tried using the more modern ethtool instead? |
| 15:15 | _rmk_ | ethtool -s eth0 speed 100 |
| 15:16 | jnettlet | dv_, looks like the most recent batch of changes has finally fixed Linaro's openembedded toolchain. Finally getting a working image with iwmmxt enabled. |
| 15:17 | rabee | 15:17 * rabeeh rebuilding ethtool |
| 15:21 | rabeeh | # ethtool -s eth0 speed 100 |
| 15:21 | rabeeh | Cannot advertise speed 100 |
| 15:21 | rabeeh | the driver is probably missing some ioctls() |
| 15:22 | _rmk_ | that sucks |
| 15:27 | rabeeh | http://www.youtube.com/watch?v=V6dC2lJNFMQ |
| 15:28 | rabeeh | was just uploaded |
| 15:31 | jnettlet | oh that does suck |
| 15:31 | jnettlet | not the video, the 100Mbps fail |
| 15:33 | rabeeh | and the video? |
| 15:33 | rabeeh | :) |
| 15:33 | rabee | 15:33 * rabeeh hates videos. |
| 15:34 | bencoh | :) |
| 15:34 | jnettlet | video is good :-) |
| 15:52 | Coolgeek | rabeeh: is it you in the video ? |
| 15:55 | dv505 | XBMC looks smooth in the video. Is that the standard Android version, or did you compile a version with custom changes? |
| 15:56 | jnettlet | an xbmc on android with hardware decoding was finally released last week. |
| 16:12 | rabeeh | Coolgeek: yes. |
| 16:12 | rabeeh | dv505: standard version apk; just installed and played a sample video |
| 16:13 | rabeeh | jnettlet: that's not the version we are using. |
| 16:14 | rabeeh | 44c on the outer case after GPU is heavily rendering the GUI |
| 16:14 | rabeeh | ambient was about 29c |
| 16:50 | dbsx | Rabeeh what is the power overhead of adding wifi and bluetooth? And do they use any power when the drivers are absent? |
| 16:51 | rabeeh | we don't have final measurements; but specs shows around 300mA on 5V rail (i.e. 1.5W) |
| 16:51 | rabeeh | when there are no drivers, even if the chip is out of reset it almost takes no power |
| 16:52 | dbsx | so at user level radio off would be low power too(I guess)? |
| 16:55 | rabeeh | yes |
| 16:59 | lubiana | so ehm, i guess this is a newbie question, but is there a kernel available with the dm_mod module? |
| 17:00 | lubiana | i am trying to set up a system with full disk encryption, but fail at this early stage |
| 17:02 | lubiana | maybe this is interesting too: i first installed the debian headless from the cubox installer but now debootstrapped debian to an usb stick |
| 17:03 | lubiana | and i want to use cryptsetup to create an encrypted volume on the sdcard |
| 17:13 | TrevorH1 | I've just used cryptsetup on debian wheezy as a test on an lvm LV |
| 17:13 | TrevorH1 | no idea if you can do FDE though |
| 17:16 | lubiana | well, i now tried the archlinuxarm kernel for cubox and aes-cbs driver seems to be integrated |
| 17:17 | lubiana | but i am meeting with a friend later and try to cross compile a kernel |
| 17:17 | lubiana | iirc the debian kernel had the device-mapper integrated but not the crypto part |
| 17:18 | lubiana | but well i will learn a lot about compiling my own kernel today :D |
| 17:24 | TrevorH1 | apt-get install cryptsetup ran update-initramfs for me |
| 19:19 | _rmk_ | rabeeh: you know that some toslink cables won't fit in a square hole? |
| 19:19 | rabeeh | _rmk_: yes. there are models that don't fit |
| 19:20 | rabeeh | but most of the models we found here do fit |
| 19:20 | _rmk_ | I ended up making mine larger - both the ABS and the metalwork inside |
| 19:20 | rabeeh | aargh |
| 19:23 | rabeeh | at the beginning of the mechanical design, we tried putting the SPDIF in the back; but there is no place for it. |
| 23:07 | Loic_ | Hi there |
| 23:07 | Loic_ | nice to meet you all |
| 23:08 | Loic_ | One question: when would arrive the cubox i4 if I buy it today? |
| 23:48 | mhoney | I ordered my i4 today.. cant wait |