| 08:32 | jnettlet[m]> | Ke: so one of the the problems with your configuration is that u-boot needs to find the device-tree to pass into the grub uefi app. u-boot really doesn't know how to handle finding a fdt file in a different device than the EFI partition. |
| 08:34 | jnettlet[m]> | I agree that your configuration is obviously something that needs to be supported. I am trying to decide which is a better solution, a) let u-boot search for more devices for a fdt file b) have u-boot pass its device-tree file over to grub. |
| 09:11 | Ke> | jnettlet[m]: I think the standard way that eg. suihkulokki is after is to just use u-boot dtb all the way and not load it at all, I only load it to get my serial ports working |
| 09:35 | jnettlet[m]> | Ke: that seems ideal and how we traditionally implemented it for the OLPC when we were first launching device-tree. However until u-boot, linux, edk2, barebox all decide to use a common device-tree repository that just isn't going to work. |
| 09:36 | jnettlet[m]> | especially since different kernel revisions may rely on device-tree chanes |
| 09:37 | jnettlet[m]> | changes |
| 10:04 | suihkulokki> | jnettlet[m]: As I'd like to see, the firmware should provide a device tree from itself, and the user the ability to override it |
| 10:06 | suihkulokki> | so assuming the kernel devs have not screwed up backward compatibility (uh), you could start the installer with it, and the installer would then note the dtb is sub-optimal and configure the installed system to use updated dtb from RFS |
| 10:10 | suihkulokki> | It also requires taking a firmer stance that breaking compatibility with old device trees is a regression |
| 10:25 | suihkulokki> | jnettlet[m]: u-boot being proactive and loading device-tree from ESP, and falling back to internal tree would probably give a good real-world experience for most users |
| 11:24 | Ke> | jnettlet[m]: would you like to share a u-boot image just out of curiosity |
| 11:24 | Ke> | jnettlet[m]: at least, if it boots from SD |
| 13:02 | jnettlet[m]> | suihkulokki: yeah, but device-trees are constantly being broken with backward compatibility |
| 13:04 | jnettlet[m]> | there is also the problem that u-boot breaks device-tree standards by putting software and driver settings in device-tree, which are only supposed to contain hardware descriptions |
| 14:20 | KBme> | jnettlet[m], is there any place where the whole procedure is documented to get latest stable kernel with gpu acceleration? |
| 14:21 | KBme> | I'll try to find the vivante drivers but iirc it was impossible to find last time I checked. only in various distribution's repos. |
| 14:34 | jnettlet[m]> | KBme: the easiest way is to use our Debian Stretch image, or our Yocto meta-layer for rocko |
| 14:35 | jnettlet[m]> | doing it by hand is extremely difficult |
| 14:35 | KBme> | well, I will need to either port to libreelec or android, so I think I will start with libreelec |
| 14:36 | KBme> | I'll check the yocto layer though |
| 14:36 | KBme> | jnettlet[m], this https://github.com/SolidRun/meta-solidrun-arm-imx6 ? rocko branch? |
| 14:37 | KBme> | ok got it. great. |
| 14:49 | jnettlet[m]> | KBme: well android is a work in progress. It will most likely be Android IoT for starters, although now with Android Go it is a bit better for low memory devices |
| 14:50 | jnettlet[m]> | libreelec is only supporting mainline drivers now. I would recommend you take a look at Geexbox, they have already ported to the new kernel and are submitting patches |
| 17:50 | KBme> | ok thanks |