00:09 | dv_ | oh man, just had a facepalm moment |
00:09 | dv_ | OF COURSE the cacheable stuff didnt give me better performance ... because I actually didnt copy over the new decoder to the cubox. doh |
00:10 | dv_ | its at 52% now. better |
00:25 | _rmk_ | that's with cacheable for the vmeta source buffers or the image buffers? |
00:25 | _rmk_ | dv: so how hot is it where you are? |
00:26 | _rmk_ | dv: it's been up to 33C here today, inside we're currently at about 28C, which is too hot for sleeping |
00:58 | dv_ | _rmk_: yeah, similar here |
00:59 | dv_ | and I use cacheable for the output buffers (the images) |
00:59 | dv_ | well, its 18?C outside right now, but inside the flat its 29?C |
01:01 | dv_ | I dont think using cacheable for input stream buffers would help much. if I comment out the memcpy, the whole thing is at ~9-14% CPU with an 1080p video |
01:01 | dv_ | okay, perhaps it gives me a few more % |
01:03 | dv_ | but I am finally too tired. lets try the sleep thing again now. later guys |
01:03 | _rmk_ | :) |
01:03 | _rmk_ | me too. |
03:07 | undone | i have troubles getting a mainline kernel with device tree to boot |
03:08 | undone | silence after uboot - i should have compiled in more debug options!? |
03:08 | undone | so i have to 'mkimage' the dtb file first? |
03:10 | undone | i've also tried the all in one method: cat z1 2 >z12; mkimage type kernel, compressioni none |
03:13 | undone | what source? i believe currently there were no changes from arm-linux to mainline |
03:14 | undone | i also have a 1280x1024 (5:4) display connected via hdmi-to-dvi from cubox |
03:15 | undone | and all kernels i've tried (incl. geexbox, xilka) through arround the pixels in vt fb |
03:16 | undone | after console mode change |
03:17 | undone | i've not tried the kernel from xilka, cause i can't boot a dtb yet |
03:18 | undone | i've applied pathes from moinejf (vt garbage, irq xy), but didnt noticed |
03:19 | undone | btw the wiki/patches are outdated |
03:23 | undone | non-dt-fb-console: sometimes e.g left corner is in middle, mostly anywhere |
03:25 | undone | *every mode change its somewhere else |
03:30 | undone | this only happens in rare cases (e.g. debian netboot installer, cubox installer); not with one of these kernels in there full distribution - ? |
03:31 | undone | the kernel never calls out to a library. does it? to libbmm? |
03:41 | undone | so i have those two problems, please help |
03:46 | undone | a) i can't boot with device tree; and b) kernels without or before that have a bug in vt over hdmi |
04:10 | undone | normally i switch between vts with alt+l/r-arrow |
04:10 | undone | from x with ctrl+alt+f* |
04:14 | undone | on cubox, every mode change the framebuffer forgets its edges |
10:09 | MMlosh | undota, I doubt changing nicks after asking a question helps.. I think you don't have to 'mkimage the device tree. You have to ${fs}load it and pass the address when doing bootm, though |
10:09 | MMlosh | Well.. judging from one machine I have that boots with DT (SabreLite) |
10:14 | MMlosh | and for that you need a new-enough u-boot |
10:28 | RandomPixels | hello |
10:49 | _rmk_ | undota: mainline kernels have no support for video output on the cubox. |
11:12 | MMlosh | I remember rabeeh saying that my cubox's MAC address should be located at it's bottom. My cubox doesn't have any label on the bottom. Was this different for v1 cuboxes, shipped as engineering samples? |
11:40 | _rmk_ | mine also doesn't have any label on it |
11:47 | MMlosh | I am having trouble having it activate ipv6 temporary addresses by default on boot... I blame a lack of fixed address |
16:46 | rabeeh | MMlosh: if you don't have a MAC address on the bottom; it means it's from the early engineering samples one. |
16:47 | MMlosh | oh |
16:47 | rabeeh | anyhow; you can either save your MAC address as a u-boot env variable 'ethaddr'; or you can program it on the SPI flash. |
16:47 | MMlosh | is there a way how I could figure out what was "mine" MAC? |
16:47 | rabeeh | if there is nothing on the bottom; it's randomly generated every boot; unless you have the 'ethaddr' u-boot env variable programmed |
16:48 | MMlosh | I mean - was I meant to receive a MAC address with the device? |
16:48 | rabeeh | http://www.solid-run.com/phpbb/viewtopic.php?f=7&t=1266&hilit=mac+address#p7084 |
16:48 | rabeeh | when did you get that CuBox? |
16:49 | MMlosh | package receive date? |
16:49 | rabeeh | read the whole thread; it tells you how to program the 'ethaddr' and how to flash your own MAC on the SPI flash. |
16:49 | rabeeh | i suggest you use MAC addresses with 'local administered' bit on |
16:50 | rabeeh | (typically for virtual machines?) |
16:51 | rabeeh | http://www.denx.de/wiki/view/DULG/WhereCanIGetAValidMACAddress |
16:51 | rabeeh | when did you receive your package? |
16:52 | MMlosh | I paid around 2012/01/23, said tobe shipped 2013/04/03 |
16:52 | MMlosh | *said to be |
16:52 | rabeeh | 2012 |
16:52 | MMlosh | I received it somewhere around 2013/04/15 |
16:52 | MMlosh | oops |
16:53 | MMlosh | yes, 2012, both cases |
16:53 | rabeeh | ok; so that's probably before MAC addresses were burned into the systems |
16:55 | MMlosh | I think the MAC stayed the same with the 2.6 kernel |
16:55 | MMlosh | but now I got a different one in 3.6 |
16:56 | MMlosh | + I have problems with "ipv6 privacy addresses", even though the script that sets net.ipv6.conf.all.use_tempaddr=2 works correctly and reports success, somehow it gets reset back to 0 |
16:57 | MMlosh | thanks for the MAC addr link.. My searches on "choosing MAC address" was not understood and directed me at mac address changing pages |