03:28 | Coburn | Does anyone know if there's a NAS system that runs on the CuBox? |
03:28 | Coburn | I know I can make my own, but FreeNAS looks interesting... |
03:31 | Coburn | sigh... there goes rabe |
03:31 | Coburn | rabeeh* |
04:55 | dbsx | Coburn: I am suspicious that he is a vampire. Sleeps all day and is awake all night. |
04:55 | Coburn | I would agree with that assumption :) |
04:57 | Coburn | dbsx: Do you know any out-of-box solutions for NAS? |
04:57 | Coburn | For example, a software program that has a web interface and I can manage it via web browser? |
04:57 | Coburn | I can set up SAMBA and everything myself, just that I wonder if it's possible to just deploy a ready-made program and let it rip |
05:00 | Coburn | Hmmm |
05:00 | Coburn | Lazy way out: Use FreeNAS |
05:01 | Coburn | Feed my inner linux penguin way out: Use CuBox + SAMBA |
05:01 | Coburn | Decisions decisions.... |
05:04 | cbxbiker61 | Coburn, some freebsd guys were doing some work with freebsd on sheevaplug, i'm not aware of them working on cubox though |
07:49 | Coburn | Prepped a old 4GB uSD that came with my CuBox (who uses 4GB uSDs anyway?) with a debootstrapped debian and samba |
07:49 | Coburn | setting it up now |
08:05 | undo | it's cold and snowing |
08:08 | undo | i know my salt |
08:12 | undo | nas? |
08:13 | undo | it's very difficult, everything else ;) |
08:21 | undo | imagin thor´s hammer :) |
08:22 | undo | wherever you can |
08:24 | undo | yölnir |
08:25 | undo | on your head or on my solar plexus, phah |
08:28 | undo | s/on/below/ |
08:33 | undo | i&i never say sorry again |
08:41 | undo | dv_, olpc gfx might need olpc kernel too |
08:47 | undo | dv_ is dbsx ? |
08:47 | undo | you can |
08:47 | undo | ggg |
09:00 | undo | dbsx, get better or by boxes and shut up |
09:06 | undo | i've spent some time on this, then you revert before reading!? |
09:08 | undo | well, my english needs correction(s) |
09:10 | undo | it's not my home language, but better than yours |
09:10 | undo | how old are you? |
09:10 | undo | a manager!? i can't believe |
10:48 | rabeeh | Coburn: openmediavault is a good one |
10:48 | rabeeh | where is the vampire? |
11:23 | undo | dbsx is the the only little mess i could see |
11:27 | undo | s/could/have to/ |
11:28 | undo | well, there are bigger problems than a little mess |
11:31 | dbsx | rabeeh: Coburn is looking for silver and a stake, also eating lots of garlic |
11:56 | dv_ | undo: apparently not if I set it to the marvell dove platform mode |
11:56 | dv_ | I'll try out full hdmi today though |
12:15 | undo | i ment dbsx and co, odf course |
12:15 | undo | the whole cangaroo farm |
12:17 | undo | get rich with bitcoins :- ) |
12:19 | undo | first, get a fat cpu, then more. they work for you! |
12:21 | undo | loosers |
12:22 | undo | nice company |
12:27 | undo | spinifex, gg |
12:30 | undo | apropos: i've shot you an email ;) |
12:33 | undo | grr |
12:38 | undo | that's what we want to no in chat channel: Coburn sent an email to his chief dbsx |
12:38 | undo | get lost |
12:45 | undo | erm.. solid-run? do you want me to hire for an up-to-date website? |
12:47 | undo | i'm from vienna, not australia |
12:48 | undo | or srilanka |
12:51 | undo | do i have to blog news each week to keep it updated? |
12:51 | undo | fuck |
12:52 | undo | tweet tweet |
12:54 | undo | so. now i really have alot of friends. |
13:22 | dv_ | rabeeh: confirmed. with a true hdmi monitor, 720p works just fine. so the problems are indeed limited to cases when a dvi connector and a dvi-hdmi cable are used |
13:22 | dv_ | i cannot confirm 1080p yet, since I do not have access to that monitor for a few hours |
14:18 | undo | i confirm that you're headless |
18:08 | rabeeh | dv_: let me explain the internals; the Armada 510 chip framebuffer is connected to an external HDMI phy (which can also be a DVI phy). |
18:09 | rabeeh | The chip framebuffer can do any resolution up to 160MHz (1920x1200@60). The HDMI phy is limited because it wants to transport audio. |
18:09 | rabeeh | If you tell the HDMI phy to be a DVI only without Audio (as I previously sent you), then whatever comes to the phy goes out bypassed without checking anything. |
18:10 | rabeeh | so potentially with DVI any resolution up to 1920x1200 can be supported (TM). |
18:10 | dv_ | but it is untested, right? |
18:10 | rabeeh | it's a feature that wasn't developed; but it's there |
18:11 | dv_ | btw. I just confirmed 1080p |
18:11 | dv_ | (with HDMI) |
18:11 | dv_ | just some minor issue with EXA, but its no showstopper |
18:13 | dv_ | also, if I understand your paste correctly, you start with a predefined 1080p video mode, and tweak that one to whatever you want |
18:21 | rabeeh | no. |
18:21 | rabeeh | you start X, xrandr to any resolution |
18:22 | rabeeh | then the internal framebuffer and the clock generator should be configured; but you would probably see nothing (since HDMI phy) won't accept that config |
18:22 | rabeeh | but regardless the framebuffer is transmitting the data in the requested resolution. |
18:22 | rabeeh | and only afterwards you do this i2ctools mangling on the HDMI phy registers. |
18:22 | dv_ | alright |
18:22 | dv_ | I was just confused by the (e0a0 = 06h) -> select a predefined 1080p60 format line |
18:22 | rabeeh | notice that you must run perioudically 'xset dpms force on' since time to time X goes to sleep (power mode) |
18:23 | dv_ | yes, or pass consoleblank=0 to the kernel |
18:23 | rabeeh | well... NXP claims that any resolution that you want can be further on added to the NXP driver; but that's not easy because of the configuration of the audio stuff in the blanking period |
18:23 | rabeeh | right. |
18:23 | rabeeh | there is also an xorg.conf configuration to disable power management too. |
18:24 | dv_ | its been a while since I used i2c tools |
18:24 | dv_ | (e0a0 = 06h) means I2C address e0a0 data 06h ? |
18:50 | rabeeh | the HDMI phy i2c has page number at the last byte |
18:50 | rabeeh | byte 255 |
18:50 | rabeeh | writing to the byte decides which page you want to work with |
18:52 | dv_ | oh the first byte is the address one, the rest is data |
19:37 | im | hi everyone |
19:38 | im | I'm trying to compile xserver-xorg-video-dove but have some troubles |
19:39 | im | where I can download latest version of xserver-xorg-video-dove? |
20:09 | dv_ | im: 0.1.0 is on the solid-run servers |
20:09 | dv_ | im: there is also a patched one on dev.laptop.org , name is xf86-video-dove |
20:10 | dv_ | im: dev.laptop.org/git/users/jnettlet/xf86-video-dove/ . also, how do you build it? |
20:12 | im | dv_: I'm using xorg-server 1.13.1 |
20:14 | dv_ | well, how are you building the driver? and what are the troubles? |
20:15 | im | dv_: troubles that current dovefb.c not support xorg-server 1.13.1 api |
20:15 | dv_ | ah |
20:15 | im | dv_: for example FBDevCloseScreen(int scrnIndex, ScreenPtr pScreen) |
20:16 | im | dv_: I found patch at http://dev.laptop.org/~jnettlet/0001-dovefb-port-to-compat-api-for-new-server.patch |
20:16 | dv_ | yes, I guess it is related to https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/xf86-video-dove/dovefb-port-to-compat-api-for-new-server.patch |
20:16 | dv_ | I had to create another patch to get autoconf to work properly |
20:17 | dv_ | https://www.dropbox.com/s/r39eicsoi9cqbz7/autoconf-related-fixes.patch <- this one |
20:17 | dv_ | well, the API patch should work, since archlinuxarm uses the very newest xorg server |
20:18 | im | dv_: thanks |
20:18 | dv_ | oh, and do you use the supplied shell script to build, or do you call autoreconf etc. yourself? |
20:19 | dv_ | I mean "build_no_dpkg_env.sh" |
20:19 | im | dv_: currently I'm call autoreconf myself, after succesfull result will write ebuild |
20:20 | dv_ | I am using jnettlets patched driver, and the following cflags: http://pastie.org/7128141 |
20:21 | dv_ | with my configure patch, you can also use newer autotools (AM_CONFIG_HEADER is deprecated) |
20:22 | dv_ | and I guess emerge has something prepared for autotools-based packages? |
20:25 | im | dv:_ yep, for example one of overlays with ebuild for dove https://www.dropbox.com/s/r39eicsoi9cqbz7/autoconf-related-fixes.patch |
20:26 | dv_ | ah, nice |
20:26 | dv_ | you can apply my autotools patch on both the original driver from the solid-run site and on jnettlets version |
20:27 | dv_ | as for the cflags, perhaps the most important is DMRVL_PLATFORM_INFO, it must be 1, this enables support for the dove platform |
20:28 | im | dv_: many thanks :) |
20:28 | dv_ | and last but not least, read this: http://www.solid-run.com/phpbb/viewtopic.php?f=2&t=1225 |
20:29 | im | dv_: what kernel you are use? |
20:29 | dv_ | rabeeh's 3.6.9 kernel |
20:29 | dv_ | note that this one has the galcore module linked in, you dont need to keep it around anymore |
20:33 | im | CONFIG_DOVE_GPU=y ? |
20:36 | dv_ | hmm? |
20:36 | dv_ | the kernel config?= |
20:36 | dv_ | what kernel are you using? |
20:37 | im | I'm using same 3.6.9 |
20:38 | dv_ | check out https://github.com/rabeeh/linux/blob/master/arch/arm/configs/cubox_defconfig |
20:38 | im | so I need to set CONFIG_DOVE_GPU=n |
20:38 | dv_ | no |
20:38 | dv_ | CONFIG_DOVE_GPU=y |
20:38 | dv_ | see the config. it is the exact same one I use |
20:38 | im | ok, I not understud what you mean with " you dont need to keep it around anymore" sorry :) |
20:39 | dv_ | well there is a galcore.ko in one of the packages |
20:39 | dv_ | i think its in these: http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-opengl/ |
20:39 | dv_ | you can safely ignore this module. |
20:41 | im | oh, galcore.ko in zip file :) |
20:41 | dv_ | what version of the graphics libraries do you use? |
20:41 | dv_ | do you use one of these from the link above? |
20:43 | im | I'm downloaded cubox-packages.tar.gz |
20:43 | im | link on cubox wiki on Downloads page |
20:44 | dv_ | and you use the libEGL.so etc. from this one? |
20:44 | im | yep |
20:45 | dv_ | they might not work. do not use the ones from bin/ in the zip file, they didnt work for me at all. |
20:45 | dv_ | the ones from the debian/ folder did. but there are newer ones. |
20:45 | dv_ | http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-opengl/marvell-opengl-hardfp-light.zip (for the .so's) and http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-libgfx/marvell-libgfx-headers-20120713.tar.bz2 (for the headers) |
20:45 | dv_ | these .so's are for hardfp though |
20:46 | im | dv_: thank you :) will try |
20:47 | dv_ | np |
20:47 | dv_ | I am writing yocto recipes for all this, and the various package versions can be really confusing |
20:47 | im | and I'm not yet trying to build xbmc with native vmeta :) |
20:48 | dv_ | I didnt try vmeta yet |
20:48 | dv_ | thats next on my list |
20:48 | dv_ | the xorg driver kept me busy til now... especially this dvi-hdmi issue was very misleading |
20:49 | im | dv_: how you are building packages? I'm build most of packages using qemu-user, but cmake wont build and cmake's projects too |
20:49 | dv_ | qemu-user ? |
20:50 | dv_ | building is done by openembedded's facilities |
20:50 | im | interesting |
20:50 | im | i'm just use gentoo, soo building with qemu-user |
20:50 | dv_ | I adapted some of the packages in the big tarball (cubox-packages.tar.gz), some of them had broken makefiles |
20:51 | im | because cross compiling with gentoo for arm on x86 is nightmare |
20:51 | dv_ | (some of the makefiles in the libgfx samples use LN instead of LD, and LNFLAGS instead of LDFLAGS ... wtf?) |
20:51 | dv_ | hmmm I never tried that |
20:52 | im | dv_: are you tried buildroot? |
20:52 | dv_ | I'll put my stuff on github soon, then you can have a look at it if you want |
20:52 | dv_ | briefly, it never built properly for me |
20:52 | dv_ | and I use yocto/oe at work, so.. |
20:52 | im | dv_: tell me please your nick on github |
20:53 | dv_ | github.com/dv1 |
20:53 | im | ok, thanks :) |
20:53 | dv_ | ignore the current meta-cubox layer repository there. it is just a fork to keep an old layer alive. this old layer didnt work properly for me, so I am writing a new one. |
20:58 | im | dv_: thanks again |
20:58 | im | later |
22:55 | undo | hhieuaath |
22:56 | undo | my naybour .. |
22:57 | undo | toooo lout |
22:57 | undo | s/t/d// |
22:58 | undo | i mean it WAS to loud for my neighbour |
23:00 | undo | and his/her little chi8ldrens |
23:01 | undo | so silence |
23:01 | undo | respect |
23:03 | undo | i go and fear for myself |
23:03 | undo | but.. |
23:03 | undo | silent |
23:04 | undo | i do not want to wake up those tiny littlte angels |
23:05 | undo | amp done |
23:05 | undo | and down |
23:08 | undo | butt.... |
23:08 | undo | i've some time to write silently |
23:08 | undo | for you, my friend |
23:10 | undo | i mean i have a ear for you losers |
23:10 | undo | from cngrlnd |
23:13 | undo | can i help you !? |
23:14 | undo | that's all i need |
23:18 | undo | i do not help any whities from colonial whities |
23:18 | undo | i don't want to |
23:18 | undo | farmer |
23:19 | undo | you don't even know wood and champion |
23:19 | undo | you might thiungik |
23:19 | undo | -op97gzlki-jhdc9oLIP |
23:19 | undo | headless :-) |
23:20 | undo | you are |
23:20 | undo | i'm not your head, baby |
23:21 | undo | you are the worst i ever read of |
23:21 | undo | my rage is contigius |
23:22 | undo | i remember |
23:22 | undo | you fuckin ... |
23:22 | undo | nothin |
23:24 | undo | well, sell |
23:24 | undo | i do not excuse me for anything |
23:25 | undo | you little mess |
23:27 | undo | i whow you the cellar |
23:27 | undo | oops |
23:27 | undo | yocta, win |
23:27 | undo | i want to fuck baby |
23:28 | undo | you're the only mess |
23:31 | undo | woouhh |
23:31 | undo | i fuck you! |
23:31 | undo | s/fuck/fucked/ |
23:32 | undo | baby |
23:33 | undo | did you realise |
23:35 | undo | how muchi love you :) |