| 10:18 | jnettlet_ | rabeeh: The PR team has done a good job getting the word out. |
| 10:20 | jnettlet_ | Can the IR receiver power up the cubox, or at least wake it from deep sleep? |
| 10:24 | rabeeh | jnettlet_: Thanks a lot. I'll pass the complement on. |
| 10:25 | rabeeh | CuBox-i is always powered on. |
| 10:25 | rabeeh | The idle state can go down to few hundreds of mW |
| 10:26 | jnettlet_ | is that with the imx6 in its "deep sleep" mode? |
| 10:26 | rabeeh | We briefly measured it around 70mA on the 5V power rail |
| 10:26 | rabeeh | are you looking for mobile functionality? |
| 10:27 | rabeeh | of so then the CuBox-i itself is not |
| 10:27 | rabeeh | but the SOM inside CuBox-i is capable of being mobile |
| 10:27 | jnettlet_ | just doing some power calculations |
| 10:27 | Kiranos | I'm a newb at this but how much of the mainstream kernel merges for cubox compatibility will also be used by cubox-i ? |
| 10:28 | jnettlet_ | does the wireless chip you guys use do Wake on Wireless? |
| 10:29 | rabeeh | Kiranos: CuBox and CuBox-i looks exactly the same, mechanical wise but shares much less kernel wise |
| 10:29 | rabeeh | much less. |
| 10:29 | Kiranos | rabeeh: ok thanks |
| 10:29 | rabeeh | jnettlet_: yes. it has that function in some GPIO |
| 10:30 | jnettlet_ | rabeeh: cool. thanks |
| 10:30 | rabeeh | i'm not sure if interesting, again for CuBox since it's DC powered |
| 10:30 | rabeeh | idle for the wireless chip is few mA on the 5V rail (lisetening mode) |
| 10:30 | rabeeh | i know for mobile those mA is a no go; but CuBox is DC powered |
| 10:30 | rabeeh | The SOM we have designed inside CuBox-i supports that though |
| 10:31 | jnettlet_ | sure it is DC powered, but there are lots of battery packs these days :-) |
| 10:32 | ralix | morning |
| 11:01 | rabeeh | hi ralix |
| 11:07 | ralix | Hi rabeeh :) This was an unordinary discussion yesterday, but did not understand everything;) my english is not so good;) |
| 11:07 | ralix | In any case, yesterday I even spotted the finances and if I get back from my business trip I once ordered the CUBOX-i4Pro ... :) |
| 11:08 | rabeeh | ralix: thank you for support CuBox-i |
| 11:08 | rabeeh | which part are you missing from the discussion? |
| 11:08 | ralix | I am so happy with the old box :) Always gladly again ... |
| 11:14 | ralix | the discussion about the kernel and booting |
| 11:17 | rabeeh | oh; let me rephrase |
| 11:17 | rabeeh | i.MX6 has internal bootrom; that you can set it to boot from multiple sources |
| 11:17 | rabeeh | for the CuBox-i it would be set to boot directly from the microSD |
| 11:17 | rabeeh | so no need for internal SPI flash as with the current CuBox |
| 11:33 | ralix | thx rabeeh :) |
| 15:05 | rabeeh | cbxbiker61: mikelangeloz was looking for your .config that you use for your kernels |
| 15:05 | rabeeh | i think he was looking for kernel 3.8 |
| 15:05 | rabeeh | he is developing an audio oriented release and doesn't like my kernel, but your's seems good enough for him |
| 15:11 | mikelangeloz | lol |
| 15:11 | mikelangeloz | nothing personal with the kernel... lol |
| 15:17 | rabeeh | cbxbiker61 is US based; mikelangeloz can you please hang out around here until he is online? |
| 15:17 | dbsx | Just hanging out waiting for a Dove DRM driver |
| 15:18 | mikelangeloz | yeah |
| 15:18 | rabeeh | hi dbsx |
| 15:18 | mikelangeloz | no prob |
| 15:18 | dbsx | hi rabeeh |
| 15:19 | dbsx | -i looks like 4 nice new machines |
| 15:20 | dbsx | Did you think of calling them -i, -i+, -i++ and -i+++ ? |
| 15:22 | mikelangeloz | http://cubox-i.com/products/ |
| 15:22 | mikelangeloz | they are awesome |
| 15:23 | dbsx | Rabeeh what is the heat like on the dual and quad core? |
| 15:27 | wumpus | I also wonder; previous imx6 quad dongles like the gk802 tend to overheat quickly, but the thermal design of the cubox is better isn't it? |
| 15:29 | dbsx | The current CuBox has great thermal properties, I expect the same from Cubox-i. |
| 15:35 | rabeeh | dbsx: you mean the heat on the processor? or outside the box? |
| 15:37 | rabeeh | we are optimizing and measuring that all the time; for now not the toughest benchmark that we are doing reaching something like 37 to 45c on the surfaces |
| 15:38 | rabeeh | by not the toughest i mean 3 processors running memtester on the L1 cache, GPU rendering and consuming lots of DDR bandwidth and gig port running iperf TCP/IP bi-directional |
| 15:38 | rabeeh | we are still looking for the toughest; worst case scenario etc... but we are unable to achieve that yet |
| 15:39 | rabeeh | gk802 thermal is nothing |
| 15:39 | rabeeh | i mean there is no thermal solution over there; you start rendering, it immediately overheats and starts slowing down clocks |
| 15:40 | rabeeh | so, 37c to 45c on the plastic surfaces is a bit warm to translate that to human experience :) |
| 15:40 | rabeeh | The first CuBox to compare was 35c to 42c |
| 15:48 | dbsx | I guess what I would really like to know the ambient temperature the CuBox-i will operate. We get 45C days. |
| 15:49 | dbsx | The CuBox v1 I tested in 45C with no problems. |
| 15:52 | rabeeh | no results for 45c ambient yet |
| 15:52 | rabeeh | btw - for the first CuBox we tested at 60c chambers :) |
| 15:52 | dbsx | wow |
| 15:53 | rabeeh | it's simple thermal design; but brilliant :) |
| 15:53 | rabee | 15:53 * rabeeh brags |
| 15:54 | rabeeh | but really CuBox-i4 was more challenging |
| 15:54 | rabeeh | s/was/is |
| 15:54 | dbsx | As soon as you said brilliant, I knew that it must have been you |
| 15:54 | rabeeh | oh no; not me |
| 15:54 | rabeeh | my team |
| 15:54 | rabeeh | i'm bragging about my team |
| 15:56 | dbsx | wifi seems to be a heat generator. What is the i4 wifi? |
| 15:58 | rabeeh | bcm4329 based |
| 15:58 | rabeeh | when it's idle; it doesn't do much |
| 15:58 | rabeeh | working hard will consume up to 1.5W |
| 15:58 | TrevorH | 15:58 * TrevorH1 sees liquid cooled cuboxes |
| 16:00 | frilled | Hah! We talked about that ;-) |
| 16:00 | rabeeh | hehe |
| 16:00 | rabeeh | mineral oil based :) |
| 16:00 | rabeeh | no need yet. |
| 16:00 | frilled | Nope ;-) |
| 16:00 | frilled | We talked about water ^_^ |
| 16:01 | rabeeh | haha |
| 16:01 | frilled | LOTS of water, actually |
| 16:01 | frilled | brb |
| 16:03 | dbsx | Rabeeh: some time ago you discussed aluminum cases. I always liked that idea. |
| 16:03 | rabeeh | right |
| 16:03 | rabeeh | once we talked about that; it was for consumer not industrial |
| 16:04 | rabeeh | the thing is that if you take the above 45c for plastic, then it's really nothing |
| 16:04 | rabeeh | you will feel a bit warm |
| 16:04 | rabeeh | but 45c on direct aluminum touch would feel uncomfortable |
| 16:05 | otavio | :) |
| 16:05 | rabeeh | so; i doubt that CuBox-i would fit good in aluminum case in the shape of the current cube |
| 16:05 | wolfy | rabeeh: do you happen to know what are the shipping costs for 1*i2-ultra + 1*i1 to Be'er Sheva ? |
| 16:05 | rabeeh | for other shapes with fins, it is diffintely doable |
| 16:06 | rabeeh | Be'er Sheva is free shipping |
| 16:06 | rabeeh | but you need to add VAT |
| 16:06 | jnettlet_ | The original TrimSlice had that problem. Nice cast aluminum body that got heated up by the Tegra2 inside. |
| 16:06 | rabeeh | welcome otavio to #cubox |
| 16:07 | rabeeh | jnettlet_: i wonder if the problem was the metal body or T2? :) |
| 16:07 | jnettlet_ | rabeeh: I think both. |
| 16:08 | jnettlet_ | The new one has a different SOC and a plastic body |
| 16:08 | otavio | :-) |
| 16:08 | rabeeh | otavio is mr. freescale yocto bsp layer; for everyone to know |
| 16:08 | jnettlet_ | otavio: nice to meet you. I was pointed to your kernel on github yesterday. |
| 16:09 | rabeeh | and u-boot |
| 16:09 | rabeeh | and kernel |
| 16:09 | rabeeh | :) |
| 16:10 | otavio | Nice to meet you guys :-) |
| 16:10 | otavio | rabeeh: thanks for the introduction :-) |
| 16:11 | otavio | jnettlet_: really? which one? |
| 16:12 | jnettlet_ | otavio: Your yocto layer and the 3.5.7 alpha kernel |
| 16:13 | otavio | jnettlet_: ahh great :-) |
| 16:14 | jnettlet_ | I was poking through your vivante xorg drivers for the imx6 |
| 16:14 | otavio | jnettlet_: :-) The driver is much better now |
| 16:14 | rabeeh | otavio: jnettlet_ is an x olpc dev worked previously on the Marvell MMP2/3 products |
| 16:15 | rabee | 16:15 * rabeeh feels like having a house party introducing one to each other |
| 16:15 | jnettlet_ | otavio: vivante gave me a sneak preview of that driver end of last year. |
| 16:16 | jnettlet_ | it is getting better. Have you tried it with Wayland yet? |
| 16:19 | dv_ | oh hi otavio |
| 16:20 | dv_ | I have seen official freescale docs for wayland |
| 16:20 | otavio | jnettlet_: Wayland, not yet. We did get fb, directfb and x11 OK. I will be working in Wayland next days |
| 16:22 | jnettlet_ | otavio: will be interested in your results. |
| 16:24 | dv_ | otavio: remember the thing I wrote in the mail, about the IPU header being in the kernel directory? |
| 16:24 | otavio | dv_: yes, I do |
| 16:24 | dv_ | it would be helpful to ask freescale about this |
| 16:24 | dv_ | whether or not it is OK to copy it to userspace |
| 16:24 | otavio | dv_: did you find the info I pointed to you? |
| 16:25 | otavio | dv_: I can answer it in some hours; I will call someone ;-) |
| 16:25 | dv_ | info? |
| 16:25 | otavio | dv_: the way to do it in Yocto |
| 16:25 | dv_ | yes, but I do not know if this is okay |
| 16:25 | dv_ | or if this header is supposed to stay in the kernel |
| 16:26 | dv_ | if it has to remain in the kernel, it would be necessary to know how userspace is supposed to use the imx6 IPU then. the ipu-lib cannot be used for imx6.. |
| 16:34 | dv_ | oh, and rabeeh, can we get some sort of cubox or solidrun logo for the yocto splash screen? |
| 16:34 | rabeeh | dv_: with transparency? |
| 16:34 | rabeeh | which resolution? |
| 16:35 | dv_ | I'll look |
| 16:36 | dv_ | seems to be variable |
| 16:36 | dv_ | the default one has 640x480 pixels and uses RGB |
| 16:36 | dv_ | (24 bit) |
| 16:37 | dv_ | the raspberry pi one has 570x720 pixels and uses 32bit RGBA |
| 16:37 | dv_ | its just a bit C header: https://github.com/djwillis/meta-raspberrypi/blob/master/recipes-core/psplash/files/psplash-raspberrypi-img.h |
| 16:37 | dv_ | *big |
| 16:47 | otavio | rabeeh: send us it in svg |
| 16:47 | otavio | rabeeh: so we make it ;-) |
| 16:49 | otavio | rabeeh: will use it for U-Boot splash as well |
| 17:14 | rabeeh | we will |
| 17:14 | rabeeh | i asked IT to prepare one |
| 19:20 | otavio | dv_: I talked to the guy at FSL |
| 19:20 | otavio | dv_: and you do need the kernel headers; there's no userlevel lib |
| 19:21 | otavio | dv_: /BUT/ I'd add a lib for it |
| 19:22 | otavio | dv_: I would make a header or something with macros so it would make the kernel calls; and it easy if they 'reinvent the wheel' and make another way for it |
| 19:24 | dv_ | ah |
| 19:24 | dv_ | perhaps we can then upstream this to FSL? |
| 19:24 | dv_ | I mean, the header with macros |
| 19:24 | dv_ | so they can add remarks etc. |
| 19:41 | otavio | dv_: We can add it in github/freescale |
| 19:41 | otavio | dv_: and have it working across chips |
| 19:41 | otavio | dv_: I'd use macros to not include overhead |
| 19:41 | dv_ | yeah |
| 19:41 | otavio | dv_: but a lib also works |
| 19:42 | otavio | dv_: but it should like, at either case, as a lib |
| 19:42 | dv_ | ideally this would be part of the imx-lib |
| 19:42 | otavio | avoid capital case names and like |
| 19:42 | otavio | dv_: imx-lib will change in future |
| 19:42 | otavio | dv_: and libvpu will be out of it |
| 19:42 | dv_ | oh? any details available? |
| 19:43 | dv_ | interesting |
| 19:43 | otavio | dv_: no, sorry |
| 19:43 | dv_ | I hope to see dmabuf support in it one day |
| 19:43 | dv_ | and no longer the buffer registration stuff |
| 19:43 | otavio | dv_: the memory allocator stuff you were talking about other day? |
| 19:43 | dv_ | yes |
| 19:44 | otavio | dv_: if you send me an e-mail detailing all you need, I can try to forward it ;-) |
| 19:44 | dv_ | alright |
| 19:44 | dv_ | also ask eric |
| 19:44 | dv_ | he talked about the contiguous memory allocator |
| 19:44 | otavio | dv_: yes |
| 19:44 | dv_ | alright, will do |
| 19:45 | otavio | dv_: I'd like to start getting this stuff at github |
| 19:45 | dv_ | gotta go now though |
| 19:45 | otavio | np |
| 19:45 | dv_ | ttyl |
| 19:45 | otavio | gn |