00:02 | dexter93 | guys, has the original cubox wiki gone down? can't find info for gen1 cubox pro |
02:19 | GoldenAngle | What is this channel about? |
06:54 | aplund | I'm trying to read device registers by mmaping /dev/mem, but this always seems to fail giving SIGBUS when reading from memory. What is the right way to do this? |
06:54 | aplund | oh |
06:54 | aplund | this is for the cubox-i |
07:07 | aplund | hmm.. solved |
07:07 | aplund | you need to read it using a 32bit type or it just returns SIGBUS |
07:07 | aplund | anyway... thanks for all the fish |
10:26 | ralix | morning @all |
10:31 | ralix | i have a problem with my wlan card, since the last kernel update... old cubox : http://pastebin.com/2F2CXLgC i have no idea at the moment :( |
10:54 | rabeeh_ | ralix: check if /lib/firmware/rtlwifi/rtl8712u.bin is there |
10:54 | rabeeh_ | oh |
10:54 | rabeeh_ | i think the issue is that it's not build as module |
10:55 | rabeeh_ | you need to have it as a module and load the kernel module after the the rootfs (that has the firmware) has been mounted |
10:55 | ralix | yes it's there : -rw-r--r-- 1 root root 122328 Oct 23 01:39 /lib/firmware/rtlwifi/rtl8712u.bin |
11:03 | ralix | I have to rebuild the whole kernel? ) Oh, that will go a long build process |
11:03 | ralix | ;) |
11:40 | topi` | rabeeh: I can confirm that the SIM holder pad works now, when I crossed wires 4&6 like jnettleton told me |
11:40 | rabeeh | great !!! |
11:41 | rabeeh | i should send a post about it |
11:41 | topi` | rabeeh: which rev will be getting the fixed pin order for SIM holder? I'm trying to persuade my boss to order more Hummingboards |
11:41 | rabeeh | we have fixed that in a new rev of HB 3.5 |
11:41 | rabeeh | the new rev will be released before the end of Nov. |
11:41 | topi` | I have a full-length mPCIe 3G modem in the half slot so it's a bit unpractical |
11:41 | topi` | but we found a half-height Ericsson 3G module which I'll be trying |
11:42 | rabeeh | i was wondering about certification of those modules |
11:42 | rabeeh | which country will you be using them? |
11:42 | topi` | but the most important thing was to get the modem to work :) |
11:42 | rabeeh | have an exact model number? |
11:42 | topi` | we're based in Finland, but we also have international customers |
11:42 | rabeeh | topi`: i agree - annoying problem |
11:42 | rabeeh | what do you do in such a case?\ |
11:42 | topi` | we got the Ericsson H5321 iirc |
11:43 | topi` | it's a very small module, unfortunately all the 4G modules are full size :( |
11:43 | rabeeh | i'm seeing also M.2 form factor coming along |
11:44 | topi` | is it possible to order a batch of, say, 100 baseboards with the extra USB headers and the HDMI header unpopulated? |
11:44 | topi` | that way a full-size mPCIe 4G modem fits in, we can design a custom case around it, and customers will be happy |
11:44 | rabeeh | yes |
11:44 | rabeeh | i would search harder before doing that |
11:45 | topi` | our use case is basically a tiny network router |
11:45 | rabeeh | because there are ready to use spacers etc... |
11:45 | topi` | but we also want to provide HDMI output if the customer wishes to display video as well |
11:46 | topi` | is the Quad module the only one with heatsink? |
11:46 | topi` | we're going to have to use a Heat spreader, most probably |
11:47 | topi` | we also have a probable need of Industrial temp range components, but not yet |
11:47 | topi` | anyhow, based on my testing, the i.MX6 is a much better choice for a SoC than those chinese cheap ones (like Allwinner) ... I was burned by the total lack of documentation |
11:48 | topi` | I was even able to compile Freescale's video libraries to get hardware video decoding with gstreamer! |
11:48 | topi` | I think Freescale is one of the most decent vendors, from open source point of view |
11:55 | dv__ | heh, true |
11:56 | topi` | the software side of the chinese vendors is just awful, awful |
11:56 | dv_ | do I hear mediatek? :) |
11:56 | topi` | and they only give you windows tooling |
11:56 | topi` | no mediatek, it's even worse |
11:57 | dv_ | worse than mediatek? |
11:57 | dv_ | this is possible? |
11:57 | topi` | I was trying out an Allwinner devel board |
11:57 | bencoh | sounds like hell |
11:57 | topi` | no, mediatek is worse |
11:57 | dv_ | ah |
11:57 | dv_ | see |
11:57 | bencoh | uh, okay :) |
11:57 | topi` | some Allwinners boot a recent Linux just okay |
11:57 | dv_ | mediatek is really incredibly unfathomably awful |
11:57 | topi` | but the vendor documentation is awful |
11:57 | dv_ | but they are really big in the bluray player market |
11:58 | topi` | the lure for $4 quadcore SoC's is strong (like Allwinner A33) but what we would save in BoM, we would pay double in devel costs |
11:58 | dv_ | yeah |
11:58 | dv_ | especially given the shoddy state of the BSPs |
11:58 | bencoh | dv_: do they have mpeg-ts support now ? |
11:58 | topi` | I told my boss, that if we want to go with the Chinese, we need to hire a couple of guys more |
11:58 | bencoh | (be it hw or sw support) |
11:59 | dv_ | bencoh: I think so, but I didnt look further. their code is incredibly bad. |
11:59 | topi` | maybe the Chinese will learn in 5 years time or so... |
11:59 | dv_ | I got some weird collection of scripts and huge kernel patches (several MB) on top ... a 2.6 kernel |
11:59 | topi` | meanwhile, I'll stick with known good vendors, like Freescale |
11:59 | dv_ | oh, and these scripts only worked in a ubuntu 10.04 VM |
12:00 | topi` | there's a Tegra K1 based industrial / devboard coming, maybe that could be something |
12:00 | dv_ | and the patches ... race conditions everywhere, crappy coding style, hacks all over the place .. |
12:01 | dv_ | but that's what you get if you get some code monkeys for minimum wage |
12:01 | topi` | dv_: I have to close my eyes every time I visit chinese made kernel code :/ |
12:01 | topi` | dv_: they say that with enough monkeys typing, one of those will eventually produce Shakespeare's works :) |
12:01 | dv_ | one funny thing was that they confused ALSA and OSS several times |
12:02 | dv_ | "alsa-example.c" . inside: open("/dev/dsp") |
12:02 | bencoh | :D |
12:02 | topi` | maybe they didn't know what a "wrapper" means? |
12:02 | bencoh | somehow it's simpler than wrapping alsa api ;) |
12:02 | dv_ | oh, and as it turned out, neither ALSA nor OSS were actually working. we had to use their own API. |
12:03 | dv_ | freescale may be more expensive, but the sw stack is infinitely better |
12:03 | topi` | dv_: is there a good, comprehensive wiki page for the status of video playback on i.MX6 somewhere? |
12:03 | topi` | particularly gstreamer |
12:03 | dv_ | (they do have problems, but these are generally manageable) |
12:03 | topi` | I think Freescale has a couple of kernel guys who have real linux experience |
12:04 | topi` | that usually helps :) |
12:04 | dv_ | topi`: well. gstreamer 0.10: abandoned, do not use it, fsl wrote plugins for this, but these aren't good (and also abandoned). |
12:04 | dv_ | gstreamer 1.0: there are my plugins (gstreamer-imx). |
12:04 | topi` | dv_: I've got the 0.99 plugins and they seem to work when I compiled imxlib and friends |
12:04 | dv_ | includes VPU based en/decoding , and video sinks based on IPU, PxP, G2D, GLES |
12:05 | dv_ | oh imxlib shouldn't be neccessary anymore |
12:05 | topi` | what kind of a sink is the IPU one? does it just provide colorspace conversion? |
12:05 | dv_ | this was temporary during PxP element development |
12:05 | topi` | I think imxlib was a dependency on compiling the libvpuwhatnot |
12:05 | dv_ | shouldnt be |
12:05 | dv_ | imx-vpu should be the dependency |
12:05 | dv_ | for IPU, G2D, PxP, there is a video transform and a sink element |
12:06 | topi` | ok, so you can also transform video with IPU? |
12:06 | dv_ | the video transform element does csc, scaling, rotation (in 90? steps), and deinterlacing (only the IPU can do that though) |
12:06 | dv_ | with IPU, PxP, and G2D |
12:06 | topi` | do all i.MX6's support IPU? I have a Quad, but we're probably going to use the DualLite |
12:06 | dv_ | iirc yes |
12:07 | topi` | we most probably only need scaling and rotation (if the display is attached in weird angles) |
12:07 | dv_ | the IPU is strangely fickle though with regards to input/output frame resolutions. some combinations work, some dont. |
12:07 | dv_ | then I recommend using G2D or PxP |
12:07 | topi` | oh... maybe padding in software helps? |
12:07 | dv_ | thats not the issue. its about the crop rectangle in the ipu task structure. |
12:08 | dv_ | I already pad frame strides to 8-byte boundaries |
12:08 | dv_ | err, 16-byte |
12:08 | dv_ | also, IPU wont rotate anything larger than 1024x1024 |
12:09 | bencoh | too bad for 720p/1080p :] |
12:09 | dv_ | I was thinking about adding some tile-based mechanism, but thats pretty complex. I have to finish other things first. |
12:09 | bencoh | (that's quite useless, honestly) |
12:10 | dv_ | tbh, if G2D were able to deinterlace, I'd probably ditch the IPU elements |
12:10 | dv_ | but IPU also supports more input/output formats (its output formats are limited to RGB) |
12:11 | bencoh | did you try writing a simple blend deinterlace shader ? |
12:11 | bencoh | might be simpler and visually better |
12:11 | dv_ | as for pxp, its not easy for me to develop for it, since the 3.14 kernel doesnt have pxp support yet, and the only sabre board I have access to is currently in use |
12:11 | dv_ | well, that would require the 3D core |
12:12 | dv_ | part of the reason why I support other sinks is the vastly smaller power consumption |
12:12 | dv_ | a 2D core with shaders would be great :) |
12:13 | bencoh | indeed |
12:14 | dv_ | pxp is interesting for webcams though, since unlike IPU and G2D, it supports Y42B as an input format, and many webcams use that |
12:15 | dv_ | (thats YUV 4:2:2 planar) |
12:30 | topi` | but we can do simple YUV conversions also with NEON |
12:30 | topi` | it's efficient enough, but will of course tie up the cpu |
12:33 | bencoh | hm, same goes for blend deint |
12:33 | bencoh | I wonder how it would perform |
12:37 | dv_ | I wouldnt do anything CPU-based with fullhd videos |
12:38 | dv_ | it makes a huge difference |
12:39 | rabeeh | there is no quad core device in 4$ :) |
12:39 | rabeeh | this thing doesn't exist at all; even not in 1M unit order :) |
12:45 | dv_ | not sure, but I think the mediatek quadcores are close |
12:45 | dv_ | (still, never use mediatek, ever)= |
13:39 | rabeeh | dv-_: i can do the math with you online and show that it's impossible :) |
13:41 | dv-_ | even if its made by a giant whose chips are in more than 200 million devices? |
13:41 | rabeeh | i'm talking about flip chip, quad cortex-a7 with 1MByte L2 cache, gpu, hdmi and DDR controller |
13:41 | rabeeh | but they need to make money |
13:41 | rabeeh | anyhow; doesn't really matter. |
13:41 | dv-_ | note that being a chinese company, they simply dont care about patents and such |
13:42 | dv-_ | btw. funny read: http://www.xda-developers.com/android/have-you-paid-your-linux-kernel-source-license-fee/ |
13:42 | bencoh | oO |
16:59 | kgp | @dv-_>I was evaluating ralink chip to create some embeeded things. (ralink was bought by mediatek)... so now I move to other solutions that are open-source. |
16:59 | kgp | I think you have a cultural difference between software and hardware companies. |
17:00 | kgp | in software open-source is part of the culture now. Many components are open-source. |
17:00 | kgp | But in hardware (ASIC in particular), you have to pay for everything. |
17:00 | kgp | Even stupid things. |
17:01 | kgp | But it will change as hardware/asic will move more and more in the mass market. |
17:02 | kgp | I'm sure you will be able to "print" your own ASIC in a few years as you print your own stuff with a 3d printer. |
22:25 | cbxbiker61 | my printrbot metal should be here by the end of the week, i feel like a little kid that's getting a new toy |