03:47 | MikeSeth | well, none of the hdmi video modes work from uboot |
03:47 | MikeSet | 03:47 * MikeSeth ponders netconsole |
11:53 | jnettlet | _rmk_, if you have a bit of time later I would love to chat with you about wifi/esata/usb and try to figure out what needs to be done to make this all work better. |
11:56 | _rmk_ | for esata, it's about rewriting the ahci drivers because the design is basically wrong. someone may have already done that, but the patches got trapped in the lakml moderation queue |
11:56 | _rmk_ | for wifi... apparantly it's being worked on by various people, including ojn. |
11:56 | jnettlet | I saw those patches that the commentor on your post referenced |
11:57 | jnettlet | they looked more sane to me, but I just started browsing the eSATA code last night. |
11:58 | _rmk_ | for usb, I've bashed Linus Walleij and Mark Brown together to hash the GPIO0 issue out - the only reason the lower port seems to get power at the moment is purely down to uboot setting it that way |
11:59 | _rmk_ | I think there's agreement there that regulator is buggy |
12:00 | jnettlet | and that is why the second port now works with the updates to u-boot that rabeeh pushed. |
12:00 | henk | hi, I am trying to take a look at http://cubox-i.com/ but everything is so dark and there is a banner "Please enable JavaScript to view this website." even though in the background the main content seems to be readable just fine without javascript. It'd probably actually be readable if it wasn't for the grey overlay asking me to enable JS. |
12:01 | rabeeh | _rmk_: what bug in the regulator? |
12:01 | rabeeh | u-boot simply didn't enable the regulator; that's why there was never +5V as the Vbus |
12:02 | _rmk_ | rabeeh: gpio number 0 is not seen as a valid gpio by the regulator code in the kernel |
12:02 | _rmk_ | and gpio number 0 controls the usbh1 regulator |
12:02 | jnettlet | rabeeh, linux shouldn't rely on u-boot to initialize hardware |
12:03 | jnettlet | if it does that will dash our dreams of SPL -> Linux |
12:03 | _rmk_ | consequently, even though I specify this in DT, the kernel completely ignores it and never claims nor drives gpio number 0, leaving it in whatever state it was before the kernel was entered |
12:03 | henk | Any idea who is responsible for that and who can change that? AFAIU the device targets hackers, so a website that basically works without JS might be desirable, right? |
12:05 | rabeeh | jnettlet: the kernel doesn't rely on the u-boot to power up the regulator |
12:05 | rabeeh | look at - |
12:05 | rabeeh | https://github.com/SolidRun/linux-imx6/blob/imx_3.0.35_4.1.0/arch/arm/mach-mx6/board-mx6q_cubox-i.c#L118 |
12:05 | jnettlet | rabeeh, yeah but we want to make it work under device-tree :-) |
12:06 | rabeeh | https://github.com/SolidRun/linux-imx6/blob/imx_3.0.35_4.1.0/arch/arm/mach-mx6/board-mx6q_cubox-i.h#L42 |
12:10 | hste | rabeeh: Have u looked into these vpu patches https://github.com/wandboard-org/linux/commit/b65ef76276775ed1781f7a767610f52d7939cf86 https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 https://github.com/wandboard-org/linux/commit/1c86a3a256ebdac32d4ba5535b077a92358adaf8 https://github.com/wandboard-org/linux/commit/bad7e05d38fb78401143ed41f38688e7b6ea27e2 ? |
13:00 | davorin | yess...my ip4pros and i1 arrived in .ch today... |
13:32 | kaipee | hello :) |
13:33 | kaipee | I just recieved my cubox-i4pro and have Arch ARM running on it - great little device |
13:33 | kaipee | though I can't seem to detect my wireless adaptor |
13:34 | kaipee | does it 'disable' when using ethernet? |
13:34 | kaipee | what tools are used to detect / manage wireless? iwconfig doesn't seemt to be available in the Arch ARM repo |
13:35 | rabeeh | kaipee: android disable wifi if ethernet is plugged |
13:35 | rabeeh | other distros should see the wifi and ethernet as-is and you can manage them the way you want |
13:35 | kaipee | I'm using Arch on it, though |
13:36 | kaipee | ifconfig only displays eth0 and lo |
13:37 | rabeeh | 'ifconfig -a'? |
13:37 | kaipee | also tried wifi-menu wlan0 and it returns 'no such interface' |
13:38 | kaipee | Ah it's labeled as sit0 |
13:39 | kaipee | rabeeh++ |
13:40 | rabeeh | kaipee: sit0 is unrelated |
13:41 | kaipee | ah, I just read |
13:41 | rabeeh | cat /sys/class/mmc_host/mmc0/mmc0\:0001/mmc0\:0001\:1/device |
13:41 | rabeeh | kaipee: the above should show your 0x4329 |
13:42 | kaipee | yeah just returned 0x4329 |
13:42 | kaipee | 'ifconfig -a' only returns eth0, lo and sit0 |
13:42 | rabeeh | so the device is there |
13:42 | rabeeh | kaipee: probably it was disabled in the kernel you are using |
13:43 | kaipee | I just downloaded the latest distro image |
13:43 | kaipee | oh - btw, it contains errors in /etc/fstab |
13:43 | kaipee | see: http://imx.solid-run.com/forums/viewtopic.php?f=8&t=405 |
13:44 | kaipee | /boot is labeled incorrectly and / (root) is not defined |
13:54 | Coolgeek | maybe there is not a fully working kernel image from archarm |
13:55 | kaipee | Oh, I thought the image provided was fully working with all the hardware? |
13:55 | Coolgeek | which one you tried ? |
14:02 | kaipee | the rootfs link from cubox-i wiki (Arch distro) : https://www.dropbox.com/s/hbtoeaael4naj5l/ArchLinuxARM.Cubox-i_16012014.bz2 |
14:05 | Coolgeek | didn't know about this one |
14:05 | kaipee | what other rootfs are there? |
14:07 | kaipee | is there a list of released rootfs? (like version history or something |
14:09 | Coolgeek | I only knew a rootfs for archarm in their website |
14:09 | Coolgeek | but it is for cubox (the first one, before the cubox-i) |
14:09 | Coolgeek | I don't know anything about the cubox-i :( |
14:09 | Coolgeek | sorry |
14:12 | kaipee | ah ok :) |
14:32 | kaipee | Can I just ask - what is the recommended way to install Arch ARM for the cubox-i ? |
14:38 | jabalv_ | hi, what is power consumption for cubox-i2? |
14:39 | jabalv_ | idle, load? |
14:45 | kaipee | jabalv_: apparently the i4 goes to <1W when idle, and up to 6-8W |
14:48 | _dab_ | jabalv: using an ac power meter, my apparent power usage has not exceeded 4 Watts (so far) |
14:52 | jabalv_ | cool |
14:52 | jabalv_ | i`m planing to use it as mail/web server |
14:53 | jabalv_ | nas |
14:53 | jabalv_ | i checked webpage, but i can`t find where is shipping costs mentioned |
14:57 | _505 | jabalv_, shipping costs are $18 (at least when I ordered) |
14:57 | _505 | that is for standard shipping |
14:57 | jabalv_ | anyone have promotional code? |
15:00 | _505 | not at hand now |
15:00 | _505 | and be aware to there might also be custom fees/import taxes. it is send form Israel |
15:08 | jabalv_ | _505: from Isralel, thats interesting |
15:14 | kaipee | is the older cubox wiki article (Arch Linux) still relevant for the cubox-i ? |
15:14 | kaipee | see: http://www.solid-run.com/mw/index.php/ArchLinux |
15:20 | dv_ | elo |
15:20 | dv_ | jnettlet, otavio, anything new about SPL support in uboot? |
15:21 | dv_ | I finally got time to rework the meta-fsl hummingboard+cuboxi patches |
15:21 | _505 | kaipee, yes and no. installing will be different. but of course, Arch is Arch, so a lot of things will be similar |
15:22 | _505 | for cubox-i, see http://imx.solid-run.com/wiki/index.php/ArchLinux |
15:25 | kaipee | _505: that's what I've followed and have Arch running so far |
15:25 | kaipee | Though I can't seem to detect my wireless device |
15:30 | davorin | hmm..how is the wlan connected to i.mx6? mines are at the swiss customs now (o; |
15:32 | davorin | "dmesg | grep -i wlan" shows also nothing? |
15:35 | hste | dv_: SPL is now working http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
15:37 | kaipee | davorin: nope, nothing shows |
15:46 | kaipee | _505: are there any real differences in the rootfs posted on ArchARM (for cubox) and the one linked in cubox-i wiki? (like modules, binaries, configs, etc.) |
16:43 | jnettlet | dv_, SPL is working well. Here. I have a couple of tweaks on top of rabeeh's patches that I want to merge. I think tomorrow will be a good day to push all of that. |
16:44 | rabeeh | CuBox-i schematics - http://imx.solid-run.com/wiki/index.php?title=CuBox-i_Hardware |
16:44 | rabeeh | finally :) |
16:45 | davorin | thanks :-) |
16:45 | rabeeh | jnettlet: please send me those patches; i think the bss tweaking that you have done is mandatory |
16:46 | rabeeh | davorin: HB will be next.... |
16:46 | davorin | and the 3rd connector fo usom (o; |
16:46 | davorin | well..it will be used on the hb as i understood you, right? |
16:46 | rabeeh | davorin: the third connector is not used in both HB / CBi |
16:46 | rabeeh | no; it won't be used in HB |
16:46 | davorin | ah i thought rgb tft will be available on hb... |
16:47 | davorin | and dsi dropped... |
16:48 | letterj | Greetings. My cubox-i4Pro seems to have stopped working after just one day. I get "No signal" from the monitor and I've even tried making a new SD Card image. Any sugguestions? |
16:49 | davorin | rabeeh? on the comparison chart, would it make sense to include sdxc compatibility and max. capacity it supports? |
16:49 | rabeeh | davorin: no; LVDS is there; the DSI signals are on the B2B but not connected to anything (probably you can patch to those) |
16:50 | davorin | well...rgb tft would have been nice to create tft add-on boards... |
16:50 | davorin | smaller lcd don't have lvds... |
16:50 | davorin | maybe time for me to do a beaglebone clone with usom (o; |
16:51 | rabeeh | letterj: i just saw your post; i'v answered on the forums; can you please check? |
16:51 | letterj | rabeeh: sure thanks |
16:52 | rabeeh | davorin: the third b2b header is an assembly option from our point of view; as i previously mentioned it holds most of the RGB |
16:52 | rabeeh | and SD3 (third SD-card) |
16:52 | davorin | so the header is not included on the usom by default? |
16:53 | rabeeh | it's not |
16:53 | davorin | but same type it is.... |
16:53 | rabeeh | it's smaller - 70 pin |
16:53 | rabeeh | from the same family from Hirose |
16:58 | davorin | interesting..."RealNetworks video codec is disabled by default on i.MX 6 series processors" |
16:59 | davorin | is that anywhere used nowadays? |
16:59 | davorin | last time i used this was back then @compuserve (o; |
17:05 | jnettlet | rabeeh, I will send those to you in the morning. |
17:05 | jnettle | 17:05 * jnettlet will probably do no more hacking today as his NFL team is playing in the Conference Championship in a few hours |
17:12 | Thecko | Can anybody confirm if the RTC on the cubox-i1 is battery backed or not? it doesn't persist time across power cycles on mine |
17:12 | _rmk_ | Thecko: the i2c rtc is battery backed |
17:12 | _rmk_ | there's two: there's an i2c one and one in the imx6 (which I don't think is backed up) |
17:13 | Thecko | Ah right, so I could be committing the time to the wrong rtc then ... I'll have a play, thanks for the info |
17:21 | Thecko | no, /dev/rtc is only a symlink to /dev/rtc0, committing the time doesn't persist across power cycle so I'm guessing that the i2c rtc either doesn't have a driver yet or the kernel i've built from geexbox isn't including it. |
17:27 | rabeeh | _rmk_: the internal imx6 has no battery backed up |
17:27 | rabeeh | it consumes too much current so a regular 3V battery will be drained in less than a month; that why the NXP PFC RTC was added |
17:28 | _rmk_ | so probably best if DT can disable the imx6 rtc |
17:29 | rabeeh | _rmk_: i agree. i should probably do the same for the 3.0.35 kernel |
17:31 | _rmk_ | just adding support for the front led pwm... is that mx6_cubox_i_pwm_lvds_backlight_data in board-mx6q_cubox-i.c ? |
17:33 | rabeeh | _rmk_: yes |
17:35 | rabeeh | and pwm2 is the IR TX |
17:36 | rabeeh | (yes there is an infrared transmitter that is hooked to pwm2) |
17:36 | rabeeh | that should be connected to LIRC IR TX blaster in some point of time |
17:37 | _rmk_ | hmm, led brightness is inverted |
17:39 | rabeeh | it's because it's connected to 3.3v in it's tail |
17:39 | _rmk_ | and... *sigh* this dt stuff won't let me specify that, because the 3rd property is optional based on the pwm implementation |
17:39 | _rmk_ | neither does it allow me to specify a default brightness for pwm-leds |
17:47 | Thecko | rabeeh, before I look in to trying to get the rtc kernel module to comm over i2c, I've just had a look at the wiki (was looking for the i2c address of rtc) and it seems to say that the cubox-i1 and cubox-i2 are not populated with an rtc on the i2c? is that definitely the case? |
17:48 | Thecko | if so I'll give up and fix my issue a different way :) |
17:49 | rabeeh | Thecko: the CuBox-i lower and upper have two configs; the first (base) is without RTC, RS-232 and the second (pro) is full |
17:50 | rabeeh | Thecko: which modem do you have? |
17:50 | rabeeh | base comes with i1/i2, pro comes with i2u / i4pro |
17:50 | Thecko | Ok thanks, I have an i4 ordered as well, I'll play with my systemd config to see if I can get xbmc to not start until it's done a successful ntpdate |
17:50 | Thecko | I'm on an i1 at the moment, i4 ordered the other day |
17:51 | rabeeh | Thecko: oh; sorry for that |
17:51 | rabeeh | but those small extra components makes the difference between delivering a <50$ device or not. sorry for that again |
17:52 | Thecko | no problem, I totally understand that :) |
17:52 | rabeeh | now if you REALLY want to play with the CuBox-i and have some time for it; then I suggest for you to put two super capacitors in row and connect to SNVS and GND |
17:53 | rabeeh | when powered down SNVS will draw ~150uA and drain the super caps (maybe will hold for 1-2 days) |
17:53 | rabeeh | when powered up then SNVS is driven internally from an LDO and will charge your super capacitor |
17:53 | Thecko | lol, nice |
17:53 | rabeeh | oh; don't forget to put a serial resistor too :) |
17:53 | rabeeh | (otherwise you might kill the LDO) |
17:53 | Thecko | yeah, otherwise I'll have an expensive firework |
17:53 | rabeeh | nah |
17:54 | rabeeh | i doubt there will be any firework; it's really difficult to get something burning while you are in the +5V range |
17:54 | Thecko | true |
17:54 | rabeeh | notice R28 also; if you assemble it or short it then you can power CuBox-i from the micro USB |
17:54 | Thecko | I'm liking the cubox though, software optimisations pending it's an excellent little device - far more capable than the rasberry pi for not much more money |
17:54 | rabeeh | (and remove the DC jack and put a big antenna instead of it) |
17:56 | Thecko | I'll make a note of that, thanks, powering from micro usb would be more useful.. I don't think the micro usb on my i1 is connected to anything currently? |
17:57 | rabeeh | it's not connected to anything; but we always assembly L4 (the 90ohm ferrite) and you only need to solder R28 |
18:00 | Thecko | excellent. the only other q. I have which I've asked in the forums but had no reply is gpumem= on the kernel command line doesn't seem to have any effect, is it only implemented for android so far? |
18:01 | rabeeh | gpumem should be taken care also for the other distros |
18:01 | Thecko | hmm |
18:01 | rabeeh | it limits the gpu memory allocation; which is essential to get sane amount of memory for the i1 |
18:02 | Thecko | my understanding is that my i1 is currently using 256M for the gpu, but I should be able to lower it |
18:02 | Thecko | my /proc/cmdline looks like: console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw rootfstype=ext4 consoleblank=0 gpumem=128M video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=16 dmfc=3 |
18:02 | Thecko | and yet /proc/meminfo shows: MemTotal: 246248 kB |
18:06 | rabeeh | gpumem=64M was found to be good for 1080p Android and Debian with GPU accelerated. |
18:06 | rabeeh | There should be a parameter to get less allocation for the VPU but I can't find it... yet |
18:06 | rabeeh | Notice that if you don't allocate anything to the gpu and vpu you should get the 512MB usable |
18:07 | Thecko | yeah, I just don't seem to be able to free up more memory to the running linux whatever I set gpumem= to |
18:07 | Thecko | it always shows 246248 kB |
18:07 | rabeeh | well... the ultimate uEnv.txt should be detecting the memory size and accordingly configure gpumem=... |
18:07 | rabeeh | with that; and SPL support we should get one single OS image for all 8 different boards |
18:08 | Thecko | excellent, to be fair I only tried to lower the gpu mem as the cubox was running out of ram and giving memory alloc errors when playing videos, but wolfgar has fixed up a lot of memory leaks in xbmc since then and it's much better now |
18:08 | Juggie | how is the google certification process going |
18:09 | rabeeh | Juggie: 30 tests out of 18k failing |
18:09 | rabeeh | most of those 30 are UVC camera recording related |
18:10 | Juggie | nice.. close then. |
18:10 | Juggie | which version are you testing? |
18:10 | rabeeh | 4.3 |
18:11 | MikeSeth | rabeeh: my -i1 doesn't have a serial and the hdmi clocking problem in uboot won't let me see uboot console, would netconsole work with cubox? |
18:11 | rabee | 18:11 * rabeeh also waiting until freescale has 4.4 ready |
18:11 | rabeeh | MikeSeth: why can't you see anything on the hdmi? |
18:11 | rabeeh | the resolution should be 1024x768@75 |
18:12 | jnettlet | rabeeh, it is because the u-boot clocks are wrong. |
18:12 | rabeeh | ? |
18:12 | rabeeh | are they? |
18:12 | rabeeh | i though the clock was set to 105MHz; is that wrong? |
18:12 | MikeSeth | apparently, yeah, which results in lower than specified frequencies and smart tvs seem to be throwing a hiss |
18:13 | Thecko | I can see uboot console on my monitor with my -i1, I can't interact with it via keyboard if it fails though :) |
18:13 | jnettlet | Thecko, why not? |
18:13 | jnettlet | usb keyboard should work |
18:13 | MikeSeth | Thecko: my monitor won't take 53hz |
18:13 | Thecko | don't know, just doesn't seem to detect a usb keyboard is connected |
18:13 | rabeeh | Thecko: you are probably not using latest and greated u-boot |
18:13 | Thecko | possibly not, I'm using whatever the geexbox repo compiles |
18:13 | MikeSeth | rabeeh: in uboot 60hz is hardwired, not 75 |
18:13 | Thecko | (compiling it locally so I can try changes to xbmc etc before they pull them in) |
18:14 | rabeeh | Thecko: gxbx already has SPL; try the bottom USB port |
18:14 | Thecko | ok I'll give that a go |
18:14 | MikeSeth | so do you know if netconsole in uboot would work? |
18:15 | rabeeh | MikeSeth: probably not |
18:16 | rabeeh | i wonder if u-boot even supports it |
18:18 | rabeeh | jnettlet: can you tell if the following patch really solves issues - http://pastebin.com/9pA9rCTY |
18:18 | rabeeh | few folks reported corrupted uImage when trying to 'bootm' from it; but only in the SPL u-boot |
18:19 | jnettlet | rabeeh, that is something I need to look at more closely before I push those patches. I need to sit down and map out the memory more closely and figure out what is ending up where. |
18:39 | Juggie | rabeeh, any plans to move to 4.4 in the near term? |
18:47 | rabeeh | Juggie: 4.3 for now |
18:47 | rabeeh | the most important thing about 4.4 in my mind is that it's better optimized for 512MByte memory devices |
18:49 | Juggie | yeah that is true. |
18:49 | Juggie | rabeeh, i am curious to see how well 4.3+mediacodec api work with xbmc. |
18:49 | Juggie | and other apps using video accel |
18:49 | Juggie | netflix, etc. |
19:06 | dv_ | jnettlet: I will then use rabeeh's uboot for the meta-fsl patches |
19:06 | dv_ | rabeeh: is your fork based on 2013.10 ? |
19:08 | dv_ | and does mx6_cubox-i_config also cover the hummingboard? |
19:08 | rabeeh | Juggie: for xbmc using mediacodec; probably only the xbmc nightly build makes sense |
19:09 | rabeeh | besides that i'v seen acceleration but i'm not impressed; relatively to native vpu support |
19:09 | rabeeh | for the gpu side (i.e menu and addons) it behaves really good |
19:09 | rabeeh | dv_; mx6_cubox-i_config covers 8 boards :) |
19:09 | rabeeh | 4x(CBi+HB) |
19:10 | rabeeh | one ring to rule them all |
19:10 | dv_ | ah |
19:10 | dv_ | because the commit message say "The support covers CuBox-i1, i2, i2ultra and i4pro" |
19:10 | jnettlet | there is a later commit for HB detection |
19:11 | Coolgeek | HB ? |
19:11 | dv_ | ah right |
19:11 | dv_ | Coolgeek: hummingboard |
19:11 | Coolgeek | ho, yeah |
20:41 | Juggie | rabeeh, native vpu in linux is better... but how close is that to working and being included in xbmc. |
20:44 | dv_ | i thought its working already |
20:44 | dv_ | i mean, in xbmc |
20:47 | rabeeh | Juggie: native is already working (wolfgar Stephan Rafin work) |
20:47 | rabeeh | The GeexBox builds are already using that |
20:47 | Juggie | nice, hope it makes into mainline |
20:47 | Juggie | and openelec as well. |
22:07 | dv_ | rabeeh: did you try your u-boot-imx6 with the hummingboard? |
22:07 | Bluerise | Net: FEC [PRIME] |
22:07 | Bluerise | data abort |
22:07 | Bluerise | did I miss anything? |
22:07 | Bluerise | trying the new SPL build |
22:08 | Bluerise | also, wondering where that's from: |
22:08 | Bluerise | dd: /dev/rdisk2s1: Invalid argument |
22:08 | Bluerise | 586+1 records in |
22:08 | Bluerise | 586+0 records out |
22:08 | dv_ | oh nevermind, didnt use the SPL file |
22:28 | Bluerise | conv=sync with dd fixed it |
22:28 | Bluerise | me dumb. |
23:54 | NetScr1be | anyone have experience trying to compile etnaviv GPU driver? |