| 08:38 | inch | Would it be difficult to get the galcore driver to work with the new kernels or would I just need to recompile and leave something out to make it work? |
| 08:44 | jnettlet | inch, that is not an easy question. The galcore driver really isn't meant to be used with the imx-drm scan out drivers. It doesn't understand things like dmabuf handles etc. |
| 08:44 | jnettlet | I do know that some users have used our 3.14.79 kernels on stretch. |
| 08:47 | inch | Ok, I'll try the etnaviv stuff first. |
| 08:59 | jnettlet | let me know if you have any questions |
| 08:59 | inch | A link to a howto would be nice. |
| 09:00 | inch | I think I'll start by installing an armhf stretch with debootstrap and using this as a sysroot when cross compiling and/or compiling in chroot with qemu-arm-static. |
| 09:01 | jnettlet | inch, if he isn't too busy then topi` may be able to help some. He just did this process. |
| 09:02 | jnettlet | I also have a patchset for 4.9 lts that adds additional support for our boards to upstream. |
| 09:10 | inch | It seems the thing I'm trying to do, can be done: https://boundarydevices.com/pengutronix-etnaviv-demo-nitrogen6x/ |
| 09:14 | jnettlet | you just want to play back video? |
| 09:14 | inch | hw accelerated Qt5 |
| 09:15 | inch | I was asked to make it work in stretch |
| 09:16 | jnettlet | yes I would just like to note that only the video element is accelerated in that demo |
| 10:10 | topi` | inch: I compiled "mpv" against DRM-GBM backend and it is able to play back 480p video software decoded |
| 10:10 | topi` | because the rendering is done in YUV textures to a GLES2 surface. It frees up the cpu to do the actual sw decoding (h264) |
| 10:11 | topi` | I compiled libdrm and mesa from the Git HEADs and installed those to /usr/local/lib |
| 10:13 | topi` | inch: the pengutronix-etnaviv-demo was done by lynxeye, and he frequents on #dri-devel |
| 10:14 | inch | I'm trying to get Qt5 webengine to work fast enough. I guess if I get it to draw to GBM, it's fast enough. |
| 10:14 | topi` | some time ago we tested importing video from a gstreamer pipeline using the VPU into a QT5 video surface |
| 10:15 | topi` | this way QT will do the YUV->RGB conversion in a shader |
| 10:15 | topi` | worked fine AFAIR |
| 10:16 | topi` | it's possible that even though Qt5 draws to GBM, it still can be sloooow if it falls back to softpipe-llvm |
| 10:16 | topi` | I lacked the insight on how to force Qt5's drm-gbm code to force to open /dev/dri/card1 instead of card0 to get hw acceleration |
| 10:17 | inch | Yes, that happens with the default Qt5 in stretch. |
| 10:17 | topi` | the biggest drawback in HB is that the RAM is a bit slow |
| 10:17 | inch | How aobut renaming card1 to card0? |
| 10:17 | topi` | I did not try that. |
| 10:17 | topi` | I verified this by compiling "kmscube" and running it first with -D /dev/dri/card0 and then -D /dev/dri/card1 |
| 10:18 | topi` | and the former was very slow, the latter ran in 30fps |
| 10:28 | topi` | I suspect renaming "card1" to "card0" won't work, because card0 is needed as well (lynxeye said the mesa library is doing some magic tricks under the hood to open surfaces using card0, but rendering to them via card1) |
| 10:59 | inch | I'm no expert at this, but perhaps the card numbers should be swapped in both kernel and mesa so that normal applications could just use card0 as usual. |
| 11:03 | dv_ | on imx6, card1 is usually etnaviv |
| 11:03 | dv_ | card0 is the hdmi out |
| 11:04 | dv_ | topi`: I wrote a tool called eglinfo a long time ago... https://github.com/dv1/eglinfo |
| 11:04 | dv_ | it would be good to give it a GBM platform implementation |
| 11:04 | dv_ | it's on my todo list.. |
| 11:10 | dv_ | topi`: if you want, you can try to write GBM support... should not be difficult. essentially a "platform_gbm_generic.cpp" source. |
| 11:15 | topi` | dv_: do you know if the VPU can used for h264 decode under 4.9 kernel?= |
| 11:16 | topi` | yeah I looked at how kmscube.c handles GBM, it seems quite simple affair |
| 11:17 | dv_ | yes |
| 11:17 | dv_ | using coda and v4l |
| 11:17 | dv_ | I tried it, it works fine |
| 12:12 | topi` | so v4l knows how to use the VPU? |
| 12:14 | topi` | I guess I need to enable coda in the kernel |
| 12:14 | topi` | there is VIDEO_CODA and IMX_HAVE_PLATFORM_IMX27_CODA |
| 14:54 | topi` | is mmcblk2boot0/1 meant to only store SPL, or perhaps spl+uboot? |
| 15:10 | rabeeh | topi`: i'm not sure if imx6 can use boot0/1 partitions |
| 15:10 | rabeeh | but typically those are pSLC quality partitions that are used to boot machines |
| 15:11 | rabeeh | Armada 38x for instance uses it |
| 15:13 | vpeter | rabeeh: I have one imx6 system with eMMC and I put u-boot.imx in /dev/mmcblk0boot0 @1kB offset. |
| 15:14 | rabeeh | it does boot? |
| 15:14 | vpeter | Obviously :) |
| 15:14 | rabeeh | ") |
| 15:14 | rabeeh | :) |
| 15:14 | rabeeh | good to know |
| 15:14 | vpeter | I wouldn't mention if it doesn't :-) |
| 15:14 | rabeeh | lol |
| 15:16 | topi` | vpeter: and you have a zeroed-out first 1MB of the mmcblk0? |
| 15:17 | topi` | how does it work out? it first tries boot0, and then boot1? |
| 15:18 | topi` | rabeeh: doesn't Freescale have any better documentation for the boot process? |
| 15:18 | vpeter | I don't delete anything. And I didn't check about boot1. |
| 15:18 | topi` | when I worked with OMAP3, TI provided pretty solid docs about the whole boot process and everything |
| 15:18 | topi` | vpeter: I meant that do you still have spl.bin on mmcblk0 offset 2k? |
| 15:19 | vpeter | I don't use SPL there - it is whole u-boot.imx at 1 kB offset. |
| 15:20 | topi` | rabeeh: do you have any handy procedure for "reviving" dead emmc boards? We fused the boards to boot from emmc, but something is botched, since nothing to serial console and lsusb doesn't find the Freescale device (usb-otg) |
| 15:20 | rabeeh | which setup are you using? |
| 15:20 | rabeeh | i.e. MicroSOM version? (1.3/1.5) |
| 15:20 | topi` | HB Gates with the v1.5 som |
| 15:21 | rabeeh | with the R48 - right? |
| 15:21 | topi` | yes, the emmc cannot be written otherwise :) |
| 15:21 | rabeeh | well... you see where this is going; right? |
| 15:21 | topi` | my script also verifies the checksuns by reading back from emmc |
| 15:21 | topi` | vpeter: where did you get the uboot.imx? |
| 15:22 | rabeeh | tip: remove R48 :) |
| 15:22 | topi` | I only extracted the spl.bin and uboot.bin from the repo.solid-run.xyz jessie package |
| 15:22 | topi` | rabeeh: what about shorting a reset on the top side of the SOM? |
| 15:22 | vpeter | topi`: I build it from source. |
| 15:22 | topi` | under the heatsink |
| 15:23 | rabeeh | topi`: that's the other option; i haven't tried it personally; but jnettlet did before and he said it didn't work |
| 15:23 | rabeeh | want to try? |
| 15:23 | topi` | vpeter: OK, was this the version rabeeh patched for emmc booting? |
| 15:23 | vpeter | topi`: Now I see I was not clear - this system I have is not from solidrun. |
| 15:24 | jnettlet | you need to enable mmc reset which defaults to off. |
| 15:24 | topi` | vpeter: but it proves that an i.mx6 can boot off of the special boot partition |
| 15:24 | vpeter | I only mention this to confirm booting from boot0 partition works. |
| 15:24 | vpeter | Exactly. |
| 15:24 | topi` | jnettlet: where do you enable this mmc reset? |
| 15:25 | jnettlet | topi`, I use cjb's mmc-utils it is in his kernel repo |
| 15:25 | rabeeh | jnettlet: so this makes sense now |
| 15:26 | topi` | I find it somewhat odd that i.mx6 is trying to boot from our "broken" spl, but if it were truly broken, that would trigger the Watchdog timeout |
| 15:27 | topi` | if SPL would work correctly, it would say: |
| 15:27 | topi` | "U-Boot SPL 2013.10-rc4 (Oct 14 2015 - 13:55:24) |
| 15:27 | topi` | " |
| 15:27 | jnettlet | topi`, it can't boot from that. the offset is wrong |
| 15:27 | vpeter | topi`: And I also need to enable boot partition (all steps here https://pastebin.com/89291BPL) |
| 15:27 | topi` | ok, so from BootROM's perspective, there are some random bytes at the offset it is trying. Why doesn't the Watchdog timeout? |
| 15:28 | jnettlet | it appears the hwreset enable is a one time programmable option, you can enable it or disable it. |
| 15:28 | topi` | vpeter: that looks easy enough |
| 15:28 | jnettlet | this would be a production option |
| 15:28 | jnettlet | obviously you want it enabled for development and unlocked production, and disabled for secure deployments |
| 15:29 | topi` | jnettlet: so, in production, one would want to disable hwresets |
| 15:29 | topi` | yep |
| 15:30 | jnettlet | although I have completely destroyed the hardware partitions with this tool, so be careful. That is why I am waiting to hear back from cjb. |
| 15:31 | topi` | maybe you also permanently disabled the HW reset on the emmc? |
| 15:34 | topi` | rabeeh: my recommendation would be to provide some kind of scripting support for customers who are going to use the emmc for booting. I understand the devices are not bricked totally, because you can still desolder the R48, but this is painful |
| 15:34 | topi` | I understand that Solid-run has also other products to worry about, but the HB is a long-term product, so as a customer I'd expect to get specific instructions on how to deploy eMMC bootable boards |
| 15:51 | rabeeh | topi`: ok |
| 15:52 | rabeeh | to be honest we have too many questions about eMMC boot; fuses etc... |
| 15:52 | topi` | rabeeh: it seems this is all my fault. I've placed the SPL at offset 2k |
| 15:52 | topi` | whereas it should go to 1k |
| 15:52 | rabeeh | which means too many issues that we don't want customers to get stuck with |
| 15:53 | rabeeh | topi`: any suggestion how to do it? i.e. a manual that says 1,2,3 etc...? |
| 15:53 | topi` | I think i'll try out the "emmc reset" tric |
| 15:54 | topi` | rabeeh: one possibility is to provide a script, that makes a board bootable (just by flashing the spl+uboot) |
| 15:54 | topi` | the customer can the provide the partitioning and boot a zImage whatever way |
| 15:54 | topi` | from a USB stick, through tftp,... |
| 15:55 | topi` | after the UBOOT is safely on the eMMC, everything is then possible |
| 16:01 | vpeter | Step by step instructions are always nice :) |
| 16:08 | topi` | there are instructions on the wiki |
| 16:08 | topi` | but there's still confusion about which bits to place where. Where do I get the correct "spl" for emmc booting, etc... |
| 16:11 | topi` | well, looks like everyone has had their fair share of eMMC boot issues... the Sitara users have problems, so do the sunxi users... |
| 16:35 | topi` | vpeter: can you give some dump of the properties of your eMMC device (that has the spl in boot0)? I'd like to compare it to my emmc |
| 16:36 | topi` | if there are no significant differences, then I'd assume the i.mx6 would try to boot from the bootpart like it does on your device |
| 17:05 | vpeter | topi`: Gave me commands. |
| 17:06 | vpeter | But I should mention that everything was fused in factory. |
| 17:09 | vpeter | There is also one dip switch where boot select is done. Like from emmc, microsd, sd, otg. BUt I newer tested this. |
| 17:37 | Artox | topi`_: you were approaching debian sid? |
| 17:37 | Artox | I have just succesfully added stretch and sid on the obs |
| 17:38 | Artox | but at this point it won't be an imx6 priority on my side |