| 00:07 | RandomPixels | has anyone installed vlc on ubuntu10.04 |
| 00:07 | RandomPixels | ? |
| 00:15 | _rmk_ | isn't that the version that the cubox ships with? |
| 00:15 | _rmk_ | there's many problems with that setup... |
| 00:16 | _rmk_ | (a) the X server doesn't support the Xv types that vlc wants, so vlc does some _really_ expensive conversions |
| 00:16 | _rmk_ | (b) vlc won't use the h/w acceleration (and from what I can find, H264 is near impossible under libva with closed source vmeta libraries) |
| 00:19 | bencoh | near impossible ? |
| 00:19 | _rmk_ | the real killer is (a), because with (a) fixed it will play some 720p low-bitrate stuff (1.8mbps) via s/w decoding |
| 00:20 | _rmk_ | bencoh: yea, I've ended up having to hard-code some parameters in the reconstructed H264 picture NALs, which will fit some streams but not others |
| 00:20 | bencoh | hmm |
| 00:20 | _rmk_ | and even then it doesn't play smoothly (because I have to force vmeta to produce the frames) |
| 00:20 | bencoh | how does the xbmc port work then ? |
| 00:21 | _rmk_ | probably uses gstreamer which is a totally different setup |
| 00:21 | bencoh | the gstreamer plugin still uses vmeta ... right ? |
| 00:21 | _rmk_ | gstreamer can cope with the pipelined conversion inside the closed source vmeta stuff |
| 00:22 | _rmk_ | libva can't, libva isn't designed for any pipelining |
| 00:22 | _rmk_ | vlc uses libav (ffmpeg) which uses libva for hardware accel |
| 00:22 | bencoh | hmm, I see. |
| 00:24 | bencoh | (well, actually I'm currently working on a video/dataflow pipeline library (upipe.org), and will probably try implementing a vmeta/cubox pipe someday ... when we find some time and the lib gets a bit more mature) |
| 01:11 | RandomPixels | see you guys |
| 01:12 | RandomPixels | g'nite |
| 02:29 | dbsx1 | I just tried a http://support.netgear.com/product/WNCE2001 ethernet to wifi device on my cubox. V. good. |
| 04:45 | rmull | Anyone else get Xserver segfaults? |
| 04:45 | rmull | I'm on kernel 3.5.7-patched with a custom config, X Server 1.12.4 |
| 04:46 | rmull | Can't seem to learn much about the segfault other than knowing that it occurred |
| 05:02 | jnettlet | rmull, is the segfault at startup? |
| 05:13 | rmull | jnettlet: No - it seems to happen without being triggered by anything. I had a browser window with a couple of tabs and a terminal open |
| 05:23 | jnettlet | rmull, that is a new one |
| 05:47 | rmull | jnettlet: Okay. I'll stay vigilant to see if I can provide more information. |
| 05:47 | jnettlet | rmull, thanks. I am working on 1.13.0 support and that has brought on all sorts of new fun and excitement. |
| 05:48 | rmull | fun /and/ excitement? some people have all the luck |
| 06:01 | Punk-ley | hi all |
| 10:58 | Jesse__ | Hi, i want to buy a cubox only to use it with xbmc is this a good idea? |
| 10:59 | Jesse__ | Is it stable? |
| 10:59 | Jesse__ | What do you guys think about it? |
| 11:02 | Jesse__ | I read on Internet the guys having problem to make xbmc stable on the cubox is there already as stable version for the cubox? |
| 11:04 | Kiranos_ | no I think there is still stuff todo, its not a end device yet that just work out of the box |
| 11:07 | Jesse__ | Ok so you advice to look to other hardware for playing only xbmc |
| 13:32 | rabeeh | _rmk_: while hacking the packed bitstream; i noticed the following on the gstreamer vmeta plugin - |
| 13:32 | rabeeh | http://pastebin.com/jVGbMCdn |
| 13:33 | rabeeh | i think the gstreamer has similiar situation where it gets a slice and now whole frame. |
| 13:34 | rabeeh | the 'FILL_ENDOFUNIT_PATTERN(&vmetadec->StmRepo, vmetadec)' pads whatever there and passes that to vmeta |
| 13:56 | _rmk_ | rabeeh: which is a total bugger if the demuxer doesn't give you all the data for a complete frame (which is why I can't use the gstreamer 0.10 stuff; it breaks on mpeg transport streams because of that) |
| 13:58 | _rmk_ | rabeeh: also, I found that padding the H264 with the standard vmeta pattern didn't seem to work (which is 0x00, 0x00, 0x01, 0xff, 0xff, 0x00, 0x00, 0x04, 0x7f, 0x88, 0x88, 0x88) |
| 13:59 | _rmk_ | that just seemed to confuse vmeta even more; I ended up having to use the H264 padding NAL (which is 0x00, 0x00, 0x01, 0x0c, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff...) |
| 14:00 | _rmk_ | but still, the biggest issue here is that vmeta wants the bitstream itself. gstreamer can give that to vmeta. libva doesn't give that and because of that requirement, any libva solution has to reconstruct the bitstream from the libva data. |
| 14:01 | _rmk_ | whether that can be done depends on what data is available from libva; and not everything in the missing bytes in the bitstream gets passed to libva, so you have incomplete information. |
| 14:02 | _rmk_ | for mpeg4, you have most of it except the timing information; you can get around that because you're told which bit in the passed data the slice starts, so you can adjust the length of the time increment so that your reconstructed header finishes at the right bit position. |
| 14:03 | _rmk_ | for mpeg2, you have mostly the complete data (you're always provided with the IQ matrix even if that's the default one) but that doesn't matter; you've got no bit alignments to worry about there. |
| 14:04 | _rmk_ | for h264, you're missing several of the default parameters specified in the picture parameter NAL; instead, you get told what the actual value is along with each slice of data. |
| 14:04 | _rmk_ | and you don't know the sequence parameter ID nor the picture parameter ID that's used by the slice without parsing the slice; too bad if it uses more than one ID... |
| 14:05 | _rmk_ | for example, here's some of my reconstruction code for H264: |
| 14:05 | _rmk_ | /* NAL_SP */ |
| 14:05 | _rmk_ | set_word(buf, pos, 0x00000167); |
| 14:05 | _rmk_ | set_bits(buf, pos, 8, 100); /* profile idc */ |
| 14:05 | _rmk_ | set_bits(buf, pos, 8, 0); /* constraint flags */ |
| 14:05 | _rmk_ | if (h264->seq_fields.bits.MinLumaBiPredSize8x8) |
| 14:06 | _rmk_ | set_bits(buf, pos, 8, 0x28); |
| 14:06 | _rmk_ | else |
| 14:06 | _rmk_ | set_bits(buf, pos, 8, 0x14); /* guess */ |
| 14:06 | _rmk_ | set_ue(buf, pos, 0); /* sps id */ |
| 14:06 | _rmk_ | set_ue(buf, pos, h264->seq_fields.bits.chroma_format_idc); |
| 14:06 | _rmk_ | ... |
| 14:06 | _rmk_ | } else if (h264->seq_fields.bits.pic_order_cnt_type == 1) { |
| 14:06 | _rmk_ | set_bits(buf, pos, 1, h264->seq_fields.bits.delta_pic_order_always_zero_flag); |
| 14:06 | _rmk_ | set_se(buf, pos, 0); /* offset for non ref pic */ |
| 14:06 | _rmk_ | set_se(buf, pos, 0); /* offset for top to bottom field */ |
| 14:06 | _rmk_ | set_ue(buf, pos, 0); /* num ref frames in pic order cnt |
| 14:06 | _rmk_ | cycle */ |
| 14:07 | _rmk_ | } |
| 14:07 | _rmk_ | ... |
| 14:07 | _rmk_ | /* NAL_PPS */ |
| 14:07 | _rmk_ | set_word(buf, pos, 0x00000168); |
| 14:07 | _rmk_ | set_ue(buf, pos, 0); /* pic parameter set id */ |
| 14:07 | _rmk_ | set_ue(buf, pos, 0); /* seq parameter set id */ |
| 14:07 | _rmk_ | ... |
| 14:07 | _rmk_ | set_ue(buf, pos, 0); /* num ref idx 10 default active minus1 xxx */ |
| 14:07 | _rmk_ | set_ue(buf, pos, 0); /* num ref idx 11 default active minus1 */ |
| 14:08 | _rmk_ | those last two are _highly_ stream specific, and setting them to zero happens to match one of those streams that was posted here. I've got another stream where one of those has to be '1' |
| 14:09 | _rmk_ | otherwise it just produces random blocky colours at the top of the picture |
| 14:10 | _rmk_ | the way libva is structured, it seems to be designed with the idea that you can pass the parameter information and data slices to your hardware, tell your hardware to decode it, and then immediately return the rendered picture for that input data |
| 14:10 | _rmk_ | _before_ you get the next data slices |
| 14:12 | _rmk_ | as I've said many times, the closed source vmeta libraries are not like that; they're pipelined. they produce the rendered picture some time after they've had the input data (sometimes after quite a bit of subsequent data) |
| 14:13 | _rmk_ | if you pass it a 128K buffer containing everything it needs to decode the first I-frame of MPEG2 data, padded out with the vmeta padding sequence, it will beg you for more data. If you give it more vmeta padding, it just sits there and asks for yet more stream buffers. |
| 14:14 | _rmk_ | and you can spin in that all you want, it won't give you the rendered picture. The only way to get it to output that is to either give it more MPEG2 data (which, in libva you don't have) or you append the magic MPEG2 'end-of-stream' sequence |
| 14:15 | _rmk_ | I feel fairly sure that if vmeta were to be opened up, a libva solution would be far more viable. But as things stand at present, the closed nature of it is an effective blocker to at least H264 decoding in a way compatible with libva. |
| 14:30 | jnettlet | _rmk_, not that I would suggest you change mid-stream, but it sounds like libvdpau might fit the vmeta decoding needs better. I am pretty sure that it is designed to forward the bitstream directly to the hardware. |
| 14:31 | jnettlet | I never got too in depth with it, but VIA engineers were favoring it over libva for this reason. |
| 14:35 | RandomPixels | hello |
| 14:36 | RandomPixels | rabeeh, are you around ? |
| 14:37 | _rmk_ | jnettlet: are you sure about that, because my reading of the vdpau code in libav shows that it passes a load of parameter buffers just like libva gets passed... and there's also the ability (iirc) to run the vdpau stuff beneath libva |
| 14:48 | jnettlet | _rmk_, I am not 100% certain of that as I haven't worked directly with it. |
| 16:54 | rmull | My hardware clock is running too fast |
| 16:55 | rmull | ntpd resets by -108 seconds every 2-3 minutes |
| 16:56 | RandomPixels | :) |
| 16:56 | RandomPixels | mine is always resetting after power off |
| 16:57 | RandomPixels | 4 Dec 15:57:04 ntpdate[3855]: step time server 91.189.94.4 offset 67300245.924852 sec |
| 16:57 | rmull | Yikes |
| 17:38 | rabeeh | RandomPixels: here |
| 17:54 | RandomPixels | hello |
| 17:54 | RandomPixels | question |
| 17:55 | RandomPixels | is it possible/feasable |
| 17:55 | RandomPixels | to build a more powerful cubox ? |
| 17:55 | RandomPixels | dual-quad core with about 8gig ram |
| 17:55 | RandomPixels | considering an increase in size and price |
| 17:58 | rabeeh | yes |
| 17:58 | rabeeh | :) |
| 17:58 | rabeeh | 8gig is almost a waste on ARM 32bit |
| 17:59 | rabeeh | Today the devices available in the market are all ARMv7 architecture which are all 32bit |
| 17:59 | rabeeh | there is an extension in ARMv7 called LPAE (similar to Intel PAE) that can get you up to 40 bit addressing. |
| 17:59 | rabeeh | 2^32bit is 4GB |
| 18:00 | rabeeh | so potentially a process in ARMv7 architecture is limited to see up to 4GB of address space. |
| 18:00 | RandomPixels | ok, so i should keep poking santa claus 2013 for a Cubox Pro :) |
| 18:01 | rabeeh | 2014 |
| 18:01 | rabeeh | or 2015 |
| 18:01 | rabeeh | if you want 8GB of memory :) |
| 18:01 | RandomPixels | :) |
| 18:01 | RandomPixels | still fine |
| 18:01 | rabeeh | hehe - just kidding |
| 18:01 | rabeeh | dual and quad ARM processors are available in the market; but the amount of memory is a bit problematic |
| 18:02 | rabeeh | the real solution for the memory size is when ARM will have ARMv8 based architecture which is the move to 64bit |
| 18:02 | RandomPixels | i mean, my ubuntu distro is a bit laggy and buggy, but with 4gb of ram i think it removes almost any kind of restriction of what you can do |
| 18:02 | rabeeh | everything else like LPAE must be considered per usage case since sometimes it's impossible to use that |
| 18:03 | _rmk_ | RandomPixels: umm, more RAM doesn't make things faster |
| 18:03 | rabeeh | u mean ubuntu on CuBox? |
| 18:03 | rabeeh | it's not bound to memory size |
| 18:03 | RandomPixels | no no no |
| 18:03 | RandomPixels | not talking about ubuntu in general, but running more apps |
| 18:03 | RandomPixels | more resource-consuming apps |
| 18:04 | RandomPixels | for example, i'd use my cubox to store my photos on an external hard-drive, while using some 3rd party software (like picasa) to do heavy processing |
| 18:11 | RandomPixels | "When the build process was running I decided to make a deb-file that you guys don't have to compile the sources yourself." i love people that do this :) |
| 18:34 | RandomPixels | i'm going back to cartoons :) |
| 20:18 | koboldmaki | hi, i have some usb high-speed errors like "usb 2-1: reset high-speed USB device number 2 using orion-ehci" with the vanilla-kernel 3.6.8. Some hints how to fix/avoid the error. |
| 20:20 | koboldmaki | The error occured when a lot of I/O runs. |
| 20:25 | rabeeh | koboldmaki: is this something only in 3.6.8? |
| 20:26 | rabeeh | what is the workload you are trying? |
| 20:30 | koboldmaki | running a simple dd on the whole disk or when run checks with "ioping" |
| 20:32 | rabeeh | are there timeouts? |
| 20:32 | koboldmaki | i use a usb-stick (16GB). i never hat a problem with the mmc or with the esata, only with an usb-stick |
| 20:32 | rabeeh | do you know for sure that the usb-stick is working ok? |
| 20:32 | koboldmaki | no kernel hints for timeouts |
| 20:33 | koboldmaki | when the reset happens, there is also the following message "usb 2-1: device descriptor read/64, error -110" |
| 20:33 | rabeeh | i mean what happens if you run the same thing on different machine? |
| 20:34 | koboldmaki | i try to connect the stick to a VMware machine... in a minute... |
| 20:45 | koboldmaki | simple test with dd, no errors via usb. linear "speed" of 15MB/s for 1 GB of data |
| 20:47 | koboldmaki | ioping works also fine in my vmware machine |
| 20:53 | _rmk | 20:53 * _rmk_ is about to boot 3.7-rc7 on his cubox... |
| 20:53 | _rmk_ | well, after updating firefox |
| 20:55 | koboldmaki | @rmk: using the "dt" for the cubox?!? |
| 20:56 | _rmk_ | nope, because all my stuff is based off rabeeh's kernel tree and moving it over to DT would be a real pain atm |
| 20:59 | koboldmaki | ok. I tried some 3.7.x vanilla kernel, and always failed if I used some parts of the "dt". |
| 21:06 | _rmk_ | vanilla misses a lot of stuff for cubox |
| 21:09 | koboldmaki | yes, but i do not really need the multi-media feature |
| 21:09 | _rmk_ | what about any kind of display output? |
| 21:10 | koboldmaki | headless.. |
| 21:15 | koboldmaki | @rmk: have you enable /dev/mem? if yes, can you run "dd if=/dev/mem of=/dev/null".. |
| 21:20 | rabeeh | mpeg4 with packed bitstream problem solved. patch sent to geexbox team |
| 21:21 | rabeeh | or shall i say - to whom it concerns, mpeg4 with packed bitstream problem solved. patch sent to geexbox team |
| 21:25 | _rmk_ | koboldmaki: if you're doing that as root then... well... you're taking a great risk |
| 21:25 | _rmk_ | if it causes a kernel panic, "doctor doctor it hurts if I do X" don't do X then. |
| 21:26 | koboldmaki | read shoudn't be a problem... |
| 21:26 | cbxbiker61 | rabeeh, the globalscale mirabox looks pretty cool, dual nics, usb3, 1G ram, 1.x GHz arm7, not sure why they didn't put sata on it though |
| 21:27 | rabeeh | they didn't |
| 21:27 | rabeeh | ? |
| 21:27 | _rmk_ | koboldmaki: frankly, with all the variations in ARM platforms we can't decently plug that one |
| 21:27 | rabeeh | the chip they use supports dual sata |
| 21:27 | cbxbiker61 | yep it does, but they don't mention sata in the specs |
| 21:28 | rabeeh | maybe it's hidden inside. it really doesn't make any sense |
| 21:28 | rabeeh | the sata ports are coming directly from the chip; so it's really just putting two connectors and 4 capacitors. |
| 21:29 | cbxbiker61 | when we can use common kernels between armv7 devices, arm will become a lot more practical |
| 21:30 | _rmk | 21:30 * _rmk_ snorts |
| 21:30 | rabee | 21:30 * rabeeh prays |
| 21:30 | _rmk_ | when we end up with a common kernel, we'll end up with lots of bloat because we'll have every driver under the sun and your kernel will be 10MB in size |
| 21:31 | rabeeh | 10MB kernel is ok |
| 21:31 | _rmk_ | along with massive initramfs images |
| 21:31 | rabeeh | i don't think the drivers for booting kernels are that big |
| 21:32 | rabeeh | any decent machine today has 1GB of memory |
| 21:32 | _rmk_ | individually they aren't but then think about the diversity |
| 21:32 | _rmk_ | and all those drivers you'll need to mount the rootfs because its behind some platform specific driver |
| 21:33 | rabeeh | come on; DT should fix most of those issues |
| 21:33 | _rmk_ | it _doesn't_ |
| 21:33 | _rmk_ | think about it |
| 21:33 | _rmk_ | please, for one moment. |
| 21:33 | _rmk_ | can we use the OMAP SD driver on the cubox? |
| 21:33 | rabeeh | we can't |
| 21:34 | rabeeh | but both omap SD and Dove SD drivers will be built in the same kernel (or loaded via initramfs) and then the right driver takes over |
| 21:34 | rabeeh | (using DT) |
| 21:34 | _rmk_ | no, we need to use the dove SDHCI driver. OMAP can't use the dove SDHCI driver, it has to have its own one. So there, immediately, you need both the OMAP and the Dove SD drivers in order to boot a common kernel on those two platforms |
| 21:34 | koboldmaki | 1 GB of RAM... well 2 or 4 GB would be better... ;-) |
| 21:34 | _rmk_ | and in that case you'll end up with a bloated kernel - maybe 10+ MB in size |
| 21:34 | koboldmaki | what gives: time dd if=/dev/mem bs=64K of=/dev/null ? |
| 21:34 | rabeeh | koboldmaki: scroll up for 8GB requests :) |
| 21:35 | koboldmaki | @rabeeh: yes saw it on the log archive ;-) |
| 21:35 | _rmk_ | koboldmaki: umm, try explaining the problem rather than just waving at it |
| 21:35 | rabeeh | _rmk_: i think it will be even more than 10MB; but at the end of the day look at the user's benefit. |
| 21:35 | _rmk_ | btw, 3.7.0-rc7 doesn't boot |
| 21:36 | rabeeh | you download a single kernel with it's initramfs built-in, and you can boot most of ARMv7 machines on the planet |
| 21:36 | rabeeh | it's like a dream for me. |
| 21:36 | _rmk_ | I don't see any benefit to having a multi-megabyte kernel even on the cubox... tbh I'm pissed that vmeta eats 256MB of RAM for its stuff |
| 21:36 | _rmk_ | to then eat more with a kernel that consumes lots more RAM is utterly insane |
| 21:37 | _rmk_ | I want my RAM doing stuff for me, not sitting around containing a load of useless crap that isn't of any use |
| 21:38 | rabeeh | _rmk_: you are a super hero when it comes to development and hacking etc... |
| 21:38 | rabeeh | but the majority of the people want to enjoy those machines without breaking teeth, and wrestling with stupid kernel misconfiguration etc... |
| 21:39 | rabeeh | i know; it takes you away from deep embedded system and pure engineering; but it serves the end user |
| 21:39 | _rmk_ | let's get one thing clear shall we... |
| 21:39 | koboldmaki | @rmk: the test with "dd" on the memory, is to see how fast you could access to the memory. I god around 170/180MB/s... with the vanilla kernel |
| 21:40 | _rmk_ | when ARM Linux started out, people accused me of being too focused on 'server' or 'desktop' type stuff |
| 21:40 | _rmk_ | now people are accusing me of being too focused on 'embedded'. no, I'm not. I'm not either. I have my views, my views haven't really changed over the years... |
| 21:41 | _rmk_ | what has changed is people's perceptions of my views, and the ways people attack my views |
| 21:42 | _rmk_ | (hence your comment about 'taking me away from deep embedded systems' as if I've been doing nothing but deep embedded stuff for the last 20 years |
| 21:43 | rabeeh | _rmk_: you are taking this too personal; no one is accusing anyone. i'm trying to put a point where in my mind ARM would be more popular and beneficial |
| 21:43 | rabeeh | ARM are trying now to go for the server / cloud market. |
| 21:43 | rabeeh | at the end of the day; if the IT guy doesn't have a CD written on it ARM server, and he installs it on any ARMv8 machine and it simply works; it's not going to be popular |
| 21:44 | _rmk_ | that much is great - and its being helped by ARM finally getting their act together with ARMv8 and mandating more stuff, something they've steadfastly refused to do before now |
| 21:45 | rabeeh | well.. they are trying but i'm not sure how mandating they are |
| 21:45 | rabeeh | for a fact, they are giving architecture licenses to companies; so they can implement their own cpu |
| 21:45 | _rmk_ | they've actively promoted differentiation between different silicon vendors reading to all the crap we've ended up with today in the 32-bit world... such as randomly placing RAM at the wierdest locations in system memory |
| 21:45 | rabeeh | that alone potentially breaks ARM pipeline instruction scheduling optimizations, and other companies chooses to implement neon or other |
| 21:46 | _rmk_ | there's even been SoCs where the second bank of RAM is _below_ the address of the first bank of RAM. |
| 21:46 | rabeeh | :) |
| 21:47 | koboldmaki | ... and run with 16bit... instead of 32bit.. |
| 21:47 | rabeeh | i think the one implemented that bank addressing should be put in jail |
| 21:47 | _rmk_ | what you find CPU vendors come out with on 32-bit stuff is absolutely horrendous |
| 21:47 | _rmk_ | quite :) I refused the patches for it. |
| 21:48 | rabeeh | _rmk_: i'm furious now when mentioning the crap hardware engineers can do |
| 21:48 | _rmk_ | then we went to memblock which made that setup even harder to support |
| 21:49 | rabeeh | and at the end of the day they tell you; it's software, why can't you fix my stupid hardware? |
| 21:50 | _rmk | 21:50 * _rmk_ hopes the LL debug stuff works on the cubox |
| 21:50 | _rmk_ | splat |
| 21:51 | _rmk_ | clk stuff is messed up |
| 21:51 | rabeeh | i think serial port clock is disabled |
| 21:51 | rabeeh | shesselba had same issue ages ago |
| 21:51 | _rmk_ | Unable to handle kernel NULL pointer dereference at virtual address 0000002a |
| 21:52 | _rmk_ | PC is at __clk_prepare+0x10/0x74 |
| 21:52 | _rmk_ | LR is at clk_prepare+0x24/0x38 |
| 21:52 | _rmk | 21:52 * _rmk_ sighs at gnome-terminal pasting the entire line |
| 21:53 | rabeeh | _rmk_: i'm going to cool now over beer. good night and ttyl |
| 21:53 | rabee | 21:53 * rabeeh runs away |
| 21:53 | _rmk_ | if you can stand watching a 15 minute youtube video... |
| 21:53 | _rmk_ | maybe not :) |
| 21:55 | koboldmaki | @rmk: could you run the dd command on the memory? |
| 21:55 | koboldmaki | on the cubox? |
| 21:56 | _rmk_ | not until I've got the cubox booting again... |
| 21:56 | koboldmaki | ok. |
| 21:57 | _rmk | 21:57 * _rmk_ wonders what happened to error checking... |
| 21:58 | _rmk_ | struct clk *clk = clk_get_sys("tclk", NULL); |
| 21:58 | _rmk_ | clk_prepare_enable(clk); |
| 21:58 | _rmk_ | return clk_get_rate(clk); |
| 22:19 | _rmk_ | yay, finally. |
| 22:23 | koboldmaki | works? |
| 22:30 | _rmk_ | root@cubox:~# time dd if=/dev/mem of=/dev/null bs=64k |
| 22:30 | _rmk_ | dd: reading `/dev/mem': Bad address |
| 22:30 | _rmk_ | 9984+0 records in |
| 22:30 | _rmk_ | 9984+0 records out |
| 22:30 | _rmk_ | 654311424 bytes (654 MB) copied, 2.52696 s, 259 MB/s |
| 22:31 | koboldmaki | tnxs.., well that about 80MB more then i god |
| 22:33 | koboldmaki | you compile the kernel also on the cubox? or do you use a cross-compiler? |
| 22:46 | _rmk_ | naa, always cross compiled now |
| 22:47 | koboldmaki | ok. |
| 22:49 | koboldmaki | is it normal that /proc/ioports is empty, and /proc/iomem contains the "ports" |
| 22:53 | _rmk_ | yes |
| 22:53 | _rmk_ | unless there's something like pci or isa stuff present |
| 22:55 | koboldmaki | ok, and lspci is also empty... |
| 22:55 | _rmk_ | because there's no pci stuff on the cubox |
| 22:58 | koboldmaki | yes, the spec info from marvel (88Ap510) shows that there could be a pci(e) |
| 23:01 | _rmk_ | yes, there's pcie, but that doesn't mean there's anything connected to it |
| 23:20 | koboldmaki | the cubox has some dma channels, why couldn't you see it via /proc/dma?... via ls -l /sys/devices/platform/mv_xor.* you see the mv xor channels. |
| 23:23 | _rmk_ | /proc/dma is for ISA dma channels |
| 23:31 | koboldmaki | ok. |