IRC log of #cubox of Sat 01 Mar 2014. All times are in CET < Back to index

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