| 14:24 | mhilt | anyone have experience getting ov5460 cams running on a Hummingboard2? MIPI or DVP. |
| 14:25 | mhilt | *ov5640 sorry |
| 14:36 | jnettlet | mhilt, it should just plug in and work. |
| 14:36 | jnettlet | topi`, sorry I have been holed away working on the "next big thing" I have come out for a bit of daylight |
| 14:37 | mhilt | jnettlet, which 5640 module have you used? |
| 14:37 | jnettlet | mhilt, our pinout matches the Wandcam. |
| 14:38 | mhilt | I couldn't source any of the three Wandcam parts -- Avnet discontinued, e-con systems discontinued, Radium doesn't respond |
| 14:39 | mhilt | I picked up the Udoo cam |
| 14:39 | mhilt | and made an adapter |
| 14:40 | mhilt | the clock is a mess coming out of the board, so my best guess is the sensor pll isn't locking |
| 14:42 | jnettlet | mhilt, the wandcam uses a clock on the board |
| 14:42 | jnettlet | it has its own crystal I believe |
| 14:42 | jnettlet | mhilt, you mind posting your device-tree changes so I can take a look? |
| 14:42 | mhilt | yeah, I guessed that might be the case |
| 14:46 | jnettlet | mhilt, what are your camera needs? |
| 14:47 | mhilt | I'm working on a project that needs dual cams |
| 14:47 | mhilt | I actually have the 5640 mostly working via DVP ... |
| 14:47 | mhilt | but picture jumps around -- I think again though it's clock related |
| 14:48 | jnettlet | I have done dual cameras with ov5640 and ov5642 parallel |
| 14:48 | mhilt | both parallel? or one parallel and one MIPI? |
| 14:49 | mhilt | I'll get my device-tree in a second |
| 14:49 | jnettlet | on parallel and one mipi-csi |
| 14:49 | jnettlet | ov5642 is parallel |
| 14:50 | mhilt | yes, that's what I would like to do - but the ov5642 was discontinued; I think ov5640 can be used as either mipi or parallel |
| 14:51 | mhilt | was there a particular 5642 module you tested with? |
| 14:53 | jnettlet | mhilt, you can still find the 5642 on ebay sourced out of China |
| 14:54 | mhilt | well, that's okay for early testing, but I can't use that for a production project :-) |
| 14:55 | jnettlet | most these cameras will be sourced from China regardless |
| 15:58 | vpeter | jnettlet: CuBox-i remote is using NEC or RC6 protocol? |
| 15:59 | jnettlet | vpeter, we specify RC6 by default in the device-tree....but it can be changed to whichever |
| 16:00 | jnettlet | https://github.com/SolidRun/linux-fslc/blob/3.14-1.0.x-mx6-sr/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi#L63 |
| 16:01 | vpeter | thanks. |
| 16:01 | jnettlet | np |
| 16:04 | vpeter | and remote sends rc6 too? This one https://www.solid-run.com/product/ir-remote-control/ |
| 16:05 | jnettlet | yes |
| 16:06 | vpeter | thanks again. Passing info to other guy :) |
| 18:54 | topi` | jnettlet: you're back! |
| 18:55 | topi` | I need a bit of a helping hand here... |
| 18:55 | topi` | don't want to explain why I'm in utter trouble, and what are the ramifications of failure, but in any case, we have a device that should convert DVI-D signal to something that goes to a special display |
| 18:56 | topi` | now, the question is, how to bend the HB to be able to display something that this damn device actually accepts? We have gotten picture successfully from a number of PCs |
| 18:56 | topi` | the *only* difference between the HB HDMI output and the outputs of these PCs are that the PCs have a VGA-compatible chipset like Radeon and so forth |
| 18:57 | topi` | so maybe the "Legacy VGA" does something tricky to the HDMI/DVI signal so that the cursed box accepts it? |
| 19:03 | jnettlet | topi`, what resolution does it need? If we detect DVI we generally on use VESA resolutions |
| 19:04 | topi` | jnettlet: it uses 1024x768-60 but if I force that with a kernel param, then the display is almost broken |
| 19:04 | topi` | if I force 1024x768-60 on a PC running linux, the same kernel params, we get perfect picture |
| 19:04 | topi` | so I've been thinking about the diffrence between a Legacy sw driven PC VGA display and these "custom" HDMI controllers like what iMX6 has |
| 19:05 | topi` | for the record, we couldn't get any picture on a Utilite2 either |
| 19:05 | topi` | which uses the Snapdragon 600, DRM+KMS enabled on the kernel |
| 19:05 | topi` | so it's not just the i.mx6 |
| 19:05 | jnettlet | topi`, does u-boot show a picture? |
| 19:06 | topi` | nope |
| 19:06 | topi` | but one reason for that might be that it generally shows a picture for only 3 seconds, and it might be too little for it to sync |
| 19:06 | topi` | i'm unable to test since the special HW is at our offices in Helsinki, and I'm nowhere near :) |
| 19:06 | topi` | tomorrow my colleagues will conduct further tests |
| 19:07 | topi` | as far as I'm able to figure out what to test |
| 19:08 | topi` | do you have any experience of sw which directly talks to the DRM? |
| 19:09 | topi` | we have a piece of sw from a 3rd party that we license; they are using Qt5 which renders directly to DRM so there's no Xorg at all |
| 19:09 | topi` | that kind of surprised me |
| 19:09 | topi` | that you can do full video + 3d rendering on Qt5 without even firing up X |
| 19:12 | jnettlet | are you using drm, or our kernel with the imx fbdev driver? |
| 19:13 | topi` | on the utilite2, we got the DRM running with freedreno and the Qt5 software just worked |
| 19:14 | topi` | I'm just now beginning to copy the same setup over to my Hummingboard rootfs |
| 19:14 | topi` | but I'm not certain how much of necessary support exists in the 3.14 fslc drm implementation |
| 19:15 | topi` | I also compiled 4.11-rc1 and got it to boot just nicely, reportedly with etnaviv drm |
| 19:16 | topi` | I get two cards (0 and 1) in /dev/dri/ and the other is reported as "imx" and the second one "etnaviv" |
| 19:16 | topi` | kind of confusing, :) |
| 19:16 | jnettlet | we have zero support for drm in 3.14 |
| 19:17 | topi` | oh, OK |
| 19:17 | topi` | but the 4.11 from Linus's tree seemed to work just OK |
| 19:17 | jnettlet | well imx is the display card, and etnaviv is the gpu |
| 19:17 | topi` | but I hear the etnaviv support is kind of experimental still |
| 19:17 | jnettlet | well it isn't very optimized |
| 19:18 | topi` | my fear is that with 4.11 we won't be able to decode video in HW |
| 19:18 | jnettlet | and currently imx drm has issues. since they switched to atomic modesetting it is quite easy to crash the kernel |
| 19:18 | topi` | but since the displays use such a lackluster resolution, we can probably do SW decoding |
| 19:18 | topi` | what does "atomic" modesetting mean? |
| 19:18 | jnettlet | there is basic video decoding in 4.11...mostly jsut h264 support |
| 19:19 | jnettlet | I would have to look what else has been added |
| 19:19 | topi` | h264 is fine, since we will be transcoding the video in any case for the customer |
| 19:19 | topi` | btw, how's your work with the 4.1.x fscl kernel going? |
| 19:19 | jnettlet | slow. their patch methodology is terrible |
| 19:20 | topi` | they still haven't learned :) |
| 19:21 | jnettlet | doubt they ever will. everything is tied into whatever internal review system they use. That generates patches and then they stuff them into git, but they don't re-use those patches in git. |
| 19:21 | jnettlet | so every release branch has no correlation to the previous for diffing etc |
| 19:24 | topi` | is there a way to set the resolution on the standard 3.14 HB image? |
| 19:24 | topi` | I tried fbset, but it returns an error |
| 19:25 | topi` | VSCREENINFO or something... I forgot |
| 19:26 | topi` | ioctl FBIOPUT_VSCREENINFO: Invalid argument |
| 19:26 | topi` | I tried: "fbset 1024x768-60" |
| 19:27 | topi` | is this a known problem? |
| 19:35 | jnettlet | it should work. did you check the modes available under /sys/class/graphics/fb0/modes ? |
| 19:35 | jnettlet | it is also probably worth dumping the edid. |
| 19:38 | topi` | yeah, we have dumped a fair number of EDIDs |
| 19:38 | topi` | but none the wiser :/ |
| 19:38 | topi` | how can I force an EDID on the 3.14 kernel? On the utilite2, I would say: drm_kms_helper.edid_firmware=edid/1024x768.bin |
| 19:39 | topi` | which, incidentally, seems to strip all other resolution options from the kernel than that 1024x768 |
| 19:39 | topi` | jnettlet: I just looked at fb0/modes and yes, only U:1920x1080p-0 there |
| 19:40 | topi` | so maybe that's why fbset fails to do anything |
| 19:40 | topi` | is there a way to force an entire res&modeline combo and ignore the limitations of fb0/modes ? |
| 19:43 | jnettlet | yeah, so it looks like the device doesn't provide an edid. |
| 19:43 | jnettlet | let me check the detection flow real quick. it has been a while since I have had to dig around there. |
| 19:45 | jnettlet | topi`, ah yes. If we don't detect an edid we assume that it is an HDMI connection because well it is 2017 :) |
| 19:48 | topi` | :D |
| 19:48 | topi` | well the specs of the device say it expects "DVI-D" at 1024x768-60 |
| 19:49 | topi` | the device DOES provide an EDID response, but my guess is that the response is somehow broken or bad |
| 19:49 | topi` | but why does a PC running a somewhat recent linux kernel still be able to display anything on it? dunno |
| 19:49 | jnettlet | topi`, try setting mxcfb_hdmi.ignore_edid=1 on the kernel commandline and see if that helps |
| 19:50 | jnettlet | that should force the standard list of VESA resolutions |
| 19:50 | topi` | I thought that would be the "standard" when the edid doesn't make sense :) |
| 19:50 | topi` | and anyways, UBOOT ignores edid, doesn't it? |
| 19:50 | jnettlet | yes, but like you said it probably doesn't have time to sync |
| 19:51 | topi` | that's the bit I'm uncertain about |
| 19:52 | jnettlet | well the "standard" used to be that...except now the majority have hdmi screens that need CEA modes to work, so we error on that side. |
| 19:52 | topi` | isn't CEA that TV thingy? as opposed to the "VGA" side of things |
| 19:53 | topi` | that are computer monitors first and foremost |
| 19:53 | jnettlet | CEA vs VESA |
| 19:53 | topi` | yeah |
| 19:54 | jnettlet | but most modern monitors want CEA modes...some monitors specifically DELL ones have a setting in the menu system where you can choose computer or video which means VESA or CEA modes |
| 19:55 | topi` | it seems the 4.11 kernel has more advanced HDMI detection... the dmesg shows a line: "dwhdmi-imx 1200000.hdmi: Detected HDMI TX controller v1.30a with HDCP (DWC HDMI 3D TX PHY) |
| 19:55 | topi` | I haven't yet tried to boot the 4.11 image on the damn devices (as I said I work remotely) but maybe tomorrow we can do that |
| 19:55 | topi` | with luck, something might work :) |
| 19:56 | jnettlet | you can try, but it may run into the same issues. rmk has written much of the imx drm support a lot of the detection we worked out together, him on drm and me on the legacy driver. |
| 19:57 | topi` | well trying only costs a few minutes :) |
| 19:57 | topi` | since I already have the kernel copmiled and the right flags worked out |
| 20:04 | topi` | btw, I could not find a .dtb for hummingboard2 in the mainline kernel tree... any ideas if it exists? :) |
| 20:04 | topi` | I had to test it on the hummingboard1 pro |
| 20:05 | jnettlet | topi`, we are working on it. |
| 20:05 | jnettlet | should make it into 4.11 |
| 20:05 | topi` | great :) |
| 20:05 | jnettlet | it was my fault it didn't make 4.10 |
| 20:05 | topi` | can you provide me with a work-in-progress at short notice? |
| 20:06 | topi` | we only have HB2's at the office |
| 20:06 | topi` | I happen to have some of the older ones at home :) |
| 20:06 | jnettlet | sure |
| 21:18 | Artox | arm-linux-gnueabihf-ld: command not found |
| 21:18 | Artox | really, this is driving me mad |
| 21:18 | Artox | so it found arm-linux-gnueabihf-gcc |
| 21:18 | Artox | but not -ld |
| 21:19 | Artox | wheezy didn't have that name :( |