| 01:04 | shesselba | rabeeh: regarding mvgbe and u-boot, looks like gbe doesn't like the buffer addresses .. I can enforce pkt send by hand but not with the addresses that get set up with mvgbe |
| 01:05 | shesselba | or cache is not setup correctly |
| 09:43 | JJames | http://wandboard.org/index.php/details |
| 14:30 | shesselba | rabeeh_: guess I fixed the mvgbe issue |
| 14:30 | janne | rabeeh_: ping |
| 14:32 | rabeeh_ | shesselba: pong |
| 14:32 | rabeeh_ | janne: pong |
| 14:33 | rabeeh_ | shesselba: what was it? buffer alignment? |
| 14:34 | shesselba | dcache |
| 14:34 | janne | rabeeh_: my cubox is finally in Berlin, unfortunately at the customs because it had no invoice |
| 14:35 | shesselba | janne: send them your paypal invoice, you ll be charged ~19% taxes |
| 14:37 | janne | if I had one I could do that |
| 14:37 | Flooo | pong |
| 14:38 | shesselba | in general, if customs can read value _and_ freight costs it is more likely to get through customs without any problem |
| 14:38 | Flooo | oh I'm not rabeeh. sry :x |
| 14:39 | shesselba | janne: you have an invoice? if not, I am sure rabeeh_ can ask CR to send you one again. |
| 14:40 | janne | rabeeh_: I've asked sales@ for a pro forma invoice. that will make dealing with customs easier for me |
| 14:40 | janne | shesselba: no, I don't have an invoice and the customs don't like commercial looking packages declared as gift |
| 14:43 | Flooo | mh. I had no problems with the 'Zoll' but I had no missing invoice.. |
| 14:47 | Flooo | janne: did they explicit tell u it has no invoice? |
| 14:48 | janne | yes |
| 14:52 | Flooo | ok. |
| 14:54 | Flooo | when u login at solid-run and view your orders you can print your invoice there.. isn't that working for you? |
| 14:56 | janne | it is a free sample to implement vmeta support in libavcodec |
| 14:59 | Flooo | ohhh.. now I got it.. it's a gift.. |
| 14:59 | Flooo | sry |
| 14:59 | shesselba | janne: great! one more for the pack.. yeah, international donations are hard to handle.. customs almost always fail here |
| 15:00 | shesselba | maybe it is best to declare it with some fake value and hope that it will slip through |
| 15:01 | rabeeh_ | janne: i'll talk to shipping to handle this. |
| 15:02 | rabeeh_ | shesselba: why dcache is enabled first place? i recall u-boot only uses i-cache only ! |
| 15:02 | janne | it usually works if there is a pro forma invoice. the packet has even the correct value in euro on the customs declaration |
| 15:02 | rabeeh_ | working with dcache is a mess since you will need a page table |
| 15:03 | shesselba | rabeeh_: because I enabled it ;) mainly, because it is enabled in other armv7 archs and kirkwood also. |
| 15:03 | shesselba | I just flipped a define to enable dcache in writethrough, now it works without any forced flushes |
| 15:04 | rabeeh_ | kirkwood is an armv5 arch |
| 15:05 | shesselba | I know |
| 15:05 | rabeeh_ | how is jumping to the kernel being handled? |
| 15:05 | shesselba | but I was looking into kw because mvgbe works there |
| 15:05 | rabeeh_ | dcache disabled before the jump? |
| 15:05 | shesselba | yep |
| 15:06 | shesselba | uups, I just booted into 3.6-rc6 ;) |
| 15:06 | rabeeh_ | working without mmu is much much more easier in u-boot. and there is no performance issues in u-boot since it's main purpose is loading the kernel |
| 15:06 | rabeeh_ | :) |
| 15:06 | shesselba | btw, with 1000Mbps enable |
| 15:06 | shesselba | d |
| 15:06 | rabeeh_ | congrats |
| 15:07 | rabeeh_ | aargh. i envey you |
| 15:07 | rabeeh_ | i wanted to do that port :) |
| 15:07 | shesselba | I have seen your patch to grab mac addr from spi flash ... hehe I guess you are busy enough! |
| 15:07 | rabeeh_ | well.. maybe i'll add the framebuffer support to u-boot and finally get red if the serial port |
| 15:08 | rabeeh_ | yes. patch added yesterday. |
| 15:08 | shesselba | anyway, I ll add the mac addr patch |
| 15:08 | rabeeh_ | we bought mac addresses; and now they can be persistent |
| 15:08 | shesselba | great |
| 15:09 | shesselba | I'd prefer to buy 00:de:ad:be:ef:01 ;) |
| 15:09 | rabeeh_ | i changed the pointer to be at 0x000d0000 from the beginning of the SPI flash |
| 15:09 | rabeeh_ | hehe. |
| 15:09 | rabeeh_ | we bought 00:ba:d0:fa:ce:00 |
| 15:09 | Flooo | :D |
| 15:09 | shesselba | really? |
| 15:10 | shesselba | or just kidding? |
| 15:10 | rabeeh_ | kidding |
| 15:10 | shesselba | dooh |
| 15:10 | shesselba | ;) |
| 15:10 | rabeeh_ | some random combination of numbers. |
| 15:10 | shesselba | ok |
| 15:10 | rabeeh_ | i think the good numbers are kept to Intel and Apple |
| 15:11 | rabeeh_ | it's like car numbers - the good ones are kept for highest end Mercedes |
| 15:11 | shesselba | ah, ok you reduced the size of env and put that mac block after it!? |
| 15:11 | rabeeh_ | car numbers === car licensing plates |
| 15:11 | rabeeh_ | env is still at 0x000c0000 |
| 15:12 | shesselba | yeah, but 64k in size |
| 15:12 | rabeeh_ | yes |
| 15:12 | shesselba | before it was 128k |
| 15:12 | shesselba | wasn't it? |
| 15:12 | rabeeh_ | i think even much more smaller. |
| 15:12 | Flooo | I got 2 questions for you.. |
| 15:12 | rabeeh_ | shoot |
| 15:13 | Flooo | have u ever thought of making a server with the SoC in cubox? |
| 15:13 | rabeeh_ | private cloud style? |
| 15:14 | Flooo | small business |
| 15:14 | rabeeh_ | (i.e. something like hundreds or thousands of CuBoxes connected via Ethernet all in a single cabinet)? |
| 15:14 | Flooo | maybe there's another model supporting more cpu cores? |
| 15:15 | Flooo | and higher frequencies |
| 15:16 | Flooo | I've read a bit about ARM servers in the last days.. maybe it's itersting for you?! |
| 15:16 | rabeeh_ | oh; so you mean something like a single SoC with quad ARM cores? |
| 15:16 | Flooo | yeah, like that |
| 15:17 | shesselba | Armada XP has 4 cores IIRC |
| 15:17 | rabeeh_ | yup. |
| 15:18 | rabeeh_ | Flooo: what is the use case that you think such a platform can be used in small business? |
| 15:19 | rabeeh_ | the usual NAS system, filer etc...? |
| 15:19 | rabeeh_ | or something else? |
| 15:20 | Flooo | I think they could replace the actual big sized, heavy power consuming servers |
| 15:22 | Flooo | associated with a linux distri they could the same jobs as the others |
| 15:22 | Flooo | +do |
| 15:23 | rabeeh_ | Flooo: what was the second issue you had in mind? |
| 15:24 | Flooo | am I right saying there is no open source driver for dove graphics? |
| 15:25 | rabeeh_ | Dove graphics and video are three things - the graphics controller (or LCD controller), Graphics Processing Unit (GPU) and Video Processing Unit |
| 15:26 | rabeeh_ | the first one, graphics controller driver is 100% open source (so called dovefb) |
| 15:26 | rabeeh_ | the GPU (which is GC600 from Vivante inside the Marvell chip) has two drivers; a kernel which is open source and user space which is closed |
| 15:27 | Flooo | is the one in the kernel hardware accelerated? |
| 15:27 | rabeeh_ | the Video Processing Unit (called Vmeta which is an IP developed by Marvell) is respnsible for the HD decoding, and also has two drivers; a kernel part which is open source and user space which is closed |
| 15:29 | Flooo | sry if I'm asking dumb questions :/ |
| 15:30 | rabeeh_ | it's not |
| 15:30 | rabeeh_ | the graphics controller is responsible on getting frames and displaying them. it has hardware acceleeration for scaling and color space conversion. so if you are asking about then the hardware acceleration is there (open source) |
| 15:30 | rabeeh_ | the rest are two parts each; one open and one close. |
| 15:31 | rabeeh_ | the open one is typically just to facilitate the closed source one and it can't be standalone. |
| 15:31 | rabeeh_ | unfortunately there isn't serious GPU and Video engine open source drivers around |
| 15:33 | Flooo | what I was gonna say is: the nouveau project did a great job there.. |
| 15:34 | Flooo | for nvidia cards |
| 15:34 | rabeeh_ | right |
| 15:34 | Flooo | It would be really nice to see that for dove |
| 15:34 | Flooo | :> |
| 15:34 | rabeeh_ | just the right guy enter - jnettlet :) |
| 15:35 | rabeeh_ | jnettlet: we were discussing the GC600 binary drivers; is there an open source alternative for that in the olpc project? |
| 15:35 | jnettlet | rabeeh_, hey sorry I have been MIA. We are waste deep in developing for the MMP3 |
| 15:36 | jnettlet | nope we are still using the binary drivers. I have a version of a DirectFB driver that vivante was supposed to release under a LGPL/BSD dual license. I am still working on getting clearance to release it. |
| 15:51 | jnettlet | rabeeh_, who is looking for OSS GC600 drivers? |
| 15:53 | rabeeh_ | Flooo had questions about that. |
| 15:53 | rabeeh_ | also we had previous requests for directFB friendly drivers. |
| 15:56 | jnettlet | rabeeh_, okay harassing Marvell/Vivante about these drivers again is on my list. They are a limited libGAL HAL driver and a directfb driver. 2D only |
| 16:39 | Flooo | I was just asking about open source drivers with 2d and 3d hw accel |
| 16:39 | Flooo | @jnettlet |
| 16:40 | jnettlet | Flooo, 2d is a possibility, 3d is not looking too good. |
| 16:41 | jnettlet | I am hoping to at least have a decent interface to hook the 3d drivers into my KMS driver like the Exynos chips are doing. |
| 16:44 | Flooo | I was asking because it would be perfect for CuBox to have XBMC running directly on KMS/DRi |
| 16:45 | jnettlet | Flooo, that can still be possible. The binary graphics drivers can create an EGL context on a raw framebuffer. |
| 16:48 | Flooo | but working on fb support was dropped in XBMC if I got that right |
| 16:49 | jnettlet | Oh I have no idea. Do they support directfb? There is driver support for that. |
| 16:50 | Flooo | they only continued with kms/dri as far as I understood |
| 16:52 | jnettlet | Flooo, well I am working hard on my KMS driver but it is not ready to be released yet. Hopefully this month |
| 16:53 | Flooo | don't hurry.. it's just a vision of mine :) |
| 16:55 | Flooo | it's sad that I'm not familar with those things :/ |
| 16:56 | jnettlet | there is always time to learn :-) |
| 16:58 | Flooo | atm it's nearly impossible. on Novembre 1st I start writing my thesis.. |
| 17:47 | janne | hmm, looks like I can wrestle the cubox even without invoice out of customs' hands |
| 18:01 | janne | got it although the customs officer wasvquite sceptical about the description computer |
| 18:02 | Flooo | he didn't believe this can be a computer at this size?? :D |
| 18:03 | Flooo | didn't he.. |
| 18:12 | Flooo | jnettlet: are the drivers currently used hard float capable? |
| 18:16 | jnettlet | Flooo, yes the new drivers are compiled against hardfp |
| 18:16 | Flooo | ok, thx |
| 18:22 | janne | yes, they were |
| 19:40 | Flooo | rabeeh_: r u still there? |
| 20:00 | rabeeh_ | Flooo: pong |
| 20:01 | rabeeh_ | janne: great - so you get the CuBox. |
| 20:01 | rabeeh_ | janne: please let me know what you need? |
| 20:05 | Flooo | rabeeh_: what do you think about the server idea? you didn't say much related to that.. |
| 20:07 | rabeeh_ | Flooo: i think ARM has a chance there. Intel and x86 guys are not sitting around and waiting for this to happen |
| 20:08 | Flooo | Flooo: do you want to be part of that or leave it to nig manufacturers? |
| 20:09 | rabeeh_ | for instance Intel has an edge on the process side; but there is no question if you take same process with the two architectures; ARM beats Intel on performance/power |
| 20:10 | Flooo | *big |
| 20:10 | rabeeh_ | Flooo: part of it ofcourse. timing is different story :) |
| 20:10 | Flooo | :D |
| 20:11 | Flooo | I could imagine to sell support for arm servers with linux.. the market is new and attractive |
| 20:12 | rabeeh_ | Flooo: still there is a big leap ARM must do to get into that area. |
| 20:12 | jnettlet | Marvell has already partnered with HP to produce some large ARM servers. I don't think they have shipped yet though |
| 20:13 | rabeeh_ | hardware wise and software wise. |
| 20:13 | jnettlet | The Enterprise Linux support is very far behind on the ARM architecture. |
| 20:15 | Flooo | jnettlet: right and because of that its attractive to get to know with this arch :> |
| 20:15 | Flooo | in my opinion |
| 20:18 | rabeeh_ | jnettlet: there are two markets actually; server market and cloud market. |
| 20:18 | jnettlet | rabeeh_, sure |
| 20:18 | rabeeh_ | server is too generic and ARM will have issues being there. for Cloud it's a limited number of applications that runs at the end; so porting wise and support would be easier. |
| 20:21 | janne | rabeeh_: yes, seems to work. just booted ubutnu from the sd card. setting up nfs root and compiling a kernel atm |
| 20:22 | jnettlet | janne, it is much faster to cross compile the kernel, if you aren't already |
| 20:22 | Flooo | thats what I wanted to say :P |
| 20:22 | janne | u-boot is in flash? I missed it on the first partition |
| 20:23 | jnettlet | grab the linaro gcc cross-compiler |
| 20:23 | janne | of course I'm cross-compiling, no need for linaro, I'm using gentoo + crossdev |
| 20:24 | rabeeh_ | janne: which kernel are you using? |
| 20:25 | janne | your github kernel |
| 22:38 | rabeeh | janne: my github misses some patches |
| 22:39 | rabeeh | http://www.solid-run.com/mw/index.php/List_of_CuBox_specific_patches#Linux |
| 22:41 | jnettlet | rabeeh, I looked at the gc3184 patches that you had posted. I didn't see any relevant changes other than whitespace |
| 22:42 | jnettlet | and then a small chunk for the new performance counters |
| 22:43 | jnettlet | rabeeh, I have also ported the dovefb xorg driver to the new compat-api.h standard that allows it to run against the 1.13 xorg server |
| 22:44 | janne | I've seen that list, nothing looked particular important. cubox runs from nfs root after my usual problems with u-boot scripts |
| 22:47 | rabeeh | janne: i use the following boot.scr script for nfs+tftp - |
| 22:47 | rabeeh | http://pastebin.com/5U22TVsh |
| 22:48 | rabeeh | janne: also recommended to upgrade to latest u-boot since it now supports tftp better (especially on a fast ethernet links) |
| 22:48 | rabeeh | http://www.solid-run.com/phpbb/viewtopic.php?f=7&t=837 |
| 22:50 | rabeeh | jnettlet: i think those were the important ones for the gc3184 driver - |
| 22:50 | rabeeh | + APIBENCH_INDEX_COMPILER_FRONTEND, |
| 22:50 | rabeeh | + APIBENCH_INDEX_COMPILER_OPTIMIZING, |
| 22:50 | rabeeh | + APIBENCH_INDEX_COMPILER_BACKEND, /* i.e. LINKER */ |
| 22:51 | jnettlet | yeah just for benchmarking. |
| 22:52 | rabeeh | are you familiar how to benchmark the Vivante GPU? |
| 22:53 | rabeeh | shesselba: SolidRun OUI (first 3 octets of the MAC address) is D0-63-B4 |
| 22:53 | janne | I have enough small (and now pretty much useless) micro sd cards to hold boot.scr and uImage |
| 22:53 | rabeeh | you can tftp both boot.scr, uImage and then nfsroot mount the rootfs |
| 22:54 | rabeeh | i typically don't use micro-sd for development |
| 22:54 | rabeeh | oh; which reminds me. |
| 22:54 | rabeeh | are you willing to cross compile libavcodec? or native build? |
| 22:55 | janne | I can understand that, changing the card is a pita, especially with connected hdmi |
| 22:57 | janne | yes, all cross-compiled. my life is too short for native builds on slow target machines |
| 22:57 | rabeeh | hehe |
| 22:57 | rabeeh | ack |
| 22:57 | rabeeh | until i get my quad ARM machine :) |
| 22:58 | N30N | I had SD card problems and had to reinstall ARCH. Now xbmc just gives me a blank screen, Xorg.log has the follow error: |
| 22:58 | N30N | [ 466.474] (EE) dovefb(0): mrvlFencePoolInit: gcoSURF_Construct failed. file mrvl_exa_fence_pool.c, line 38 |
| 22:58 | N30N | [ 466.474] (EE) dovefb(0): XV initialize fence pool fails |
| 22:58 | N30N | There any fixes for this? |
| 22:58 | janne | it will be still slow compared to a quad-core i5/7 |
| 23:00 | rabeeh | janne: please decide - you want to compare against your life span or core i7? :) |
| 23:03 | rabeeh | janne: one pitfall to watch; hardfp vmeta is still not resolved. |
| 23:03 | rabeeh | is your gentoo hardfp or softfp? |
| 23:03 | rabeeh | or the cross compiler. |
| 23:06 | janne | damn, I have both but used hardfp for the cubox |
| 23:07 | N30 | 23:07 * N30N will try switching to the non "patched" kernel then. Apologies for interrupting. |
| 23:09 | rabeeh | janne: sorry for that |
| 23:09 | rabeeh | the vmeta driver is hardfp but we are missing the marvell-ipp package in hardfp format |
| 23:11 | jnettlet | rabeeh, I can provide that for you |
| 23:11 | jnettlet | what pieces do you need? |
| 23:12 | rabeeh | jnettlet: do you have the whole marvell-ipp in hardfp? |
| 23:13 | rabeeh | the only difference between the 510 and 610 is vmeta |
| 23:13 | rabeeh | it should be the same processor and iwmmxt |
| 23:14 | jnettlet | rabeeh, I went through a long support battle with them over this. A chunk of the libraries do not need to be hardfp because they are code that is loaded into the DSP for decoding. |
| 23:14 | rabeeh | which dsp? |
| 23:14 | rabeeh | you mean the iwmmxt part? |
| 23:14 | rabeeh | or the vmeta? |
| 23:15 | jnettlet | the vmeta |
| 23:15 | rabeeh | right |
| 23:15 | janne | does it actually matter, float arguments are seldom in public functions of decoder libraries |
| 23:16 | rabeeh | even the video codecs; i think none uses the floating point at the end; so it's really rebuilding in order to change the ELF header |
| 23:16 | rabeeh | as i recall, only wavelet base decoders uses floating point; the rest are all integer which gets accelerated by integer vector operations (iwmmxt, neon etc...) |
| 23:23 | janne | if they don't use fixed point |
| 23:29 | jnettlet | guys I have to get focused on audio driver work right now. Ping me tomorrow and I will sort through my vmeta stuff. I have vmeta working on hardfp via gstreamer. |
| 23:34 | rabeeh | jnettlet: thanks. |