00:06 | ninny | Ok thanks |
00:06 | ninny | is there anything I can do to try and get this working |
00:06 | rmull | Your networking? |
00:06 | ninny | yes |
00:07 | rmull | Sure. Is your interface up? |
00:07 | ninny | should it be working from the get go |
00:07 | rmull | Dunno, depends on your distro |
00:08 | ninny | cubox v2 with ubuntu core |
00:08 | ninny | new from cubox installer |
00:08 | ninny | think eth0 is up |
00:08 | ninny | just booting into it now |
00:08 | rmull | "ip link set eth0 up" should do it |
00:08 | ninny | wife is asleep so can spend an hour or two getting this sorted finally :) |
00:09 | ninny | ok yeah that seems to work |
00:09 | ninny | so how can I get this to work on startup? |
00:10 | ninny | just updating apt-get |
00:11 | rmull | startup stuff is distro-specific, I don't run ubuntu. I can help you get networking up in a generic manner if you want. |
00:12 | ninny | well if you have any hints, you've been incredibly helpful just doing that |
00:13 | ninny | at least I've managed to install nano and ping finally :) |
00:14 | ninny | what would usually be the next step? |
00:16 | rmull | Do you usually acquire a DHCP lease, or do you use static networking? |
00:16 | ninny | dhcp |
00:16 | ninny | well |
00:17 | rmull | If your network does DHCP, you can use a DHCP client like dhclient or dhcpcd or pump |
00:17 | ninny | I tell the router to keep static |
00:17 | rmull | Try dhcpcd eth0 and see what happens |
00:17 | ninny | ok so the link set eth0 that you told me to use is a first time thing, then you setup dhcp from there usually? |
00:17 | rmull | Yep, first need to have the interface up |
00:17 | rmull | Then you can run the DHCP client and see if it can fetch a lease |
00:18 | ninny | no wormy, but I'll install it |
00:18 | rmull | Do you have dhclient? |
00:18 | ninny | quickly should I setup the etc/resolv.conf first? |
00:18 | rmull | Probably can't install if you don't have networking up :P |
00:18 | rmull | You only need resolv.conf if you have a static network config |
00:18 | ninny | ok |
00:18 | rmull | Otherwise it will be managed by your dhcp client |
00:19 | ninny | no I have network with the ip link set eth0 up |
00:19 | ninny | let me install dhcpcd |
00:20 | rmull | You may already have a client installed |
00:21 | rmull | I'd be surprised if you didn't |
00:21 | ninny | dhcpcd.sh: interface eth0 has been configured with new IP=192.168.2.102 |
00:21 | ninny | ace |
00:21 | rmull | Okay, cool - so can you ping some domain name successfully? |
00:22 | ninny | yeah but I could with the other thing you gave me at the start |
00:22 | rmull | oh... |
00:22 | rmull | So then does your apt-get work? |
00:22 | ninny | yeah I just installed dhcpcd with it |
00:22 | ninny | and nano and ping :) |
00:22 | ninny | the first thing you gave me worked |
00:23 | rmull | Oh, that was it? Huh. OKay. |
00:23 | ninny | yeah :) |
00:23 | ninny | luckily |
00:23 | ninny | thanks |
00:23 | ninny | but now I just need it to launch on boot |
00:23 | ninny | so I can setup an init.d script with dhcpcd |
00:23 | ninny | right? |
00:23 | rmull | Depends, I don't know what init system ubuntu uses these days |
00:23 | rmull | So I'll let someone else step in |
00:24 | ninny | no worries I can find that out |
00:24 | ninny | what do you use usually? |
00:24 | rmull | If they use standard initscripts then there's probably one called "networking" or similar |
00:24 | rmull | I use crux |
00:25 | ninny | network-interface |
00:25 | ninny | network-interface-container |
00:25 | ninny | network-interface-security |
00:25 | rmull | sigh |
00:25 | ninny | networking |
00:25 | ninny | in init.d |
00:25 | ninny | I'll have a mess.. |
00:26 | ninny | all seems setup and working enough |
02:44 | dbsx | dmitrijus: rmull: news is that it works with http:// not git:// or https:// |
02:45 | rmull | dbsx: Odd... I used git:// |
03:08 | Coburn | Funny thing |
03:08 | Coburn | Slackware is available for ARM |
03:08 | Coburn | And my linux format DVD has slackware 14 on it |
03:09 | Coburn | I know what I'll be trying out this weekend |
03:11 | dbsx | and slackware has just been voted distro of the year |
03:12 | dbsx | http://www.linuxquestions.org/questions/linux-news-59/2012-linuxquestions-org-members-choice-award-winners-4175448592/ |
03:15 | dbsx | For kernel sources, we have vdorst, rabeeh, xilka, geexbox(XBMC), xilka and moinejf . |
03:15 | dbsx | Each of these service a different need. moinejf has admirable aim of straight up kernel with out of tree marvell drivers. |
03:15 | dbsx | The kernel requirements are for headless, xbmc, xilka and debian based distros (and others). |
03:15 | dbsx | Given the slow cycles thru kernel.org how do we get ONE kernel repo that covers all of the above needs. |
03:15 | dbsx | Methinks SR need to take on the task of repo/patch consolidation (especially with any marvell updates) |
03:16 | dbsx | Add FDT to that |
05:51 | Coburn | true |
05:51 | Coburn | Also |
05:52 | Coburn | CuBox can supposedly do realtime 1080p encoding |
05:52 | Coburn | If so, show me the money. |
05:52 | Coburn | I'm curious to let a DVD Rip get transcoded on the CuBox |
05:53 | Coburn | When I mean "show me the money", I mean, tell me what packages etc I'll need |
05:54 | Coburn | [12:15:36] Methinks SR need to take on the task of repo/patch consolidation (especially with any marvell updates) |
05:54 | Coburn | Ditto. Hire a guy to decidate themselves to that task |
05:54 | Coburn | dedicate* |
05:55 | Coburn | Open Source Hardware Product of the Year (NEW) - Raspberry Pi (79.29%) <- that's rigged |
05:55 | Coburn | Just sayin. :P |
09:47 | shesselba | Coburn: The SoC inside CuBox _cannot_ encode 1080p in real time.. neither it can transcode (decode+encode) it |
09:47 | wumpus | realtime 1080p encoding? I've looked at the vmeta hal library in some detail, but couldn't find much related to encoding |
09:48 | shesselba | plus a DVD is limited to mpeg2 SDTV resolutions, plus why would you want to upscale digital SDTV content to 1080p and re-encode it? |
09:49 | wumpus | maybe the vmeta hw can do encoding with the right microcode, but i'm pretty sure the current sw cannot, there are no venc_ objects... |
09:49 | shesselba | There is no magic "csi-miami-find-the-pixels-that-have-never-been-there" algorithm at all |
09:51 | shesselba | wumpus: I haven't checked vmeta sources yet - does it load a firmware blob? |
09:53 | wumpus | the vmetahal.so loads ucode blobs on demand (looking at the symbols it has dv, h264, jpeg, mpeg2, mpeg4, vc1) |
09:58 | wumpus | my guess is that the chip contains multiple units, each which either require a table to be loaded, or a shader-like microcode... I don't know how much configurability the microcode allows, though.. most video decoding hardware is strictly that, decoding hardware |
10:00 | wumpus | I wonder where coburn read that anyway |
10:02 | shesselba | wumpus: my guess is, it is "just" a vliw core that marvell pimped to get it done.. or I wouldn't be surprised if it is a xscale/pxa type that they added some simd stuff too |
10:02 | shesselba | marvell uses them in virtually _every_ chip they have ;) |
10:04 | wumpus | heh could be :) |
10:05 | wumpus | given some time it'd be possible to find out the ISA, then again, I'm busy enough with the vivante driver right now |
10:05 | shesselba | you are they initiator of etnaviv? |
10:06 | wumpus | yes |
10:06 | shesselba | great stuff! |
10:06 | wumpus | thanks :) |
10:07 | shesselba | I follow your git log - I am working on the external clock generator found on cubox right now (that will provide pixclk to gpu) |
10:07 | shesselba | them I will handle hdmitx |
10:07 | shesselba | _and then_ I'd love to try out etna_viv! |
10:20 | shesselba | wumpus: I am about to get board with Marvell Armada 1500 (88DE3100) - call it the big brother of 88AP510 |
10:21 | shesselba | while Dove is basically Kirkwood+vMeta+GC, A1000 looks like ArmadaXP+vMeta+GC |
10:22 | shesselba | that one has GC1000 and vMeta with encoding capabilities on chip, but that is only from the block diagramm, no further details yet |
10:57 | wumpus | ah yes, the clock for GC is provided externally on most SoC, usually found in /proc/clocks, haven't looked much at that yet as it's kernel domain |
11:01 | wumpus | GC1000 is interesting, I expect some small challenges getting etna_viv to work with that (for example, shader instruction memory is at a different offset) |
11:03 | wumpus | and it also has two pixel pipes |
11:03 | shesselba | wumpus: if it is just a different offset that should be easy to handle, it has some identification registers? |
11:03 | shesselba | ok that is maybe a little more challenging ;) |
11:04 | wumpus | I expect it's pretty easy to handle, afaik all GCxxxx are similar, but I'd have to get my hands on one before I can adapt the code to it |
11:04 | wumpus | yes there's loads of identification registers (see rnndb/common.xml) |
11:05 | shesselba | I do have one now =) |
11:05 | shesselba | but Dove has priority for me atm |
11:06 | wumpus | for me too, I want to get a basic usable driver for gc6xx/gc8xx first then worry about the rest |
11:07 | shesselba | btw, etna_viv will only handle 3d stuff? and requires some drm 2d driver? |
11:14 | wumpus | it currently renders either directly to the frame buffer (/dev/fb0) or an offscreen buffer |
11:14 | wumpus | for that, it doesn't require anything beyond the vivante gpl kernel driver |
11:15 | shesselba | ok but for the long run, there should be an drm kernel driver? |
11:15 | shesselb | 11:15 * shesselba reminds himself to bug rmk about that |
11:17 | wumpus | not necessary to get anything working, but I suppose it could unify memory management and clean up some interfaces |
11:17 | shesselba | ok |
11:18 | wumpus | as for 2d, that can be done using the current kernel driver, quite a lot is known about the 2D engine, but it's not really the focus of my work (I'm mostly interested at fullscreen 3d rendering) |
11:20 | wumpus | I did document the 2d registers in the same style as the rest (see rnndb/state_2d.xml), mostly from the (abandoned) gcx project |
11:21 | wumpus | I think the most pressing reason to change anything kernel space would be to get rid of the 128MB memory hole that's completely reserved for the GPU at boot time, if that's possible |
11:21 | shesselba | yeah, for 2d rmk has a driver in his pocket.. I will ask him as soon as I have done my si5351 tests |
11:22 | shesselba | and maybe asked rabeeh about some jitter tests as I don't have the equipment to measure jitter |
11:38 | wumpus | rmk has a 'driver in his pocket' for 2D? interesting, any public source code? |
11:52 | shesselba | you don't dare to look in his pocket ;) I know he has one, but has not released anything. Maybe I can bribe him with si5351 and tda drivers ;) |
11:55 | wumpus | yeah i don't want to see his pocket, just the driver ;) i guess if he's also programming the gc pipe we could share some common infrastructure |
14:03 | shesselb | 14:03 * shesselba just posted si5351 clock driver to mainline linux, let the flaming begin ;) |
14:14 | dbsx | what causes |
14:14 | dbsx | arch/arm/include/asm/memory.h:175:2: error: impossible constraint in 'asm' |
14:14 | dbsx | in a native build of rabeehs or vdorst kernel???? |
14:16 | dbsx | debian gcc-4.6 and 4.7 |
14:22 | dbsx | gnite |