| 00:12 | wegas | heap_: blank as in black or blank as in no video signal? |
| 01:24 | heap_ | wegas: black as in black, but the reason was missing marvell-libgfx package |
| 02:23 | root_ | anyone know where to download the Cubox-i Vivante bin firmware? |
| 02:35 | mk01 | root: http://xbian.brantje.com/pool/devel/main/x/xbian-package-imx-lib-6q/xbian-package-imx-lib-6q_1.0.0-1_armhf.deb |
| 02:37 | crypt0s_ | mk01: sweet -- thx I'll note that |
| 02:37 | crypt0s_ | mk01: I was looking more for the ones im supposed to put in the firmware dir when i compile the kernel though |
| 02:37 | crypt0s_ | which i think are http://repository.timesys.com/buildsources/g/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q-1.1.0-ts/ |
| 02:38 | mk01 | crypt0s_: when you unpack the package |
| 02:38 | mk01 | you will find the ipu .fw files |
| 02:38 | mk01 | re VPU |
| 02:38 | crypt0s_ | mk01: ok -- and those go in /firmware in the kernel source, right? |
| 02:39 | mk01 | they go to "/lib/firmware/vpu" |
| 02:39 | crypt0s_ | ahhhh ok. now, does the kernel have to have support for them compiled in first as well? |
| 02:40 | crypt0s_ | mk01: as you can tell i'm kinda new to building embedded linux :) |
| 02:40 | mk01 | y |
| 02:40 | mk01 | just put them into the target dir |
| 02:41 | mk01 | kernel will load them (kernel module) accordingly when needed |
| 02:41 | mk01 | it is not relevant to compiling the kernel |
| 02:41 | crypt0s_ | mk01: Im trying to get X11 to use Graphics Accel in Gentoo |
| 02:42 | mk01 | via what driver ? |
| 02:42 | crypt0s_ | mk01: doesn't vivante provide a binary driver with a kernel shim? |
| 02:46 | mk01 | you can build DRM Vivante |
| 02:47 | crypt0s_ | mk01: Let me ask a stupid question real quick since Google didn't help me |
| 02:47 | crypt0s_ | mk01: what is DRM |
| 02:48 | mk01 | you will see this during building of the kernel |
| 02:48 | crypt0s_ | mk01: I'm building vanilla 3.13.1 |
| 02:48 | crypt0s_ | not the 3.10 provided kernel |
| 02:55 | mk01 | http://server.vijge.net/static/cubox/irclog/201401/cubox-20140129.html |
| 03:00 | crypt0s_ | mk01: i read the chatlog but dont understand how this helps me |
| 03:02 | mk01 | AFAIK the only possibility to run X11 on 3.13 would be through fb video driver |
| 03:02 | mk01 | but if you have zero experience, I would start with something confirmed (documented) to work |
| 06:14 | Dacto | For the 3.10.30 kernel, what should the uImage load address be? |
| 06:15 | Dacto | LOADADDR |
| 06:35 | mk01 | default uboot is 0x10800000 |
| 06:36 | mk01 | but more important is that the same addr is used for LOADING kernel and for STARTING it |
| 06:37 | mk01 | so that tftp/bootm/ext4load/load all commands use the same pointer |
| 06:38 | mk01 | again by default all use ${loadaddr} (if not specified otherwise) |
| 06:38 | mk01 | and loadaddr = 0x10800000 |
| 06:48 | Dacto | hmm I see |
| 06:49 | Dacto | I just merged back in the changes from the 3.0.35 kernel that uses mkuimage.sh |
| 06:49 | Dacto | locally, building now. |
| 07:13 | mk01 | Dacto: if you don't expect uImage to be started without the u-boot environment informations, you can also write 0x000000 to the uImage |
| 07:14 | mk01 | (if your concerns go to mkimage ussage/parameters) |
| 07:15 | Dacto | I was compiling it for use in u-boot. So /should/ I use 0 or does it actually not matter the value if using within a u-boot env? |
| 07:17 | mk01 | not matter |
| 07:17 | mk01 | in u-boot |
| 07:17 | Dacto | ok |
| 07:17 | mk01 | as set for cuboxi/humming |
| 07:18 | Dacto | ? |
| 07:18 | mk01 | sorry |
| 07:19 | Dacto | What do you mean as set for cbi/c1? |
| 07:19 | mk01 | doesn't matter for this particular case (cuboxi as per wiki) |
| 07:20 | mk01 | just wanted to make clear that "doesn't matter" is relevant for this specific device/uboot image |
| 07:21 | mk01 | "as set for ..." = "as preconfigured by default for cbi/c1" |
| 07:21 | mk01 | ok ? |
| 07:21 | Dacto | Meaning, that the uEnv/environment vars sets this? |
| 07:21 | Dacto | Yeah I understand |
| 07:22 | mk01 | yes, my first sentence was refering to that |
| 07:23 | Dacto | Okay, I was reading that here as well: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard#Booting_the_kernel |
| 07:23 | mk01 | (env setting is relevant in that case taking precedence over "uimage - written" infos) |
| 07:24 | mk01 | and what is the problem? you can't boot ? |
| 07:24 | Dacto | No, just need some infos on uImage loadaddr for compiling |
| 07:25 | Dacto | or during the process |
| 07:26 | mk01 | ok . so yes, you can put 0x108..... which is overridden by env setting ;) |
| 07:26 | Dacto | Haven't tried booting with 3.10.30 yet :P |
| 07:26 | mk01 | I tried but keeps resetting upon loading kernel and don't have serial console to look into it |
| 07:27 | mk01 | also had some .dbt conflicts (duplicates of busses) |
| 07:28 | Dacto | busybox on the forum suggested something about EARLY_PRINTK to help with debug? does the display work? |
| 07:30 | mk01 | in my case it gets rebooted prior screen configuration |
| 07:30 | mk01 | so I have to check with serial |
| 07:30 | Dacto | hmm ok, I wonder if mine will be any different |
| 07:33 | jnettlet | Dacto, I highly recommend switching to the zImage format with device-tree |
| 07:34 | Dacto | I am now using that, one in the 3.10.30 repo |
| 07:34 | mk01 | jnettlet: good morning ! |
| 07:34 | jnettlet | mk01, morning. I slept in a bit today |
| 07:34 | mk01 | we are just speaking about you |
| 07:34 | Dacto | Oh it's morning for you jnettlet? Good morning as well then. |
| 07:35 | jnettlet | Dacto, thanks |
| 07:35 | Dacto | I've just finished building the kernel, have yet to load it up though. |
| 07:36 | jnettlet | Build instructions are on my todo list this weekend |
| 07:36 | jnettlet | I am going to test the myriad of patches for the wireless driver in wireless-next as well. Hopefully get the wifi working better |
| 07:37 | mk01 | jnett: so this one options? "Use appended device tree blob to zImage" |
| 07:38 | jnettlet | you can use that if you want, but with the latest u-boot I fixed up the auto-boot so if you just build the .dtb file you can just drop that in / or /boot of your first partition of the sdhc card and it will get auto-loaded |
| 07:38 | jnettlet | as long as you use the default kernel names for it |
| 07:38 | mk01 | jnettlet: I wasn't looking into it in detail just cloned, but tell me, such patches as removed sleep & suspend clocks , bus clocking are in or not in ? |
| 07:39 | Dacto | Anything particularly different about building that differs? Assuming use of the imx_v7 config? |
| 07:40 | jnettlet | Dacto, I highly recommend you build with the customized imx_v7_cubox-i_hummingboard_defconfig I have included in my tree |
| 07:40 | jnettlet | that will enable all the hardware one the board. Everything that is on the SOC is defined to be built in. wifi and other optional things are built as modules |
| 07:40 | Dacto | Yes I was referring to that one, I apologize for not mentioning the filename in it's entirity |
| 07:41 | Dacto | entirety* |
| 07:41 | jnettlet | np |
| 07:41 | jnettlet | you can just say cubox-i defconfig |
| 07:43 | Dacto | Ah ok. Will do so from now on. |
| 07:44 | jnettlet | mk01, cpufreq, cpuidle and bus-freq are in. I am still sorting out how to handle power states best for the users. |
| 07:44 | mk01 | jnettlet: ok |
| 07:46 | mk01 | jnettlet: I'm just asking as when I started with 3.10.17 (fsc) I was following the ideas/steps from 3.13/3.14 patches |
| 07:46 | mk01 | jnettlet: which you provided with rmk. |
| 07:47 | jnettlet | mk01, well in my kernel upstream patches are taken from upstream, and rmk's work that isn't accepted. Then I drop the freescale patches that are in their tree with the same function. |
| 07:51 | mk01 | jnettlet: so the 12mhz power state is still in ? |
| 07:54 | mk01 | jnettlet: on running "make dtbs" I have "ERROR (duplicate_label): Duplicate label 'hdmi' on /soc/aips-bus@02100000/i2c@021a4000/edid@50 and /soc/aips-bus@02000000/hdmi@0120000" on all *sabre* boards |
| 07:55 | jnettlet | mk01, yeah I have patches for that. just build the imx6q-cubox-i.dtb directly |
| 07:56 | mk01 | yes that works. |
| 07:56 | mk01 | wasn't sure if I brok |
| 07:57 | jnettlet | a lot of people are emailing me that other mx6 stuff is broken. My answer is patches are welcome. This is really just focused on the CBi/HB right now. |
| 07:57 | jnettlet | although my auto-backport script broke the drm backports branch. I need to fix that this weekend. |
| 07:58 | mk01 | that was my second queastion |
| 07:58 | mk01 | re question |
| 07:59 | jnettlet | mk01, yes the low_bus_freq_mode is still included. did you have a problem with it? |
| 08:01 | mk01 | jnettlet: not "problem" wise are targeted my questions |
| 08:01 | jnettlet | I plan on using that to handle things like shutdown -h gracefully |
| 08:01 | mk01 | just fetching more info. |
| 08:01 | jnettlet | although I haven't tested/debugged it yet. |
| 08:02 | mk01 | ok, because I took the steppings completely out from mx6 platform |
| 08:02 | jnettlet | steppings for the bus frequency? |
| 08:03 | mk01 | yes: the bus freq modes |
| 08:03 | jnettlet | any reason why? |
| 08:03 | jnettlet | it should scale with the cpu-frequency |
| 08:04 | mk01 | I started with going through the patches |
| 08:04 | mk01 | and somehow |
| 08:05 | jnettlet | I have patched the cpufreq ondemand governor to count iowait in its algorithms so disk/network activity will scale the cpu frequency hence the bus-frequency and speed everything up |
| 08:05 | mk01 | didn't stop |
| 08:07 | mk01 | jnettlet: do you think that the lowest modes gets any use on ci/c1 ? |
| 08:08 | jnettlet | mk01, not yet but they will. I will use the lowest mode to handle halt properly. |
| 08:08 | mk01 | I mean it is so slow making more troubles than benefits ? |
| 08:08 | mk01 | ok |
| 08:10 | jnettlet | I will use the second lowest for a C3 like state, Freeze userspace but let everything else go into lowest power mode. |
| 08:10 | mk01 | so last two questions: what you didn't start to look into - from the issues we just shortly spoken about? |
| 08:10 | jnettlet | think of it like a fast recovery sleep, that still draws the screen |
| 08:11 | jnettlet | or I may blank the screen and blink the front led...I am not sure |
| 08:11 | mk01 | the DRM from staging seems to have broken deps. if you don't have prio on this currently, I will look into it |
| 08:11 | mk01 | jnettlet: ok, understood :) |
| 08:12 | jnettlet | mk01, like I said DRM is completely broken in my tree right now. My auto-backport script completely screwed up pulling in files in include/drm |
| 08:12 | jnettlet | I will be patching that this weekend. |
| 08:13 | jnettlet | I fixed the script and will pull in a "fix" patch to this tree and probably start a new branch without the problems |
| 08:13 | mk01 | jnettlet: so finally you leaves nothing to 3rd parties :)) |
| 08:14 | mk01 | you want to fix all of them yourself |
| 08:14 | jnettlet | well for the drm problems, it is just rerunning a script and then merging. It is silly for someone else to dig through patches when I just need to run a script and then check some output |
| 08:15 | mk01 | ok |
| 08:15 | jnettlet | if you want something to do. I haven't looked into handling halt better. |
| 08:16 | mk01 | never tried halt (poweroff). what you don't like there ? |
| 08:19 | mk01 | just remembered, ... yesterday I pulled new SPL/uboot - with ext4 support commit |
| 08:20 | mk01 | ext2 got renamed ext4 but default env still uses ext2 namings |
| 08:23 | jnettlet | mk01, they don't use the ext2 namings they use the new loadfs interface. |
| 08:25 | mk01 | jnettlet: existing cards will retain the original env, do they not ? |
| 08:26 | jnettlet | mk01, if it is saved. unfortunately the ability to test for that is also broken in u-boot as rmk found out. |
| 08:26 | jnettlet | but we aren't putting any more dev time into u-boot it is too broken to keep spinning our wheels in |
| 08:28 | mk01 | jnettlet: again, it's not complain, it is getting the info from closest source (you) |
| 08:31 | mk01 | jnettlet: what would be the best approach to update all existing installs? dd SPL, copy .bin. then dd also default env from the las |
| 08:31 | mk01 | latest template ? |
| 08:32 | mk01 | jnettlet: or just take 1mb from "adapted" working sdcard and flash this 1mb as template ? |
| 08:32 | jnettlet | I would dd SPL and u-boot.bin and then dd 0's onto the space where the old env lived. But in my wiki I will just not that people should clear their default env |
| 08:33 | jnettlet | I think this problem will be fixed mostly by new distro images coming out and people will just DD the entire image to their card and be happy that everything works |
| 08:34 | mk01 | yes, indeed, but I'm not big fan of ".img"-way of distribution |
| 08:35 | mk01 | and want to push SPL & uboot.img update with next update to kernel package |
| 08:35 | mk01 | will do with zeroing |
| 08:39 | jnettlet | mk01, alternatively you can ship a uEnv.txt that will override the old environment, or a boot.scr that scripts clearing the offending env variables. |
| 08:39 | mk01 | currently uEnv.txt is shipped |
| 08:40 | mk01 | but if any user saved env with any change, |
| 08:40 | mk01 | even "run loadbootenv" will fail |
| 08:40 | mk01 | on ext2load not known. |
| 08:42 | mk01 | but no problem if you are telling that eroing will apply defaults and defaults are still following the previous "use-cases" |
| 08:43 | mk01 | as looking for uEnv.txt / boot.src fr0 |
| 08:43 | jnettlet | well we can re-add CONFIG_CMD_EXT2, we aren't memory constrained |
| 08:44 | mk01 | no no, it is not a problem |
| 08:44 | jnettlet | really it is fine. I would rather have more support than less so u-boot can suffice until barebox is ready for consumption |
| 08:44 | jnettlet | I will just need rabeeh to push the changes |
| 08:48 | mk01 | oh so it was just CONFIG_CMD_EXT2 removed from include/configs/mx6_cubox-i.h ? |
| 08:48 | mk01 | silly question |
| 08:49 | mk01 | so I can re-build with ext2 option |
| 08:49 | mk01 | thus providing for the |
| 08:50 | mk01 | thus providing back-compatibility for those with saved env ... right ? |
| 08:52 | jnettlet | mk01, absolutely |
| 08:53 | jnettlet | http://pastebin.com/GtLAMTBH |
| 08:53 | jnettlet | mk01, always remember the work we put is never set in stone, but a basis for distributions to work from. |
| 08:54 | jnettlet | and patches are always welcome back |
| 08:55 | jnettlet | if people want to do something different it will not hurt our feelings. |
| 09:03 | mk01 | jnettlet: please, where is stored the default env in the uboot sources ? |
| 09:03 | mk01 | found src |
| 09:04 | jnettlet | mk01, include/configs/mx6_cubox-i.h |
| 09:05 | mk01 | ah, yes. pg-down key. |
| 09:05 | mk01 | thanks |
| 09:14 | jnettlet | mk01, do you work on Arch? |
| 09:36 | mk01 | jnettlet: bootz zImage - fdtfile loads the kernel and hdmi screen nicely |
| 09:36 | jnettlet | great |
| 09:42 | mk01 | jnettlet: and NO to your Arch question |
| 09:49 | heap_ | mk01: hi |
| 09:49 | mk01 | heap_: caves |
| 11:41 | aplund | What's the deal with ".txt" firmware files? I don't have any, yet they seem to be needed. |
| 12:00 | heap_ | hi, does anybody make work SqueezeLite on arch armv7? |
| 12:29 | rabeeh | mk01: what did i miss? |
| 12:30 | rabeeh | anything i need in u-boot? |
| 12:30 | rabeeh | Please notice the new repo home - |
| 12:30 | rabeeh | https://github.com/SolidRun/u-boot-imx6 |
| 12:32 | mk01 | rabeeh: the removed ext2 capability affects already existing sd cards with user-saved environment |
| 12:33 | mk01 | as there was hardcoded use of "ext2load" |
| 12:34 | mk01 | rabeeh: probably this won't hit majority of users |
| 12:35 | rabeeh | but ext2 is also important |
| 12:35 | rabeeh | although not widely used anymore |
| 12:35 | mk01 | ext2 can by loaded with ext4 |
| 12:36 | mk01 | so "functionality" is there |
| 12:36 | mk01 | only old "hard" references will fail |
| 12:39 | mk01 | when I flashed i got error on loadbootscript - used ext4load instead to boot with no problem. but for instance all XBian installs have modded saved env so - jnettlet provided a solution - dd SPL, uboot.img, then dd zero the saved env area |
| 12:40 | mk01 | ... not important details as I put back EXT2 and during update I will zero saved env out |
| 15:13 | Guest85752 | hey guys is this the channel for cubox? |
| 15:15 | joshua0139 | i just bought an sd card and a cubox-i4pro and was wondering if anyone can confirm if cubox can use regular sd cards? |
| 15:15 | joshua0139 | i bought a sandisk extreme pro sd card which isnt micro |
| 15:24 | jnettlet | joshua0139, it can with a usb to sdhc adapter. The internal card slot is microsdhc |
| 15:25 | joshua0139 | i have one of those just in case which makes this no problem, thank you for your response, i've been searching for a while so its a relief to hear. |
| 17:26 | mk01 | jnettlet: is there any special know-how / steps / boot params in regards to hdmi/cec ? cec adapter is visible, chardev registered, libcec opens the 'bus' but looks like no messag |
| 17:26 | mk01 | message gets acked |
| 17:27 | mk01 | jnettlet: maybe you don't have patchs for this already available so would be an area to look into ? :) |
| 17:28 | jnettlet | as far as I know hdmi-cec should be up to date and configured properly |
| 17:30 | jnettlet | mk01, you probably want to try this patch. http://pastebin.com/s22YaBui |
| 17:30 | jnettlet | possibly a conflict between the kms/drm driver and fbdev/mfd driver |
| 17:34 | jnettlet | mk01, I have a project for you. rmk has written a new cec driver. I will get you the patches for you to integrate into 3.10 and test, if that is okay with you. |
| 17:34 | mk01 | yes |
| 17:34 | mk01 | I'm ok |
| 17:36 | mk01 | in my test config DRM was as module and not loaded when I tried the CEC, just FB stuff in Graphics & vpu & hdmi cec in MCX platform under drivers |
| 17:37 | jnettlet | yes, so you will need to disable the mcx hdmi cec driver and device-tree entries, and integrate what will hopefully be the upstream driver. |
| 17:38 | mk01 | ok |
| 17:39 | jnettlet | here is the first patch. http://www.home.arm.linux.org.uk/~rmk/cubox/0001-CEC-add-generic-HDMI-CEC-driver.patch |
| 17:39 | jnettlet | you can use that to get started, but the resulting driver is not fully functional. The second patch will finish that up, and should be done soonish |
| 18:11 | mk01 | jnettlet: rmk is Russell ? |
| 18:17 | jnettlet | mk01, yes |
| 18:17 | jnettlet | although he is rethinking the patch right now. |
| 18:31 | mk01 | jnettlet: ok, got the hdmi-cec class |
| 18:31 | jnettle | 18:31 * jnettlet +1 |
| 18:39 | mk01 | the idea is to keep just hdmi_core from mxc platform, right ? |
| 18:40 | ths_ | hello ! i just received cubox i4 boot is ok ... with SolidRun logo etc ... but display goes on energy saving .. |
| 18:40 | mk01 | ths_: consoleblank=0 |
| 18:40 | mk01 | (as kernel parameter) |
| 18:40 | ths_ | hello ! where ? |
| 18:41 | ths_ | in uEnv ? |
| 18:41 | mk01 | if that is in use, then yeas |
| 18:42 | mk01 | append to "setenv bootargs ........ consoleblank=0" |
| 18:42 | ths_ | no i stopped the cubox |
| 18:42 | ths_ | here: bootargs_common= |
| 18:43 | mk01 | yes, should work |
| 18:44 | ths_ | bootargs_common=console=ttymxc0,115200 init=/init vmalloc=400M no_console_suspend androidboot.console=ttymxc0 androidboot.hardware=freescale consoleblank=0 |
| 18:44 | ths_ | ok ? |
| 18:45 | mk01 | yes |
| 18:46 | ths_ | mk01: no |
| 18:47 | mk01 | your display does energy saving after a time or right after solidrun logo ? |
| 18:47 | ths_ | in uEnv.txt ? ok ? |
| 18:48 | mk01 | re does=goes |
| 18:48 | ths_ | just after logo ... when system run i presume |
| 18:48 | ths_ | sorry for my english i'm french |
| 18:48 | mk01 | then it is no blanking |
| 18:48 | mk01 | but video output |
| 18:49 | ths_ | yes i think |
| 18:50 | mk01 | for normal linux kernel boot there is "video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=16" |
| 18:50 | mk01 | but have no idea how much android different is |
| 18:56 | davorin | mk01: are other bootargs supported already for video out? |
| 18:56 | davorin | like dev=lvds and so on? |
| 19:14 | mk01 | davorin uyou |
| 19:15 | davorin | hmm? |
| 19:15 | mk01 | davorin you mean for u-boot stage as well or final system booted ? |
| 19:16 | davorin | yes |
| 19:16 | mk01 | u-boot is hdmi only (AFAIK) |
| 20:05 | purch | what is the fastest supported sd card for cubox-i4 |
| 20:29 | purch | I ordered this http://www.sandisk.com/products/memory-cards/microsd/extremepro-uhs-i/?capacity=8GB and Ultra, too |
| 20:29 | purch | hope it is as fast too |