| 01:57 | mhoney | any word on when xubuntu 13.10 will be available for cubox? |
| 12:14 | seer | hi |
| 12:15 | Guest70894 | i was wondering if anyone can help me out with a issue i am having with my C1 |
| 12:15 | jnettlet | possibly |
| 12:15 | Guest70894 | i can't seem to get there serial connection to print readable output |
| 12:15 | Guest70894 | fromthe u-boot iamge |
| 12:15 | Guest70894 | it is just garbage |
| 12:15 | Guest70894 | checked speed etc |
| 12:16 | jnettlet | turn of hardware flow control |
| 12:16 | jnettlet | s/of/off/ |
| 12:16 | Guest70894 | it is not on |
| 12:16 | Guest70894 | flow control is set to none |
| 12:16 | jnettlet | and you are sure you don't have the tx/rx pins reversed? |
| 12:17 | jnettlet | that will cause garbage on the display also |
| 12:17 | Guest70894 | ok i will try changing them |
| 12:19 | Guest70894 | change the TX and RX over and now get nothing |
| 12:21 | Guest70894 | tx on the board to rx on the serial controller is what i had before from the diagrams i was reading and plug designs i have seen |
| 12:21 | jnettlet | can you take a picture of your connections on the board and console and post them? |
| 12:21 | jnettlet | that is correct |
| 12:23 | Guest70894 | sure 2 questions first. does cable length effect it and would using a usb to serial adapter cause this issue? |
| 12:24 | Guest70894 | i have another serial adapter coming in case that is it plus it is more suited to connecting wires too |
| 12:24 | jnettlet | serial can support 100meter length. and most people are using a usb to serial adapter |
| 12:25 | jnettlet | you just need to make sure it is a 3.3v usb to serial not 5v |
| 12:25 | Guest70894 | but if i join the TX and RX wire from the serial from the pc then the input comes out so i think the adapter should be fine. |
| 12:26 | Guest70894 | oh did not know there was different ones |
| 12:26 | Guest70894 | i will check voltage on the cable from pc |
| 12:28 | Guest70894 | crap that looks like it is it |
| 12:28 | Guest70894 | between the ground and the TX it is sitting at 6v |
| 12:30 | jnettlet | yep, wrong cable |
| 12:31 | jnettlet | sorry |
| 12:32 | Guest70894 | how do you tell if it is a 3v adpater or not. the other one i ordered is this one |
| 12:32 | Guest70894 | http://www.ebay.com.au/itm/141072933896?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649 |
| 12:32 | Guest70894 | i hope it will be ok as i liked the wire connectors on it |
| 12:34 | lycanthropistCBi | I can see a MAX232 on there, wich is a 5V part. Therefore the FTDI chip probably also outputs 5V. |
| 12:34 | lycanthropistCBi | Try searching for "usb serial 3.3V" or something. |
| 12:34 | Guest70894 | really not having good luck with this device so far. ok thanks |
| 12:37 | Guest70894 | http://www.ebay.com.au/itm/3-3V-5V-Optional-USB-to-TTL-UART-RS232-COM-Serial-Converter-Module-DTR-RTS-/200974914272?pt=AU_B_I_Electrical_Test_Equipment&hash=item2ecb09d2e0&_uhb=1 |
| 12:37 | Guest70894 | looks ok as it lets me select the voltage |
| 12:40 | Guest70894 | actually this one seems better as comes with cables that will connect. |
| 12:40 | Guest70894 | http://www.ebay.com.au/itm/USB-to-TTL-Serial-UART-RS232-Adaptor-PL2303HX-for-PIC-Arduino-AVR-Raspberry-/171118487801?pt=AU_B_I_Electrical_Test_Equipment&hash=item27d774e8f9&_uhb=1 |
| 12:40 | jnettlet | yep that should be fine |
| 12:40 | Guest70894 | can you see any reason why it would not be good |
| 12:41 | jnettlet | either of those should work fine. |
| 12:41 | Guest70894 | thanks. |
| 12:42 | Guest70894 | so i guess that explains the junk output i was getting and my days of pulling my hair out between that and microSD adpater issues |
| 12:43 | jnettlet | welcome to the wonderful world of dev hardware |
| 12:44 | Guest70894 | i will have a lot to learn i suspect |
| 12:45 | Guest70894 | can you only use the C1 images people develop on this board or should the other mx6 iamges work as well |
| 12:46 | jnettlet | The other images should work, you just need to use u-boot and kernel specifically for this device |
| 12:47 | jnettlet | however _rmk_ has done great work so future upstream imx6 kernels with just the carrier-1 device-tree should work. |
| 12:48 | Guest70894 | ok. Are the C1 images quad core? They all have solo in their name for the uboot config |
| 12:50 | jnettlet | The current C1's shipped out are all single core 512MB DDR |
| 12:52 | Guest70894 | oh misread the info page on the board and thought they were 4 core model |
| 12:53 | _rmk_ | jnettlet: probably won't be v3.13 as Shawn hasn't fixed the SDHC DAT3 pinmux yet (and is going to do it at some point) |
| 12:54 | _rmk_ | that's probably going to happen after the v3.13 merge window :( |
| 12:54 | jnettlet | ouch |
| 12:55 | jnettlet | _rmk_, SDHC DAT3 pinmux? do you have a patch in your branch? |
| 12:55 | Guest70894 | has anyone tried video playback on the 1 core model? wondering if it will be way under powered for what i am try |
| 12:55 | jnettlet | it should do 1080p |
| 12:55 | _rmk_ | jnettlet: I have but Shawn doesn't like it :p |
| 12:56 | Guest70894 | so it has enough grunt to handle the decode and network traffic at the same time? |
| 12:56 | jnettlet | _rmk_, is that just the device-tree entry or is there code that needs to be changed? |
| 12:56 | _rmk_ | dt stuff only |
| 12:57 | jnettlet | ah okay. yeah I have those changes. but the boundary kernel is still barfing trying to read the mmc. Your kernel works fine. Guess I will need to back out some of their patches to see what broke it. |
| 12:58 | jnettlet | what is his beef with your patch? seems reasonable to add it to all the supported usdhc ports |
| 12:58 | jnettlet | would he prefer it removed from the platform and handled board by board? |
| 12:59 | _rmk_ | basically,, dat3 needs to be moved out of the existing sets and handled separately |
| 12:59 | _rmk_ | as a separate group |
| 13:00 | jnettlet | I can see that, but shouldn't hold up adoption because of it. Especially since we are the first board to implement it. |
| 13:01 | _rmk_ | it means changing a number of the existing board descriptions |
| 13:01 | Guest70894 | thanks for the help. Going to go now but i am sur ei will be back here once i get my new serial adapter. |
| 13:02 | jnettlet | The device-tree is really becoming a bottle-neck in hardware support. All the XO-1.75/XO-4's have a problem where the entries are wrong because PowerPC used marvell, then ARM used mrvl, now Marvell wants to swtich back to marvell |
| 13:03 | _rmk_ | you know how that should be solved? |
| 13:03 | _rmk_ | we support both prefixes in the kernel. |
| 13:03 | jnettle | 13:03 * jnettlet is more and more thinking that device-tree should live in its own repo, and both u-boot and the kernel can pull from it. |
| 13:03 | _rmk_ | that way, both old and new DTs work. no compatibility issues. |
| 13:04 | jnettlet | yep, but the discussion ended when that was brought up. I guess Marvell doesn't like mrvl, probably some marketer making it a branding thing |
| 13:21 | Coolgeek | can't you put aliases in DT ? like "alias mrvl=marvell" and use mrvl always ? |
| 13:21 | Coolgee | 13:21 * Coolgeek noob |
| 13:22 | jnettlet | nope |
| 13:23 | Coolgeek | ef |
| 13:23 | Coolgeek | erf |
| 13:23 | _rmk_ | jnettlet: that's why marketing should be kept away from tech stuff :) |
| 13:23 | jnettle | 13:23 * jnettlet doesn't know what he is more frustrated with. That Marvell put access to both GC clocks in a single register or the fact that common clock has no way to support this. |
| 13:24 | jnettlet | seems like this is a major problem |
| 13:25 | shesselba | jnettlet: why can't ccf deal with >1 clock per register? basic clock devices may not, but you can always write a clk-provider that can |
| 13:26 | jnettlet | shesselba, how do I designate to the provider which clock I want to change? |
| 13:26 | dxtr | So, what could be the reason u-boot isn't spitting out anything over HDMI? |
| 13:27 | shesselba | jnettlet: you expose two different clocks |
| 13:27 | dxtr | I have the latest u-boot from the cubox installer |
| 13:28 | jnettlet | shesselba, with the same clk_hw? |
| 13:28 | shesselba | let me refresh on ccf for a minute |
| 13:28 | jnettle | 13:28 * jnettlet would greatly appreciate it. |
| 13:29 | jnettlet | dxtr, I am not sure u-boot on the Cubox supports HDMI. Although I could be wrong. |
| 13:31 | jnettlet | dxtr, yeah it only supports serial access. |
| 13:31 | dxtr | It does? |
| 13:31 | dxtr | Oh.. I remember having it HDMI support |
| 13:31 | dxtr | But I might be wrong :P |
| 13:31 | jnettle | 13:31 * jnettlet is only referencing the wiki. |
| 13:32 | _rmk_ | right, time to pull out the cubox and pack it up |
| 13:33 | shesselba | jnettlet: I sure need more fresh-up on ccf but in clk-si5351, I have one clk_hw for each "clock" involved in the tree. But they share the same call-backs |
| 13:34 | shesselba | if you use container_of, you can reference global structs as well |
| 13:34 | shesselba | i.e. for locking |
| 13:34 | jnettlet | that is what I was thinking of |
| 13:34 | jnettlet | it just seems like we are working around something that should be straight forward. |
| 13:35 | jnettle | 13:35 * jnettlet will look at clk-si5351 |
| 13:35 | shesselba | what exact register are you talking about? dove's? |
| 13:36 | jnettlet | shesselba, nah they are for the mmp3 XO-4. It has a dual-core gpu but all the clocks are controlled through a single register. |
| 13:36 | shesselba | ok |
| 13:37 | shesselba | bbl |
| 13:37 | jnettlet | this means you have both cores on and powered no matter what. I want to shutdown idle cores individually |
| 13:38 | shesselba | ok, but ccf should be able to allow you this (quite) easily |
| 13:40 | jnettlet | I must be missing some puzzle piece then. |
| 14:11 | dxtr | Okay, so if I want to enable the serial console, what tty is it? |
| 14:11 | dxtr | I'm guessing /dev/ttyS0 is hdmi? |
| 14:14 | jnettlet | dxtr, u-boot enables the serial console automatically. |
| 14:18 | dxtr | jnettlet: Not in securetty and inittab :( |
| 14:20 | lioka | systemd does it for you |
| 14:20 | dxtr | And what if I don't have systemd? |
| 14:21 | jnettlet | oh you mean on your desktop. Depends on what type of serial connection you are using. If it is a serial to usb, then the device will be ttyUSB0 |
| 14:21 | lioka | dxtr: which hardware we are talking about ? |
| 14:22 | lioka | dxtr: cubox or cubox-i ? |
| 14:23 | jnettlet | he said cubox. cubox-i hasn't been released yet. |
| 14:25 | lioka | dxtr: S0:2345:respawn:/sbin/agetty -L ttyS0 115200 vt100 |
| 14:25 | lioka | in inittab |
| 14:25 | lioka | and ttyS0 in securetty |
| 15:32 | dv__ | rabeeh: will the kernel and uboot patches for the carrier one automatiacally apply to the cubox-i ? in other words, will adding c1 support implicitely add cubox-i support? |
| 16:36 | yar0d | Hello :-) |
| 16:37 | yar0d | Did the last installer work for xilkax ? |
| 16:37 | yar0d | thanks |
| 17:01 | rabeeh | dv_: mostly yes; with some changes to gpios |
| 17:02 | dv_ | rabeeh: so kernel and uboot binaries for the c1 will also work with the cubox-i ? |
| 17:02 | rabeeh | yes. mostly |
| 17:02 | dv_ | alright |
| 17:02 | rabeeh | except few gpios and pwms |
| 17:02 | rabeeh | i was wondering if someone knows about running some C code on the internal SRAM for DDR config |
| 17:03 | rabeeh | i'm looking now into that to have a single u-boot image that supports all versions of the microsom |
| 17:03 | rabeeh | i.e. one u-boot to config DDR for solo, dual lite, dual and quad with it's different DDR configs |
| 17:12 | shesselba | rabeeh: remember dove's cpufreq behaviour? |
| 17:13 | shesselba | ever tried to switch cpu pll, l2 or ddr ratios? |
| 17:13 | shesselba | or just slow mode? |
| 17:16 | rabeeh | shesselba: the basic support is having full speed or DDR speed |
| 17:16 | rabeeh | i.e. 800mhz or 400mhz |
| 17:17 | rabeeh | anything else is not supported by mainline; although doable |
| 17:17 | rabeeh | there are few changes for overclocking if you want to play with your machine :) |
| 17:18 | dv_ | otavio, please help us out of our confusion |
| 17:18 | dv_ | what is the connection between boundarydevices, pengutronix, timesys, and freescale? |
| 17:19 | jnettlet | rabeeh, it should be doable, that is how we bootload the XO's |
| 17:19 | dv_ | I was told that pengutronix is porting and mainlining patches for freescale |
| 17:19 | dv_ | but: boundarydevices *also* seems to be working on imx support for 3.10 |
| 17:19 | rabeeh | jnettlet: but this is 100% freescale related |
| 17:19 | jnettlet | cforth gets loaded into SRAM and runs on the security processor, which then bootstraps openfirmware |
| 17:19 | dv_ | and timesys is also involved somehow |
| 17:19 | rabeeh | u-boot ofcourse doesn't mind |
| 17:20 | rabeeh | openfirmware? |
| 17:20 | rabeeh | why openfirmware was choosen vs. something much more easier like u-boot? |
| 17:20 | shesselba | rabeeh: ok, but it is not dynamic, i.e. as you are kind of stuck at 400MHz DDR, you only have the option to fall back to DDR or double it? |
| 17:20 | otavio | rabeeh: this is possible |
| 17:20 | jnettlet | security and support at the time. |
| 17:20 | otavio | rabeeh: but not yet supported in U-Boot |
| 17:20 | rabeeh | shesselba: it is dynamic |
| 17:20 | rabeeh | but we don't have the support for it |
| 17:21 | otavio | rabeeh: the right way to do it is splitting the U-Boot in two (SPL and main U-Boot) and run the DDR setup on SPL |
| 17:21 | shesselba | you can have e.g. 933MHz CPU and L2, but 400MHz DDR? |
| 17:21 | dv_ | I see the possibility that the kernel work rabeeh, jnettlet, and _rmk_ are doing could be redundant |
| 17:21 | otavio | this is how we do in mx23/mx28 for example |
| 17:22 | dv_ | if it is already done in the boundarydevices fork for example |
| 17:22 | otavio | dv_: it is not |
| 17:22 | otavio | dv_: boundary uses one u-boot for each soc-type |
| 17:22 | jnettlet | dv_, what is done in the boundarydevices fork? |
| 17:22 | dv_ | but boundarydevices has a linux-imx 3.10 alpha |
| 17:22 | dv_ | jnettlet: look at https://github.com/boundarydevices/linux-imx6/tree/imx_3.10.9_1.0.0_alpha |
| 17:23 | jnettlet | dv_, I already have it and have partially merged _rmk_'s tree. |
| 17:23 | dv_ | and there is also https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.10.9_1.0.0_alpha . perhaps this includes boundarydevices-specific extras |
| 17:23 | jnettlet | sorting out some booting bugs it has |
| 17:23 | dv_ | ah |
| 17:23 | jnettlet | mainline doesn't have them so it is one of their patches that has busted things |
| 17:23 | otavio | jnettlet: 3.10.9? |
| 17:24 | jnettlet | yep |
| 17:24 | dv_ | so, this 3.10.9 tree is boundarydevices' own work? not hired by freescale? |
| 17:24 | jnettlet | both |
| 17:24 | jnettlet | a lot of the patches are from freescale |
| 17:24 | otavio | dv_: yes |
| 17:24 | rabeeh | shesselba: it supports m:n where m:n * 2 is integer |
| 17:24 | dv_ | why does freescale hire boundarydevices *and* pengutronix to do the same thing? |
| 17:24 | otavio | dv_: they do it by theirself |
| 17:25 | otavio | hey hey hey |
| 17:25 | otavio | not same |
| 17:25 | otavio | 3.10.9 is NOT mainline |
| 17:25 | otavio | this is the current BSP kernel and future GA BSP |
| 17:25 | dv_ | oh, so boundarydevices maintains linux-imx, and pengutronix mainlines the patches? |
| 17:25 | otavio | Boundary is doing the support for their board |
| 17:25 | rabeeh | the way i understand it is that freescale has kernels with tons of patches that they maintain by their internal teams |
| 17:26 | otavio | rabeeh: you got it right |
| 17:26 | rabeeh | Boundarydevices only maintains their BSP changes for only their boards |
| 17:26 | otavio | Pengutronix works a lot in mainline |
| 17:26 | otavio | I thing some of this work in backed by FSL itself |
| 17:26 | rabeeh | (i.e. different DT file for their board) |
| 17:26 | dv_ | ah, now I get it |
| 17:26 | jnettlet | yes but Boundary gets a lot of errata patches and other fixes from freescale that should go upstream |
| 17:27 | otavio | And for example, we .. O.S. Systems support Yocto by our own |
| 17:27 | otavio | jnettlet: yes; as I do |
| 17:27 | otavio | jnettlet: and I port to Yocto the ones I get |
| 17:27 | dv_ | but I guess FSL eventually wants to have that boundarydevices 3.10 linux-imx , at least until pengutronix mainlines all patches |
| 17:27 | otavio | jnettlet: and yes, some ought to go mainline, for sure. |
| 17:27 | otavio | dv_: no |
| 17:27 | otavio | dv_: fsl supports their kernel, only |
| 17:28 | dv_ | otavio: sure. but they could cherry pick boundarydevices commits |
| 17:28 | otavio | dv_: some, yes |
| 17:28 | dv_ | but the next goal for FSL is 3.5.7 |
| 17:29 | jnettlet | but there isn't a patch in that tree with an @boundarydevices.com address since Dec. of 2012. All the latest patches have freescale.com addresses |
| 17:30 | dv_ | so that leaves pengutronix. I guess some of their work could overlap with what jnettlet and _rmk_ are doing |
| 17:30 | rabeeh | dv_: freescale next goal is 3.10 lts |
| 17:31 | otavio | dv_: no; 3.5.7 is dead |
| 17:31 | otavio | dv_: next bsp is 3.10 based |
| 17:31 | otavio | dv_: as it is LTS |
| 17:31 | rabeeh | http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.10.9_1.0.0_alpha |
| 17:31 | dv_ | otavio: I see nothing about 3.10 in meta-fsl-arm |
| 17:31 | jnettlet | yep, that works for me as it is what I am targeting for most my work. |
| 17:31 | otavio | dv_: I am working on this |
| 17:31 | otavio | dv_: all in master-next btw |
| 17:31 | dv_ | ah |
| 17:32 | otavio | for c1 and one, 3.10 should be the target |
| 17:32 | otavio | 3.10 beta release will be ... close to c1 avaiability |
| 17:32 | dv_ | jnettlet: my thought is that it would be beneficial if these guys could cooperate with us here |
| 17:32 | otavio | jnettlet: indeed |
| 17:32 | dv_ | a lot of questions you ask might already be answered by them, and vice versa |
| 17:33 | otavio | jnettlet: it seem you're duplicating work |
| 17:33 | jnettlet | dv_, it would be great. Anybody know anyone in any of the communities? |
| 17:33 | otavio | jnettlet: I know them all |
| 17:33 | otavio | jnettlet: all communities involved |
| 17:33 | otavio | jnettlet: fsl, boundary, u-boot and yocto |
| 17:33 | otavio | hheh |
| 17:34 | rabeeh | dv_ / jnettlet / otavio: i asked the pengutronix guys to join #cubox for cooperation |
| 17:34 | dv_ | otavio: the problem is that pengutronix is not saying anything |
| 17:34 | dv_ | they just mention patches, but no details |
| 17:34 | rabeeh | there is redundency in _rmk_'s work; also dv_ on your work on gst |
| 17:34 | dv_ | yes |
| 17:35 | jnettlet | and pengutronix's public repos are all relatively old if they plan on mainlining code. |
| 17:35 | jnettlet | the most recent branch I found was some clock work that was done just after 3.8 |
| 17:35 | otavio | jnettlet: I think we ought to focus in 3.10 for now. |
| 17:36 | otavio | jnettlet: this is the one that has gpu, vpu and ipu working |
| 17:36 | otavio | jnettlet: and ga release near |
| 17:36 | otavio | jnettlet: mainline won't be fully supported until 3.15 or so |
| 17:36 | dv_ | sure. step by step. |
| 17:36 | otavio | jnettlet: and customers (using c1 or one) will need ga kernel supported |
| 17:36 | otavio | jnettlet: or fsl does not answer questions |
| 17:36 | jnettlet | otavio, yeah well that is kind of how things have fleshed out. _rmk_ will focus on mainline and then we can pull bits back into 3.10 |
| 17:37 | otavio | yes |
| 17:39 | jnettlet | if boundary and freescale want in on the fun that would be great. I think _rmk_ was planning on poking at freescale during the conference. |
| 17:39 | jnettlet | pengtronix are also welcome but they seem to not like to share their toys with others |
| 17:39 | jnettlet | hopefully that isn't the case |
| 17:41 | jnettle | 17:41 * jnettlet is almost done beating Marvell and Freescale's vivante drivers into a single codebase |
| 17:41 | jnettlet | then I need to convert a bunch of patches from newer Freescale kernels that don't exist in the standalone kernel driver source they released. |
| 17:46 | otavio | jnettlet: can you describe what are you doing? |
| 17:46 | otavio | I am a bit lost here |
| 17:47 | jnettlet | otavio, for which project? |
| 17:48 | otavio | oh man! |
| 17:48 | otavio | lol |
| 17:48 | otavio | I am missing a single place where we know about each other work |
| 17:48 | jnettlet | for the Carrier-1 my current tinkering is getting _rmk_ and rabeeh's work into the 3.10 freescale/boundary kernel and making it work |
| 17:48 | otavio | this will end with a lot of work duplication otherwise |
| 17:48 | otavio | jnettlet: awesome |
| 17:50 | rabeeh | jnettlet: oh; you are doing that? because i was about to do that too :) |
| 17:50 | jnettlet | I have it booting from device-tree but something is broken with the sdhc card detection. It seems like a patch that they have merged has broke something as not much else has happened on the mmc host driver since march |
| 17:50 | rabeeh | jnettlet: gimme the sources please |
| 17:50 | rabeeh | preferred a github |
| 17:51 | jnettlet | sure. I currently have the work in the boundary tree. I can merge it back to generic freescale if preferred. |
| 17:52 | rabeeh | jnettlet: boundary have more patches than freescale? |
| 17:52 | rabeeh | i mean except their DT file? |
| 17:52 | jnettlet | rabeeh, yeah that is why I started there |
| 17:52 | dv_ | otavio: there is the google+ group |
| 17:52 | rabeeh | :) |
| 17:52 | jnettlet | although it may have been a poor choice. |
| 17:52 | rabeeh | i think we are all lost here; anyone suggest how we manage the information? |
| 17:52 | dv_ | otavio: https://plus.google.com/communities/113793735711752568811 |
| 17:53 | dv_ | the g+ community is a nice start. but something that lists the currently running projects would be good |
| 17:53 | rabeeh | dv_: today we have forums / wiki / irc |
| 17:53 | otavio | jnettlet: please use FSL tree |
| 17:53 | otavio | jnettlet: we can cherry-pick code if need |
| 17:54 | otavio | jnettlet: boundary ends adding customer changes there and will be problematic to merge later |
| 17:54 | dv_ | rabeeh: the imx wiki? |
| 17:54 | dv_ | should this also be used for development? |
| 17:54 | rabeeh | yes |
| 17:54 | otavio | I can make a project in our Basecamp account |
| 17:54 | otavio | and add people |
| 17:55 | rabeeh | otavio: basecamp is on invitation; we need hundreds of devs to join |
| 17:55 | rabeeh | (and they will once they start getting the devices on end of Nov) |
| 17:55 | otavio | rabeeh: For general people a wiki is the way to go |
| 17:56 | otavio | rabeeh: I am more concerned for us to avoid duplicaitng work and to have a place to share info |
| 17:57 | jnettlet | generally we have just been chatting on the irc channel and posting milestones on g+ but nothing official |
| 17:57 | dv_ | otavio: that is also my concern |
| 17:58 | rabeeh | jnettlet: for instance, i didn't know about your dt support for the fsl 3.10 tree |
| 17:58 | dv_ | otavio: some sort of "opensource imx(6) development center" would be nice to have |
| 17:58 | otavio | The bad of this is people does not follow irc all the time |
| 17:58 | otavio | and gets out of sync |
| 17:58 | rabeeh | otavio: oh they don't |
| 17:58 | dv_ | where projects can be added, links to the repos placed, each project can have a blog etc. |
| 17:58 | rabeeh | look at this http://imx.solid-run.com/forums/viewtopic.php?f=2&t=209 |
| 17:59 | rabeeh | dv_: sounds exactly like what a wiki page should do |
| 18:00 | otavio | ok; back to my work |
| 18:03 | rabeeh | shesselba: what is mostly you are looking for in changing clock settings? |
| 18:03 | rabeeh | i mean for dove and ddr clocks? |
| 18:04 | shesselba | rabeeh: looking at Andrew Lunn's cpufreq driver and was wondering how to interpret the ratios in DFS control registers |
| 18:04 | shesselba | there is CPU PLL to L2 and CPU PLL to DDR ratios |
| 18:07 | shesselba | both are set to 4 (possibly encoded) |
| 18:08 | shesselba | or CPU PLL is actually set to 1.6GHz |
| 18:08 | shesselba | haven't checked all dividers |
| 18:09 | shesselba | anyway, DFS ctrl needs at least L2 ratio set for slow/fast mode transitions |
| 18:10 | shesselba | but who knows what really happens based on the limited FS docu |
| 18:10 | rabeeh | shesselba: doing dfs with dove is way non trivial |
| 18:10 | rabeeh | you need to encode some internal state machine that does the frequency scaling when the processor is in WFI mode |
| 18:10 | shesselba | slow/fast mode transition would be enough for now |
| 18:10 | rabeeh | it's completely non trivial |
| 18:11 | rabeeh | slow / fast is peanutes; you just click that bit, enter WFI (which triggers the change) |
| 18:11 | shesselba | no, you need to setup l2 ratio at least |
| 18:11 | shesselba | (ok, you can get that from CPU clock dividers register) |
| 18:13 | shesselba | but what irritates me, is that ddr ratio can stay at zero |
| 19:24 | jnettlet | rabeeh, https://github.com/linux4kix/linux-imx6/tree/solidrun-imx_3.10.9_1.0.0_alpha |
| 19:24 | jnettlet | still sorting out what has broken -cd detection |
| 19:25 | rabeeh | jnettlet: thanks |
| 19:26 | rabeeh | if that kernel is usable and stable then i think we should completely neglect the 3.0.35 and focus on that as the non mainline kernel |
| 19:26 | rabeeh | what do you think? |
| 19:28 | jnettlet | I agree. just need to get it booting all the way. This problem was supposed to be fixed not sure what has the cd detection all angry. |
| 19:29 | jnettlet | rabeeh, oh...the default config is setup to load the KMS driver not the FBDev. |
| 19:41 | dv_ | jnettlet: so do you think I should add recipes for this kernel to my meta-fsl-arm-extra fork ? |
| 19:42 | dv_ | (once it fully boots) |
| 19:42 | jnettlet | dv_, you can get started on it. It needs some TLC before it is ready for primetime |
| 19:57 | jnettlet | okay the cd_gpio is returning not valid. |
| 20:28 | buzzwash | Hello solidrunners from Washington DC |
| 21:21 | flixh | cbxbiker61: you are around? |
| 21:22 | flixh | cbxbiker61: tried to get the uImage compiled from your 3.11.6 sources running, but it hangs after u-boot says it's trying to load the kernel |
| 21:23 | flixh | damned, i need a stable kernel for my cubox... |
| 21:24 | dv_ | flixh: the 3.6.9 from rabeeh's github repo worked fine for me |
| 21:24 | dv_ | ( https://github.com/rabeeh/linux ) |
| 21:32 | cbxbiker61 | flixh, can you try the 3.11.6 from the xilka site for testing, if it boots for you, then just get me the diff of the config and i'll rebuild |
| 21:50 | flixh | dv_: it's oopsing for me under load when i'm activating lvm, raid support and nfs |
| 21:50 | flixh | cbxbiker61: will try |
| 22:43 | flixh | cbxbiker61: installed 3.11.6 via UPDATE-KENREL.sh, and this one is booting and running right now |
| 22:47 | cbxbiker61 | flixh, just get me a diff of the config you made vs the xilka 3.11.6 and i'll build a new version |
| 22:49 | flixh | cbxbiker61: well, 3.11.6 with my config did not boot. might not be due to my config but can be... |
| 22:49 | cbxbiker61 | probably a compiler issue |
| 22:49 | cbxbiker61 | local compiler's don't get used much (although in my setup they do) |
| 22:50 | flixh | natively, on the cubox? |
| 22:50 | flixh | using gcc 4.8.1 |
| 22:50 | cbxbiker61 | do you have a big linux box? |
| 22:51 | jnettlet | I have found a few problems compiling kernels with 4.8.1 |
| 22:51 | flixh | not big, no. i7 ultrabook |
| 22:51 | jnettlet | hahaha....only an i7 |
| 22:51 | cbxbiker61 | just get me the diff and i'll do it |
| 22:51 | jnettlet | that should compile a kernel in less than 5 minutes with an ssd |
| 22:51 | cbxbiker61 | oh, well you have native linux |
| 22:52 | flixh | well, it's a notebook. I'm doing numerical simulation of production processes, there you get BIG machines :) |
| 22:52 | cbxbiker61 | so get my cross-compile script and build a cross compiler |
| 22:52 | jnettlet | or just grab the Linaro cross compiler. |
| 22:52 | jnettlet | I recommend the 4.7.2 version for stability |
| 22:52 | flixh | cbxbiker61: i lack disk space, unfortunately... i need to clean up... |
| 22:53 | cbxbiker61 | jnettlet, my cross compiler is based on linaro latest (4.8.2+), works great |
| 22:54 | cbxbiker61 | i follow linaro's compiler very closely |
| 22:58 | dv_ | yeah, building linux with gcc 4.8 can cause problems |
| 22:59 | flixh | cbxbiker61: the diff is here http://greenslug.homelinux.org/kernel/dove-3.11.6.config.patch |
| 22:59 | dv_ | there are patches to fix that |
| 22:59 | dv_ | https://lists.yoctoproject.org/pipermail/meta-freescale/2013-July/003534.html |
| 22:59 | flixh | what about gcc 4.6.4 for kernel compilation? |
| 23:01 | cbxbiker61 | like i said linaro 4.8 latest works fine |
| 23:02 | cbxbiker61 | i've got a shitload of people using it |
| 23:03 | cbxbiker61 | in the diff, there should be no reason to build nfs server into kernel, module should be file |
| 23:03 | cbxbiker61 | file/fine |
| 23:03 | flixh | well, i need it anyway so why not put it in there. but yeah, modules should be fine |
| 23:04 | cbxbiker61 | everything else looks fine, i'll build/post a new version in an hour or so |
| 23:05 | flixh | thanks, looking forward to it |
| 23:05 | cbxbiker61 | ok, just remembered, so it doesn't sound like i was shouting, older kernels don't like 4.8, but all of the newer ones are fine |
| 23:07 | jnettlet | define newer please. |
| 23:07 | jnettlet | I have had problems with linaro 4.8.2 and linux 3.10.xxx |
| 23:09 | flixh | Is "CC=gcc-4.6 make uImage" sufficient to force a specific gcc during building? |
| 23:11 | cbxbiker61 | jnettlet, 3.10.x is fine with gcc 4.8.2+ |
| 23:11 | cbxbiker61 | here it is |
| 23:12 | jnettlet | I will file patches once I get time to figure out what isn't working. |
| 23:12 | cbxbiker61 | hang on, i'll look at my build script, i have it use an older compiler with older kernels |
| 23:14 | cbxbiker61 | actually, i've been building all of the 3.x kernels with current gcc, i only downlevel the compiler for 2.6.x |
| 23:17 | cbxbiker61 | http://www.xilka.com/xilka/source/BuildCrossArm-4.8-2013.10.sh builds a good cross compile |
| 23:47 | cbxbiker61 | flxh, finished building the new 3.11.6, whereever you have your UPDATE-KERNEL.sh just delete *3.11.6* and rerun UPDATE-KERNEL.sh |
| 23:48 | cbxbiker61 | btw, all of the raid stuff is modules |
| 23:56 | _rmk | 23:56 * _rmk_ has his cubox desktop up on the hotel monitor :) |
| 23:56 | bencoh | :) |