| 00:15 | dv_ | gentlemen, look: http://www.geek.com/chips/very-tiny-45-computer-cubox-i-runs-android-and-linux-1569433/ |
| 00:30 | shesselba | dv_: multi-core hype :) |
| 00:35 | dv_ | oh multicore has real benefits |
| 00:35 | dv_ | but I am more excited about the fact that this is an imx6 |
| 00:36 | dv_ | i have been working with these SoCs. pretty nice hardware. |
| 03:12 | DHowett | The cubox-i is somewhat depressing though |
| 03:13 | DHowett | I was going to put together a platform based on the Armada 510 and found the original Cubox only when I was looking for reference implementations. |
| 03:13 | DHowett | I settled on the 510 because of its actual, working gigabit ethernet. |
| 03:14 | DHowett | The -i advertises gige on the freescale but is limited to 470 mbit "due to internal limitations" |
| 03:14 | DHowett | the 510 achieves 1gbit handily here. |
| 03:14 | DHowett | Why the regression, then? |
| 04:36 | cbxbiker61 | the Marvell 510 has the GBit on the chip and is fully implemented, this is uncommon an arm hardware |
| 04:38 | cbxbiker61 | soc's are always full of compromises, for most purposes the imx chip is better than the marvell chip |
| 07:21 | jnettlet_ | With quad-core and esata I think I will finally have a replacement build machine. Will pre-order mine later today. |
| 08:14 | Thor__ | anyone know if theres a dual nic model out of the cube ? |
| 08:29 | Kiranos | its not |
| 08:29 | Kiranos | http://www.solid-run.com/store |
| 08:44 | NotRelevant | http://utilite-computer.com/web/utilite-specifications |
| 08:45 | Kiranos | didnt know about this: http://cubox-i.com/ |
| 08:45 | Kiranos | why change website? |
| 08:45 | Kiranos | wow seems to have been announced yesterday |
| 08:46 | NotRelevant | http://utilite-computer.com/web/utilite-pr-140713 |
| 08:47 | NotRelevant | "zero-screws" |
| 08:47 | NotRelevant | ... an elegant "zero-screws" housing |
| 08:55 | Kiranos | NotRelevant: that is not relevant (pun intended :P ) there are multiple ways of even building your own server to get dual nics, the question was about cubox, I dont see why you post about that here? |
| 09:07 | NotRelevant | Kiranos: what question are you talking about? I think I missed that |
| 09:07 | Kiranos | [08:15:42] anyone know if theres a dual nic model out of the cube ? |
| 09:07 | Kiranos | so why did you post about the link?:) |
| 09:07 | NotRelevant | I joined the channel after that |
| 09:08 | NotRelevant | I just post links to ARM stuff... |
| 09:08 | Kiranos | ok |
| 09:10 | rabeeh | Kiranos / NotRelevant - anyone seen my posts 15m ago? |
| 09:10 | rabeeh | i got disconnected from the channel and i'm not sure if the messages went out |
| 09:10 | NotRelevant | http://server.vijge.net/static/cubox/irclog/201309/cubox-20130904.html |
| 09:10 | Kiranos | I didnt see it |
| 09:11 | NotRelevant | rabeeh: was it important/relevant? :) |
| 09:11 | rabeeh | let me paste back again - |
| 09:12 | rabeeh | as you guys saw yesterday's CuBox-i launch; we are building devs machines |
| 09:12 | rabeeh | so if there are devs that are willing to get their hands dirty we can send them early hardware |
| 09:12 | rabeeh | please send me PM on irc |
| 09:24 | jnettlet_ | rabeeh: have you guys found a reliable source for decent sdhc cards? I just went through my entire collection and found two that had decent performance doing 4Kb random writes. |
| 09:25 | cbxbiker61 | sandisk ultra |
| 09:26 | jnettlet_ | cbxbiker61: yeah I just ordered some for testing. |
| 09:26 | jnettlet_ | but it appears to be certain models |
| 09:27 | cbxbiker61 | yeah, they're the best, i'm using the 32gigs |
| 09:27 | jnettlet_ | I have read you need the version that has 30MB/s in their title |
| 09:29 | tarzeau | when is the cubox going to be available and wouldn't it make a great ltsp client? |
| 09:31 | jnettlet_ | tarzeau: the cubox is available and yes it does. |
| 09:32 | tarzeau | the webpage shows preorder.. |
| 09:32 | jnettlet_ | that is the new cubox |
| 09:32 | tarzeau | i wonder if i could get one in switzerland somehow to check if it works as wanted |
| 09:32 | tarzeau | oh i meant the new cubox the one for about 100$ |
| 09:33 | tarzeau | the current clients we have are around 220$ |
| 09:33 | jnettlet_ | do your displays use HDMI for audio and video? That would be the only limitation. |
| 09:34 | tarzeau | we usually have vga, dvi, but the later screens all have hdmi. |
| 09:34 | tarzeau | hdmi cables are expensive here, but that'd still be cheaper than 220$ |
| 09:35 | tarzeau | and i'd have to create ARM images of the ltsp client, but that's fine |
| 09:36 | jnettlet_ | tarzeau: ideally you would want to change them in a couple of ways. With this hardware it would be optimal to do the video/audio decoding on the ltsp client to take advantage of the hardware decoding |
| 09:36 | jnettlet_ | it would also take some stress off your server's CPU |
| 09:37 | tarzeau | we've got a load balanced cluster of servers. and their cpu is not stressed by the amount of clients but more what the users do (like scientific software) |
| 09:37 | dbsx | so does anyone know what the power input to the cubox-i might be? |
| 09:37 | tarzeau | but yes, if it's able to do hardware decoding, i guess it makes sense to run mplayer and other video stuff, and maybe the browser locally on the client |
| 09:37 | jnettlet_ | I would guess 5volts 2amps |
| 09:39 | dv_ | tarzeau: or gstreamer |
| 09:39 | tarzeau | whatever we used to have alix clients (100mbit, bad video card) then switched to zotac (gbit and nvidia graphics card) |
| 09:39 | dv_ | the browser too. I do not know about firefox, but you can build chrome to use opengl ES for 2d rendering |
| 09:43 | dbsx | just found it on the web sit 5v/2a and 5v/3a |
| 09:43 | jnettlet_ | dv_: is there a gstreamer plugin to do remote decoding? |
| 09:44 | dv_ | what do you mean? you can always sent bitstreams to be decoded over the network |
| 09:44 | tarzea | 09:44 * tarzeau hates firefox, since ever! |
| 09:45 | tarzeau | if only google chrome wouldn't leak so much memory so badly |
| 09:45 | dv_ | it does? never noticed |
| 09:45 | tarzeau | google chrome? ever run it on linux for 7 days? 70 days? |
| 09:45 | dv_ | nope |
| 09:46 | dv_ | this is chromium 29 you are talking about? |
| 09:46 | dv_ | i wouldnt be surprised though. the codebase is *immense*. it would be a miracle if there werent any leaks. |
| 09:47 | jnettlet_ | dv_: I was thinking something a little more transparent than setting up rtp pipelines |
| 09:47 | jnettlet_ | Chrome 28 and 29 are much better. Regardless any modern web browser is going to use as much RAM as you can give it. |
| 09:47 | dv_ | jnettlet_: hmm there is the GDP payloader, which could be considered an alternative to rtp/rtsp |
| 09:48 | dv_ | but what do you want to achieve? |
| 09:51 | jnettlet_ | I was just thinking about something like the chromecast but using gstreamer. |
| 09:52 | jnettlet_ | but my desktop would see the remote renderer as an output |
| 09:53 | dv_ | what do you send to the chromecast? |
| 09:53 | dv_ | HLS? plain http? rtsp? |
| 09:54 | jnettlet_ | chromecast uses webrtc to send xml command streams. The client tells the chromecast what to go out and download and play. |
| 09:54 | dv_ | hmm I think I have seen webrtc plugins for gstreamer somewhere |
| 09:55 | jnettlet_ | so instead of web -> client -> chromecast you get client -> chromecast <- web |
| 09:55 | dv_ | right, here: https://code.google.com/p/kurento/source/checkout?repo=gst-plugins-webrtc |
| 09:55 | rabeeh | jnettlet_: we have a bunch of those |
| 09:55 | jnettlet_ | rabeeh: the chromecasts? |
| 09:55 | rabeeh | but why using microSD if you can use sata drive? |
| 09:55 | dv_ | jnettlet_: gstreamer has plugins for a bunch of transports. just need to decide which one. |
| 09:55 | rabeeh | jnettlet_: microsd |
| 09:56 | rabeeh | i'm reading slow today; sorry but i was overclocked for the last few months :) |
| 09:56 | rabeeh | now you see why |
| 09:56 | jnettlet_ | rabeeh: not just for cubox. You are one of the few platforms that supports eSata |
| 09:56 | jnettlet_ | rabeeh: yeah I understand. New stuff looks excellent. |
| 09:57 | rabeeh | thanks |
| 09:57 | jnettlet_ | good choice straying from Marvell. Unless you are the size of Google it is hard to get their help on things. |
| 09:58 | jnettlet_ | I have updated my thread on the new group that is supporting the OLPC school server to point to your new hardware. With the new pricepoints they should work perfectly for the group. |
| 09:58 | dv_ | plus, freescale docs are much better |
| 09:59 | rabee | 09:59 * rabeeh agrees |
| 10:01 | jnettlet_ | rabeeh: I know it is early but do you have a guestimate for ship dates? |
| 10:01 | dv_ | jnettlet_: you are envisioning a change in the XO's to freescale? |
| 10:02 | rabeeh | end of nov |
| 10:02 | rabeeh | but next week we will send hardware for devs |
| 10:02 | rabeeh | early birds |
| 10:02 | rabeeh | jnettlet_: please PM a shipping address of yours if you want to have it |
| 10:02 | jnettlet_ | dv_: not at all. This is for the School Server which is not an official OLPC product any longer. It is being maintained by a group in Canada. |
| 10:02 | jnettlet_ | rabeeh: will do thanks. |
| 10:03 | jnettlet_ | dv_: the XO-4 will be the existing product for the forseeable future. It still needs lot of polish and Android. |
| 10:04 | rabeeh | we already got some questions on 4GB memory size; i was wondering if this is achievable |
| 10:04 | jnettlet_ | I think you are limited to 3GB |
| 10:04 | rabeeh | hardware wise it's no brainer; but from the kernel and Linux side i think max achievable is 3GB? |
| 10:04 | ralix | morning |
| 10:04 | rabeeh | hi ralix |
| 10:04 | jnettlet_ | hey ralix |
| 10:04 | ralix | CuBox-i4Pro coool |
| 10:05 | ralix | morning rabeeh and jnettlet_ :) |
| 10:06 | suihkulokki | iMX.6 seems to be getting rather popular |
| 10:06 | TrevorH1 | dual ethernet cubox would be a killer product - was hoping there might be one in the new lineup :( |
| 10:06 | ralix | I want to ... I must go check the finances ... Why Germany is still far away, transportation is always expensive;) |
| 10:06 | jnettlet_ | rabeeh: actually Linux should be able to do 4GB, you will only get access to 3.8 of it though. |
| 10:08 | cbxbiker61 | zram swap seems to be working without problem on my arm machines, funny thing is it seems to cause lockups on my i686 machine |
| 10:09 | dv_ | jnettlet_: is PAE available for arm? |
| 10:09 | dv_ | :) |
| 10:09 | rabeeh | TrevorH1: gigs? or fast? |
| 10:09 | dv_ | jnettlet: is PAE available for arm? |
| 10:09 | jnettlet_ | dv_: Nope. That is why ARM64 is such a big deal. |
| 10:09 | dv_ | ah. |
| 10:09 | rabeeh | jnettlet_: sounds like a CuBox-i4ultimate version? |
| 10:09 | rabeeh | LPAE is not available for Cortex-A9 |
| 10:10 | dv_ | but arm64 requires new cores |
| 10:10 | dv_ | perhaps part of an imx7? :) |
| 10:10 | jnettlet_ | LPAE is only A15? |
| 10:10 | rabeeh | :) |
| 10:10 | rabeeh | jnettlet_: let me double check |
| 10:11 | TrevorH1 | rabeeh: you mean there's something other than gigE? |
| 10:11 | dv_ | oh the other nice thing about the switch: cortex + NEON is better supported than the PJ4 with iwmmxt instructions |
| 10:11 | rabeeh | http://lwn.net/Articles/415190/ |
| 10:11 | rabeeh | LPAE is A15 |
| 10:11 | jnettlet_ | dv_: yep |
| 10:12 | dv_ | oh rabeeh, do you have a working u-boot for the cubox-i that can be released? |
| 10:12 | rabeeh | there are other custom implementations like the Marvell Discovery XP that has LPAE supported; but that's a completely custom processor |
| 10:12 | rabeeh | http://us.generation-nt.com/patch-v2-0-9-rm-mvebu-enable-lpae-support-armada-xp-socs-help-210926042.html |
| 10:12 | rabeeh | dv_: u-boot, kernel, buildroot and Android 4.2.2 already working |
| 10:12 | dv_ | with any luck, this is all that has to be added to the meta-fsl-arm openembedded layer to support it |
| 10:13 | rabeeh | i can share later on the bring up effort; most of the stuff already working (and stable) |
| 10:13 | rabeeh | dv_: well.. this is something i really don't know what to do with |
| 10:14 | ralix | Android paaah, wir wollen arch... ;-);-);-) |
| 10:14 | rabeeh | since there are multiple flavors; and i'm using kernel 3.0.35 from fsl i need to build mostly for different board flavors |
| 10:14 | ralix | ups |
| 10:14 | dv_ | fsl is moving to 3.5.7 now |
| 10:14 | ralix | android paaah, we want to arch ... |
| 10:14 | rabeeh | ralix: arch will get early sample boards too |
| 10:14 | rabeeh | pepedog already reached out |
| 10:15 | ralix | :) |
| 10:15 | rabeeh | dv_: so the 3.5.7 has dt support; and i think the best would be u-boot figuring out which board it's being loaded on and then accordingly attached the right dt for the kernel |
| 10:15 | dv_ | I think 3.5.7 is still marked as work-in-progress, but its backed by freescale |
| 10:15 | rabeeh | ralix: if you know arch devs that we willing to port arch to CuBox-i please let them contact us |
| 10:16 | rabeeh | alpha released; but on their support forums they have been promising serious performance upgrade; something related to gpu |
| 10:17 | jnettlet_ | I am focusing most my work on 3.10. That is what KitKat is supposedly using and GKH is making that the lts kernel. |
| 10:18 | dv_ | I guess freescale is busy going through the 2500+ patches on top of 3.0.35 :) |
| 10:20 | jnettlet_ | ouch |
| 10:20 | dv_ | hopefully, their move to 3.5.7 is part of a bigger effort to stay close to mainline as much as possibel |
| 10:24 | rabeeh | http://imx.solid-run.com/forums/viewtopic.php?f=2&t=2#p7 |
| 10:25 | rabeeh | guys what do you think? is it a good move going for new forums and website? |
| 10:27 | cbxbiker61 | rabeeh, well one advantage is that confusion over models will be less with the seperate sites |
| 10:29 | rabeeh | that's what exactly i was thinking about; although they share most of the user space stuff; the kernel and the platform itself is different |
| 10:30 | cbxbiker61 | yes, the people who don't live and breathe arm hardware would be confused |
| 10:31 | jnettlet_ | but you can just group the forums by product. |
| 10:32 | jnettlet_ | Even users should be able to know the difference between the Cubox and Cubox-i |
| 10:36 | rabeeh | another thing i had in my mind is that the current structure of the forums is too hardware / kernel and general thing centric |
| 10:36 | rabeeh | it doesn't really expose the use case, the ideas that can be developed on top, different languages support etc... |
| 10:37 | rabeeh | it's completely understood from devs point of view; but far from end users |
| 10:37 | ralix | I would find it better if the forum is grouped by product |
| 10:37 | cbxbiker61 | maybe you could get a tech-writer sort to look through the existing posts and come up with a new structure |
| 10:37 | rabeeh | cbxbiker61: we had one suggesting a good structure two years ago |
| 10:37 | rabeeh | let me look it up |
| 10:39 | rabeeh | http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=9 |
| 10:39 | jnettlet_ | Having a forum for "Hey look what I did with my cubox" could definitely be cool |
| 10:39 | rabeeh | jnettlet_: The first CuBox was released purely for developers; and all the stuff around it was more for developers |
| 10:39 | jnettlet_ | Yep just like the "Gears" section |
| 10:40 | rabeeh | we want to change this approach to get the creative individuals say their words |
| 10:41 | jnettlet_ | Are you thinking about shipping some Cubox's pre-configured? |
| 10:42 | rabeeh | if someone orders it with sd card; he will get the android 4.2.2 |
| 10:42 | rabeeh | ralix: i know; i want arch too |
| 10:42 | jnettlet_ | is the platform Google certified? |
| 10:42 | rabeeh | but this can change; as get it pre-configured to whatever you want |
| 10:42 | rabeeh | not yet |
| 10:42 | rabeeh | i think we can make it before we ship |
| 10:43 | jnettlet_ | but you are working on it. great! |
| 10:43 | rabeeh | the imaging process this time should be easier |
| 10:43 | rabeeh | cubox-i is actually storage-less internally; it boots directly from micro-sd |
| 10:44 | rabeeh | imaging wise today's method are pretty lame |
| 10:44 | jnettlet_ | as long as you have a reliable micro-sd vendor then that should be good. |
| 10:44 | rabeeh | the send you a complete GB of images to a pre defined micro-SD card |
| 10:45 | jnettlet_ | OLPC went with micro-SD for the XO-1.5 and it was a nightmware to get reliable performance. |
| 10:45 | jnettlet_ | tracked it down to counterfeit cards |
| 10:45 | rabeeh | jnettlet_: f2f looks promising. cbixbiker61 has been playing with it |
| 10:45 | rabeeh | the write side is 2x times |
| 10:46 | rabeeh | but i still don't understand why they get faster results on the read side on large reads |
| 10:46 | rabeeh | i mean reading the i-nodes should be a snap and then ext4 lays out the files on a fresh volume consecutively (optimizing mechanical drives spindle) |
| 10:47 | rabeeh | anyhow; what i was thing is something like the following - |
| 10:47 | jnettlet_ | rabeeh: I just started testing it yesterday. I agree. |
| 10:47 | rabeeh | create some sort of virtual hard drive that logs the write activity; so when an image is sent it's sent as a list of blocks to be written, and their offset |
| 10:47 | cbxbiker61 | i've been using f2fs root filesystem on two cuboxes without problems for a month and a half |
| 10:48 | jnettlet_ | it is the 4K random write speeds that can kill you on a bunch of cards |
| 10:48 | rabeeh | something like a fuse based hard drive |
| 10:49 | rabeeh | so potentially if someone has an image to send it; he uses that virtual drive to log the writes to their place and the end user gets this single file that has both the content and where to write to |
| 10:49 | rabeeh | so, it solves the big 4GB images that has few hundreds of MB actual data; but doesn't solve imaging to different volume sizes |
| 10:50 | dv_ | rabeeh: what u-boot version is flashed on the boxes? |
| 10:50 | rabeeh | maybe f2f has a good volume resizing on the fly |
| 10:50 | rabeeh | the oldy 2009.8 from fsl |
| 10:50 | dv_ | there is support for imx6 in a 2013 uboot |
| 10:50 | rabeeh | one of the things we have done is that kept most of the sabre-sd from muxing point of view |
| 10:50 | jnettlet_ | yeah we cheat for OLPC. We extend the partitions on reboot after imaging if a larger storage medium is found |
| 10:51 | rabeeh | so anything that has sabre-sd support should be easily portable to cubox-i |
| 10:51 | cbxbiker61 | f2fs utils aren't fully developed yet, so i don't think resizing would be easy yet |
| 10:51 | dv_ | you might want to ask otavio about this |
| 10:51 | rabeeh | dv_: u-boot? |
| 10:51 | rabeeh | or f2f? |
| 10:51 | dv_ | u-boot |
| 10:51 | rabeeh | ok. |
| 10:51 | dv_ | but you didnt keep this weird sabre setup where the u-boot image was copied to the first blocks of the sd card, followed by the kernel? |
| 10:52 | dv_ | (which was rather annoying) |
| 10:52 | dv_ | in other words, is it like with the current cubox? |
| 10:52 | rabeeh | dv_: u-boot must be loaded to second block on the sd card |
| 10:52 | rabeeh | it's pre-defined by the chip boot loader |
| 10:52 | rabeeh | afterwards you can do whatever you want with the kernel |
| 10:53 | dv_ | and the uImage? |
| 10:53 | rabeeh | current cubox has internal SPI flash |
| 10:53 | rabeeh | sabre-sd mainly puts uImage as raw image on the sd card after u-boot |
| 10:53 | dv_ | uh wait a minute. I am confused. what is the SPI flash used for then? for a first level bootloader to load u-boot? |
| 10:53 | rabeeh | but you can put it on a file as fat32 / ext2,3,4 or whatever u-boot filesystem support is |
| 10:54 | dv_ | ah good. that I can live with. |
| 10:54 | rabeeh | for cubox? spi flash has u-boot |
| 10:54 | dv_ | okay. so. with the cubox-i , I do have to copy the u-boot image to the second block of the sd card. |
| 10:54 | rabeeh | the internal boot loader inside dove can't boot from sd card; it can boot from spi/sata/nand/pci-e |
| 10:54 | rabeeh | dv_: you do |
| 10:54 | rabeeh | cubox-i doesn't have spi flash |
| 10:54 | dv_ | nono, I am talking about the cubox-i, not the current cubox. |
| 10:55 | rabeeh | you need to copy u-boot into second block. sorry. |
| 10:55 | rabeeh | but this approach is superior. |
| 10:55 | rabeeh | for instance we had infinite issues about teaching people how to unbrick CuBox (i.e. reflashing the spi flash) |
| 10:55 | dv_ | anyway, its okay if I just have to copy u-boot in that special way. the sabre required the uImage to be copied outside of the partitions as well. |
| 10:56 | rabeeh | now it's storage-less internally; everyhing is held on the micro-sd card that can be reflashed on a PC |
| 10:56 | dv_ | that was annoying when we were tweaking kernel configs |
| 10:56 | dv_ | well, it certainly makes it easier to move to a newer u-boot |
| 10:57 | dv_ | which in turn gives us ext4 support and support for uEnv.txt files |
| 10:57 | rabeeh | what are uEnv.txt? |
| 10:57 | rabeeh | env variables inside a file? |
| 10:57 | dv_ | text files containing uboot env vars |
| 10:57 | dv_ | so no uboot-mkimage necessary for boot.scr files anymore |
| 10:57 | rabeeh | aargh.. i hate this even more |
| 10:58 | rabeeh | in my mind CuBox-i should boot the kernel directly |
| 10:58 | rabeeh | for devs it's not good since they change their kernel every few minutes |
| 10:58 | rabeeh | but for end users they want to boot fast. |
| 10:58 | rabeeh | besides that in some of the models there isn't micro-usb for rs-232 access |
| 10:59 | rabeeh | so the choices are either enabling u-boot framebuffers or directly booting a kernel |
| 10:59 | dbsx | I have ordered the 4core to play with, hope I made the right choice. |
| 11:01 | cbxbiker61 | on a slightly different note, i got a nexus 7 quad with 32G, it's an awesome handheld |
| 11:02 | dbsx | I was thinking about getting one biker, worth the money? |
| 11:02 | cbxbiker61 | yeah, it should have a very long service life |
| 11:03 | cbxbiker61 | one reason I went with google is due to the fact that they'll stay on top of updates |
| 11:03 | cbxbiker61 | and then once it falls off their radar, the open source comunity will continue to support it |
| 11:05 | cbxbiker61 | the wireless charging will be nice once someone releases a good base for it |
| 11:09 | dbsx | My spouse wants one, so ... |
| 11:11 | cbxbiker61 | x-mas present |
| 11:14 | cbxbiker61 | new ceo of nokia drives nokia into the shitter...so why not make him the new ceo of microsoft.... microsoft politics make me laugh |
| 11:20 | TrevorH1 | I reckon he was on MS's payroll the entire time with a brief to drive the value of nokia down |
| 11:20 | cbxbiker61 | absolutely |
| 11:21 | cbxbiker61 | they had a new os ready to roll when he stepped in, and the first thing he did was kill it |
| 11:22 | dv505 | for the split in forums/wiki, not so sure about that. Hardware might be different, but there is also a lot of software info on the wiki/forum. This would likely not change that much |
| 11:22 | dv505 | aren't subforums and a wiki namespace a better solution? |
| 11:23 | dbsx | I like the new-it-co-uk forum structure. |
| 11:24 | dbsx | newit.co.uk |
| 11:24 | dbsx | beginners sections |
| 11:28 | _rmk_ | hmm, isn't SPDIF normally spelt S/PDIF? |
| 11:28 | dv_ | yes |
| 11:28 | dv_ | officially, at least |
| 11:29 | dv_ | often, people just leave out the slash |
| 11:29 | _rmk_ | I was meaning rather than SPDI/F :) |
| 11:29 | dv_ | oh never saw that one |
| 11:29 | _rmk_ | its all over the cubox-i site :( |
| 11:30 | dv_ | this is then a typo |
| 11:30 | dv_ | congrats, you found a bug! unfortunately, this is not donald knuth you are talking about, so you wont get a cheque with 2.56 dollars |
| 11:31 | _rmk_ | "Q: Waht is your shipping dates and Delivery times?" |
| 11:31 | _rmk_ | ^^ |
| 11:31 | ljere | Hello, I have a cubieboard2 on which I installed a debian7.1 ARMHF A20 |
| 11:31 | ljere | is it possible to install the nand |
| 11:45 | _rmk_ | rabeeh: the standard kernel does not support direct booting, and the way we're going it won't unless you wrap it with something that gives it all the information it needs like a DT or ATAG structure |
| 11:51 | dbsx | What is involved in outputting sound on CuBox via Bluetooth dongle? (including video sound). Do we have enough kernel support to do this? |
| 11:59 | rabeeh | _rmk_: good catch |
| 12:13 | jnettlet_ | dbsx: for the Cubox-i or the Cubox with a bluetooth dongle? |
| 12:14 | jnettlet_ | really either way you just need to enable the bluetooth stack, with alsa support and then have the supporting userspace packages |
| 12:17 | dbsx | With either -i or --i. I was wondering how much lag there would be with a video. The idea is to watch video with a BT headset. |
| 12:20 | jnettlet_ | dbsx: it used to be horrid. But recent pulseaudio revisions have helped. It is literally the one major thing that keeps me using pulseaudio |
| 12:21 | dbsx | I will give it a shot |
| 12:43 | jnettlet_ | _rmk_: rabeeh: isn't UEFI supposed to fix these issues? I know it isn't 100% a direct kernel boot, but....close enough. |
| 12:47 | _rmk_ | EFI is effectively just another boot loader - one of its jobs is to load the operating system and execute it |
| 12:48 | _rmk_ | and it has ways to communicate system data to the operating system |
| 12:49 | _rmk_ | having a kernel called from the reset vector directly is a completely different kettle of fish - for example, unless the SDRAM has already been initialised (eg, by a secure monitor) then you have to do that. You also have to work out a way to tell the kernel how much RAM there is, or hard code it, or find some way to detect how much RAM is present and tell the kernel |
| 12:52 | _rmk_ | I've had platforms where the boot loader has been a very basic bootp/tftp thing with a hardcoded command line, which has been a problem from time to time |
| 12:52 | _rmk_ | I've also had platforms which have used the kernel as a boot loader (netwinders) which have been better but had their own range of problems (not only technical but also licensing too) |
| 12:53 | _rmk_ | (Nettrom was based on a highly modified linux kernel, but the source was never officially released for it) |
| 12:56 | jnettlet_ | setting ATAG_MEM and loading the kernel into memory is the bare minimum to boot the kernel right? |
| 12:56 | jnettlet_ | the short version of what you just wrote :-) |
| 12:57 | cbxbiker61 | looks like the imx.6 code is here https://community.freescale.com/thread/303342 , you have to register |
| 12:58 | _rmk_ | for non-DT, ATAG_CORE, ATAG_MEM, pointing r2 at the location of those, r1 set to the machine type, maybe setting up a serial port if you want debugging, and calling the kernel. |
| 12:58 | jnettlet_ | I was talking with DT. |
| 13:00 | _rmk_ | with DT, you need to load the DT blob and kernel, set r2 to point at the blob and call the kernel. |
| 13:00 | _rmk_ | again, you may want some device initialisation if you want debug |
| 13:01 | jnettlet_ | sure |
| 13:01 | _rmk_ | also note that if you want suspend/resume, you need to leave some code at the reset vector to do something different on a resume reset |
| 13:01 | jnettlet_ | you can't embed the DT into the kernel? |
| 13:01 | _rmk_ | you can but that's a stop-gap solution for non-DT boot loaders |
| 13:02 | _rmk_ | and it'll try and parse the data at r2 as an ATAG list |
| 13:03 | dv_ | cbxbiker61, what do you mean by "the imx.6 code"? |
| 13:04 | cbxbiker61 | cubox-i video code |
| 13:04 | cbxbiker61 | video acceleration code |
| 13:04 | _rmk_ | that sounds like it's not that open |
| 13:04 | dv_ | ah right. this will probably contain the VPU wrapper and the imx-lib |
| 13:05 | dv_ | _rmk_: its all open except for the VPU firmware |
| 13:05 | _rmk_ | does that mean I can feed it slices, or is it like vmeta and it needs an elementary stream? |
| 13:06 | cbxbiker61 | i haven't looked at the code yet, i'm downloading it now |
| 13:06 | dv_ | so far I have seen it using an elementary stream |
| 13:06 | dv_ | but thats what I cared about. I think there was some sort of manual mode, which could refer to slices |
| 13:07 | dv_ | cbxbiker61: there is the imx-lib, which is a thin layer on top of ioctl's. and there is the vpu wrapper, a more higher level layer, which also abstracts away most imx version differences. |
| 13:07 | dv_ | I didnt download these directly though, since I use openembedded. |
| 13:07 | dv_ | there is meta-fsl-arm . |
| 13:08 | jnettlet_ | dv_: GL_VIV_direct_texture |
| 13:08 | dv_ | jnettlet_: I am writing a sink for this already |
| 13:08 | dv_ | the vivante chip inside the armada could use this too, but well, there is this whole galcore mess |
| 13:09 | jnettlet_ | dv_: yeah yeah I know. I am working on it. I keep getting distracted by real work :-P and real wife |
| 13:09 | dv_ | :) |
| 13:09 | dv_ | _rmk_: btw there is a chance that we could add dmabuf support to these libs |
| 13:12 | jnettlet_ | oh this has the vivante EXA driver that they released to me under NDA earlier this year. |
| 13:12 | dv_ | and these drivers do not need x11 for EGL |
| 13:12 | jnettlet | 13:12 * jnettlet_ wonders if it has gotten any better |
| 13:12 | dv_ | plus they have wayland support |
| 13:13 | jnettlet_ | yeah that is just through EGL I think |
| 13:13 | jnettlet_ | GLESv2 actually |
| 13:13 | dv_ | yes |
| 13:13 | dv_ | well, there is the vivante specific stuff to initialize EGL |
| 13:13 | dv_ | (EGLNativeDisplay, EGLNativeWindow) |
| 13:14 | dv_ | I also recommend to keep an eye on https://github.com/Freescale/meta-fsl-arm/commits/master |
| 13:14 | jnettlet_ | This is the same code they gave to me. Marvell's legal is such a bottleneck |
| 13:15 | dv_ | since there are patches introduced that sometimes are critical |
| 13:16 | jnettlet_ | that guys commit avatar looks like he is coding in some layer of hell. |
| 13:16 | dv_ | :) |
| 13:16 | jnettlet_ | made even better by the name Otavio |
| 13:17 | dv_ | these vivante drivers even come with a libGL |
| 13:17 | dv_ | granted, it is somewhat glitchy, but works fine in fullscreen |
| 13:21 | jnettlet | 13:21 * jnettlet_ is not a big fan of shimming OpenGL to run on GLES hardware |
| 13:21 | dv_ | beats software rendering though |
| 13:23 | jnettlet_ | I am glad SDL2 supports GLESv2 now |
| 13:26 | jnettlet_ | oh freescale has an optimized AAC code also. The open source one is horribly inefficient. |
| 13:30 | dv_ | you mean libfaad? |
| 13:30 | dv_ | yeah that one is slow. I usually use the one from libav. |
| 13:30 | dv_ | the imx6 also has a hardware audio resampler. only for certain sample rates though. |
| 13:31 | dv_ | but 44.1 <-> 48 is covered at least |
| 13:34 | jnettlet_ | I hate the cd for hanging the albatross of 44.1k onto digital audio |
| 13:35 | jnettlet_ | dv_: which platform are you doing your freescale work on? |
| 13:36 | dv_ | the sabre sd dual lite |
| 13:36 | dv_ | here: http://at.farnell.com/freescale-semiconductor/mcimx6q-sdp/eval-i-mx-6-sabre-6quad/dp/2253177?Ntt=MCIMX6Q-SDP |
| 13:36 | dv_ | I dont own it though. I have sometimes more access to it, sometimes less. not exactly pleasant for development.. |
| 13:37 | dv_ | oh this is the quad version in the link. the one I use is a dualcore. otherwise identical. |
| 13:38 | jnettlet_ | sure. |
| 13:44 | dv_ | (I bet the display makes up most of the price) |
| 18:54 | jnettlet_ | samsung unpacked event is starting. I can't wait to see the craziness that ensues this year. |