00:14 | LangeOortjes | coinsen, the dt kernel requires you to compile and install the u-boot and SPL as documented on the wiki. The newer u-boot is able to boot from the zImage and loads the correct dtb file unto memory |
00:16 | LangeOortjes | mmm okay, he downside of muting parts and joins is that I am now talking to a ghost :). The upside is that I can go to sleep now |
02:11 | coinsen | LangeOortjes: thank you. i read your answer by accident in the irc logs |
12:04 | map7 | Does the CuBox Xubuntu 12.10 in the CuBox installer come with the GPU drivers pre-installed? |
12:10 | aplund | rabeeh: I had the question about how the pins were connected to the peripherals a little while ago. You said you had some info for me. |
13:03 | coinsen | hi there |
13:06 | coinsen | ive finally managed it to get my new kernel working (3.10) |
13:07 | coinsen | however, i dont have a video output any longer via hdmi |
13:07 | coinsen | i've connected a 19 inch monitor with hdmi <-> dvi adapter to my cubox which is capable of doing 1280x1024, but although ive changed the uEnv.txt, my monitor stays "black", in standby mode |
13:09 | jnettlet | coinsen, it is a known problem I am working on a patch. Can you please post the output of dmesg and the command fbset? |
13:10 | coinsen | yes, just a moment |
13:12 | coinsen | jnettlet: https://gist.github.com/coin3d/9410378 |
13:13 | coinsen | with the old kernel, i was forced to use 640x480. but at least it produced a picture on my monitor :) |
13:14 | jnettlet | coinsen, oh interesting so it is setting the resolution properly, but your monitor doesn't like it. |
13:14 | coinsen | jnettlet: i thought the same, yes |
13:15 | coinsen | btw my uEnv.txt is: mmcroot=/dev/mmcblk0p2 rootwait rw console=tty1 consoleblank=0 video=mxcfb0:dev=hdmi,1280x1024M@60 dmfc=3 |
13:21 | jnettlet | hmmm using those timings on my hdmi -> dvi adapter produces a picture. |
13:21 | jnettlet | let me see what my monitor thinks it is doing |
13:26 | jnettlet | coinsen, can you also get me the output of /sys/devices/soc0/soc.1/20e0000.hdmi_video/edid ? |
13:30 | coinsen | jnettlet: i added it in the gist |
13:35 | jnettlet | coinsen, what model monitor is this? The edid says it doesn't support 1280x1024, but 1280x768 |
13:35 | jnettlet | Established timings supported: |
13:35 | jnettlet | 640x480@60Hz |
13:35 | jnettlet | 640x480@67Hz |
13:35 | jnettlet | 800x600@75Hz |
13:35 | jnettlet | 832x624@75Hz |
13:35 | jnettlet | 1280x768@87Hz |
13:35 | jnettlet | 1024x768@60Hz |
13:36 | coinsen | its a pretty old one, wait a moment |
13:38 | jnettlet | coinsen, could you also remove that video= option form you uEnv.txt and see what gets detected? |
13:38 | jnettlet | s/form/from/ |
13:39 | coinsen | i dont think its 1280x768, because that would mean its a widescreen monitor, wouldnt it? |
13:39 | coinsen | and its just an old 5:4 screen |
13:40 | coinsen | ok, i removed the video option and reboot now. |
13:43 | coinsen | its this one: http://www.prad.de/new/monitore/test-lge-l1970hr.html |
13:43 | coinsen | res is 1280x1024 |
13:44 | coinsen | what output do you need? |
13:49 | coinsen | fbset now gives 1280x720-60 |
13:49 | jnettlet | and no picture? |
13:49 | coinsen | however, the display is still in standby mode |
13:54 | jnettlet | coinsen, try video=mxcfb0:dev=hdmi,1024x768@60 |
13:54 | jnettlet | just curious if any resolutions work |
13:54 | jnettlet | I will have a proper fix this weekend. |
13:55 | jnettle | 13:55 * jnettlet bbl |
13:56 | coinsen | great, thank you. btw, are you a official cubox-i employee? |
13:56 | coinsen | i mean solidrun employee ;) |
14:04 | coinsen | no video output on 1024x768 as well :( |
14:11 | coinsen | ill now try to connect it to my TV |
14:11 | coinsen | :D |
14:15 | coinsen | tv works! |
14:17 | jnettlet | well the tv better work. it is just the hdmi->dvi setup that needs help. |
14:18 | LangeOor1jes | jnettlet: now that we are on the subject of hdmi-output. My 1080p Acer monitor is connected via HDMI yet the cubox outputs 720p |
14:20 | jnettlet | LangeOor1jes, the "safe" default value is 720p. You can try adding a video= line to your kernel commandline to force 1080p, or from the commandline run fbset -xres 1920 -yres 1080 |
14:26 | coinsen | jnettlet: are you sure that its the dvi hdmi combination, or just 5:4 monitor resolutions? |
14:27 | LangeOortjes | jnettlet: Then my monitor starts complaining about the input signal not being supported. Noticed that the refresh rate is decreased to 29Hz. So I halved the length of a pixel and then it worked |
14:33 | coinsen | argh, i dont have a wlan0 device with 3.10 kernel any longer :( |
14:37 | coinsen | OMFG. is it possible that the cubox-i has problems with some wifi channels? |
14:37 | coinsen | i started my wifi search and only found 2 out of about 8 networks |
14:38 | coinsen | then i changed the channel of my wlan from 13 to 1 |
14:38 | LangeOortjes | coinsen: but you managed to get wlan working in 3.10? |
14:38 | coinsen | and now the cubox recognizes it |
14:38 | coinsen | LangeOortjes: no, since the wlan0 device was missing, and my monitor output was gone as well, i decided to boot back to 3.0 |
14:42 | coinsen | btw, can anyone tell me the difference between all the gpu drivers available? "dfb", "fb", "wl", and "x11"? |
14:46 | slangen | coinsen: have you checked "dmesg" with the 3.10 kernel. maybe there were problems with loading the firmware for the wifi. happened to me. |
14:46 | jnettlet | coinsen, a little of both. the older "pure" dvi monitors need vesa timed resolutions. Currently we are only providing CEA based resolutions that are used by HDMI |
14:49 | coinsen | jnettlet: ah, okay. btw, are you a solidrun employee? |
14:50 | jnettlet | coinsen, nope just part of the community. |
14:50 | coinsen | slangen: hmm, not sure. i had the same firmware as in 3.0, stored in /lib/firmware/brcrm/ - but there was a huge delay when booting, it gave some output regarding the wifi stuff |
14:51 | coinsen | there are some other people complaining about that in the forums as well |
14:51 | slangen | coinsen: if there was a delay of about a minute |
14:51 | coinsen | jnettlet: cool. thanks for your effort. |
14:51 | jnettlet | coinsen, the firmware names changed. |
14:51 | coinsen | jnettlet: damn! where did you get the new firmware from? |
14:52 | jnettlet | it is the same firmware just different names. check dmesg output it should complain there. |
14:52 | jnettlet | although the wifi driver needs work. I just haven't had the time to finish it. |
14:54 | slangen | jnettlet: what would interest me about the firmware blob is: why are there two files needed? and where is the offical place to find the nvram.txt or whatever it name should be? |
14:56 | jnettlet | slangen, well one the the firmware, and the .txt file is the configuration for the firmware. This allows vendors to tweak some values of the hardware without needing a new binary. |
15:04 | slangen | jnettlet: thanks for the explanation. is there an official source for the .txt file? because it is not here: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/brcm |
15:04 | slangen | when i installed it on my system i had to look some packages of other distributions to find it (i'm trying to run gentoo) |
15:07 | jnettlet | slangen, I am not sure who officially carries that. It may be possible to just create a blank file for the firmware defaults. I don't play around with broadcom too much |
15:08 | slangen | jnettlet: no worries, i just went on to hijack the question of coinsen :) |
15:12 | slangen | jnettlet: but if i can ask some more question as i'm currently running your kernel. how is it possible to run the graphics driver with hardware acceleration? sorry for the broad question. |
15:12 | coinsen | ;) |
15:14 | jnettlet | slangen, if you can't get help from the forums or from someone else here I will have more time Sunday. I just don't have time today. |
15:15 | slangen | okay, cool, thanks again |
15:18 | mk01 | jnettlet: vpu_*_datasheet.pdf files are VPU/IPU or IPU is separate? ... ach just checked it, there is nothing. was expecting some description of its internal states, IPU_INT_STAT_* for instance .will I find something in the driver source driver files (what I now trying), or should I go directly to web ? |
15:20 | mk01 | jnettlet: also please, should one expect any SD card issues with 3.10.30 (even if corner cases)? as I have some IOEs and tried all SD i have |
19:05 | davorin | iltaa... |
23:38 | aplund | I'm still trying to work on turning off the SPDIF output in the 3.10 kernel. But I don't have sufficient information about how the thing works. Does anyone know what I should be looking for? Is it the SPDIF Control registers? Or should I try and turn off the clock source? |
23:38 | aplund | Or something else? |
23:39 | mk01 | and if you compile SPDIF driver into kernel what happens? it get initialized during u-boot ? |
23:40 | aplund | yeah. I think so. |
23:40 | aplund | compiled into the kernel iirc. I'm using the cubox-i*_defconfig from jnettlet's branch. |
23:40 | mk01 | then remove it from setting |
23:41 | mk01 | or remove SPDIF section from imx6q-cubox-i.dtb source file |
23:41 | mk01 | there are device mappings |
23:42 | aplund | hmm... ok. I'll see what that does. But I would rather like to turn it back on when neeeded. |
23:42 | mk01 | arch/arm/boot/dts/imx6dl-cubox-i.dts |
23:43 | mk01 | sorry this one arch/arm/boot/dts/imx6q-cubox-i.dts |
23:43 | mk01 | what is bothering you on 5he fact it is on ? |
23:44 | aplund | just the location (it's bothering my wife). Can be quite bright at night time. |
23:44 | mk01 | ok |
23:44 | mk01 | then buy a SPDIF cable |
23:44 | mk01 | cut the cable |
23:45 | Juggie | why solve a problem with code that you can solve with a 1cmx1cm piece of black electrical tape. |
23:45 | coinsen_ | lol |
23:45 | aplund | meh. |
23:46 | mk01 | I like the cable + cut so just connector stays |
23:46 | mk01 | as more "professional" |
23:46 | mk01 | :D |
23:46 | Juggie | would disabling the driver even turn off the light |
23:46 | aplund | no |
23:46 | Juggie | that is questionable |
23:46 | aplund | tried that |
23:46 | aplund | and runtime power management is working but doesn't disable it |
23:47 | Juggie | i would doubt its controlable but maybe |
23:47 | aplund | there is a report that it is |
23:49 | mk01 | there is alsaucm |
23:49 | mk01 | which can go down to pins |
23:49 | mk01 | in the driver |
23:50 | mk01 | and control (set) them |
23:50 | mk01 | from userspacwe |
23:51 | mk01 | in arch/arm/boot/dts/imx6q-pinfunc.h |
23:51 | mk01 | you have pins |
23:51 | mk01 | #define MX6QDL_PAD_EIM_D22__SPDIF_OUT 0x0a8 0x3bc 0x000 0x6 0x0 |
23:51 | mk01 | #define MX6QDL_PAD_ENET_RXD0__SPDIF_OUT 0x1e4 0x4f8 0x000 0x3 0x0 |
23:51 | mk01 | #define MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x24c 0x61c 0x000 0x4 0x0 |
23:52 | mk01 | there are many "OUT" |
23:52 | mk01 | i was skipping clocks and "IN"s |
23:53 | mk01 | but I also have doubts |
23:53 | mk01 | as the light on spdif means the same as have power on analogue output |
23:53 | mk01 | which is there even on mute |
23:54 | mk01 | and If I check my AVs with spdifs |
23:54 | mk01 | all are with light on since poweron of AV |
23:54 | mk01 | regardless of output being active or not |
23:55 | mk01 | personally I would move wife to next room |
23:55 | mk01 | :) |