| 01:02 | crypt0s | hey |
| 01:02 | crypt0s | i heard earlier that there is some issues with UHD Sd cards |
| 01:02 | crypt0s | any docs on that? |
| 01:03 | crypt0s | Also: is there a way to pause it from rebooting automatically if uboot has issues loading the kernel? |
| 01:03 | crypt0s | i'd like to read the error. |
| 01:15 | MikeSeth | crypt0s: from what I know there is a clocking problem that prevents uhs cards from working in uboot |
| 01:16 | MikeSeth | and u-boot doesnt seem to reboot automatically for me |
| 01:16 | MikeSeth | interrupt it with a keypress when autoboot starts, then execute the boot manually step by step |
| 01:19 | crypt0s | MikeSeth: it looks like it has a problem loading kernel into mem and then bombs out and reboots |
| 01:19 | crypt0s | so i can drop to console, continue the boot, and then it has the error and immediately reboots |
| 01:19 | crypt0s | it's pretty annoying. |
| 01:20 | _rmk_ | MikeSeth: I have a Samsung UHS card in my cubox-i which uboot seems to be happy with. |
| 01:21 | _rmk_ | crypt0s: capturing a console log and putting it somewhere accessible may help to understand the problem |
| 01:24 | crypt0s | _rmk_: ah with uboot. crap i keep forgetting i have UART |
| 02:23 | crypt0s | _rmk_ MikeSeth : I figured out the issues |
| 02:23 | crypt0s | The 3.13.1 kernel won't boot |
| 02:24 | crypt0s | but obv. the 3.0.10 provided will |
| 02:24 | crypt0s | so i rebuilt, and I believe I am also using the older uBoot but will have to confirm |
| 02:25 | crypt0s | in any event -- I have gentoo working now and I'm in single-user mode |
| 02:28 | _rmk_ | why won't 3.13.1 boot? |
| 02:29 | crypt0s | uboot flubbed loading it into memory that was the auto-reboot issue |
| 02:30 | crypt0s | i'll get you the full message as soon as I get uboot dumping to UART |
| 02:30 | _rmk_ | the only issue I've had there is when loading the dt blob too low (0x11000000) with the kernel setup with a large log buffer - which I need to debug wireless |
| 02:30 | _rmk_ | I've since modified it to load the DT at 0x18000000 |
| 02:30 | _rmk_ | but you shouldn't be hitting that |
| 02:30 | crypt0s | _rmk_: that was the base address I set |
| 02:30 | crypt0s | 1800000 |
| 02:31 | _rmk_ | loadaddr=0x10800000 |
| 02:31 | _rmk_ | fdt_addr=0x18000000 |
| 02:32 | _rmk_ | first is where the kernel gets loaded, second is where the DT blob gets loaded |
| 02:32 | crypt0s | hrm OK let me try that |
| 02:32 | _rmk_ | don't forget... |
| 02:32 | crypt0s | that gets set with setenv right? |
| 02:32 | _rmk_ | fdt addr ${fdt_addr} |
| 02:33 | _rmk_ | bootz ${loadaddr} - ${fdt_addr} |
| 02:33 | crypt0s | shit ok there's def. something wrong then because I didn't have that in my uEnv.txt |
| 02:35 | crypt0s | _rmk_: ok does this make sense? |
| 02:35 | crypt0s | bootfile=/boot/uImage |
| 02:35 | crypt0s | loadaddr=0x10800000 |
| 02:35 | crypt0s | fdt_addr=0x18000000 |
| 02:35 | crypt0s | fdt addr ${fdt_addr} |
| 02:35 | crypt0s | mmcargs=setenv bootargs root=/dev/mmcblk0p1 rootwait video=mxcfb0:dev=hdmi consoleblank=0 |
| 02:35 | crypt0s | bootz ${loadaddr} - ${fdt_addr} |
| 02:36 | r00t_ | yello/ |
| 02:38 | _rmk_ | crypt0s: I don't think so... but then I don't know much about uEnv.txt files yet :p |
| 02:39 | r00t_ | hey I have a question about when your on android |
| 02:40 | crypt0s | _rmk_: you boot manually? lol. OK well let me figure out how to finish the rest of the gentoo install and I'll test that out with 3.13.1 |
| 02:40 | r00t_ | Ok, lets say you run out of space on your micro sd card and you want to install a custom made apk how would you install it and run it from the usb drive/ |
| 02:40 | _rmk_ | crypt0s: no, I use the old method of jnettlet's scripts grabbing a boot.scr off the sd card, and executing that |
| 02:41 | crypt0s | r00t_: you should be dropping the custom apk to the usb and running it from there |
| 02:41 | crypt0s | r00t_: try using a file access program to open the APK file or doing it manually from the adb |
| 02:42 | crypt0s | if you're not using adb, you should try that out first. |
| 02:42 | _rmk_ | crypt0s: I thought I might have had a random uEnv.txt kicking around here somewhere but... seems not. |
| 02:42 | r00t_ | I do but it proceeds to try to install to the micro sd |
| 02:42 | crypt0s | _rmk_: darn. |
| 02:42 | crypt0s | r00t_: hrm - android may not like installing apps on the USB but you should be able to force it with adb |
| 02:42 | crypt0s | are you using adb? |
| 02:43 | r00t_ | not at present |
| 02:43 | crypt0s | _rmk_: i'll just try it manually and let you know. |
| 02:43 | crypt0s | r00t_: try using that and see if you can get what you need. |
| 02:43 | _rmk_ | crypt0s: ok, thanks... I'm about to crash anyway. |
| 02:43 | r00t_ | I dont know how to force usb though |
| 02:43 | crypt0s | _rmk_: OK. Thanks for your help man. |
| 02:44 | r00t_ | :P at least all this stuff is easier on linux, tho |
| 02:44 | r00t_ | *power to the free os* |
| 02:44 | _rmk_ | been looking too much at broadcom wireless code this evening, amongst trying to get /this/ machine set for more debugging on a slow insidious memory leak |
| 02:44 | crypt0s | r00t_: http://stackoverflow.com/questions/15756862/how-to-install-android-apps-to-the-sd-card-by-default |
| 02:45 | r00t_ | same concept thanks |
| 02:45 | crypt0s | r00t_: ? |
| 02:45 | r00t_ | setting the external |
| 02:46 | crypt0s | sorry look at the first answer to that stack overflow |
| 02:46 | r00t_ | lmao |
| 02:46 | crypt0s | adb shell pm set-install-location 2 |
| 02:46 | r00t_ | yea |
| 02:46 | r00t_ | it should work now |
| 02:46 | r00t_ | (im surprised this isnt on the forums) |
| 02:47 | r00t_ | because now I can just use my 1 tb hdd instead of buying a bigger micro sd |
| 02:50 | r00t_ | nice |
| 02:50 | r00t_ | thanks |
| 02:50 | crypt0s | np |
| 02:51 | crypt0s | r00t_: it worked? |
| 02:51 | r00t_ | seems to be |
| 02:51 | crypt0s | awesome |
| 02:51 | r00t_ | if I hit a bug ill make note of it |
| 02:54 | r00t_ | it also appears I can move already installed apps to the usb as well |
| 11:51 | matoking | My Cubox-i was finally shipped! |
| 11:54 | rabeeh | matoking: great |
| 11:54 | rabeeh | what are you willing to do with it? |
| 11:55 | matoking | A local server for web app development, NAS, a BitTorrent client, maybe run a Bitcoin node on it |
| 11:56 | matoking | And some other ideas I haven't thought of yet :) |
| 12:03 | rabeeh | wumpus had notes about bitcoin on the forums few months ago |
| 12:03 | rabeeh | he was looking to use the openCL extension for that |
| 12:05 | matoking | You mean, for mining? |
| 12:05 | rabeeh | yes |
| 12:07 | matoking | Hmm |
| 12:10 | matoking | I was planning on running a bitcoind node on it |
| 12:11 | matoking | Bitcoin mining is not feasible, but I'm not sure about Litecoin |
| 12:19 | wumpus | nah the gc2000 OpenCL extension can't run the bitcoin miners, too many instructions |
| 12:19 | wumpus | I guess it's the same for litecoin |
| 12:26 | MikeSeth | rabeeh: something weird, my transcend cards are now working |
| 12:27 | MikeSeth | [B[1~[1~[D[B |
| 12:27 | MikeSeth | gah |
| 12:27 | rabeeh | MikeSeth: what has changed? |
| 12:28 | MikeSeth | rabeeh: I dont know yet, I suspect there is some magic in the card controller that triggers upon partition *write* |
| 12:28 | MikeSeth | the only significant difference is that this time I zeroed the card out |
| 12:29 | MikeSeth | I will find out |
| 12:33 | matoking | @wumpus What do you mean by "too many instructions"? Do you mean there are some instructions Cubox-i doesn't support or does the sheer amount of instructions simply remove any performance advantages that could be had from using OpenCL? |
| 12:41 | rabeeh | matoking: i think he is referring to the fact that the max queue size of the openCL engine is 128 instructions |
| 12:41 | matoking | Yeah, that could explain it |
| 12:47 | wumpus | yes the OpenCL is embedded profile, which is very limited |
| 12:48 | wumpus | not that it would be a good match for bitcoin mining otherwise, it's a completely different kind of iron you need for that nowadays |
| 12:50 | wumpus | (to be clear, this is about the *GPU*, not the cubox-i itself that doesn't support instructions) |
| 12:50 | wumpus | you can run as many instructions as you want on the quad ARM cores :) |
| 13:04 | matoking | @wumpus Yeah, ASICs have superseded CPUs and GPUs in Bitcoin mining |
| 13:05 | matoking | Mining scrypt-based currencies such as Litecoin and Dogecoin are probably a better choice since the efficiency gap between CPUs and GPUs is smaller |
| 13:05 | matoking | But even then I don't suppose it's actually profit unless you are doing it for fun :P |
| 13:08 | wumpus | running a bitcoin node on the cubox(-i) works fine, all verification work is done by the CPU anyway, only bottleneck might be memory, the daemon tends to be somewhat of a memory hog |
| 13:09 | matoking | Yeah, that was what I planned on doing in the first place |
| 15:57 | dv_ | vc1 and wmv3 work now \o/ |
| 16:00 | rabeeh | dv_: \o/ |
| 16:18 | jnettlet | dv_, nice! |
| 16:28 | rabeeh | dv_: any initial numbers on cpu utilization on getting high bitrates decoded? |
| 16:45 | dv_ | rabeeh: running tests now |
| 16:49 | dv_ | on the i4pro, with top, and the "birds" 40mbps sample, I measure 3% . smooth playback. |
| 16:49 | rabeeh | :) |
| 16:49 | rabeeh | i wonder how much that would be on hb |
| 16:50 | rabeeh | although should be similar |
| 16:50 | dv_ | http://www.auby.no/files/video_tests/ |
| 16:50 | dv_ | the vc1 hddvd test runs also at 3-4% |
| 16:51 | dv_ | this is without audio (audio would be done in software) |
| 16:51 | dv_ | hm I also think HB should show something similar, since I looked at the CPU% of the process itself in top, not the overall CPU usage, so this figure should not depend on the number of cores |
| 16:53 | dv_ | one remaining strange issue is the combination of IPU-based deinterlacing and the EGL vivante texture sink |
| 16:54 | dv_ | after a while, the IPU reports "Invalid argument" |
| 16:55 | rabeeh | ipu? |
| 16:56 | rabeeh | that's weird; GB reported issues after a while trying to playback videos where the VPU memory can't be allocated anymore |
| 20:36 | donovang | Heyas - anyone got time to answer a question about supported video paremeters in boot.cfg for new cubox ? |
| 20:38 | rabeeh | donovang: go ahead |
| 20:38 | donovang | the official arch linux image for cuboxi has its video parameter set to 1920x1080M@60. |
| 20:38 | donovang | At one point, there was a reference for these parameters somewhere in the old cubox lore (wiki or forums) |
| 20:39 | donovang | I was wondering if you could point me to a reference for what I can set that parameter to ? |
| 20:40 | rabeeh | those parameters are completely unrelated to the older cubox |
| 20:40 | donovang | Just to clarify, I'm looking for a reference for the "video" variable in the boot.cfg |
| 20:40 | rabeeh | they set the framebuffer resolution of the hdmi output |
| 20:41 | donovang | That's what I figured. I'm just trying to find a table so that I can tweak the resolution to get along best with my not-so-nice monitors. |
| 20:41 | donovang | ** table of possible parameters |
| 20:44 | rabeeh | what is that not-so-nice monitor? |
| 20:44 | rabeeh | a standard one or not? |
| 20:45 | rabeeh | notice that having 'video=mxcfb0:dev=hdmi' without specifying the resolution should configure the screen according to edid |
| 20:45 | donovang | This monitor is 1600 by 900 I think |
| 20:45 | rabeeh | (edid is the data from your monitor that tells what your monitor supports) |
| 20:45 | donovang | awesome |
| 20:45 | donovang | I will try that |
| 20:45 | donovang | I'd be happy with 1024x640 :) |
| 20:45 | rabeeh | and running 'cat /sys/devices/platform/mxc_sdc_fb.0/graphics/fb0/modes' should tell you the modes of your screen |
| 20:46 | rabeeh | if you got the modes list correctly then your monitor is a nice monitor and seems to be correctly identified |
| 20:46 | donovang | Ahh awesome |
| 20:47 | donovang | Okay - - will be modding boot.cfg. Many reboots await me. Thanks! |
| 20:47 | donovang | BTW, just got my Cubox Pro |
| 20:48 | donovang | This is such a ridiculous upgrade over the old cubox. Awesome job with this. Will be my new workstation for many months. |
| 20:59 | rabeeh | what a nice complement "ridiculous upgrade over the old cubox. Awesome job with this" :) |
| 21:02 | sickness | I have to agree even if I never tried the old cubox, the cubox pro is SO powerful it feels like a real server over ssh =_) |
| 21:04 | pahartik | sickness: Is there any difference between "CuBox" and "CuBox Pro" other than additional RAM? |
| 21:04 | rabeeh | by CuBox pro they refer to CuBox-i4pro |
| 21:05 | rabeeh | i think :) |
| 21:05 | sickness | oh |
| 21:05 | sickness | I don't think so, just 2gb ram on the pro, iirc |
| 21:05 | sickness | btw I have a normal "cubox pro" not the new "i" models |
| 21:09 | pahartik | sickness: I got same device some weeks ago, it works well but I remain waiting for appropriate kernel |
| 21:10 | sickness | what's the problem with the kernel? |
| 21:13 | pahartik | sickness: "Linux 3.6.9" does not have drivers for everything |
| 21:14 | sickness | what's missed? video adapter? |
| 21:16 | pahartik | sickness: Accelerated graphics at least |
| 21:17 | sickness | oh, well, I use it headless anyway ;) |
| 21:18 | pahartik | sickness: Supposedly "Linux 3.0.something" would have them, "Linux 3.10" and "Linux 3.13" are being worked on |
| 21:20 | sickness | good |