IRC log of #cubox of Wed 04 Sep 2013. All times are in CEST < Back to index

00:15 dv_ gentlemen, look:
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
08:44 NotRelevant
08:45 Kiranos didnt know about this:
08:45 Kiranos why change website?
08:45 Kiranos wow seems to have been announced yesterday
08:46 NotRelevant
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
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:
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
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
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
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
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 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
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 , 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
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:
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.