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 |