| 00:36 | MikeSeth | is it just me or there's an awful lot of issues with android being reported? |
| 00:36 | MikeSeth | boot loops, crashes, stuttering, networking won't work, overscan, bizzare video behaviour |
| 00:37 | _rmk_ | you mean on the cubox-i or ? |
| 00:42 | MikeSeth | cubox |
| 00:46 | _rmk_ | dunno |
| 00:49 | Coburn | apologies for the autoresponse |
| 00:49 | Coburn | it was a test and as I mentioned to rmk, it was broken |
| 00:49 | MikeSeth | well, we pointed and laughed |
| 00:49 | Coburn | _rmk_: thanks for your email, you've saved my bacon |
| 00:50 | _rmk_ | you'll need the kernel side for the acceleration to work though |
| 00:50 | _rmk_ | what are you trying to do? |
| 00:51 | Coburn | well, the project is to make a little jukebox using a CuBox, a hiFace DAC and a HDMI-enabled 7" portable monitor |
| 00:52 | Coburn | It's for a client. I need to output Xorg to the monitor, so he can use it as a "desktop", allowing him to read lyrics/announce song titles, etc |
| 00:52 | _rmk_ | ok, gimme half an hour or so |
| 00:53 | Coburn | alright, again I really appreciate it |
| 00:53 | Coburn | I've spent so much time tearing my hair out, I'll be bald ;P |
| 00:53 | Coburn | :)* |
| 00:53 | Cobur | _> |
| 01:17 | Coburn | coffee |
| 01:17 | crypt0s | is there a separate chan for cubox-i or is this it? |
| 01:22 | _rmk_ | you're in the right place |
| 01:35 | crypt0s | excellent |
| 01:37 | crypt0s | so i noticed that the disk contains 1 partition (not counting uboot in the first 1 mb) |
| 01:37 | crypt0s | but it the wiki about flashing uboot and the kernel |
| 01:38 | crypt0s | it doesn't say anything about how to specify which kernel to boot or where that kernel will be in the partition |
| 01:42 | crypt0s | And yet i still see a /boot partition with uboot in it in the official debian image -- I'm a little confused as to the setup process. If anyone is familiar with this I'd appreciate the assistance |
| 01:47 | _rmk_ | crypt0s: are you familiar with uboot? |
| 01:47 | crypt0s | I am not. |
| 01:50 | _rmk_ | okay, which bit of the planet are you on? :) |
| 01:50 | crypt0s | the north american bit haha |
| 01:50 | crypt0s | specifically the eastern coastal portion |
| 01:51 | _rmk_ | ok, so... it may be better to ask during your morning time when more people are about here... I'm not going to be around much longer. |
| 01:51 | _rmk_ | since it's almost 1am here |
| 01:51 | crypt0s | ah |
| 02:15 | kuguar-tsk | yesterday tried to work in android. why then after one hour vayfay lost access point. |
| 02:16 | kuguar-tsk | vayfay=wifi, sorry, google translate |
| 02:34 | kaipee | anyone know what wireless chip is in the i4Pro? |
| 05:17 | Coburn | > Linux cubox 3.13.1-rmk-cts #2 PREEMPT Fri Jan 31 04:17:37 CET 2014 armv7l |
| 05:17 | Coburn | Jan 31 04:22:10 localhost kernel: armada-drm armada-510-drm: No connectors reported connected with modes |
| 05:17 | Coburn | We're onto something! |
| 05:18 | Coburn | /dev/fb0 exists |
| 05:19 | Coburn | :D |
| 05:36 | Coburn | oh sweet |
| 05:36 | Coburn | framebuffer console |
| 05:42 | jnettlet | great |
| 05:43 | Coburn | now I just need to compile the armanda driver |
| 05:44 | Coburn | if this works, rmk will be my hero |
| 06:10 | jnettlet | Coburn, _rmk_ should be everyone's hero |
| 06:11 | Coburn | heh |
| 06:11 | pahartik | Coburn: I am interested about building kernel as well, currently running custom "Linux 3.6.9" |
| 06:11 | Coburn | So close! |
| 06:12 | Coburn | pahartik: normally, building your own kernel is for your own configuration, ie. jukebox, PVR, etc. |
| 06:12 | Coburn | Fun but can be VERY annoying at compile errors |
| 06:12 | Coburn | pahartik: the biggest part of the cubox you lose when you use a new kernel is the GPU |
| 06:13 | jnettlet | Coburn, patience I am working on that. |
| 06:13 | Coburn | if you can live without the GPU side of the cubox, then sure. but it's a feature that could be required. in my case, i needed a 3.11+ kernel with the hiface dac driver for my client. |
| 06:14 | Coburn | and i also needed hdmi. I was going to go to intel atom, sink another $300 into that, but rmk saves the day. |
| 06:14 | Coburn | now it's saying "/usr/bin/ld: cannot find -lGAL" which is odd |
| 06:14 | pahartik | Coburn: Got my "SolidRun CuBox Pro" ~10 days ago, just figuring it out |
| 06:14 | Coburn | but I got closer than I did yesterday. |
| 06:14 | Coburn | pahartik: once you know what you want to use it for, then you can see your options. |
| 06:15 | jnettlet | Coburn, that is the driver looking for the Vivante GPU drivers. |
| 06:16 | jnettlet | Coburn, if you aren't using the GPU then try installing the xf86-video-modesetting driver |
| 06:19 | pahartik | Coburn: Not sure yet, X11 with at least 2D acceleration... Could use video output too, though I already have "Raspberry Pi" for video output (MPEG-2 and H.264) |
| 06:22 | Coburn | jnettlet: I fail to see what this modesetting driver is. |
| 06:22 | Coburn | I have a kernel that gives me HDMI output. Can I install the modesetting driver, and then what does Xorg do with that? |
| 06:22 | jnettlet | Coburn, ? |
| 06:23 | Coburn | wait |
| 06:23 | Coburn | stratch that thought |
| 06:23 | Coburn | Ha! |
| 06:23 | Coburn | It actually compiled the xf86 driver! |
| 06:23 | jnettlet | nothing. It uses the cpu to render the framebuffer on the screen, and interfaces with KMS to change resolutions and allocate framebuffers |
| 06:25 | paharti | 06:25 * pahartik has successfully configured and built Linux kernels for at least 7 architectures during last ~15 years |
| 06:26 | Coburn | [ 3031.711] (EE) Failed to load /usr/lib/xorg/modules/drivers/armada_drv.so - libGAL.so missing? |
| 06:26 | Cobur | 06:26 * Coburn gets out the hammer |
| 06:27 | jnettlet | Coburn I told you it is trying to link to the binary vivante drivers. |
| 06:27 | Coburn | yep, but it compiled, now Xorg wants to find those drivers |
| 06:27 | jnettlet | you don't have GPU support in your kernel so just use the generic modesetting driver |
| 06:29 | Coburn | WINNAR |
| 06:29 | Coburn | I WIN! |
| 06:29 | Coburn | I CAN HAS XORG RUNNING. |
| 06:29 | Coburn | Woohoo... |
| 06:30 | Coburn | even takes me back to the framebuffer shell |
| 06:30 | paharti | 06:30 * pahartik did recently read "Armada DRM/KMS Driver Might Now Be Ready" -article and thought it was about time to order device |
| 06:31 | Coburn | jnettlet: thanks for your advice though. while i persisted with rmk's wrapper, i will keep your thing in mind. |
| 06:32 | jnettlet | pahartik, don't rely on Phoronix for any OSS reporting at all. |
| 06:32 | pahartik | jnettlet: Why is that? |
| 06:32 | jnettlet | I am working on releasing my 3.10 kernel with the latest vivante drivers that will work with the KMS driver very soon. |
| 06:33 | jnettlet | pahartik, he is a very biased reporter. He lacks any ethics and understanding about the OSS software development landscape |
| 06:33 | pahartik | jnettlet: That is very much appreciated |
| 06:34 | jnettlet | Actually his reporting has hurt many relationships between companies and their respective OSS communities |
| 06:34 | pahartik | jnettlet: Situation acknowledged |
| 06:35 | jnettlet | and his benchmarks he pushes constantly with "Open Benchmarking" are completely flawed. Many of the top Linux developers have spoken out about it. |
| 06:37 | pahartik | jnettlet: I try to avoid referring to that site then |
| 06:38 | Coburn | the thing is |
| 06:38 | Coburn | in my eyes |
| 06:38 | Coburn | we need a non-binary driver |
| 06:38 | Coburn | that we can compile for the kernel |
| 06:39 | jnettlet | Coburn, we are working on it. etnaviv It takes time though. |
| 06:40 | Coburn | yeah, but this poisons OSS |
| 06:40 | jnettlet | what poisons OSS? |
| 06:40 | Coburn | I mean, I want to have a device that has a GPU that doesn't lock me into using a specific kernel version |
| 06:41 | jnettlet | The kernel part of the vivante driver is OSS and doesn't lock you into a specific kernel version. |
| 06:41 | Coburn | so what does though? |
| 06:41 | jnettlet | It is just not acceptable to be merged into mainline. |
| 06:41 | Coburn | why not? |
| 06:42 | jnettlet | because it is not written to kernel standards and it's only user interface is not OSS right now. |
| 06:42 | pahartik | jnettlet: What is difference between that "Linux 3.10" driver you are working on and driver to be included on "Linux 3.14+"? |
| 06:42 | jnettlet | we are working on a completely OSS layer, but GPU drivers take time |
| 06:43 | pahartik | jnettlet: Or did you just describe that? |
| 06:43 | jnettlet | pahartik, nothing. I am maintaining a 3.10 long term support kernel that backports all the current work we have done for Marvell and Freescale SOC's |
| 06:43 | jnettlet | trying to provide a stable full-featured kernel while we finish the work needed to merge things into mainline in the future. |
| 06:43 | pahartik | jnettlet: Oh, very good |
| 11:32 | MikeSeth | Finally got an external SD card adapter, now going to test all OS images and check out common problems |
| 11:36 | jnettlet | good luck with that |
| 11:50 | jnettlet | we may break 100 for the weekend. |
| 11:51 | _rmk_ | ? |
| 11:52 | dshankar | (think he's referring to # in this channel) |
| 11:52 | _rmk_ | ah |
| 11:55 | _rmk_ | I see Coburn has had success :) |
| 12:16 | jnettlet | _rmk_, in some sense. I am not sure that he has actually succeeded with GPU acceleration |
| 12:19 | jnettlet | _rmk_, do you have your latest 3.13 patchset broken out uploaded somewhere? |
| 12:46 | jnettlet | found it nevermind |
| 12:48 | _rmk_ | for the cubox-i? |
| 12:49 | jnettlet | yeah. you changed the name a bit so I was just looking past it. |
| 12:49 | jnettlet | all set now |
| 12:50 | _rmk_ | I gave ojn's patches for dealing with resets/clocks/power for sdio wifi cards a go last night and hit problems... because the imx esdhc driver does its own thing rather than using the generic stuff |
| 12:51 | _rmk_ | felt like I was hitting my head against a brick wall :p |
| 12:52 | jnettlet | do you have a link to the patches? |
| 12:52 | _rmk_ | yes, I should be able to pick them out from an archive :) |
| 12:52 | jnettlet | well I can do that. I figured you had them handy |
| 12:54 | _rmk_ | http://archive.arm.linux.org.uk/lurker/mbox/20140120.035653.2e0f6141.rfc822 |
| 12:55 | _rmk_ | patch 3 doesn't seem to exist, and patch 2 was just for dw_mmc.c |
| 13:04 | jnettlet | It is on the MMC mailing list. http://comments.gmane.org/gmane.linux.kernel.mmc/24728 |
| 13:05 | jnettlet | just some device-tree entries for the chromebook dtsi |
| 13:12 | jnettlet | _rmk_, can we just do this http://fpaste.org/73355/91170299/ to parse the generic device-tree? |
| 13:18 | _rmk_ | I did wonder about that, but the imx esdhc code is parsing some of those generic properties itself too |
| 13:24 | jnettlet | yeah that will need to be cleaned up. |
| 13:51 | dv_ | jnettlet: you mentioned some userspace CMA allocator API for your kernel a while ago |
| 13:52 | jnettlet | dv_, that is what _rmk_'s latest libbmm is doing |
| 13:52 | dv_ | I think the same API is now used by _rmk_'s vmeta library, so for gst-vmeta, I do not need to change anything |
| 13:52 | dv_ | what about imx? |
| 13:52 | jnettlet | we should use the same |
| 13:52 | dv_ | libbmm on imx? |
| 13:52 | jnettlet | sure |
| 13:52 | jnettlet | libbmm for everything |
| 13:53 | dv_ | uh okay |
| 13:53 | dv_ | I still associate bmm with marvell for some reason |
| 13:53 | jnettlet | it was actually originally written by samsung |
| 13:53 | dv_ | but okay, that makes things easy. if the gstreamer-imx build system detects bmm during autoconfiguration, it will use this allocator instead of the others |
| 13:54 | dv_ | so I take it phycontmem is obsolete? |
| 13:55 | jnettlet | oh you might have missed that diatribe. Yeah _rmk_ and I decided we could do things in a way that had a chance of being merged upstream. |
| 13:56 | jnettlet | the bmm kernel module allocates the memory through CMA and then exports it to userspace through a dmabuf fd |
| 13:57 | jnettlet | it is then up to userspace to pass that back into the binary blobs kernel interface to get back a physical address for it. |
| 13:58 | jnettlet | so we will have to patch imx-vpu to be able to pass back a physical address if we give it a dmabuf fd |
| 13:58 | jnettlet | _rmk_, ^ That was the final workflow you implemented for vMeta correct? |
| 13:59 | dv_ | yeah I remember that. what I missed was that phycontmem is obsolete |
| 14:01 | dv_ | jnettlet: in the imx case, I'd prefer to use bmm directly in gstreamer-imx . but that does not collide with patching imx-vpu |
| 14:01 | dv_ | you would patch the imx-vpu allocators. I would not use them. the reason is that I use both VPU and IPU, and these have different allocators atm. (for using the VPU allocators I need to initialize the VPU library etc.) |
| 14:02 | dv_ | but as said, that would not affect you |
| 14:02 | jnettlet | so you are handling the IOCTL's directly in your gstreamer module? |
| 14:02 | dv_ | atm yes, for the IPU |
| 14:02 | dv_ | for VPU, I am using VPU_DecGetMem and VPU_EncGetMem |
| 14:02 | jnettlet | does the IPU pass back PA's or the VPU? |
| 14:03 | dv_ | PA's |
| 14:03 | jnettlet | physical addresses |
| 14:03 | dv_ | both give me physical (and virtual) addresses |
| 14:03 | jnettlet | then they both should grow dmabuf ioctl's I guess. |
| 14:03 | dv_ | and for using the ipu ioctls, I need to open /dev/mxc_ipu |
| 14:03 | dv_ | so you see I couldnt use either of then as "universal" physmem allocators in the plugins |
| 14:04 | dv_ | aand, enter bmm, which would be one universal allocator for all of them. much cleaner. |
| 14:04 | jnettlet | and possibly upstreamable as it doesn't expose PA's |
| 14:04 | dv_ | there is one big problem though |
| 14:05 | dv_ | imx-vpu controls the VPU directly through its registers. in user space. |
| 14:05 | dv_ | as part of that, it passes physical addresses to registers |
| 14:05 | jnettlet | yep |
| 14:05 | dv_ | so you still need to expose PA's to user space |
| 14:05 | _rmk_ | jnettlet: yep |
| 14:05 | dv_ | because there is no ioctl here that you could intercept |
| 14:06 | jnettlet | dv_, let me look at the code quick. |
| 14:07 | dv_ | unfortunately it also seems that the buffer pool logic I had to circumvent is hardcoded into the VPU |
| 14:07 | dv_ | which is not so nice for me |
| 14:09 | jnettlet | dv_, I am looking at the ipu code and there is IPU_ALLOC, and IPU_FREE just like the VPU |
| 14:10 | dv_ | where? |
| 14:11 | dv_ | ioctl(fd_ipu,IPU_ALLOC,&val) |
| 14:11 | dv_ | ? |
| 14:11 | jnettlet | both would just need to grow IPU_DMABUF_IMPORT IPU_DMABUF_RELEASE |
| 14:11 | dv_ | https://github.com/Freescale/gstreamer-imx/blob/master/src/ipu/allocator.c#L64 |
| 14:11 | jnettlet | drivers/mxc/ipu3/ipu_device.c |
| 14:12 | dv_ | okay, for IPU you could add dmabuf |
| 14:12 | dv_ | you'd need to extend the ipu_task struct |
| 14:13 | dv_ | task.input.paddr task.output.paddr -> task.input.dmabuf_fd task.output.dmabuf_fd |
| 14:14 | dv_ | jnettlet: ah yes, there is one more detail pertaining to that driver: it considers blitting without transformation an error |
| 14:14 | jnettlet | I would probably just append the dmabuf_fd to it |
| 14:14 | jnettlet | wow that is awesome |
| 14:14 | _rmk_ | you don't want to store the fd inside the kernel - instead, you want to store at last two things: the dma_buf_attachment and the scatterlist table |
| 14:14 | _rmk_ | least |
| 14:14 | dv_ | that is, for example if all parameters (width, height, format etc) are the same, only the physical address is different, then the driver reports an error |
| 14:15 | jnettlet | _rmk_, I was planning on just working off what you have done with the vmeta char driver |
| 14:15 | dv_ | which is actually stupid. it means that simple frame copies are disallowed |
| 14:15 | dv_ | so if you extend that driver, also remove this restriction please :) |
| 14:16 | dv_ | oh, and in case you stumble upon ipu-lib: ignore it. it doesnt work for imx6. |
| 14:16 | jnettle | 14:16 * jnettlet wonders if it is a restriction because the dma engine can't handle overlapping memory regions |
| 14:16 | jnettlet | great |
| 14:16 | dv_ | I dont think so. if for example the destination region is just one pixel wider or narrower its all ok again |
| 14:17 | dv_ | I think this is a design flaw. if all parameters _including_ the physical address were the same, or overlapping, then it would be an error, yes. |
| 14:20 | jnettlet | dv_, what channel are you using for the task? |
| 14:20 | jnettlet | MEM_PP_MEM? |
| 14:20 | dv_ | I'm not choosing any |
| 14:21 | dv_ | default I guess? |
| 14:21 | dv | 14:21 * dv_ cannot look it up atm unfortunately - running windows right now |
| 14:22 | jnettlet | dv_, no problem. When you get a chance send me the command sequence your are sending to the IPU and I will track down where things are going wrong. |
| 14:22 | jnettlet | I am plenty busy at the moment. |
| 14:22 | dv_ | actually you can see it in the file I linked |
| 14:23 | dv_ | https://github.com/SolidRun/linux-imx6/blob/imx_3.0.35_4.1.0/include/linux/ipu.h <- this is the API I use |
| 14:24 | dv_ | well, gotta run. ttyl |
| 14:33 | jnettlet | dv_, oh yeah if you aren't doing a crop, or a rotate, or something else it spits you right back out. |
| 14:34 | jnettlet | I wonder why they do that. |
| 14:50 | davorin | nice...first customer with a dead i4p after 10 hours using geexbox... |
| 14:50 | davorin | there a temp overheat shutdown thingie on the i.mx6 lik eon rpi? |
| 14:52 | jnettlet | davorin, yep |
| 14:52 | jnettlet | how is it dead though? Did it shutdown and won't power on? Any lights come on? |
| 14:58 | davorin | yepp..no led on now... |
| 14:59 | davorin | only spdif led visible... |
| 15:00 | davorin | guess the thermal shutdown can't be revoked.... |
| 15:02 | jnettlet | that doesn't sound like thermal shutdown. Can they try the sdhc card in another computer? |
| 15:03 | jnettlet | or have them try it a couple of times waiting about 4 seconds in between each try. |
| 15:03 | davorin | #define that doesn't sound like thermal shutdown |
| 15:04 | jnettlet | it powering on the spdif but not the front light. |
| 15:04 | davorin | so a thermal shut will not light the spdif led? |
| 15:06 | jnettlet | a thermal shutdown happens well before any damage can be accrued to the chip. |
| 15:06 | jnettlet | So it just shutting itself off is more than enough time for it just do a normal boot again |
| 15:08 | jnettlet | but beyond that there are thermal checks for the gpu and soc that will limit them if the device is getting too hot. |
| 15:15 | davorin | you know how customers are....(o; |
| 15:15 | davorin | hard to convince them to try everything out, especially when they are technically not that blessed... |
| 15:16 | davori | 15:16 * davorin hates to send a replacement... |
| 15:19 | jnettlet | yep, one of the downfalls of modern society. All this technology and 90% of the population has no idea how it works |
| 15:21 | davorin | http://www.bash.org/?244321 |
| 15:21 | dlloyd | ugh, somehow i knew which one that was before clicking |
| 15:24 | davorin | hmm...solidrun seems to be extremely busy these days....no feedback since ages (o; |
| 15:26 | gori | jnettlet: make that closer to 99%... |
| 15:31 | _rmk_ | jnettlet: or want to know how it works... that's for "other people" to know |
| 15:41 | Bluerise | at least they know to always blame someone else ;) |
| 16:24 | jnettlet | _rmk_, it looks like there is another patchset that brings more of the random device-tree flags into mmc_of_parse() |
| 16:25 | jnettlet | that might be enough to sort out the mxc ehci driver. |
| 17:16 | kuguar-tsk | where can I get |
| 17:17 | kuguar-tsk | nightly builds |
| 17:17 | jnettlet | nightly builds? |
| 17:18 | kuguar-tsk | http://imx.solid-run.com/forums/viewtopic.php?f=6&t=500#p3001 |
| 17:19 | jnettlet | kuguar-tsk, that is a nightly xbmc build for android. If you google xbmc android you will find them. |
| 17:21 | kuguar-tsk | ok |
| 17:22 | kuguar-tsk | now i try use cubox as android tv box. all very slows |
| 17:23 | gwolf | kuguar-tsk: In my experience, most of the slowness you experience is due to slow storage |
| 17:23 | gwolf | Do you have a class-10 SD card? |
| 17:23 | gwolf | (they are hard to get in my country, I'm stuck to class-4 ones) |
| 17:23 | kuguar-tsk | gwolf, yes |
| 17:24 | kuguar-tsk | sony, class 10+ |
| 17:24 | gwolf | Oh... So that should not be the problem :-) I was to suggest you to install just the loader to the SD, and the system to external media (say, a ESATA or USB HDD) |
| 17:24 | jnettlet | I should put this on the wiki, but it is not necessarily the class speed that is important. That class is based on max sustained write speed. |
| 17:25 | jnettlet | What you really want to do is look at the speed of random 4k writes to really maximize performance |
| 17:25 | kuguar-tsk | my lenovo p770 much faster |
| 17:26 | jnettlet | kuguar-tsk, which CBi did you buy? |
| 17:27 | kuguar-tsk | jnettlet, i4pro |
| 17:28 | jnettlet | it should be plenty fast although there are many variables. For one your lenovo p770 is driver a much lower resolution display. |
| 17:28 | kuguar-tsk | 720p |
| 17:29 | jnettlet | but beyond that the Android builds are very new and the developer community is more focused on Linux support |
| 17:29 | kuguar-tsk | oh, no, i'm wrong |
| 17:29 | kuguar-tsk | 540x960 |
| 17:30 | kuguar-tsk | but he have only 2 cores |
| 17:32 | kuguar-tsk | actually, i bought CBi to use like network video recorder with 1-2 ubiquiti aircam |
| 17:32 | jnettlet | but you haven't even defined what "slow" is to you. The Android builds are not final, but just development previews |
| 17:37 | gwolf | jnettlet: Given you are currently answering questions, I'll also bomb you with mine ;-) |
| 17:37 | jnettlet | shoot |
| 17:38 | gwolf | I'm also an ARM newbie... So, I'm trying to understand several details on uboot |
| 17:38 | gwolf | one of them that baffles me constantly is... How to set some environment variables.. and why some things don't work :-| I'll explain... |
| 17:38 | jnettlet | really I would recommend against it :-P |
| 17:39 | gwolf | I mostly use the cubox (i4) thorugh the serial port, as I only have a HDMI screen at home (and I don't have much free time to play with it) |
| 17:39 | jnettlet | fair enough |
| 17:39 | gwolf | Thing is, STDIN is not accepted via serial. I get the boot messages sent both to the terminal and to HDMI |
| 17:39 | jnettlet | you can connect it to a dvi monitor with an adapter |
| 17:39 | gwolf | But whenever I type anything to it, it goes ignored |
| 17:39 | jnettlet | STDIN when in linux or u-boot? |
| 17:40 | gwolf | In both :) Right now, in uboot... |
| 17:40 | gwolf | Some days ago, I connected a USB keyboard. I was able to get output via serial terminal, input via USB keyboard |
| 17:40 | gwolf | but right now, even that does not work |
| 17:40 | jnettlet | so you type into it and nothing shows up on the screen? |
| 17:40 | gwolf | right |
| 17:40 | jnettlet | what terminal emulator are using? |
| 17:41 | gwolf | I get the "type anything", but be it via console or via keyboard, I don't get a reply |
| 17:41 | gwolf | minicom |
| 17:41 | jnettlet | and you have hardware flow control disabled? |
| 17:41 | gwolf | It *did* work some days ago with the external keyboard, but right now even that does not work (and that's why I thought it would be a env variables thing) |
| 17:42 | gwolf | yes, hardware flow control is enabled. Should I disable it then? |
| 17:42 | jnettlet | disable it and see if it makes a difference. |
| 17:42 | gwolf | Great! Yes, it makes me feel dumber :-P |
| 17:43 | jnettlet | excellent. |
| 17:43 | gwolf | OK, that allows me to start playing. I want to build a "clean" Debian image, be it through debian-installer (if I get it to boot) or debootstraping in a different machine and just completing the setup in the cubox |
| 17:43 | jnettlet | for usb try the second port down |
| 17:43 | gwolf | i'll update you on this later |
| 17:43 | jnettlet | okay |
| 17:43 | gwolf | Oh, does that make a difference? Hm, didn't think of it! |
| 17:44 | gwolf | right, lower USB port works. Thanks for the double-insight! :) |
| 18:47 | davorin | bugger...kickstarter isn't available outside us/ca/nz... |
| 18:48 | gwolf | davorin: which kickstarter? I am in Mexico and took part in the Cubox-i kickstart... |
| 18:49 | davorin | kickstarter.com |
| 18:49 | davorin | i mean to start a project... |
| 18:50 | jnettlet | davorin, http://www.indiegogo.com/ |
| 18:50 | davorin | yeah, know that one and i am already registered there... |
| 18:50 | davorin | took part in the cubie project there... |
| 18:51 | davorin | long time i used 3d software.... |
| 18:52 | davorin | but probably better with a nice 3d product picture (o; |
| 18:52 | gwolf | oh |
| 19:52 | crypt0s | so anyone here have gentoo on their cubox-i |
| 20:09 | MikeSeth | there isn't an image but it should be possible to create one |
| 20:10 | MikeSeth | however compilation of all packages won't be very.. rapid |
| 20:10 | MikeSeth | gwolf: I've built a clean debian image but I can't get it to boot and have no way to diagnose it |
| 20:11 | gwolf | MikeSeth: What's wrong with it? |
| 20:11 | gwolf | MikeSeth: I'm currently running the second stage debootstrap installation... It is taking quite long (as expected on my SSD), but will share it as soon as I can :) |
| 20:11 | MikeSeth | gwolf: I am not certain, the bootloader fails to start the kernel, but because there's no serial support on my cubox and a bug in uboot that makes hdmi barf on my display, I can't see what's wrong |
| 20:11 | gwolf | I also want to check the real size requirements... |
| 20:12 | gwolf | MikeSeth: oh :( Yes, I thankfully have an i4, which makes the task easier :) |
| 20:12 | gwolf | (and faster!) |
| 20:14 | MikeSeth | oh, I did the build in a vagrant vm |
| 20:14 | gwolf | I'd expect an emulated ARM to be quite slow as well :-| |
| 20:14 | MikeSeth | I cross-compiled |
| 20:15 | gwolf | ah, right. I saw your post on that -- I didn't want to go through all of that :) |
| 20:15 | gwolf | After all, the binary packages are ready... I'm not building my own kernel, true... |
| 20:18 | hste | MikeSeth: I made one a time ago, but if I remember right I had to add ssh and dhcp so that I could ssh into it |
| 20:20 | MikeSeth | hste: it won't get past the second bootloader stage so that won't solve my problem |
| 20:21 | hste | MikeSeth: if u look into http://stende.no-ip.info/files/buildgk802.sh you can see how I made a wheezy image |
| 20:22 | MikeSeth | that's more or less what I did, though this gives me an idea |
| 20:23 | gwolf | A question: I'm a newbie to the ARM platform, but... Has anybody tried installing with the Debian Installer? Why not? |
| 20:24 | MikeSeth | gwolf: you mean live on a cubox? |
| 20:24 | gwolf | right |
| 20:25 | MikeSeth | I don't think there's an installer with the kernel that supports imx6 hardware |
| 20:25 | hste | MikeSeth: I have one plain debootstrapped here of jessie, http://stende.no-ip.info/files/jessie.tgz |
| 20:25 | gwolf | Oh, I expected the needed compatibility part to be only the bootloader. I see. |
| 20:25 | MikeSeth | also, because of how cubox's boot sequence is hard programmed, the image needs to be specifically modified for the cubox |
| 20:26 | MikeSeth | hste: oh that may come useful, does it have spl uboot in it? |
| 20:26 | gwolf | Ok... I still have quite a bit of learning to do :) |
| 20:28 | hste | MikeSeth: nope need to add kernel and uboot etc |
| 20:33 | hste | MikeSeth: You can also look into this http://projectgus.com/2013/05/debian-installer-for-zealz-gk802-android-tv-quad-core-arm-minipc/ |
| 20:41 | MikeSeth | thanks, this is useful |
| 21:21 | crypt0s | MikeSeth: I'm cross-compiling so gentoo shouldnt be an issue other than getting the kernel build flags right |
| 21:22 | crypt0s | I'm reading _rmk_'s google plus and it looks like 3.14 might have mainline support for cubox-i |
| 21:22 | crypt0s | but it's not stable yet so kinda debating if I want to deal with it and just work around issues with ethernet or if I want to try unstable kernel |
| 21:34 | MikeSeth | Turns out the SPL second stage won't proceed if there's no valid partition table on SD |
| 21:35 | MikeSeth | so red light not coming up may very well indicate a partition table problem |
| 22:45 | MikeSeth | ten bags of edible cocks! |
| 22:45 | MikeSeth | I bricked my samsung tv |
| 22:45 | MikeSeth | so I pulled my old one |
| 22:45 | MikeSeth | and on that the uboot hdmi problem is gone |
| 23:12 | _rmk_ | MikeSeth: how did you brick it? |
| 23:46 | ojn | _rmk_: threw a brick through it, perhaps? |
| 23:49 | _rmk_ | maybe |
| 23:53 | MikeSeth | _rmk_: went into the debug menu to see the resolution and accidentally pressed firmware update for the micom unit |
| 23:56 | _rmk_ | erk... unfortunate. I assume this menu isn't normally user accessible? |
| 23:56 | MikeSeth | no, though it takes a whopping 3 button sequence to get into it |
| 23:57 | MikeSeth | I'll turn it in for the warranty service |
| 23:57 | MikeSeth | basically eeprom needs to be rewritten over i2c |
| 23:58 | MikeSeth | the genius samsung engineers *first* zero the eeprom and *then* ask for an USB drive with an image update |
| 23:58 | _rmk_ | wow |