| 03:04 | _dab_ | _rmk_: are you there? |
| 06:39 | jnettlet | aaahhhh....it is going to be a good day today. |
| 09:53 | _dab_ | _rmk_: oi |
| 10:21 | MikeSeth | I've just realized I could use a cubox as a secure puppet master |
| 10:21 | MikeSeth | configure highly restrictive access, stick it in a safe with a hole in its back |
| 10:21 | MikeSeth | that'd solve like half of my compliance problems |
| 10:37 | heap | hi |
| 10:37 | heap | anybody can take a look - http://imx.solid-run.com/forums/viewtopic.php?f=16&t=541 ? thank |
| 10:37 | heap | still not sure about cuboxpro vs cuboxi |
| 10:38 | MikeSeth | heap: the hardware is there (CAAM) but apparently the linux support for it is currently weak and broken |
| 10:40 | MikeSeth | boundarydevices says the CAAM support in the kernel is functional in 4.1.0 BSP 3.0.35 |
| 10:41 | MikeSeth | heap: https://community.freescale.com/thread/303229 |
| 10:43 | heap | MikeSeth: hi, in cuboxi is CAAM, and in cubox pro is which one? |
| 10:43 | MikeSeth | heap: I have no idea, sorry |
| 10:44 | MikeSeth | jnettlet: the guy with the ethernet phy problem tried different cable/switch combinations and examined the ethernet socket for damage, nada |
| 10:45 | MikeSeth | jnettlet: http://imx.solid-run.com/forums/download/file.php?id=22 |
| 10:46 | heap | MikeSeth: ok thanks |
| 10:47 | heap | does anybody know if there is difference between cuboxpro and cuboxi in the Crypto acceleration? |
| 10:47 | MikeSeth | there certainly is, they are based off entirely different SoCs |
| 10:58 | _rmk | 10:58 * _rmk_ wonders what _dab_ wanted |
| 11:57 | jnettlet | MikeSeth, yeah that looks fine. So it appears to be a software problem. I will have to think about that. |
| 12:10 | _dab_ | _rmk_: I can get uImage to work. Only zImage on 3.13.1 |
| 12:10 | _dab_ | s/can/can't/ |
| 12:12 | jnettlet | _dab_, are you using an appended dtb or specifying one in the your uboot config? |
| 12:13 | _rmk_ | also note that if you build a very large kernel, uboot won't warn you if the address you loaded the dtb at results in the kernel overwriting it |
| 12:13 | _dab_ | appended dtb is the one that no work. |
| 12:14 | _rmk_ | show me the commands you're using to create the uImage from the point where the kernel build completes |
| 12:15 | _dab_ | one minute |
| 12:16 | _dab_ | cat arch/arm/boot/zImage arch/arm/boot/dts/${2} > /tmp/zImage.${1}; mkimage -A arm -O linux -C none -T kernel -a 0x10008000 -e 0x10008000 |
| 12:17 | _dab_ | is that what you wanted? |
| 12:18 | _rmk_ | looks correct to me |
| 12:19 | _dab_ | I cloned it from the cubox build and just changed the -a and -e |
| 12:19 | _dab_ | I have not debugged at all, given zimage works I figured I would charhe onwards with other stuff |
| 12:20 | _dab_ | charge |
| 12:20 | _rmk_ | well, the zImage method is the modern day preferred method :) |
| 12:20 | jnettle | 12:20 * jnettlet +1 |
| 12:21 | jnettlet | uImage really has no value other than that is what many embedded people got used to due to limitations in older versions of u-boot |
| 12:21 | _dab_ | what is annoying is that I find the uboot needs cold restarts. reset or reboot from linux is inconsistent |
| 12:22 | _rmk_ | I've not noticed that, and I do a lot of just typing "reboot; logout" remotely and waiting for it to reboot itself - both on the cubox-i and also the hb |
| 12:24 | jnettlet | there is something there. I haven't narrowed down on it yet. I have a couple of hummingboards that don't reset via the watchdog at all. They go all the way down but don't come back up. |
| 12:24 | _rmk_ | if you did want to debug the uImage problem, then doing those steps (with changing the config, adding printascii and monitoring the serial) would be a good way forward |
| 12:24 | jnettlet | although I haven't tested those with my PFD patch |
| 12:27 | _dab_ | ok, I will get to that. I have a build (or two) and a .config to test first. |
| 12:27 | _dab_ | http://imx.solid-run.com/forums/viewtopic.php?f=8&t=535&p=3325#p3325 |
| 12:27 | _dab_ | and assoc links has some interesting info on uboot |
| 12:29 | _dab_ | Is the default environment setup inherited from freescale or is rabeehs work? |
| 12:31 | jnettlet | in u-boot? |
| 12:32 | heap | based on that http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=634&hilit=crypto+acceleration it looks like there is no speed improvement wiht hw encrypt acceleration ;/ |
| 12:33 | jnettlet | well hw crypto acceleration is as much about offloading the encryption from the CPU as speeding it up. |
| 12:34 | jnettlet | if you have dedicated crypto hardware that performs as well as cpu based encryption then you can do encryption with very little overhead to overall performance of the systme. |
| 12:34 | jnettlet | system |
| 12:35 | heap | yes, but what u mean by crypto hw... or which one |
| 12:35 | heap | still not sure what is most powerful for NAS if old cubox pro or new cuboxi |
| 12:36 | davori | 12:36 * davorin doesn't get why people want to run nas on rpi/cubox/whatever (o; |
| 12:37 | davorin | time to upgrade my home network to 10g with sfp+ switches (o; |
| 12:38 | heap | davorin: because of low power consumption? |
| 12:39 | davorin | that's maybe the only one...and if you can live with lower speeds... |
| 12:39 | davorin | i use my 3 nas for media, backup and software distribution...for several computers.. |
| 12:39 | heap | davorin: for moives/music/ and backup u dont need extra speed.. |
| 12:40 | heap | 3 nas? what nas? |
| 12:40 | davorin | well..i tend to use media from several places at once... |
| 12:40 | davorin | selfbuilt is the best way... |
| 12:40 | davorin | n40l with nas4free on usb stick |
| 12:40 | heap | blah .. its 25w in indle.. |
| 12:40 | heap | w/out hdds |
| 12:41 | davorin | doesn't hurt me (o; |
| 12:41 | heap | its not so green :) |
| 12:41 | davorin | if you want to go green shut down youtube... |
| 12:42 | davorin | nowadays the largest power consumption due to isps forced to upgrade all links to 40gig |
| 12:42 | davorin | and those junipers aren't green at all (o; |
| 12:42 | heap | well if u are fine with 20mb/s data transfer i think cubox is fine solution. |
| 12:42 | _dab_ | jnettlet: yes the env in uboot |
| 12:42 | jnettlet | _dab_, mostly my creation. rabeeh has tweaked a few things for the cubox-i release version. |
| 12:43 | _dab_ | u taking any suggestions for next time you do a default? |
| 12:43 | jnettlet | it is mostly setup for a dev environment, not optimized to boot super fast. |
| 12:44 | jnettlet | _dab_, you can go nuts, but no. I am done with u-boot and am working to move everything to barebox |
| 12:45 | _rmk_ | +1 :) |
| 12:45 | _dab_ | ok. good luck that. |
| 12:45 | _dab_ | with that |
| 12:45 | jnettlet | almost done |
| 12:45 | jnettlet | just need to get my new CBi4p for testing |
| 12:47 | _dab_ | my i4pro is heading to a customer for test and play next (with rmks kernel) |
| 12:51 | _dab_ | jnettlet: I will eagerly await your opinion on the i4. I like the speed. Big change from the old cubox |
| 12:52 | jnettlet | _dab_, oh I have had one already. It is a good box. Besides the additional cores, the real performance win is the 1066Mhz 64-bit DDR3 |
| 12:53 | jnettlet | For multimedia the NEON simd is also very important |
| 12:55 | _dab_ | It shall be interesting to see how it shapes up. Lots of different uses for for an i4 |
| 12:59 | obinou | Hello ! Do you know if the cubox-i2 (delayed until late january) has been shipped already ? |
| 12:59 | obinou | I got the i4 , not the i2 yet |
| 13:01 | heap | _dab_: is there really big speed improvement compare to old cubox? |
| 13:05 | _dab_ | heap: I will do benchmarks next week. Finger feel says it is way quicker. |
| 13:06 | heap | quicker in what?:) well ok, i ll not order the old cubox pro, and wait for the cubox-i |
| 13:13 | dv_ | neon is indeed important |
| 13:13 | dv_ | and I think its support is much better in the cortex-a9 compared to the a8 |
| 13:17 | jnettlet | rockchip just announced the first a12 soc. That is dual-issue NEON out-of-order, vs a9 is in-order |
| 13:18 | jnettlet | the claim is the same efficiency as a9 but greater performance. I am curious what Freescale is working on since they killed the iMX7 |
| 13:23 | jnettlet | _rmk_, are you running irqbalanced on your CBi4p? |
| 13:26 | heap | dv_: whats neon? |
| 13:30 | heap | anyway is there still support/developemnt for the cubox pro or its dead because of -i models? |
| 13:31 | dv_ | neon is a SIMD instruction set for ARM |
| 13:31 | dv_ | as for support, I dont know about solidrun, but in the community, there are some activities going on. scaled back though because the freescale imx has priority |
| 13:32 | _rmk_ | jnettlet: yes, but I need to do some debugging on it |
| 13:33 | heap | dv_: ah ;/ |
| 13:33 | heap | dv_: and this SIMD inst set is good for overal performance? |
| 13:33 | dv_ | heap: jnettlet's and _rmk_'s kernel efforts would be useful for both machines |
| 13:33 | dv_ | yes it is |
| 13:34 | dv_ | neon has been designed for multimedia applications iirc |
| 13:34 | heap | ah so only multimedia |
| 13:34 | dv_ | no, not only multimedia |
| 13:34 | dv_ | but thats one of its primary use cases |
| 13:42 | jnettlet | heap, NEON is like SSE1/2/4 for x86 |
| 13:43 | jnettlet | _rmk_, it looked to me like it wasn't able to move interrupts to other cores. Although that may be designed for power efficiency. |
| 13:44 | _rmk_ | yea, it tries to classify the interrupts according to the driver names, and because of the random nature of driver names, it doesn't always guess correctly |
| 13:45 | _rmk_ | and having the local timer interrupt show up as if it were a normal interrupt doesn't help it either |
| 13:46 | jnettlet | I still need to investigate cpu scheduling options. I am not sure if it is even worth trying to shutdown cores for a power usage point of view. |
| 13:46 | heap | jnettlet: thanks, looks likes it related to 3d things, mainly graphic.. like dv said |
| 13:49 | jnettlet | heap, there is actually a patchset that is floating around for the kernel that uses the NEON extensions to speed things like XOR functionality for the kernel software arid |
| 13:49 | jnettlet | make that raid |
| 13:49 | jnettlet | it can also be faster for certain types of memcpy etc. |
| 13:50 | _rmk_ | another issue is that the irqs need to not sit idle for irqbalance to make decisions |
| 13:50 | _rmk_ | when I'm running it in debug mode here, only the local timer, ethernet and occasionally mmc interrupts do stuff |
| 13:50 | heap | jnettlet: thats cute. |
| 13:51 | heap | i ordered now cuboxpro, so i hope the support and dev for it will not end in meantime. |
| 13:52 | jnettlet | heap, don't worry about that. There is plenty of support for the Dove platform upstream in the kernel. I still work on a platform very similar to Dove. |
| 13:52 | nikitis | Is rabeeh here? |
| 13:52 | _rmk_ | heap: and we're still pushing stuff upstream |
| 13:52 | dv_ | yeah, as said, the current focus is imx, but once it is stabilized, dove should get back more attention again |
| 13:52 | heap | whats dove? |
| 13:52 | dv_ | dove is the platform inside the cuboxpro |
| 13:53 | heap | ah thanks |
| 13:53 | dv_ | also known as armada 510 ... never understood marvell's naming system |
| 13:53 | nikitis | I want to speak to someone who does support for the cubox. |
| 13:53 | _rmk_ | dv: I'm doing both... multitasking between them all :) I won't comment on my scheduling algorithm though :) |
| 13:53 | dv_ | cubox or cubox-i ? |
| 13:54 | dv_ | _rmk_: /dev/urandom scheduling algorithm? :) |
| 13:54 | _rmk_ | ./topic Cubox/Cubox-i/Humming board discussions: please be clear when stating Cubox which model you are referring to. |
| 13:55 | _rmk_ | dv_: yea... especially as I spent most of yesterday hacking on a hybrid-8 derivated ircd for another network :) |
| 13:55 | _rmk_ | derived |
| 13:55 | dv_ | heh |
| 13:56 | dv_ | I'm also involved in a million things. funny how this eventually comes to be |
| 13:57 | _rmk_ | that kind of fell to me when I realised that the ircd was getting on for more than 10 years old and apart from one bug fix, hadn't been touched |
| 13:57 | _rmk_ | and since I run 50% of the servers there (one in the UK and one in canada)... |
| 13:57 | _rmk_ | well, technically more than that at the moment because I also have one test server running on ARM hardware here :) |
| 13:58 | dv_ | oh :) |
| 13:58 | dv_ | btw are you familiar with the math behind fourier transforms, dct etc.? |
| 13:58 | nikitis | Is rabeeh on? |
| 13:59 | _rmk_ | dv: I /should/ be, because I was taught all that at uni, but that was 20 odd years ago and I've not used that stuff very much since. |
| 13:59 | MikeSeth | nikitis: ask your questions here |
| 14:00 | dv_ | _rmk_: something that occurred to me the other day, since you are an ARM wizard. you know the opus codec? it is missing DCT and FFT arm optimizations. existing ones cannot be easily used, because opus uses nonstandard window sizes. |
| 14:00 | dv_ | if you find the codec interesting, and want to flex your ARM muscles, that would be one possibility |
| 14:00 | _rmk_ | nikitis: it's always a good idea to ask the question you want to ask, and stick around - sometimes people are busy and only see your question after a while... |
| 14:01 | nikitis | My question is, [email protected] is saying they may not replace my broken cubox-i4 Pro which came to me smashed in the mail. And I want to talk to someone about it |
| 14:01 | jnettlet | or ask it on the forums. |
| 14:01 | dv_ | probably not at the moment, because iirc they dont have i4pros in stock |
| 14:01 | dv_ | they sold out pretty quickly apparently |
| 14:02 | _rmk_ | dv: I'll bear that in mind. |
| 14:02 | nikitis | stock wasn't an issue according the mail, they said the mail only covers $35, which isn't the full price, but i don't see how that is my problem |
| 14:02 | dv_ | _rmk_: the rockbox guys have been attempting to do this, but they focus mainly on (very) old ARM cores, not NEON etc. |
| 14:03 | dv_ | oh that sounds weird. |
| 14:03 | nikitis | I'm expecting a full replacement |
| 14:03 | dv_ | yeah, of course |
| 14:03 | dv_ | hm as jnettlet said, the forums may also work |
| 14:04 | _rmk_ | bbl. |
| 14:08 | jnettlet | dv_, are you using the opus codec through libav? |
| 14:12 | nikitis | I get a feeling they don't want to replace my broken one |
| 14:13 | nikitis | i replied to them just now stating that I expect a replacment cubux i4-pro because it was not my fault they did not pay for insurance to pay for the full price of the product. You just can't advertise a product online, take my money, and send me something different. |
| 14:17 | jnettlet | nikitis, we understand your frustation, but this is not the forum to vent on. This is a community irc channel focused on support and development. Please contact SolidRun through their forums or continue your existing email conversation with their support. |
| 14:18 | nikitis | I was more letting MikeSeth know, he helped me out with it a few days ago. |
| 14:24 | MikeSeth | nikitis: I remember, I think that rabeeh may clarify this, also, SolidRun may very well be required by israeli law to replace it, so chances are support made a mistake; but again I do not speak on behalf of SolidRun |
| 14:29 | nikitis | Well that's why I wanted to speak with rabeeh about it. |
| 14:30 | nikitis | I realize there is a complex issue regarding the situation and scarecity of devices, but still I need some guarentee I'm getting a replacement, the email last sent to me was not convincing, and I would hate to have to take drastic measures. |
| 14:30 | dv_ | jnettlet: no, I am using the implementation from opus-codec.org |
| 14:31 | jnettlet | dv_, okay. I know that libav has the best NEON optimizations for DCT and FTT but I wasn't sure if they are used for external codec libraries. |
| 14:32 | dv_ | from what it seems, libav uses the opus-codec.org code as well |
| 14:34 | jnettlet | yes, I was unsure if their DCT FTT neon work integrates with external codec libraries. most likely not but I haven't looked through that code in a while |
| 14:43 | dv_ | well they use the cooley-turkey FFT algorithm, and most implementations implement only radix-2 and radix-4 . but opus also needs radix-3 and 5. |
| 15:47 | rabeeh | nikitis: please discuss this with SolidRun sales contact - [email protected] |
| 15:47 | rabeeh | oh; he is not here :( |
| 15:47 | rabeeh | i'll follow up with him; i'm just reading bottom up |
| 15:48 | rabeeh | MikeSeth: i just had a "** No partition table - mmc 0 **" on the SPL u-boot |
| 15:49 | rabeeh | i'v placed the micro SD on my PC back again and there was no partition table |
| 15:49 | rabeeh | this leads me to two things - 1. either i haven't flashed the card correctly or 2. u-boot SPL somehow overwrites the first MBR partition (it was all zeros) |
| 15:50 | MikeSeth | rabeeh: no, this is card specific |
| 15:50 | MikeSeth | or you're looking at another issue |
| 15:50 | rabeeh | MikeSeth: i'v using also a Transcend 4GB one |
| 15:50 | rabeeh | no no; i'm trying to debug exactly the same issue |
| 15:50 | MikeSeth | in my case the partition table is perfectly readable on the host after having visited u-boot |
| 15:50 | jnettlet | as have I that is what came in my CBi4p |
| 15:51 | rabeeh | this is also another SPL failure - http://fpaste.org/74501/15582701/ |
| 15:51 | MikeSeth | the same card that fails will work perfectly in pre-SPL uboot |
| 15:52 | MikeSeth | rabeeh: data corruption? |
| 15:52 | rabeeh | yes |
| 15:52 | rabeeh | not in my case; someone sent it over |
| 15:53 | rabeeh | unfortunately i'm unable to reproduce any of the SPL issues. |
| 15:53 | MikeSeth | rabeeh: but can you reproduce it with transcend 4gb? |
| 15:54 | rabeeh | i don't know MikeSeth; i'm trying again |
| 15:54 | jnettlet | rabeeh, you might have missed it but my alternate pfd errata fix has helped stabilize _Adik_'s problems with Sandisk sdhc cards. |
| 15:54 | rabeeh | i had a Transcend with partitions; installed to CBi4pro with SPL; it boots to u-boot and failes with the partition table thing |
| 15:55 | MikeSeth | jnettlet: can I have the patch? I'll test it asap |
| 15:55 | rabeeh | now putting that card into the PC shows zero MBR |
| 15:55 | MikeSeth | rabeeh: this zeroing does -not- happen in my case |
| 15:56 | rabeeh | MikeSeth: i'm retrying now again; maybe i did a mistake and there were really no partitions. |
| 15:56 | jnettlet | MikeSeth, the binaries are on my dropbox. hold on. https://dl.dropboxusercontent.com/u/736509/i4pro/u-boot/SPL https://dl.dropboxusercontent.com/u/736509/i4pro/u-boot/u-boot.img |
| 15:56 | MikeSeth | rabeeh: if you want to, I can create an image that 100% reliably fails on transcend and works on sandisk |
| 15:57 | MikeSeth | rabeeh: are you trying the card of the exact type I gave you? |
| 16:00 | rabeeh | yes. |
| 16:00 | rabeeh | but now it's working back again |
| 16:01 | MikeSeth | do you have an -i1 at hand? |
| 16:02 | rabeeh | MikeSeth: guess :) |
| 16:02 | MikeSeth | all other things failing I can come to you with my -i1 and the card |
| 16:02 | rabeeh | want to see my next super computer? |
| 16:02 | MikeSeth | as long as it's not iPhone |
| 16:03 | rabeeh | hold on |
| 16:04 | rabeeh | first - my Transcend card - http://dl.dropboxusercontent.com/u/72661517/IMG_20140205_165745.jpg |
| 16:05 | MikeSeth | looks same |
| 16:09 | rabeeh | my next clustered super computer - http://dl.dropboxusercontent.com/u/72661517/IMG_20140205_170601.jpg |
| 16:10 | rabeeh | i need lots of ethernet wires and switches |
| 16:11 | jnettlet | :-) |
| 16:11 | MikeSeth | is that a 110V supply code on the note on the wall? |
| 16:11 | MikeSeth | ha |
| 16:12 | jnettlet | but do they blend? |
| 16:12 | MarcusVinter | lol MikeSeth, I was reading that |
| 16:12 | jnettlet | that is how we need to get the CBi viral |
| 16:12 | rabeeh | 110v |
| 16:12 | MarcusVinter | And a box of cubox feet that need manually adding. |
| 16:12 | rabeeh | the power supply supports both; it's just the outlet connection |
| 16:13 | rabeeh | there are about 250 CBi4p |
| 16:13 | rabeeh | i wonder how much power they need to run for instance an opencl benchmark? |
| 16:13 | rabeeh | or simulate some protein? |
| 16:13 | MikeSeth | if you took a picture with a better camera I could photoshop some rainbows and unicorns |
| 16:14 | rabee | 16:14 * rabeeh searches for a better camera |
| 16:14 | MikeSeth | don't, I can't actually photoshop :) |
| 16:14 | MarcusVinter | I think we should get a photo tour of the office |
| 16:15 | MarcusVinter | I can lol. Ill do it. |
| 16:15 | MikeSeth | also |
| 16:15 | MikeSeth | you probably should not toy with these photos |
| 16:15 | MikeSeth | imagine all the people on the waiting list who'll see this and be angry about the cubox they haven't yet gotten |
| 16:16 | rabee | 16:16 * rabeeh removing the link |
| 16:16 | jnettle | 16:16 * jnettlet was thinking the same thing |
| 16:16 | rabeeh | but those are going to customers |
| 16:17 | jnettlet | exactly. they should be happy |
| 16:17 | rabeeh | they will go into burn-in test soon and then shipped |
| 16:17 | MikeSeth | I never presumed otherwise :P |
| 16:18 | rabeeh | i hope in a month or so we won't be lagging production wise |
| 16:18 | MikeSeth | rabeeh: mind quick /msg |
| 16:18 | MikeSeth | ? |
| 16:19 | rabeeh | sure |
| 16:20 | rabeeh | btw - just tried on CBi1 and exact Transcend works |
| 16:23 | jnettlet | rabeeh, try the u-boot images I posted above. |
| 16:25 | MikeSeth | rabeeh: are you in the office on fridays? |
| 16:28 | rabeeh | MikeSeth: typically Fridays is with family; Saturday is where i'm more in the office |
| 16:33 | MikeSeth | hmm |
| 16:34 | MikeSeth | I should arrange a sleepover at my cousin's in Nesher and see you on a saturday then |
| 16:34 | rabeeh | that would be great !!! |
| 16:35 | rabeeh | MikeSeth: Android with 512MB is simply a disaster |
| 16:35 | MikeSeth | I submit Android is a disaster in all scenarios |
| 16:36 | rabeeh | why? |
| 16:36 | rabeeh | oh; bug... |
| 16:36 | MikeSeth | hey, let's make an operating system for ubiquitous, low performance, low power devices by making it Java based and inverting the Unix access control scheme |
| 16:36 | rabeeh | it's only left with 311MB out of 512MB; need the gpu_mem thingy |
| 16:37 | MikeSeth | rabeeh: which doesn't work, VPU steals 128Mb |
| 16:37 | rabeeh | yeah; that too |
| 16:37 | rabeeh | probably vpu_mem is required too |
| 16:37 | MikeSeth | I dont think there is one, IIRC its hardcoded in kernel headers |
| 16:37 | rabeeh | there isn't; but i can added |
| 16:38 | MikeSeth | that would be awesome, many people (myself included) are mad about this |
| 16:38 | rabeeh | it's pretty much required; but then i would have to test with xbmc and see what a good value would be |
| 16:38 | MikeSeth | you know what |
| 16:38 | MikeSeth | lemme try doing this |
| 16:38 | rabeeh | which distro are you using? |
| 16:39 | MikeSeth | Debian |
| 16:39 | rabeeh | GB/OE/XB? :) |
| 16:39 | rabeeh | xbmc on Debian? |
| 16:39 | MikeSeth | no, but I have a host of cards so gb etc won't be a problem |
| 16:39 | MikeSeth | also I have a custom vagrant vm for building full debian rootfs |
| 16:39 | MikeSeth | about to publish it |
| 16:40 | MikeSeth | I'll be home in half an hour |
| 16:40 | rabeeh | oh; good |
| 16:40 | MikeSeth | then I'll be able to play with it' |
| 16:40 | rabeeh | please look at mk01 debian packages too |
| 16:41 | hste | rabeeh: Here is sth u can look at :)https://community.freescale.com/docs/DOC-94464#comment-3696 |
| 16:43 | MikeSeth | oh lawdy |
| 16:43 | MikeSeth | rabeeh: will do |
| 16:43 | dv_ | ah btw rabeeh, in case you missed it, cubox-i support is now merged into the meta-fsl-arm-extra OE layer |
| 16:44 | rabeeh | nice |
| 16:44 | rabeeh | dv_: seen it :) |
| 16:44 | dv_ | with SPL, so all models including HB are supported |
| 16:44 | rabeeh | \o/ |
| 16:48 | jnettlet | dv_, I thought SPL was rejected? |
| 16:48 | dv_ | they agreed to the u-boot fork |
| 16:49 | jnettlet | unbelievable |
| 16:49 | dv_ | it shouldnt be a permanent solution though |
| 16:49 | dv_ | so, a 2014.01 uboot or better yet barebox would be better |
| 16:49 | jnettlet | nope, dump u-boot asap |
| 16:49 | rabeeh | jnettlet: my expectations from u-boot are quite low |
| 16:49 | rabeeh | just load the damn uImage and run it |
| 16:49 | jnettlet | right now the earliest SPL would make it into u-boot would be 2014.04 |
| 16:50 | dv_ | see http://freescale.github.io/doc/release-notes/1.5/ |
| 16:50 | dv_ | there is a list of machines using barebox |
| 16:50 | rabeeh | the only thing i would really like from upstream is f2fs, btrfs and other fs support; but nothing beyond that |
| 16:50 | jnettlet | rabeeh, that is what I am working on. It was slow this week due to Fosdem |
| 16:50 | dv_ | these release notes will be updated in the future, and will include cubox-i notes |
| 16:51 | dv_ | jnettlet: alright, if you require barebox testing, I'm all ears :) |
| 16:53 | jnettlet | dv_, I have to finish the 3.10 kernel then barebox is next. |
| 16:53 | dv_ | okay, same goes for the kernel of course |
| 16:53 | jnettlet | :) |
| 16:55 | dv_ | btw, a guy called philip craig was interested in your work as well, because he stumbled upon the same issue I found regarding missing writecombine mapping |
| 16:55 | dv_ | he's helping me with gstreamer-imx development |
| 16:55 | jnettlet | dv_, I will actually take you up on that soon. I will want you to take a look at _rmk_'s bmm and libbmm and make sure it does what you need for ipu/vpu memory allocations |
| 16:55 | dv_ | just so you know if someone asks you about it |
| 16:55 | dv_ | hmm okay |
| 17:04 | rabeeh | MikeSeth: http://pastebin.com/ZDyGuw0V |
| 17:04 | rabeeh | you can now vpumem=... |
| 17:05 | MikeSeth | ah but I wanted to write the patch! |
| 17:07 | rabeeh | MikeSeth: oh sorry |
| 17:08 | rabeeh | i though you wanted to try it |
| 17:08 | MikeSeth | tis ok |
| 17:08 | MikeSeth | I will try it, going home right now |
| 17:08 | rabeeh | hste: you had somewhere sometime a link for patches that does those allocations differently? |
| 17:08 | MikeSeth | there's no VPU acceleraction in current geexbox/xmbc right? |
| 17:08 | hste | rabeeh: how low can vpumem be set and still be used to sth ?:) |
| 17:08 | rabeeh | ofcourse there is |
| 17:09 | rabeeh | hste: i'm trying this right now |
| 17:09 | MikeSeth | oh |
| 17:09 | MikeSeth | then I need an USB switch |
| 17:09 | rabeeh | gpumem=64M is a must |
| 17:09 | MikeSeth | hrm |
| 17:09 | hste | rabeeh: yes it was someone that had done some patches to set dma etc. don't have the links now |
| 17:23 | dv_ | yes, especially if you want to watch h264 content |
| 17:24 | dv_ | thanks to frame reordering the VPU may require up to 17 frames for decoding. multiply the size of an 1080p frame by 17, and you get the idea |
| 17:33 | MikeSeth | alright, got the switch, let's try it |
| 17:36 | rabeeh | 1080p frame is 2MB; 2x27 = 54MB |
| 17:36 | rabeeh | 1080p frame is 2MB; 2x17 = 34MB which is way smaller than the current 128MB |
| 17:53 | dv_ | yeah, but thats the bare minimum |
| 17:54 | dv_ | there is also potentially a compositor running, videos may be displayed using opengl ES (and the vivante direct textures), XBMC renders everything with GLES etc. |
| 17:54 | dv_ | also, frames may be queued somewhere in the playback pipeline |
| 17:56 | rabeeh | dv_: 64M? |
| 17:57 | rabeeh | or more? |
| 17:57 | dv_ | very hard to say. 64M sounds reasonable. |
| 17:57 | dv_ | 128M if you use more complex pipelines perhaps |
| 18:00 | dv_ | but actually, the best approach would be what jnettlet has been doing with CMA: allow the pool to grow if necessary |
| 18:00 | dv_ | pointless to introduce in the 3.0.35 kernel though, I know |
| 18:01 | dv_ | rabeeh: once some more bugs are ironed out in gstreamer-imx I will try to shift the focus to helping jnettlet and _rmk_ with libbmm & 3.10 kernel testing and OE integration |
| 18:02 | dv_ | perhaps solidrun could eventually move to this 3.10 kernel as the officially supported one? |
| 18:06 | _rmk_ | that's better... irqbalance now does something |
| 18:06 | _rmk_ | it was reading /sys/devices/system/cpu and looking for any entry containing "cpu" |
| 18:07 | _rmk_ | so it thought there were... five CPUs in the cubox-i |
| 18:07 | _rmk_ | and then when it scanned /proc/interrupts, it found four |
| 18:07 | dv_ | heh |
| 18:07 | _rmk_ | so it reset all the interrupt counts |
| 18:07 | _rmk_ | repeat for each cycle of evaluation |
| 18:08 | _rmk_ | I now have ethernet on cpu 0, mmc0 on cpu1, one usb on cpu2, and mmc1 on cpu3 |
| 18:12 | rabeeh | dv_: move to a newer kernel will happen soon |
| 18:15 | dv_ | rabeeh: oh really? which one, the fsl or boundarydevices 3.10 one? |
| 18:20 | jnettle | 18:20 * jnettlet is curious |
| 18:23 | _rmk | 18:23 * _rmk_ rebuilds irqbalance .debs |
| 18:26 | rabeeh | dv_: whatever jnettlet and _rmk_ decides :) |
| 18:27 | jnettlet | oh then both 3.10 and head |
| 18:27 | rabeeh | with 3.0.35 there were no options |
| 18:27 | MikeSeth | rabeeh: the patch works, with reduced memory footprint web browsing on debian is now bearable on -i1 |
| 18:28 | MikeSeth | now I have to find my external HDD and try video in geexbox |
| 18:28 | rabeeh | jnettlet: but even with 3.10 i'm confused with your work vs. fsl |
| 18:28 | rabeeh | (mainly because i haven't touched that at all) |
| 18:29 | rabeeh | well.. maybe this is a good time to explain to me (and maybe all on #cubox) what the heck have you guys cooking :) |
| 18:29 | rabeeh | well.. maybe this is a good time to explain to me (and maybe all on #cubox) what the heck have you guys been cooking :) |
| 18:29 | jnettlet | rabeeh, my work is integrated with fsl. Just instead of using their code as the base, I am using Linaro's code as the base and merging FSL's patches into that tree along with my own and needed backported code. |
| 18:31 | jnettlet | https://plus.google.com/112696520735663897193/posts/VFDY48Jri9K is most of it. |
| 18:31 | jnettlet | I still haven't looked at what needs to be pulled in to run on Android. |
| 18:32 | rabeeh | i'm familiar with that; what i'm actually asking (again because i have looked at any code yet) is how far is it from - http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.17_1.0.0_beta |
| 18:33 | jnettlet | it incorporates all that and more, also omits some things that were buggy or not needed because they were backported from upstream. |
| 18:33 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/irqbalance/ <-- fixed irqbalance daemon, built on ubuntu 12.04.4 |
| 18:34 | MikeSeth | it would be awful nice if all your work could be viewable in one place |
| 18:34 | jnettlet | that should help performance a bit |
| 18:35 | MikeSet | 18:35 * MikeSeth has glued the card reader to the bottom of the table so now he knows when something is being written because his feet blink blue |
| 18:35 | jnettlet | MikeSeth, it is all viewable in one place. On the Internet :-P |
| 18:36 | jnettlet | thank you thank you...I will be here all week |
| 18:36 | dv_ | rabeeh: and _rmk_ is mainlining things |
| 18:37 | dv_ | rabeeh: so jnettlets kernel contains all features in a way that may or may not be possible to upstream, and _rmk_'s kernel over time adapts these features in a way that is possible to mainline |
| 18:37 | dv_ | so over time, _rmk_'s kernel will be the default, and the need for jnettlet's kernel will diminish. but we are not anywhere near that atm |
| 18:38 | rabeeh | so the plan is obvious; Android will be stuck with 3.0.35; everything else moves to jnettlet tree and the heavy gunners uses _rmk_s |
| 18:38 | rabeeh | all agree? |
| 18:38 | jnettlet | rabeeh, I hope to move android support to a branch on 3.10 |
| 18:38 | MikeSeth | android users aren't even people :P |
| 18:39 | jnettlet | but other than that yes that is the plan. |
| 18:39 | rabeeh | the only thing i would be happy for android with new kernel is f2fs support |
| 18:39 | dv_ | as for memory allocation, the plan is to use a modified libbmm that uses the CMA mechanism in the new 3.10 kernel. this is useful for both dove and imx platforms. for dove, the libvmeta was patched to be based on the new libbmm |
| 18:39 | purch | with these 3.10.x kernels we can install latestt ubuntu armhf on cubox-i? |
| 18:39 | jnettlet | rabeeh, I have f2fs support in my kernel |
| 18:39 | rabeeh | having ext4 on micro sd is a bad idea in general (cbxbiker61 had numbers) |
| 18:39 | dv_ | so for vmeta support software does not have to be modified |
| 18:39 | dv_ | for imx the situation is different |
| 18:39 | rabeeh | jnettlet: yeah; i know |
| 18:40 | dv_ | with CMA, the physical memory pool is allowed to grow iirc |
| 18:41 | jnettlet | dv_, well not really. You still allocate X amount of memory at boot, but that memory can be used by other things until the contiguous memory needs to be allocated. Then movable pages are moved around to make room for the contig allocation. |
| 18:41 | dv_ | rabeeh: also, these two new kernels work for both dove and imx |
| 18:41 | dv_ | oh ok, so its the other way round, it can "shrink", that is, be used for other stuff |
| 18:42 | jnettlet | shrink and then be reclaimed |
| 18:42 | dv_ | well thats ok too. then gpumem can be set to a conservative value. |
| 18:42 | jnettlet | that with zswap should help us minimize the need for swap to disk |
| 18:42 | _rmk_ | rabeeh: my focus is purely on "get mainline kernels working better on SolidRun's platforms" |
| 18:42 | rabeeh | i'v seen gpumem=64M is ok on all the cases i have tested |
| 18:43 | rabeeh | _rmk_: and god bless you for that :) |
| 18:43 | _rmk_ | which includes pushing the missing drivers upstream, fixing the design problems as we go |
| 18:44 | rabeeh | _rmk_: there will be a vpu drivers change from the private APIs fsl has to v4l - right? |
| 18:44 | jnettlet | rabeeh, that won't even be needed when we finish migrating to all the latest graphics work. Almost all the buffers get allocated via GEM, galcore just needs enough memory for command queue, event queue, and a few other things |
| 18:44 | jnettlet | 8MB's is probably enough. Everything else is allocated via CMA from the general pool |
| 18:45 | _rmk_ | such as - in the merge window for 3.14, I pushed my component support, which allows things like video and audio stuff to get sorted out in a more generic way (so we're not re-inventing the wheel every time we hit the same multi-component device problem) |
| 18:46 | _rmk_ | rabeeh: I've not looked at FSL's VPU stuff too closely, so I can't comment there... I got as far as noticing that it exposes physical memory addresses into userspace. |
| 18:47 | _rmk_ | rabeeh: and anything which exposes physical addresses into userspace is by definition a security bug, and can't be upstreamed |
| 18:48 | dv_ | true |
| 18:49 | dv_ | I think the only way to mainline this is to turn the VPU into a v4l decoder device |
| 18:49 | rabeeh | so all the pengutronix work on getting the vpu into v4l apis didn't happen yet? |
| 18:49 | dv_ | which is what pengutronix is supposedly trying to do |
| 18:49 | dv_ | we never heard anything |
| 18:49 | dv_ | these guys dont communicate |
| 18:49 | _rmk_ | one reason I've not looked too hard at the VPU stuff is that the kernel DRM drivers don't support overlay scaling yet, which is a real pain for displaying the decoded video |
| 18:50 | dv_ | however, one gstreamer developer has recently submitted a v4l decoder plugin code |
| 18:50 | dv_ | that one looks interesting |
| 18:50 | _rmk_ | dv: there was a bit of discussion at kernel summit about the problems there - and it may be my component stuff has unblocked the problem there |
| 18:52 | _rmk_ | one of the issues brought up was that subsystems such as DRM, ALSA, V4L all want to be presented with a complete "card" and not the individual sub-devices |
| 18:53 | _rmk_ | so, ASoC got around that a long time ago by introducing separate DAIs, codecs and such like, and a way to bind them all together, and once they're all known, handing them off to ALSA |
| 18:53 | _rmk_ | that's great for ALSA, but it's limited to solving just one subsystem... |
| 18:54 | _rmk_ | the result was that the v4l/drm/framebuffer people then ran into the same problem, and tried solving it their own way... a display subsystem |
| 18:56 | _rmk_ | so, the idea behind the component stuff is to solve this problem /once/ and in a common way which everyone can use. |
| 18:57 | _rmk_ | so, I'm hoping that we'll now see movement on sorting out the IPU, get the imx-drm driver out of drivers/staging, and see some of the v4l stuff progressing |
| 18:59 | MikeSeth | hrmk, geexbox doesn't want to mount my USB hard disk |
| 19:02 | _rmk_ | and yes, as jnettlet has said, the point of this is to reduce the amount of code outstanding from mainline, making the delta smaller, and therefore easier to forward port as newer kernel versions appear... |
| 19:05 | _rmk_ | MikeSeth: I'm sorry, but that's something I'm unable to help with since... (a) I don't know how geexbox is setup and (b) I don't know which kernel they're using (certainly a different one to the one I'm looking at) |
| 19:07 | jnettlet | and bring the general userbase up to a more recent kernel that will be stable and receive updates for a couple of years |
| 19:08 | rabeeh | jnettlet and _rmk_: do you have your kernels in github? |
| 19:09 | rabeeh | _rmk_: you were mentioning that a month ago that you will be moving your stuff to github? |
| 19:11 | jnettlet | rabeeh, I do but I am waiting to push my re-org of the latest upstream work and the fsl .17-beta code until I can test it. |
| 19:12 | jnettlet | rabeeh, I wouldn't be adverse to working on a community github repo. |
| 19:12 | _rmk_ | rabeeh: I don't, because I don't maintain the patches in a stable form - it's more important for me to track progress in the mainline kernel - the cubox-i4 right now is running a derivative of: |
| 19:12 | MikeSeth | _rmk_: I can't even get a root shell on it, it won't switch VTs |
| 19:13 | _rmk_ | Author: Linus Torvalds |
| 19:13 | MikeSeth | never mind networking |
| 19:13 | _rmk_ | Date: Tue Feb 4 12:26:56 2014 -0800 |
| 19:13 | _rmk_ | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs |
| 19:14 | _rmk_ | which is according to http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/ the very latest |
| 19:16 | jnettlet | MikeSeth, did those u-boot binaries I posted help with your SDHC problems? |
| 19:20 | MikeSeth | jnettlet: I haven't tried them yet |
| 19:20 | MikeSeth | geexbox is doing a great job pissing me off |
| 19:21 | jnettlet | MikeSeth, have you tried the other xbmc distro that they just released a beta of? |
| 19:23 | jnettlet | http://openelec.tv/forum/125-solidrun-cubox-i |
| 19:26 | MikeSeth | nope, I need to try a kernel patch on geexbox and literally everything is broken |
| 19:27 | MikeSeth | wont switch VTs, won't mount USB HDD, won't connect to network, mouse is lagging |
| 19:28 | davorin | lagging is also on openelc on intel ... |
| 19:28 | davorin | feels like pointing with a wii ir remote (o; |
| 19:29 | MikeSeth | yeah, probably compiz doing something funny |
| 19:29 | MikeSeth | or just not enough ram |
| 19:29 | davorin | but then again...who uses a mouse to control xbmc when watching movies on a telly |
| 19:29 | davorin | kinect would be it... |
| 19:29 | MikeSeth | ok I need to take a break or I'll get annoyed |
| 19:29 | davorin | jump up/down to switch channels.. |
| 19:30 | davorin | move left/right to control volume |
| 19:30 | davorin | is there a distro with gpu/vpu libs and headers built-in? |
| 19:34 | dv_ | _rmk_: interesting, this does make sense |
| 19:34 | dv_ | _rmk_: clearly defined components would indeed help a lot |
| 19:35 | MikeSeth | ahh piece of crap doesn't like NTFS and is missing the fuse module |
| 19:35 | MikeSeth | goddamnit |
| 19:36 | xraxor | davorin do you want to try xbian? http://imx.solid-run.com/forums/viewtopic.php?f=7&t=528 |
| 19:36 | dv_ | a mainlined VPU module would have to break compatibility however. right now, userspace queries /dev/mxc_cpu to get a base address for the registers, and then touches the VPU registers directly |
| 19:37 | davorin | might give it a go... |
| 19:37 | davorin | so far geexbox works best on i1 |
| 19:37 | davorin | haven't tried latest openelc build though... |
| 20:10 | _rmk_ | dv: one of the issues is that with DT, you describe the hardware itself, rather than supplying information your OS implementation requires |
| 20:10 | _rmk_ | dv: so that rather forces the issue |
| 20:12 | MikeSeth | davorin_away: do you get flicker at 1080p? |
| 20:12 | MikeSeth | on geexbox for -i1 |
| 20:12 | davorin_away | with geex? |
| 20:13 | MikeSeth | the screen blanks momentarily for several seconds |
| 20:13 | davorin_away | nope...clean and smooth h.264 bluray m2ts with all audio streams in it and hd7.1 decoding |
| 20:13 | davorin_away | you're using openelc? |
| 20:13 | davorin_away | openelec |
| 20:14 | MikeSeth | nope, stock geexbox off solidrun wiki |
| 20:14 | davorin_away | aah..i use the one from geexbox.org with make-sdcard thingie |
| 20:14 | davorin_away | 20140116 i think |
| 20:15 | MikeSeth | I dont know if its related to the memory settings I am playing with or my kernel build |
| 20:15 | davorin_away | what video is it? |
| 20:15 | davorin_away | reencoded? |
| 20:15 | davorin_away | i've seen certain problems with mkv containers |
| 20:15 | davorin_away | especially no video playback when there is no audio stream in it for example.. |
| 20:18 | davorin_away | do you see "player is ahead of time" in the logs? |
| 20:18 | MikeSeth | it won't let me have a terminal, maybe there's an option to enable logging and view it externally |
| 20:19 | MikeSeth | otherwise I'll have to figure out how to start it |
| 20:22 | MikeSeth | the movie is mp4 |
| 20:25 | MikeSeth | rabeeh: should vpu memory allocation be related to gpu memory allocation? |
| 20:25 | MikeSeth | I *increase* gpumem and geexbox hangs |
| 20:25 | davorin_away | had that with stock openelec build... |
| 20:26 | davorin_away | crashed when starting a movie..so had to decrease to 64m on i1 |
| 20:26 | davorin_away | apparently openelec used more memory than geex |
| 20:28 | rabeeh | MikeSeth: gpu and vpu are different hardware engines |
| 20:28 | rabeeh | completely unrelated |
| 20:28 | xraxor | davorin_away if you try xbian would let me know how it works on the i1? dev didnt test on it |
| 20:28 | davorin_away | okidoki...will do 2morrow... |
| 20:28 | MikeSeth | rabeeh: gpumem=64M vpumem=128M works; gpumem=64M vpumem=96M hangs; gpumem=16M vpumem=96M works |
| 20:29 | xraxor | thanks :) |
| 20:29 | davorin_awa | 20:29 * davorin_away needs to label all his microsd cards (o; |
| 21:18 | rabeeh | MikeSeth: please explain hangs? |
| 21:18 | rabeeh | consistent hangs? maybe it's different issue unrelated to memory allocation |
| 21:18 | rabeeh | and for gpumem=16M; this is on 1080p? |
| 21:31 | nikitis | Is rabeeh available? |
| 21:36 | xraxor | yes rabeeh is online, you can make your question |
| 21:55 | MikeSeth | rabeeh: as soon as geexbox starts Xorg, it stops responding. I can enable logging and play to find out more |
| 22:00 | MikeSeth | rabeeh: same effect if vpumem < 96M, as far as I can tell |
| 22:03 | rabeeh | nikitis: ping; i'm back |
| 22:05 | rabeeh | hmm... he seems to be offline; i'll PM him |
| 22:05 | davorin_away | hmm..weird...i2 plays fine a h.264 bluray stream..but struggles heavily on sd with mp3 audio |
| 22:13 | davorin_away | s/i2/i1/ |
| 22:19 | dv_ | in what way? cpu usage? stuttering? |
| 22:19 | dv_ | and what are you using for playback? |
| 22:25 | davorin_away | endless buffering... |
| 22:25 | davorin_away | that's on geex |
| 22:28 | rabeeh | davorin_away: h.264 too? |
| 22:29 | davorin_away | with h.264 720x400 |