| 00:15 | pepedog | Rabeeh |
| 00:15 | rabeeh | pepedog: hi |
| 00:15 | rabeeh | how are you? |
| 00:16 | pepedog | Is there vivante binaries |
| 00:16 | pepedog | Yes, I'm fine, thank you |
| 00:16 | pepedog | How are you? |
| 00:16 | Whitepyro | Hello Rebeeh :) |
| 00:16 | pepedog | Xorg.conf too |
| 00:17 | pepedog | I'm refining my rootfs img |
| 00:17 | rabeeh | i'm great |
| 00:17 | rabeeh | Whitepyro: hi |
| 00:18 | Whitepyro | How are you today? |
| 00:18 | rabeeh | pepedog: sorry; but i'm lagging on that info |
| 00:18 | rabeeh | Whitepyro: great. thanks |
| 00:18 | Whitepyro | Good to hear. :) |
| 00:18 | rabeeh | pepedog: i wanted to ask about how you make your rootfs |
| 00:18 | rabeeh | is there a script around that makes that? or everything is manual? |
| 00:19 | Whitepyro | I was thinking.... Got a question... If you got time to answer. What do you think makes you different from the "utilite"? Is there much difference? Where do you think you excel over them? |
| 00:19 | pepedog | Yes, I have a script, but it has to be run on arch, on any v7 |
| 00:20 | rabeeh | pepedog: is the script public any where? |
| 00:21 | rabeeh | pepedog: the reason i'm asking is that previously devs had rootfs images that are hard to maintain; since they where all done by either a private script; or sometimes 100% manual |
| 00:21 | rabeeh | which forbids repetition; and upgrade from other devs |
| 00:22 | rabeeh | Whitepyro: there are differences; but we all share the same imx6 products |
| 00:22 | pepedog | Hold on, will scp (which I thought I already done) |
| 00:23 | rabeeh | pepedog: i'm not sure if this is a good idea or not; but what do you think of having a centralized area which rootfs are generated by scripts (either native or on x86) |
| 00:23 | Whitepyro | Care to elaberate on those differences? I'm still on the fence.. But I've been watching the forums religiously LOL.. Also there's a lot of spam on there as of late.... :| Might wanna look into that. |
| 00:24 | rabeeh | Whitepyro: yeah; spam about going to Jordan :) |
| 00:24 | rabeeh | we have been trying to fight that spam a long time |
| 00:24 | rabeeh | maybe with the VouchSafe captcha things will be easier. |
| 00:25 | Whitepyro | Have you guys decided about going public with the carrier one board? Would be great for a lot of people with Rasberry pi's to fit in their existing case :P.. Just a thought... |
| 00:25 | Whitepyro | Yeah the spam really sucks...... |
| 00:25 | pepedog | Make me mod like other forum |
| 00:25 | Whitepyro | Needs' more moderators..... :| |
| 00:25 | pepedog | http://myplugbox.com/mkca |
| 00:25 | rabeeh | Whitepyro: we are having lots of debates about that |
| 00:25 | rabeeh | we are getting lots of requests on getting the c1 board public; still no decision here |
| 00:25 | Whitepyro | I want it though hehe |
| 00:26 | rabeeh | :) |
| 00:26 | Whitepyro | Either one |
| 00:26 | Whitepyro | :P |
| 00:26 | Whitepyro | I just want a stable xbmc |
| 00:26 | Whitepyro | :P |
| 00:26 | rabeeh | the C1 is unlike CuBox-i or Utilite |
| 00:26 | Whitepyro | Rasp pi not having AAC decode is a bugger. |
| 00:26 | rabeeh | it's a bare board |
| 00:26 | pepedog | C1 10 second boot, utilite quad 25 seconds |
| 00:27 | pepedog | Utilite on ssd too |
| 00:27 | Whitepyro | yeah an ssd would be killer |
| 00:27 | Whitepyro | :P |
| 00:27 | Whitepyro | but i feel the problem with utilite is that lack of software support (that I can see) |
| 00:28 | Whitepyro | At least with your products there's geekbox, etc. |
| 00:28 | Whitepyro | plus the footprint is smaller :P |
| 00:28 | rabeeh | Whitepyro: Stephan (Wolfgar) from xbmc has support to utilite too. |
| 00:29 | rabeeh | yeah; the footprint is much much more smaller :) |
| 00:29 | Whitepyro | Yeah I've read his blog... But it seems its still in a beta/alpha state and such |
| 00:29 | Whitepyro | no visible files have been released that I could see too. |
| 00:31 | rabeeh | pepedog: why can't this script run also on an x86? |
| 00:32 | rabeeh | because of 'pacstrap'? |
| 00:32 | rabeeh | i think with static qemu-system-arm this can be done |
| 00:33 | rabeeh | anyhow; it looks really easy |
| 00:33 | pepedog | Because the archchroot part (fancy chroot that fixes niggles), and pacstrap. |
| 00:34 | rabeeh | pepedog: the good part of the imx6 support is that the dri driver should be already done by freescale |
| 00:34 | rabeeh | so getting accelerated X should be doable, easily |
| 00:34 | rabeeh | the thing is that i was so busy on working on getting production hardware and initial software and community support that i haven't spent any time doing the X stuff |
| 00:35 | rabeeh | maybe the folks around here can help a bit (namely jnettlet, dv_, _rmk_, otavio) |
| 00:35 | rabeeh | anyone else is welcome to step in and give us the 10m lecture on how to get accelerated X |
| 00:35 | Bluerise | rabeeh: just by the way: thanks for all the great work |
| 00:35 | pepedog | Pacstrap https://wiki.archlinux.org/index.php/Install_from_Existing_Linux#Alternative:_Install_arch-install-scripts_natively_on_non_Arch_distro |
| 00:36 | rabeeh | Bluerise: thank you for the support. the great work is still not there :) |
| 00:36 | rabeeh | there is lots of work; once we start shipping it will be great :) |
| 00:36 | _rmk_ | rabeeh: I'd be much closer to that if the hardware was stable - I'm seriously doubting that the IPU can cope reliably with resolution changes |
| 00:36 | pepedog | systemctl commands can be done with symlinks |
| 00:36 | pepedog | Change passwd with sed |
| 00:36 | rabeeh | we are trying to get as much hardware in hands of devs to get the platform the best around for community work |
| 00:37 | _rmk_ | after a few resolution changes, I'm just seeing the whole IPU turn into lemon mode - it's got clocks but nothing is running internally. All fifos are empty. |
| 00:38 | _rmk_ | annoyingly, there's no register(s) to read to show any counters are running, and there's no registers to hit to say "reset this bit of the IPU" or even "reset the whole IPU" |
| 00:39 | Whitepyro | So you going to do any new videos soon rabeeh? :P I like seeing the hardware working hehe.. |
| 00:40 | rabeeh | _rmk_: do you think it's a hardware thing? |
| 00:40 | rabeeh | i think there are few contacts a freescale that we can pull to debug this |
| 00:41 | _rmk_ | rabeeh: I'm beginning to suspect so, I've been prodding the hardware trying to work out what's going on for quite some time now. |
| 00:42 | _rmk_ | what I'm seeing is after doing a few mode sets under X, the TV stops saying it has a signal. |
| 00:42 | _rmk_ | If I put a frequency counter on the TMDS clock, I have the right clock rate. The scope shows that its a stable clock. |
| 00:42 | rabeeh | oh |
| 00:43 | _rmk_ | If I then look at the TMDS data lines, there's some data but not as much as I would expect given the complex image. |
| 00:43 | rabeeh | but your scope wouldn't see anything since those are high frequencies |
| 00:43 | rabeeh | (on the data lines) |
| 00:43 | _rmk_ | err, at low res it's fine. |
| 00:43 | _rmk_ | what I summise is that the HDMI phy and bridge are still working - outputting the control and data but no video information at all |
| 00:44 | _rmk_ | so no pixel info, no hsync or vsync markers |
| 00:44 | _rmk_ | and I think that's because the IPU is just totally dead - no counters are running there to generate the hsync/vsync, and all the fifo status registers in the DI, DMFC, IDMAC all report empty |
| 00:45 | rabeeh | _rmk_: when changing between frequencies; is it required to reset the IPU? |
| 00:45 | _rmk_ | once it gets into this state, it doesn't matter what I do, it doesn't recover until I reboot |
| 00:45 | _rmk_ | there's no IPU reset from what I can see |
| 00:46 | rabeeh | or at least the part that gets the new clock and it's relevant fifo? |
| 00:46 | _rmk_ | I've been through all the IPU registers looking for some kind of reset I can use to recover it |
| 00:47 | rabeeh | changing frequencies in a middle can create glitches that a state machine in the entrance of the IPU can get stuck |
| 00:47 | rabeeh | which pll are you using now? |
| 00:47 | _rmk_ | if you have fbset, and if that works, you could try under the FSL BSP several different resolutions and see whether it behaves the same |
| 00:47 | rabeeh | did you try and you say it's the same behavior? |
| 00:47 | rabeeh | or you are asking me to try? |
| 00:48 | rabeeh | is it good enough to switch between two frequencies? or much more? |
| 00:48 | _rmk_ | the DI is now running off PLL5, and the IPU runs off that mmdc_ch0 thing |
| 00:48 | _rmk_ | at 198MHz |
| 00:48 | _rmk_ | ipu at 198MHz, mmdc_ch0 at 396MHz |
| 00:48 | _rmk_ | from PLL2 |
| 00:49 | _rmk_ | it would be useful if someone else can confirm this. |
| 00:49 | _rmk_ | what I'm doing here is cycling through the 10 basic resolutions my TV supports, leaving each one set for 15 seconds |
| 00:50 | rabeeh | why do you care about mmdc clock? |
| 00:50 | _rmk_ | sometimes it makes it through the whole lot, other times it does this and then its reboot time |
| 00:50 | rabeeh | are you running in frequency scaling of the dram controller too? |
| 00:50 | _rmk_ | rabeeh: this is how 3.12-rc sets it all up. I assume it's some default. |
| 00:51 | rabeeh | _rmk_: in the freescale bsp; if the hdmi monitor is off and processor is idle; mmdc can frequency scale from 396mhz to 25mhz |
| 00:51 | rabeeh | i'm not sure if you are running low resolution on hdmi (i.e. low bandwidth) it is allowed to switch the frequency of the mmdc |
| 00:51 | rabeeh | oh; which u-boot are you running? |
| 00:52 | rabeeh | jnettlet? or mine? |
| 00:52 | _rmk_ | do you know where the freescale bsp sources the ipu clock from? |
| 00:52 | _rmk_ | jnettlet's |
| 00:52 | _rmk_ | I'm talking about the IPU1_HSP_CLK_ROOT as shown on their CCM clock tree diagram |
| 00:56 | rabeeh | what does your 0x020c403c register say? |
| 00:56 | rabeeh | CCM_CSCDR3 |
| 00:56 | _rmk_ | Value at address 0x20C403C (0xb6ff603c): 0x10841 |
| 00:58 | _rmk_ | bits 10,9 are the ipu mux setting, both 00 for me there |
| 00:58 | rabeeh | devmem 0x020c403c |
| 00:58 | rabeeh | 0x00014E41 |
| 00:59 | _rmk_ | so you're running off the 540MHz PFD |
| 00:59 | _rmk_ | there's nothing doing any scaling in my kernel though (that's not supported yet) |
| 01:02 | rabeeh | _rmk_: if i would guess; i would say that the problem is unrelated to the ipu frequency itself |
| 01:02 | rabeeh | ipu freq is fixed all the way; right? |
| 01:02 | _rmk_ | yes, never changes from 198MHz for me |
| 01:02 | _rmk_ | the DI external clock is the one I change via PLL5 |
| 01:03 | rabeeh | i recall reading somewhere in the reference manual that they have glitchless plls |
| 01:03 | rabeeh | i'm reading the section back again. |
| 01:05 | _rmk_ | I could try toggling between 720x480 and 720x576... that won't change the clocking at all, won't change the X resolution but will change the Y |
| 01:11 | _rmk_ | another one to try is toggling between 720p @60 and @50Hz - same pixclock but quite different settings in the ipu |
| 01:11 | rabeeh | _rmk_: that's a good idea |
| 01:11 | rabeeh | it would only change the divider? |
| 01:12 | rabeeh | 18.5.1.5.3 PLL clock change |
| 01:12 | rabeeh | In order to modify or stop the clock output of a specific PLL, all the clocks generated |
| 01:12 | rabeeh | from the current PLL must be transitioned to the new PLL whose frequency is not being |
| 01:12 | rabeeh | modified. |
| 01:12 | rabeeh | For clocks which can't be stopped (core and bus clocks), this should be done via the |
| 01:12 | rabeeh | glitchless mux. Before changing the PLL setting, power it down. Power up the PLL after |
| 01:12 | rabeeh | the change. See Disabling / Enabling PLLsfor more information. |
| 01:12 | rabeeh | oops - sorry for the flood |
| 01:12 | rabeeh | _rmk_: they mention a glitchless mux. |
| 01:12 | _rmk_ | yea, there isn't one on the DI external clock path :( |
| 01:13 | _rmk_ | or if there is, they haven't marked it |
| 01:17 | _rmk_ | it just went with the 720p 50 <-> 60Hz switching |
| 01:18 | _rmk_ | the pixclock and vertical scan settings are identical for those two modes, its all in the horizontal settings: |
| 01:18 | _rmk_ | h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.0KHz |
| 01:18 | _rmk_ | h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.5KHz |
| 01:36 | _rmk_ | ah ha, we have an IPU reset bit |
| 01:49 | _rmk_ | oh god Sascha, what mess have you created here... |
| 01:51 | rabeeh | :) |
| 01:51 | rabeeh | Sascha from Pengutronix? |
| 01:51 | rabee | 01:51 * rabeeh needs to get some sleep |
| 01:51 | rabeeh | good night all |
| 01:52 | Bluerise | night! |
| 01:52 | _rmk_ | yea |
| 12:08 | jnettlet | _rmk_, have you seen this error amonst your carrier-1 kernel tribulations. mmc0: Card removed during transfer! |
| 12:08 | jnettlet | mmc0: Resetting controller. |
| 12:08 | jnettlet | mmcblk0: unknown error -123 sending read/write command, card status 0x900 |
| 12:10 | jnettle | 12:10 * jnettlet needs to run out for 30min. |
| 12:10 | _rmk_ | I don't believe so |
| 12:10 | _rmk_ | but the card doesn't get accessed very much while the kernel's running |
| 12:15 | _rmk_ | okay, imx-drm hacks around the problem of interfacing DT into DRM really badly, and it leads to exactly the oops I saw last night because it gets it all wrong |
| 12:16 | _rmk_ | the various sub-modules providing the outputs all assume that the "card" is present - unbinding the device which provides that causes hell becaues it cleans stuff up without these other modules really knowing about it |
| 12:53 | svere | _rmk_: sounds like it would be better to rewrite the whole thing |
| 12:55 | _rmk_ | its the same problem which my armada drm would suffer from if it were DT-ified |
| 12:56 | _rmk_ | we actually could do with some generic infrastructure to help deal with this problem |
| 12:57 | svere | _rmk_: so it frees the crtcs without the other parts knowing about it? |
| 12:57 | _rmk_ | no, it frees the drm_device leaving everything else behind - the individual component destroy functions are empty |
| 12:57 | _rmk_ | this causes drm itself not to shut down properly |
| 12:58 | _rmk_ | so we end up with kernel warnings that there are still framebuffers registered (WARNING: CPU: 0 PID: 863 at /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_crtc.c:4036 drm_mode_config_cleanup+0x250/0x25c()) and warnings that the memory managers aren't clean (WARNING: CPU: 0 PID: 863 at /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2c/0x34()) |
| 12:58 | svere | so the correct way would be to tell all components to destroy first? |
| 12:59 | _rmk_ | yes, but that's not easy given how Sascha has structured this, because you then have the reverse problem when the drm_device is re-created later |
| 13:00 | _rmk_ | this multi-device problem is something I've been thinking needs to be sorted at a higher level anyway - asoc has the same problem and its own solution to it |
| 13:00 | svere | seems simlar to the clock trees no? you need to know what your parent is / childs are |
| 13:00 | svere | at destroy you destroy the childs first, at create you create the parent and it creates his childs |
| 13:01 | svere | like tree-up tree-down |
| 13:01 | _rmk_ | btw, I'm producing the warnings by just doing this: |
| 13:01 | _rmk_ | echo imx-drm > /sys/bus/platform/drivers/imx-drm/unbind |
| 13:01 | _rmk_ | if you then do this: |
| 13:01 | _rmk_ | echo imx-drm > /sys/bus/platform/drivers/imx-drm/bind |
| 13:01 | _rmk_ | echo imx-drm > /sys/bus/platform/drivers/imx-drm/unbind |
| 13:02 | _rmk_ | then you oops the kernel |
| 13:02 | svere | yeah i read your mail but don't have a device to test yet |
| 13:02 | svere | :-( |
| 13:02 | _rmk_ | I've just been taking the opportunity of an easily provokable oops to fix some of the backtracing code to produce slightly nicer output |
| 13:03 | svere | :-) |
| 13:04 | svere | yeah and i saw that drm_fbdev_cma_restore_mode() doesn't check the return value of drm_fb_helper_restore_fbdev_mode(), so errors there go silently |
| 13:05 | svere | _rmk_: btw how many crtcs does the current hardware support? i thought 2 |
| 13:05 | svere | i'm asking because imx-fbdev has MAX_CONNECTOR 4 |
| 13:06 | _rmk_ | remember that in DRM, CRTCs can be attached to more than one connector |
| 13:08 | _rmk_ | I haven't quite worked out how a "crtc" maps to the IPU, but I think there's two "crtcs" per IPU - at least that's how DT describes it. I'm less than certain because I think the IPU can only support one primary video display data stream |
| 13:08 | svere | didn't know that... do you have a link to some good doc about drm to understand its internals? |
| 13:09 | svere | _rmk_: true, there are two DIs per IPU |
| 13:09 | _rmk_ | docs on drm are quite difficult to come by, but the code is quite understandable for the most part. |
| 13:09 | svere | according to the ref. manual |
| 13:10 | svere | _rmk_: ok. i think i will figure out the overall flow of drm for practice and write it down somewhere :-) |
| 13:11 | _rmk_ | the general model is: on mode set, you can attach a number of connectors a crtc. the connectors have encoders, and the connector chooses the appropriate encoder. |
| 13:11 | _rmk_ | all connectors attached to a crtc have the same display timing of course |
| 13:11 | svere | so connectors are physical connectors? |
| 13:12 | _rmk_ | yes - to a certain extent. It's obvious with things like HDMI and VGA, but less so with LVDS (think about the socket the panel has to plug into on the motherboard in a laptop!) |
| 13:13 | svere | sorry for the stupid questions, but its quite hard to start as a noob if you have 10 loose ends... |
| 13:13 | svere | understood |
| 13:13 | _rmk_ | oh I know :) I had the same problem with asoc and the maintainer was entirely unhelpful to the point of being quite obstructive |
| 13:14 | _rmk_ | but there's a big difference between asoc and drm: drm code is loads easier to read than asoc :) |
| 13:14 | svere | so when setting a display mode, the connectors (e.g. HDMI) are connected to the crts which in our case correpond to the DI of an IPU? |
| 13:15 | svere | _rmk_: your help is very much appreciated |
| 13:15 | _rmk_ | the DIs appear to correspond to crtcs, and things like the HDMI phy and LDB (lvds bridge) are the connectors/encoders |
| 13:16 | _rmk_ | btw, many "connectors" wrap the encoder up with themselves. |
| 13:16 | _rmk_ | especially if there's only one possible "encoder" |
| 13:17 | svere | ahhh ok |
| 13:17 | _rmk_ | My understanding of the IPU is that the DIs take the stream of data to be displayed and add timing information to it |
| 13:17 | _rmk_ | the data stream is generated by the previous modules in the IPU, which includes the overlay processing, addition of cursor, etc |
| 13:18 | svere | so the DIs read-out the resulting images, add timing information and pass them to the encoders like HDMI etc |
| 13:19 | _rmk_ | the DIs take that data stream, add a pixel clock, and a number of "waveforms" to it (which when programmed appropriately, resemble the line and frame syncs) and provide the output at the required pixel clock rate onto a bus. |
| 13:19 | _rmk_ | so you end up with two buses, one for each DI. |
| 13:20 | _rmk_ | hanging off those buses are a set of muxes, one per "output" module (LVDS/HDMI etc) which selects which DI those use |
| 13:21 | svere | ok, and that's where the clock stuff comes into play because we need to provide the "correct" pixel clock to the DIs |
| 13:21 | svere | ok |
| 13:24 | _rmk_ | okay, next week I'm not going to be able to do much with the carrier-1 - I could take it with me, but its root fs is on NFS and that's staying here |
| 13:28 | svere | _rmk_: we are currently using pll5 for generating the pixel clock. is this correct? |
| 15:01 | _rmk_ | ok, I think giving up with imx-drm at least until after KS is a good plan, it's just far too broken, and there's a DRM bug too which needs fixing |
| 15:01 | _rmk_ | svere: correct |
| 15:01 | _rmk_ | svere: well, mostly anyway. |
| 15:02 | _rmk_ | as I said before, I'm using PLL5 if the IPU clock can't give us a clock within 1% of the desired pixel clock |
| 15:59 | svere | _rmk_: which xorg driver are you using for test? and can i find it somewhere? |
| 16:16 | _rmk_ | I'm using my own armada-drm one, but apparantly xf86-modesetting should work too |
| 16:17 | svere | _rmk_: will give it a try once my carrier-1 arives |
| 16:19 | _rmk_ | the advantage of using xf86-modesetting is that you won't have any of the dependencies on the vivante gpu drivers to worry about |
| 16:21 | svere | good |
| 16:22 | svere | _rmk_: btw did you push your latest state to your git already? |
| 16:36 | jnettlet | a good test would be to get the xf86-arm-soc driver and try it. That is supposed to be the base for arm based KMS drivers. |
| 16:38 | _rmk_ | jnettlet: I think there's several projects all working to the same goal... |
| 16:38 | _rmk_ | isn't the modesetting driver the already generic kms driver? |
| 16:39 | _rmk_ | and I think the idea is that X would try and load a separate GPU acceleration driver |
| 16:39 | jnettlet | that is the plan, although I haven't found any evidence of progress on that topic. |
| 16:39 | _rmk_ | if that's the case, I don't see any reason why we'd need someone to go off and write something ARM specific |
| 16:39 | _rmk_ | and it's something which should not be ARM specific anyway |
| 16:41 | jnettlet | you would think that. But then that driver is still heavily geared to the exynos chipset which is what it was developed on. |
| 16:41 | _rmk | 16:41 * _rmk_ doesn't rate the exynos drm driver very highly, because that's where this drm dt mess was first created |
| 16:42 | jnettlet | so I can grab my zImage and .dtb file over tftp but then my script breaks trying to load them. |
| 16:50 | jnettlet | damn the usb port just sheered off my board |
| 16:51 | _rmk_ | how did you manage that? |
| 16:52 | jnettlet | looks like there was enough tension on the power cord that whenever I would hit the reset button or pop out the sdhc card it would rock the port enough to fatigue the metal. |
| 16:54 | _rmk_ | you know where to pick up some places to supply 5v? |
| 16:55 | jnettlet | _rmk_, yep the fuse pad I already blew and jumped with solder :-) |
| 16:55 | _rmk_ | next to that micro usb connector, there's a pattern for one of those through-hole power sockets |
| 16:56 | svere | cu |
| 16:58 | jnettle | 16:58 * jnettlet was thinking about supergluing that connector. |
| 16:58 | jnettlet | should have gone with my instincts |
| 16:58 | _rmk_ | oh, you resoldered it first? |
| 17:00 | jnettlet | I resoldered the micro usb connector back when rabeeh warned us. Then I blew a fuse on the board and removed it to get things working again. |
| 17:00 | jnettlet | I noticed a little play in the micro-usb connector and was thinking I should probably glue it to the board to be safe, but then got distracted |
| 17:01 | jnettlet | my resolder and the ends of the posts are still attached to the board :-) |
| 17:03 | _rmk_ | hmm. |
| 17:06 | jnettlet | I think I may have been the recipient of the "problem" board. There is always one or two in the initial batch |
| 17:07 | _rmk_ | so you don't think you have a carrier-1 board there but a problem board :p |
| 17:11 | jnettlet | the thing is I knew I was tempting fate this morning when I repaired my wife's galaxy note 2's smashed screen. |
| 17:12 | jnettlet | my life has to have a "broken" things quota, and with that fixed something else was inevitably going to break. |
| 17:12 | jnettlet | at first I thought it was going to be the car when we went out shopping, but nope carrier-1 board |
| 17:15 | _rmk | 17:15 * _rmk_ grumbles, imx-drm is disgusting |
| 17:16 | _rmk_ | I just found a late_initcall in it which adds the CMA stuff after all the other sub-modules have registered |
| 17:17 | _rmk_ | which is one of the reasons I'm getting one of the oopses |
| 17:54 | lioka | drivers/staging/imx-drm/ipu-v3/ipu-di.c:610:2: error: 'struct ipu_di_signal_cfg' has no member named 'pixclock' |
| 17:55 | lioka | s,pixclock,pixelclock, i assume ? |
| 17:59 | _rmk_ | yep |
| 18:14 | _rmk_ | robclark: still here? |
| 18:14 | robclark | hi _rmk_ |
| 18:14 | _rmk_ | can you explain what function the drm_bridge stuff provides? |
| 18:15 | robclark | I guess you can think of it as allowing an extra level of encoder (but not visible to userspace).. basically it enables bridge chips (like lvds to eDP, and that sort of thing) |
| 18:16 | _rmk_ | so, the encoder would be pixels to lvds, and then the bridge would be lvds to DP? |
| 18:16 | robclark | yeah |
| 18:16 | jnettlet | okay back in business |
| 18:17 | _rmk_ | well, I keep looking at how to fix this imx-drm module mess and keep coming up against brick walls |
| 18:18 | robclark | hmm.. |
| 18:18 | _rmk_ | I have quite a long email describing how imx-drm initialisation works now |
| 18:19 | _rmk_ | its really quite scarey |
| 18:19 | robclark | I did finally get my 3.3V uart->usb.. so I guess I should make some time to play w/ imx-drm.. |
| 18:19 | robclark | I suppose I should be glad for not having had to look at imx-drm at all yet :-/ |
| 18:20 | robclark | _rmk_, did you send email to some list? |
| 18:20 | _rmk_ | luckily for you, I've not sent yet, otherwise you'll probably be running away from it by now |
| 18:20 | robclark | heheh, ok |
| 18:21 | robclark | maybe you should make that email in form of a patch to imx-drm/TODO |
| 18:21 | _rmk_ | when you do, just don't unbind the imx-drm device. it will get rid of the drm_device structure, leaving everything else in place with pointers to it. |
| 18:21 | robclark | to be sure that everyone knows what needs to be fixed before moving out of staging |
| 18:22 | robclark | awesome |
| 18:22 | _rmk_ | then all it takes is something to try and take a DRM lock and... bang. |
| 18:24 | robclark | oh, fun.. looks like it is four drivers, which I guess can all be registered/unregistered independently? |
| 18:24 | robclark | err, no, 5.. there is a subdir.. |
| 18:25 | _rmk_ | this is the list from built-in.o: |
| 18:25 | _rmk_ | 0: R_ARM_ABS32 imx_drm_init |
| 18:25 | _rmk_ | 4: R_ARM_ABS32 imx_pd_driver_init |
| 18:25 | _rmk_ | 8: R_ARM_ABS32 imx_tve_driver_init |
| 18:25 | _rmk_ | c: R_ARM_ABS32 imx_ldb_driver_init |
| 18:25 | _rmk_ | 10: R_ARM_ABS32 imx_ipu_driver_init |
| 18:25 | _rmk_ | 14: R_ARM_ABS32 ipu_drm_driver_init |
| 18:25 | _rmk_ | 18: R_ARM_ABS32 imx_hdmi_driver_init |
| 18:25 | _rmk_ | all those as module_init, and this as a late_initcall: |
| 18:25 | _rmk_ | 0: R_ARM_ABS32 imx_fb_helper_init |
| 18:26 | robclark | oh, yeah, I guess I don't have hdmi yet |
| 18:26 | _rmk_ | and it's 100% reliant on those being called in that exact order |
| 18:26 | robclark | what can possibly go wrong :-P |
| 18:27 | _rmk_ | -EPROBE_DEFER one day? thankfully not yet though. |
| 18:31 | robclark | _rmk_, well, anyways, I don't think bridge really helps w/ the module init order.. maybe we can do something in drm to handle better modular drivers, although userspace is still not going to be aware of connectors which show up late to the party |
| 18:32 | robclark | tbh drm grew up w/ desktop cards, where you either had the thing plugged in or you didn't |
| 18:32 | _rmk_ | no, I was just wondering how it fitted into the model |
| 18:32 | robclark | ahh, ok |
| 18:33 | _rmk_ | I guess at some point some docs ought to be created with pretty diagrams showing the DRM structure of these key components :) |
| 18:33 | robclark | I though we added bridge to drm docbook.. although, yeah, probably some pictures would be useful too |
| 18:33 | _rmk_ | why did everyone else just take a step backwards? :) |
| 18:47 | lioka | _rmk_: you mention your rootfs is on nfs -- is ethernet is working in u-boot on your board ? |
| 18:47 | lioka | mine says Net: No ethernet found. |
| 18:48 | _rmk_ | yes, my rootfs is on nfs, but I'm actually still booting the kernel off a fat partition on the sd card rather than NFS... |
| 18:48 | lioka | and to be honest i still can't boot any kernel on my carrier-one, even that precompiled from cubox-i ftp |
| 18:49 | _rmk_ | can you log the serial and upload it somewhere? (some paste site?) |
| 18:49 | lioka | got nothing after Startng kernel... on every kernel i tried |
| 18:50 | _rmk_ | what have you set the bootargs to? |
| 18:51 | lioka | console=ttymxc0,115200 |
| 18:51 | lioka | plus nosmp sometimes |
| 18:52 | _rmk_ | it still would be interesting to see the serial output |
| 18:52 | lioka | last kernel i've tried was your, with imx_v6_v7_defconfig and CONFIG_ARM_APPENDED_DTB=y |
| 18:56 | jnettle | 18:56 * jnettlet just finished some changes and now has kernel/dtb loading from tftp |
| 18:56 | jnettlet | nfs root mounting should also work. |
| 18:57 | lioka | http://pastebin.ca/2469119 |
| 18:59 | lioka | and printenv, http://pastebin.ca/2469120 |
| 19:00 | _rmk_ | hmm, don't see anything obviously wrong there. |
| 19:01 | jnettlet | lioka use my version of u-boot |
| 19:01 | lioka | jnettlet: sure. where can i grab one ? (excuses :) |
| 19:01 | jnettlet | do you want to compile it yourself or just use a binary? |
| 19:02 | lioka | jnettlet: binary would be great |
| 19:03 | jnettlet | lioka, https://dl.dropboxusercontent.com/u/736509/u-boot.imx put it on your card with dd if=u-boot.imx of=/dev/sdX bs=512 seek=2 conv=fsync |
| 19:03 | jnettlet | obviously changing paths and such for your setup. |
| 19:04 | _rmk_ | jnettlet: I see a lot of people quote /dev/sdX for SD cards... why is this? |
| 19:04 | dxtr | Okay, so why is geexbox using 60% CPU constantly? |
| 19:04 | _rmk_ | /dev/sd* has traditionally been for SCSI/SATA disks |
| 19:04 | dxtr | Installed from the cubox installer |
| 19:04 | dxtr | dv505: I checked the CPU usage (re: the geexbox problems yesterday |
| 19:04 | jnettlet | _rmk_, because capital X will never match a card so it will error out rather than overwrite an existing partition of the wrong device |
| 19:05 | _rmk_ | I guess if you're using a USB based thing for the SD card, they may show up as a scsi disk |
| 19:05 | jnettlet | oh you mean the /dev/sd |
| 19:05 | jnettlet | /dev/sd is generally SCSI/SATA or removable media. |
| 19:05 | _rmk_ | yea, there's the danger of doing it to /dev/sda which would be bad on modern SATA systems :) |
| 19:06 | jnettlet | mmcblk is usually internal non-removable media. |
| 19:06 | _rmk_ | its mmcblk for me on my laptop which has a built-in sd card slot |
| 19:07 | _rmk_ | I'd suggest just using $device or something bland like that without suggesting that it may start with "sd" |
| 19:07 | jnettlet | interesting. I should ping cjb about it |
| 19:08 | jnettlet | _rmk_, you may want to update to that u-boot image as well. It allows saving the u-boot env to the sdhc card if you make changes. |
| 19:08 | jnettlet | and not needing an appended dtb is nice also. |
| 19:09 | _rmk_ | yea, I ought to make it tftp the boot script and dtb, and then load the initramfs off the sd card |
| 19:09 | dxtr | Nevermind, it's up to 90% |
| 19:10 | dxtr | xbmc.bin is using 99% :( |
| 19:12 | dxtr | And that's on idle |
| 19:12 | jnettlet | you can also just drop a uEnv.txt file onto your sdhc card to overwrite some variables. Here is mine for net-booting kernel and device-tree but loading root off sdhc card. http://fpaste.org/48100/28910213/ |
| 19:16 | dxtr | So.. Why is this? |
| 19:16 | _rmk_ | right, got some nice simple component handling into imx-drm |
| 19:18 | lioka | http://pastebin.ca/2469133 my last kernel |
| 19:19 | lioka | http://pastebin.ca/2469136 kernel from solid-run |
| 19:42 | _rmk_ | that is just... weird |
| 19:45 | _rmk_ | oh hang on, what could be the cause is, in this case you're loading the uImage at 0x10008000. Don't do that, load it at 0x10800000 |
| 19:45 | _rmk_ | because... it seems uboot tried to execute the uImage header |
| 19:46 | lioka | lemme check ... |
| 19:48 | lioka | OHNOEZ |
| 19:48 | lioka | it works. silly me. |
| 19:49 | lioka | _rmk_: thank you |
| 19:49 | _rmk_ | whee, another success story :) |
| 19:50 | jas-hacks_ | Are you guys booting the carrier one boards? |
| 19:52 | jnettlet | jas-hacks_, yep |
| 19:53 | jas-hacks_ | cool! What cpu's are on those boards, dual or quad? |
| 19:54 | jnettlet | the first batch are the solo with 512MB's, but they have a microsom so you can upgrade the soc and ram on the board. |
| 20:00 | jas-hacks_ | it will be interesting to see how well any of the linux distros will run in 512MB. |
| 20:02 | _rmk_ | I have ubuntu running on it via nfs and no swap |
| 20:02 | _rmk_ | well, did have until I purposely oopsed the kernel earlier today |
| 20:03 | jnettlet | yes but it is ubuntu 12.04. That may as well be debian :-) |
| 20:03 | jas-hacks_ | is that a headless image? |
| 20:03 | _rmk_ | I'm working (and going slightly mad over) the imx-drm driver |
| 20:05 | jas-hacks_ | I have a 12.04 image with GPU/VPU support, but it is armel. |
| 20:05 | jnettle | 20:05 * jnettlet is just happy that I don't have to pull this sdhc card in and out of the machine anymore |
| 20:06 | _rmk_ | I haven't had to... until I load a nonfunctional kernel onto it :) |
| 20:06 | _rmk_ | which might happen very shortly |
| 20:09 | _rmk_ | pulling the power is something I'm trying to avoid because then it loses the time, and I have to wait for ubuntu to reset the clock before I can get back in. |
| 20:11 | _rmk_ | I have it all nicely scripted here so I just do ./build-cubox-i.sh -m and leave it to build the kernel, copy it and the modules over, and then reboot. |
| 20:11 | _rmk_ | what did I just say... I'm going to have to grab that SD card now. |
| 20:13 | _rmk_ | but all I do is put the SD card in, re-run the script, it spots that the SD card is plugged in instead, and copies the kernel to the card instead of over the network. magic. :) |
| 20:14 | _rmk_ | better... still dies though. |
| 20:52 | _rmk_ | right, at least that gets hdmi registered again via my component interface |
| 20:52 | _rmk_ | now to convert all the other "connectors" |
| 20:55 | flixh | hi i'm trying to get a current tip from https://github.com/rabeeh/linux |
| 20:56 | flixh | to run on my cubox (it's 3.6.9). Unfortunatly I'm getting kernel oops as soon as there is load. |
| 20:57 | flixh | Any pointers to which kernel I should try to get a stable one running. |
| 20:59 | flixh | A precompiled 3.5.0 which I got a long time ago was rock stable . Unfortunatly udev in debian now needs devtmpfs compiled into the kernel, which this one did not have |
| 22:36 | flixh | I have been searching the forums and the wiki for hours, i've been trying four different kernels. |
| 22:37 | flixh | I seem to be unable to find a either a precompiled kernel with device mapper, nfs server, lvm and raid support |
| 22:38 | flixh | or kernel sources other than raabeh's 3.6.9 clone (which produce an oopsing kernel for me). Nobody? |
| 22:44 | cbxbiker61 | did you look at the xilka kernels ? |
| 22:47 | flixh | yes, i looked at one. but lvm or device mapper was not activated. |
| 22:48 | cbxbiker61 | flixh, tell me which config options need to be turned on and i'll update the latest kernel, i don't always get everything turned on |
| 22:56 | flixh | cbxbiker61: that's difficult to list, do you have a .config which i can diff mine against? |
| 22:57 | flixh | oops, paste mishap, sorry |
| 22:57 | flixh | CONFIG_DEVTMPFS=y |
| 22:58 | flixh | CONFIG_BLK_DEV_DM=y |
| 22:58 | flixh | CONFIG_DM_SNAPSHOT=m |
| 22:58 | flixh | CONFIG_DM_CRYPT=m |
| 23:00 | flixh | CONFIG_DM_RAID=m |
| 23:00 | flixh | CONFIG_DM_UEVENT=y |
| 23:01 | flixh | CONFIG_NFS_FS=y |
| 23:01 | flixh | CONFIG_NFSD=y |
| 23:01 | flixh | CONFIG_NFSD_V3=y |
| 23:02 | flixh | I hope, that's it. |
| 23:17 | cbxbiker61 | flixh, i'll do that in a little bit, kinda busy at the moment |
| 23:19 | flixh | cbxbiker61: thanks a lot, which sources are you compiling? if you tell me, i can do it myself. |
| 23:21 | cbxbiker61 | http://www.xilka.com/kernel/3/3.11/3.11.6/source/ and http://www.xilka.com/kernel/3/3.11/3.11.6/release/1/dove-3.11.6.config |
| 23:21 | cbxbiker61 | go ahead and rebuild that and post a diff of your config |
| 23:29 | flixh | cbxbiker61: hm, that's not a simple git tree, so do i need to apply all those patches? In a specific order? |
| 23:30 | cbxbiker61 | local patches311='0001-ARM-Dove-select-CPU_PJ4.patch |
| 23:30 | cbxbiker61 | 0002-ARM-Dove-increment-ZONEORDER.patch |
| 23:30 | cbxbiker61 | 0003-ARM-Dove-Add-the-LCD-in-the-Dove-DT.patch |
| 23:30 | cbxbiker61 | Kernel-3.10-0006-dove-drm.patch |
| 23:31 | cbxbiker61 | Feroceon-no-inline-l2_inv_all.patch |
| 23:31 | cbxbiker61 | linux-3.9.3-kirkwood-crypto-address.patch |
| 23:31 | cbxbiker61 | Kernel-3.5+-f2fs-dont-error-on-xattr-and-acl-options.patch |
| 23:31 | cbxbiker61 | Kernel-3.10-mmc_start_host-mmc_flush_schedule_work.patch |
| 23:31 | cbxbiker61 | Kernel-3.11-Dove-watchdog.patch |
| 23:31 | cbxbiker61 | Kernel-3.11-bluetooth.patch' |
| 23:31 | cbxbiker61 | that's the order |
| 23:31 | flixh | thanks |
| 23:40 | _rmk_ | jnettlet: looks like DRM doesn't support hotplugging certainly connectors from beneath a drm_device |
| 23:58 | flixh | cbxbiker61: compiling, natively on the cubox. I'll see tomorrow evening if the results works. thanks for your help. need to get some sleep now |