| 08:59 | topi` | Artox: I don't think UBOOT enables any watchdogs, since I'm not seeing any reset after getting stuck in the "Loading kernel.." part |
| 08:59 | topi` | I need to enable EARLY_PRINTK to see what's going on there |
| 09:05 | jnettlet | you need to build u-boot with the option to enable the watchdog. It is in the config just undef'd |
| 09:05 | topi` | OK |
| 09:06 | topi` | so basicallly it just resets the device if the kernel doesn't take over the watchdog in due time? |
| 09:06 | jnettlet | yeah, kernel or userspace |
| 09:06 | jnettlet | I have the default set at 30 seconds but that is adjustable |
| 10:22 | topi` | I think the imx6 watchdog can do max 125 seconds |
| 11:57 | inch | I compiled libdrm, mesa and kmscube from git for Debian stretch. Kmscube tries to use imx-drm_dri.so and not the etnaviv_dri.so What did I miss? |
| 11:59 | inch | From strace I can see that it reads /sys/dev/char/226:0/device/uevent and finds "DRIVER=etnaviv" there but nobody touches etnaviv_dri.so (checked with inotifywait) |
| 12:00 | inch | s/touches/opens/ |
| 12:01 | inch | Kernel is "4.11.0-rc5-00012-g9eb3ba5 (topi@Geekbox)" |
| 12:09 | inch | Found something: It reads /sys/dev/char/226:1/device/uevent and finds "DRIVER=imx-drm" |
| 12:11 | inch | [ 1.595677] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 |
| 12:21 | inch | trying again with "--with-gallium-drivers=etnaviv,imx" |
| 13:12 | topi` | inch: I think this is the supposed behavior. Should open imx-drm_dri and then mesa internally switches to use etnaviv |
| 13:13 | inch | It's compiled, but kmscubre crashes. |
| 13:13 | inch | etna_resource_from_handle:367: BO stride is too small for RS engine width padding |
| 13:13 | inch | failed to create resource_from_handle: Invalid argument |
| 13:13 | inch | failed to create fb: No such device or address |
| 13:14 | inch | Some other test apps I could try? |
| 13:14 | topi` | kmscube only works when using -D /dev/dri/card1 |
| 13:14 | inch | I used that. |
| 13:15 | topi` | interesting |
| 13:15 | inch | Without it I only get "drmModeGetResources failed: Invalid argument" and "failed to initialize legacy DRM" |
| 13:15 | topi` | I think kmscube is such a stripped down DRM app that if it doesn't work then there's something amiss |
| 13:16 | topi` | yeah, drmModeGetResources won't work |
| 13:16 | topi` | let me look up the compilation options for my mesa libs and stuff |
| 13:16 | inch | hmm. |
| 13:16 | topi` | I had to tweak the configure lines quite a bit when compiling mesa |
| 13:16 | topi` | and bug the folks at #dri-devel to the point of annoyance |
| 13:18 | inch | For some reason etnaviv_dri.so and imx-drm_dri.so are the same file. |
| 13:18 | topi` | that cannot be |
| 13:19 | topi` | oddly enough, this is the case on my system |
| 13:19 | topi` | they are the same file, according to sha1sum |
| 13:21 | topi` | but this doesn't seem to affect... kmscube works and in full framerate |
| 13:24 | topi` | I'll run kmscube under strace to see which .so's it *actually* dlopens |
| 13:27 | topi` | it opens imx-drm_dri.so first. I cannot see any signs of trying to open etnaviv_drm.so |
| 13:27 | topi` | I admit this does not make sense... |
| 13:30 | topi` | you can try to "manually" install the binary libs from my compiled mesa, they should fit straight into a debian/stretch install: |
| 13:30 | topi` | http://212.47.252.246:6666/ |
| 13:30 | inch | Ok, I'll try that. |
| 13:31 | topi` | just unpack it (it goes to /usr/local/lib) and try to make kmscube use those libs (ldconfig -v) |
| 13:31 | topi` | I compiled my kmscube against those libs |
| 13:31 | topi` | when you get at least *something* working, it's easier to make progress then :) |
| 13:42 | inch | Same errors. |
| 13:43 | topi` | OK so it might not be due to the mesa userspace |
| 13:43 | inch | There are drm_kms_helper.edid_firmware=edid/1024x768.bin and drm.debug=0x06 on kernel command line. |
| 13:43 | inch | Can I get them out without usb-keyboard and without a serial cable? |
| 13:43 | topi` | do you get normal drm stuff if you do "dmesg | grep drm" |
| 13:45 | topi` | the drm.debug cmd line certainly won't disturb it |
| 13:46 | inch | https://k2c42.dy.fi/etnaviv/dmesg |
| 13:46 | topi` | drm_kms_helper neither, since they just affect the way the resolution lookup is done |
| 13:46 | topi` | edid/1024x768.bin is a built-in forcing for 1024x768 resoltion |
| 13:46 | topi` | with the VESA modelines I think |
| 13:47 | inch | The project is going to use a 1024x768 monitor but I don't have such a thing here. |
| 13:47 | topi` | then it is a good idea to drop that drm_kms_helper cmdline :) |
| 13:48 | topi` | just edit /boot/uEnv.txt and remove it from there |
| 13:48 | topi` | make sure /boot is mounted, it might be "noauto" in the fstab |
| 13:51 | inch | I got the forced edid out (/proc/cmdline) but still the same errors. |
| 13:51 | topi` | yes probably have no influence on those errors |
| 13:52 | topi` | ./configure --with-egl-platforms='drm' --enable-install-test-programs --enable-etnaviv-experimental-api |
| 13:53 | topi` | I think this is how I configured the mesa build |
| 13:53 | topi` | I'll double-check |
| 13:53 | topi` | nope; unrecognized options :( |
| 13:55 | inch | Output of kmscube: https://k2c42.dy.fi/etnaviv/kmscube.txt |
| 13:55 | topi` | note that you need to get the bleeding edge of mesa and libdrm to be able to use etnaviv |
| 13:56 | topi` | it cannot create a fb? I wonder where a fb is needed... |
| 13:56 | inch | I go them from git://anongit.freedesktop.org/mesa/drm and git://anongit.freedesktop.org/mesa/mesa |
| 13:57 | topi` | that's the place |
| 14:00 | inch | Strace too: https://k2c42.dy.fi/etnaviv/kmscube_strace.txt |
| 14:02 | topi` | I suggest joining #dri-devel and asking robclark, he's the man |
| 14:04 | topi` | robclark suggests there needs to be a HDMI monitor or something connected |
| 14:05 | topi` | so that /dev/fb0 and stuff will work normally, the failing ioctl is DRM_IOCTL_MODE_ADDFB |
| 14:05 | inch | I have some random screen connecte with a hdmi-dvi cable. |
| 14:05 | inch | But not that final 1024x768 sized one. |
| 14:07 | topi` | any screen can work. I have a Samsung office monitor that gives me a 1920x1080 resolution |
| 14:08 | topi` | then kmscube says "Using display 0xabcd1234 with EGL version 1.4" |
| 14:09 | topi` | for me, the DRM_IOCTL_MODE_ADDFB syscall returned no error and it continued eexcuting normally |
| 14:09 | inch | There might be something weird with the monitor. The framebuffer text console looks quite bad. |
| 14:10 | topi` | I think it tries to open /dev/fb0 |
| 14:10 | topi` | can you write to it manually? I mean "dd if=/dev/urandom of=/dev/fb0" |
| 14:11 | inch | Yes, I get the random stuff on the screen. |
| 14:11 | topi` | then that's OK |
| 14:14 | topi` | I think the best way to get something on a display is to force a known edid on it |
| 14:14 | inch | I switched to another monitor and got the cube on the screen. |
| 14:14 | topi` | like edid/1024x768.bin |
| 14:14 | topi` | I've also encountered bad monitors, or they give bad edid responses and then some stuff just won't work |
| 14:15 | topi` | is the cube hw rendered or llvmpipe rendered? |
| 14:15 | topi` | you'll notice the latter, since it will update like 2 fps |
| 14:15 | topi` | dog slow |
| 14:15 | topi` | remember also to lower the debug level of the drm module |
| 14:15 | topi` | echo 5 >/sys/module/drm/parameters/debug |
| 14:16 | topi` | otherwise tons of debug messages from etnaviv, which will also slow the kernel to crawl |
| 14:16 | inch | Seems to be hardware rendered. |
| 14:16 | inch | 3% cpu and 1920x1200 works fine. |
| 14:16 | topi` | then the mesa libs seem to do their work |
| 14:18 | inch | I think the edid forcing kernel command line option doesn't force "enough". I think I still saw a lot of graphics modes listed. |
| 14:19 | topi` | probably it still does the effect of bringing down the screen to the desired resolution |
| 14:19 | topi` | did you try kmscube with the mesa libs you compiled? |
| 14:19 | topi` | I already know "my" libs work ;) |
| 14:19 | inch | I'm trying now. |
| 14:20 | topi` | I wonder if there is any way to "fish out" the parameters used for configure |
| 14:20 | topi` | I hate autotools |
| 14:21 | inch | Mine works too. |
| 14:22 | inch | From bash command history: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-gallium-drivers=etnaviv,imx --with-dri-drivers= --enable-gbm --enable-egl --enable-gles1 --enable-gles2 |
| 14:23 | inch | I compiled in chroot with qemu-arm-static. Cross compiling failed in make install. |
| 14:23 | topi` | that looks good |
| 14:24 | topi` | if you compile under qemu-arm-static, that's not cross compiling, that's native compiling |
| 14:24 | topi` | If there are issues crosscompiling any of the mesa stack for armhf, I think robclark can help on that as well, he's the maintainer of Qualcomm Adreno drivers |
| 14:25 | topi` | he knows everything about ARM |
| 14:29 | inch | The "bad" screen I have is a BK101TH-L400-GH513A |
| 14:31 | topi` | oh, those are always kind of interesting displays :) |
| 14:31 | topi` | there are a million different "industrial" displays from various manufacturers and they mostly work OK with windows PCs :) |
| 14:32 | topi` | another ting I compiled to test the etnavid drm was "mpv" with just the egl-gbm backend |
| 14:33 | topi` | it took a bit of googling to compile the beast, but when I got it compiled, I was able to playback 480p video using CPU decoding and NV12 textures on DRM output |
| 14:34 | topi` | cpu 75% with the Big Buck Bunny test video |
| 14:34 | inch | I'll compile Qt 5.8 see how fast webengine works. |
| 14:34 | topi` | I think this is the best the i.MX6 can do with software decoding... it should also be possible to use CODA in mainline kernel to decode using hardware |
| 14:41 | topi` | how long does it take to compile something as huge as Qt5.8 under emulation (qemu-arm-static) ? |
| 14:41 | topi` | I have a 8-core ARM board for compilation and it still takes a long time |
| 14:42 | inch | It takes a whole day, but this time I'll try to use distcc to do the actual compiling outside the chroot. |
| 14:42 | topi` | :D |
| 14:44 | topi` | I'm getting this for faster compilation: https://www.solid-run.com/marvell-armada-family/armada-8040-community-board/ |
| 14:44 | topi` | probably the fastest ARM cores available for now for a decent price |
| 14:44 | topi` | in the SPEC2000 gcc benchmark, the cortex-a72 easily outperforms things like Intel Atoms clock-by-clock |
| 14:45 | topi` | we'll see |
| 14:51 | topi` | jnettlet: what do I need to change to automatically load /boot/initrd in UBOOT? |
| 14:51 | topi` | it only loaded zImage and the .dtb |
| 14:51 | topi` | with the "regular" mmcboot |
| 14:52 | topi` | initrd is a symlink to my.initrd |
| 14:55 | topi` | Ramdisk image is corrupt or invalid |
| 14:55 | topi` | this is probably the reason :/ |
| 14:55 | topi` | I need to make an uImage out of it |
| 14:57 | jnettlet | you shouldn't have to. Although u-boot may be compiled without initramfs support |
| 15:00 | topi` | uboot doesn't even try to load initrd |
| 15:01 | jnettlet | yeah, so you just need to enable an option in the config |
| 15:01 | topi` | duh, no init found on my initrd image :D |
| 15:01 | topi` | I guess I'm not very good at this |
| 15:02 | topi` | No init found. Try passing init= bootarg. |