Hi Loic, Am 12.07.2016 um 14:56 schrieb LOIC DEVULDER:
I'm testing openSUSE (and SLES) on ARM64 servers and I ran into an issue with the default DT integrated into the UEFI of my server (this problem is investigated by Matthias Brugger). To workaround my problem, I had to load a custom DT using the 'devicetree' option of grub2. But the main problem is that I didn't find a way to add it properly in the grub.cfg file without hacking the file (which is very bad)!
So, I've made a small patch to add a new option called GRUB_DEVICETREE_FILE in /etc/default/grub file. I also compiled a new grub2 version with this patch and tested it successfully on my servers (https://build.opensuse.org/package/show/home:ldevulde:branches:Base:System/g...).
Cool patch! I ran into the same limitation myself previously and resorted to duplicating a menu entry into custom.cfg. However, for the more frequent use case, a vanilla .dtb file specified via "devicetree" may be lacking firmware-supplied dynamic information. That brings up an unrelated thought: Alex, is there any chance that GRUB2 can cycle back through EFI to U-Boot and influence which fdt gets loaded based on menu selection? What I am thinking of is Raspberry Pi 2 with 4.1.19 vs. 4.6+ .dtb and switching between the two via GRUB being too complicated. I had thought about adding generating a devicetree line for grub.cfg but unlike extlinux GRUB doesn't have a dtbdir command apparently, so it always needs the full filename, not just the dir to search in. Is there an EFI callback when GRUB or Linux accesses the table the first time and do we have access to any efivars or the like to know what it's up to? :) Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org