| 00:00 | jnettlet | _rmk_, I don't see anything particular about the d in solidrun. There is some scan flicker around the logo on my display. I thought that was a problem with the way I converted the logo. |
| 00:00 | _rmk_ | yes, that's what I see in mine - ficker |
| 00:00 | jnettlet | uboot seems very particular about its bitmap conversion |
| 00:01 | jnettlet | you see that in X also? |
| 00:01 | _rmk_ | with the kernel booted I see a very similar effect |
| 00:01 | jnettlet | oh interesting |
| 00:01 | _rmk_ | and other weirdness |
| 00:01 | jnettlet | The text looked fine so I figured that was U-boot's decoding routine that was a problem. |
| 00:03 | jnettlet | but that does make some sense since it is supposed to be a 60hz mode and the monitor is reporting 52 |
| 00:04 | _rmk_ | X gets it so my monitor reports 61Hz |
| 00:04 | _rmk_ | but Rabeeh's kernel gets 60Hz |
| 00:05 | jnettlet | interesting |
| 00:06 | _rmk_ | yea, there's soo much here which falls under that heading :( |
| 00:06 | _rmk_ | I've just found some differences in the HDMI phy settings |
| 00:11 | jnettlet | yep just what I was thinking. |
| 00:11 | jnettlet | didn't see where those were set though. |
| 00:13 | jnettlet | nothing in u-boot 2009 that directly relates to hdmi |
| 00:16 | jnettlet | _rmk_, are you using the fb or kms driver? |
| 00:16 | _rmk_ | kms |
| 00:17 | jnettlet | ultimately the phy is a board to board test that needs to pass for hdmi compliance. |
| 00:18 | dv_ | interesting. pengutronix will soon mainline some patches to wrap IPU and VPU as v4l mem2mem devices |
| 00:18 | jnettlet | here is a freescale patch that was done to hdmi to pass compliance for a reference board. https://www.osadl.org/monitoring/patches/r8s7/1679-ENGR00215340-HDMI-PHY-config-adjust-to-pass-electric.patch |
| 00:19 | dv_ | I am temporarily halting my gstreamer-imx work and observing this, since it would replace these plugins |
| 00:19 | _rmk_ | jnettlet: well, the hdmi does seem to be capable of working - I have rabeeh's kernel running with the same image dd'd into /dev/fb0 and its fine there |
| 00:20 | jnettlet | _rmk_, okay then we just need to dupiclate the phy settings. |
| 00:21 | jnettlet | I assume that rabeeh already ran the eye test through the scope and verified the signal being output under his kernel will pass HDMI certification. |
| 00:21 | _rmk_ | I have six registers which are different |
| 00:22 | jnettle | 00:22 * jnettlet is eager with anticipation |
| 00:22 | _rmk_ | 0x801, 0x1008, 0x100c, 0x1019, 0x101a, and 0x101c |
| 00:22 | _rmk_ | (offset from 0x120000) |
| 00:23 | _rmk_ | first byte value is 3.12-rc, second is Rabeeh's |
| 00:23 | _rmk_ | 0x0801 0x40 0x00 |
| 00:23 | _rmk_ | 0x1008 0xdc 0x6e |
| 00:23 | _rmk_ | 0x100c 0x14 => 20 VSYNCINDELAY 0x05 |
| 00:23 | _rmk_ | 0x1019 0x40 => 64 AVICONF0 0x60 |
| 00:23 | _rmk_ | 0x101a 0x19 AVICONF1 0x2a |
| 00:23 | _rmk_ | 0x101c 0x06 AVIVID 0x04 |
| 00:23 | _rmk_ | I'm thinking about also dumping out the ipu settings too |
| 00:24 | _rmk_ | ... if I can work out this ipu thing |
| 00:26 | dv_ | I used the IPU |
| 00:26 | dv_ | it can indeed be confusing |
| 00:27 | dv_ | avoid the ipu-lib . it does not work with the imx6. |
| 00:27 | dv_ | other than that, whats unclear? |
| 00:28 | _rmk_ | if I'm reading this right, it works by executing microcode to control the display of a framebuffer? |
| 00:28 | dv_ | this is not what I saw |
| 00:29 | dv_ | I used the IPU for blitting, colorspace conversion, deinterlacing, 90°-step rotation, and scaling in one step |
| 00:29 | dv_ | well yes, there is some IPU microcode, which is probably for all the stuff I just mentioned |
| 00:30 | _rmk_ | from what I see from the top level architecture diagram, it looks like... |
| 00:30 | _rmk_ | image data is fetched by idmac |
| 00:30 | _rmk_ | that data is eventually passed to the display controller |
| 00:30 | dv_ | (I also used the IPU to display decoded video by blitting to the framebuffer) |
| 00:30 | _rmk_ | the display controller then passes it to a display interface |
| 00:30 | _rmk_ | which then passes it to the HDMI phy |
| 00:31 | jnettle | 00:31 * jnettlet has had too much wine to look at this more tonight :-) I will read the backlog and take a look closer in the morning. |
| 00:31 | jnettlet | ttyl |
| 00:31 | _rmk_ | and the display controller runs on microcode |
| 00:31 | dv_ | ok, the IPU might actually be a larger block, and I touched only a portion of it |
| 00:31 | dv_ | jnettlet: ttyl |
| 00:34 | _rmk_ | jnettlet: sleep well |
| 00:34 | dv_ | right. I have been using some of these blocks (VDI, IRT, IDMAC, DP ...) through a higher level API |
| 00:34 | dv_ | ( linux/ipu.h ) |
| 00:36 | dv_ | its this one: https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_12.09.01_GA/include/linux/ipu.h |
| 00:38 | dv_ | note how you can use the IPU here as a more or less generic memcpy across physical addresses ... :) |
| 00:53 | _rmk_ | yea, I suspect the problem here is you need to have a Freescale IPU Degree(tm) to properly understand this |
| 00:59 | dv_ | as said, pengutronix is wrapping it in a mem2mem device. I am curious as to how much they manage to wrap |
| 00:59 | _rmk_ | well, they're still going to have to have either a fbdev or a drm interface to it for X to use |
| 01:00 | dv_ | yes. or at least something dmabuf based |
| 01:00 | _rmk_ | I don't think anyone will tolerate having another KMS like interface in the kernel |
| 01:01 | dv_ | I guess KMS will be done with the display interface bits of the IPU? |
| 01:01 | _rmk_ | yea, but I've no idea how at the moment |
| 01:01 | dv_ | the 2d blitter bits however are very powerful and useful. I do not see a reason why these cant be mainlined. |
| 01:02 | _rmk_ | it looks like its a case of choosing the right paths and writing the right microcode for the display resolution |
| 01:03 | dv_ | if you want to experiment with the IPU, have a look at the imx-test package |
| 01:03 | dv_ | some of these tests work with the imx6, some dont |
| 01:03 | dv_ | (thats how I managed to figure out how to use it for video) |
| 01:03 | dv_ | link: http://download.ossystems.com.br/bsp/freescale/source/imx-test-3.5.7-1.0.0.tar.gz |
| 01:06 | dv_ | there is also https://github.com/rogeriorps/ipu-examples , but that does not contain much . just some basics. |
| 01:22 | _rmk_ | hmm. |
| 10:21 | dv_ | jnettlet: is it somehow possible to read out a "native" resolution from edid in uboot 2013? |
| 10:21 | dv_ | I would like to try and write a config that picks the native resolution automatically, since currently, I have to explicitely specify it as a kernel parameter |
| 10:27 | wolfy | dv_: I am curious, what distro do you use ? |
| 10:27 | dv_ | wolfy: yocto |
| 10:27 | dv_ | well actually this is more like a framework to build your own distro |
| 11:18 | _rmk_ | whee, Sascha pointed to the problem almost immediately and got it right |
| 11:19 | _rmk_ | wrong clock polarity set in the display interface part of the ipu |
| 11:53 | jnettlet | ah nice. |
| 11:54 | jnettlet | dv_, yep, but we will need to enable i2c for the hdmi port to read the edid info out. |
| 12:06 | _rmk_ | jnettlet: do you set bit 17 in the display interface "general" register in u-boot? |
| 12:06 | jnettlet | _rmk_, just looking at that now. |
| 12:06 | jnettlet | :-) |
| 12:08 | jnettlet | _rmk_, nope. I don't even see that general register defined. will look further. |
| 12:08 | _rmk_ | its address is 0x2640000 for DI0 |
| 12:08 | jnettlet | found it |
| 12:12 | jnettlet | nothing is directly fiddling with it. Trying to see if there is incidental twiddling |
| 12:16 | jnettlet | if (sig.clk_pol) |
| 12:16 | jnettlet | di_gen |= DI_GEN_POL_CLK; |
| 12:16 | jnettle | 12:16 * jnettlet needs to set that sig.clk_pol |
| 12:17 | jnettlet | ah my mode clock generation is wrong. This should fix it. |
| 12:22 | _rmk_ | jnettlet: I need bit 17 cleared |
| 12:23 | _rmk_ | the code in the kernel is different to that... |
| 12:23 | jnettlet | _rmk_, well it shouldn't be set. Let me dump the registers and look. |
| 12:23 | _rmk_ | if (!sig->clk_pol) |
| 12:23 | _rmk_ | di_gen |= DI_GEN_POLARITY_DISP_CLK; |
| 12:25 | _rmk_ | and its all confusing, because: |
| 12:25 | _rmk_ | unsigned clk_pol:1; /* true = rising edge */ |
| 12:25 | _rmk_ | but setting DI_GEN_POLARITY_DISP_CLK is described in the docs as "active high" |
| 12:26 | _rmk | 12:26 * _rmk_ wonders if the data is latched into a transparent latch (in which case level active makes sense) or a d-type latch (in which case edge sensitivity is correct) |
| 12:26 | jnettlet | yep I am seeing the same here in the u-boot code |
| 12:27 | jnettlet | u-boot is setting clk_pol if the FB_SYNC_CLK_LAT_FALL bit is not set |
| 12:27 | jnettlet | So if you want it to be 0 then I need to set that. |
| 12:31 | _rmk_ | I think we need to set that |
| 12:32 | _rmk_ | I'm just sending Sascha another email with the differences between uboot and kernel in, and the different terminology between that and the manual |
| 12:32 | jnettlet | _rmk_, looks good |
| 12:34 | _rmk_ | the twinkling on the d has gone? |
| 12:35 | jnettlet | yep all the twinkling has gone |
| 12:35 | _rmk_ | :) |
| 12:35 | jnettlet | we have slain the hdmi vampires |
| 12:35 | _rmk_ | well, at least that one :) |
| 12:36 | _rmk_ | and it didn't involve garlic |
| 12:36 | jnettlet | still don't know why my console is not getting muxed properly. |
| 12:37 | jnettle | 12:37 * jnettlet guess he should fix dv_'s boot problems while he is mucking around in u-boot |
| 12:37 | jnettlet | dv_, would you like uenv.txt support added as well? |
| 12:38 | jnettlet | _rmk_, reply 1 on this page also brings up the problem. http://boundarydevices.com/configuring-i-mx6-machines-different-screens-nitrogen6x-sabre-lite/ |
| 12:43 | _rmk_ | yea, they want the bit set |
| 12:43 | _rmk_ | I wonder if different display bridges need different clock polarities... which would be quite silly |
| 12:44 | _rmk_ | bit 17 controls the DI output clock polarity, which gets supplied to the three display bridge muxes from what I can see. |
| 12:45 | jnettlet | that is how I understand it. My bet is that is to handle different lvds tfts |
| 12:46 | jnettlet | or maybe an external encoder? |
| 12:46 | _rmk_ | probably - which means it should be in the lvds display bridges :) |
| 12:48 | jnettlet | it looks like a lot of this was written by one or two companies and mostly done without any collaboration |
| 12:49 | _rmk_ | yea, it wouldn't surprise me if the DIs were supposed to be the proper chip-to-external-world outputs, and the display bridges were something which then got integrated onto the SoC later |
| 12:51 | _rmk_ | one thing I notice with the imx6 compared to the cubox is how much faster CPU memory bandwidth seems to be |
| 12:52 | _rmk_ | its quite noticable dragging a window around in X on the imx6 with no acceleration that the CPU seems to be able to cope much better |
| 12:53 | jnettlet | well 2 years of SOC advancement and DDR3 vs DDR2 |
| 12:53 | _rmk_ | yep |
| 12:57 | _rmk_ | well, I guess I should catch up with email... 200+ messages unread since last night |
| 12:58 | jnettlet | good luck with that. |
| 13:37 | dv_ | jnettlet: yes |
| 14:05 | jnettlet | okay console is outputting to hdmi |
| 16:17 | jnettlet | anyone want to give input as to how uboot keyboard/monitor support should work? |
| 16:18 | jnettlet | maybe catch the escape key and break out of the boot sequence? Very old school bios like. |
| 16:21 | Bluerise | backspace? |
| 16:21 | _rmk_ | Well, you could make it say: |
| 16:21 | _rmk_ | BBC Computer 32K |
| 16:21 | _rmk_ | |
| 16:21 | _rmk_ | Acorn DFS |
| 16:21 | _rmk_ | |
| 16:21 | _rmk_ | BASIC |
| 16:21 | _rmk_ | |
| 16:21 | _rmk_ | >_ |
| 16:22 | jnettlet | hmmm usb does not have hotplug support |
| 16:23 | _rmk_ | seriously though, I'd suggest a two-key press to abort boot |
| 16:23 | _rmk_ | shift-something |
| 16:23 | _rmk_ | less chance of accidentally stopping it |
| 16:24 | jnettlet | right now the key presses are really slow to register. I need to figure out if it is my wireless keyboard low on battery or a problem with the usb keyboard driver. I have already found one. |
| 16:27 | MikeSet | 16:27 * MikeSeth reads Yaghmour's Building Embedded Linux Systems |
| 16:27 | MikeSeth | I'm freaking jealous of you folks sitting here screwing around with PCI compliance and nagios all day |
| 16:27 | _rmk_ | heh. that's a book I reviewed for O'Reilly. :) |
| 16:28 | jnettlet | two thumbs up? |
| 16:28 | MikeSeth | the phy limit is 4 ;P |
| 16:29 | MikeSeth | ...I am horrible. |
| 16:46 | ssvb | Why "Tauros2: Disabling L2 prefetch"? Is prefetch really not supported by the hardware? Or is there some sort of errata? |
| 16:47 | ssvb | memcpy speed is just pathetic and it would be nice to find some way to improve it |
| 16:52 | jnettlet | ssvb, it is errata |
| 16:53 | ssvb | oh, what a bummer |
| 16:54 | ssvb | being beaten even by Raspberry Pi on certain workloads is not very nice |
| 16:57 | ssvb | has anyone seen "88SV581x-V7 PJ4 ARM v7 SheevaTM CPU Core Datasheet (Doc No. MV-S105190-01)"? |
| 16:58 | jnettlet | probably. |
| 17:04 | _rmk_ | iirc, the cpu core datasheets tend not to be public |
| 17:06 | jnettlet | ssvb, you can try enabling the L2 prefetch and linefill burst 8 if you like. I am not guaranteeing any sort of stability. |
| 17:07 | jnettlet | usb polling with this keyboard is sucky |
| 17:09 | Turl | ssvb: small world heh :) |
| 19:41 | jnettlet | dv_, okay basic uEnv.txt support and loading from both ext and fat is pushed. If you could test it at some point I would appreciate it. |
| 19:43 | shesselba | jnettlet: can you point me to recent carrier-1 repos? want to have it running at least |
| 19:50 | jnettlet | shesselba, this is my u-boot repo. https://github.com/linux4kix/u-boot |
| 19:51 | jnettlet | is that what you are looking for? |
| 19:51 | shesselba | yes, I was aware that you are working on u-boot |
| 19:51 | shesselba | for kernel, I have _rmk_'s rfc |
| 19:53 | jnettlet | yep that is about where we are at right now. |
| 19:53 | shesselba | great, thanks! |
| 19:53 | jnettlet | I have a kernel repo I am still pulling together. |
| 20:33 | dv_ | jnettlet: ok, when I am home again |
| 20:46 | otavio | jnettlet: How is your u-boot fork? |
| 20:46 | otavio | I'd like to get cubox support into Yocto soon |
| 20:46 | otavio | and I'd like to not duplicate your work |
| 20:46 | otavio | ;-) |
| 20:50 | dv_ | otavio: my meta-fsl-arm-extra fork has carrier one support already |
| 20:50 | dv_ | I will add jnettlet's latest uboot changes as soon as I am home |
| 20:51 | dv_ | u-boot is a separate recipe (u-boot-c1.bb) , because jnettlet's fork is based on a different version than uboot-imx |
| 20:51 | dv_ | the kernel however is just a linux-imx 3.0.35 with rabeeh's patches |
| 20:52 | dv_ | what I didnt do yet is to modify the sdcard image generation. the part where the uImage is copied right after the uboot binary needs to be optional (turned on by default ; for the carrier one, we then explicitely turn it off) |
| 20:56 | dv_ | _rmk_: btw, about your display interface questions: is this useful? https://github.com/Freescale/linux-module-virtfb |
| 21:09 | jnettlet | otavio, my u-boot repo has near complete carrier-1 support. All the basics are there and some more advanced things are coming along like HDMI console and usb support. |
| 21:13 | otavio | jnettlet: can you base this on top of our patches-2013.10 branch? |
| 21:16 | jnettlet | otavio, it should merge. I am just following mainline right now. |
| 21:17 | otavio | jnettlet: in this case, this is trivial |
| 21:17 | otavio | :) |
| 21:20 | dv_ | jnettlet: oh that would be very useful |
| 21:20 | dv_ | then its just a matter of inserting a few lines into the uboot .bbappend file in meta-fsl-arm-extra |
| 21:20 | dv_ | anyway, going home now. ttyl |
| 21:46 | shesselba | jnettlet: does rabeeh's u-boot instructions still apply for your u-boot? I can boot his, but not yours |
| 22:01 | otavio | shesselba: no; drop 'skip=2' |
| 22:01 | otavio | shesselba: from dd command |
| 22:04 | shesselba | otavio: but still u-boot.bin or u-boot.imx? |
| 22:04 | ssvb | jnettlet: enabling l2 prefetch speeds up memcpy quite significantly, but looks like it is some sort of automatic prefetch which only works in the forward direction |
| 22:05 | ssvb | jnettlet: software prefetch using PLD instructions seems to have no effect |
| 22:06 | ssvb | jnettlet: which again brings the question about the PJ4 core datasheet and the errata list |
| 22:07 | shesselba | otavio: it's u-boot.imx, thanks for the hint |
| 22:18 | otavio | :) |