Hello Wolfgang, thanks for your interest in this topic. I think you misunderstood my question, I will elaborate on that. You might skip over the technical details and read my questions in the end of this mail.
Am Freitag, 19. Oktober 2018, 11:10:48 CEST schrieb Wolfgang Denk: > > As you might guess, I use ptxdist for building the BSP for an i.MX6 based > > How could I guess this? It's a pretty exotic proprietary > environment after all. All the world is using OE/Yocto these days Nope, it's not proprietary, it is free software and actively maintained: https://www.ptxdist.org/ Lots of people are also using buildroot from https://buildroot.org/ and build U-Boot with that. So I would not say "all the world", but that's off topic here. ;-) > You still don't explain which exact command you are running that > produces the output? > > f you are running the default bootcmd secuemnce, it would make a lot > of sense to run this sequence manually, step by step, so have an > exact understanding of what is going on. > > It _looks_ to me as if you were running $boot_extlinux in the end, > but it would be nice to be sure... Yes, I'm running the default bootcmd sequence, that find's the extlinux.conf file on the SD card and in the end boot_extlinux is run, I confirmed that. The one and only extlinux.conf file is found, the problem is with parsing. > > What actually works is using an extlinux.conf similar to the examples in > > doc/ README.distro, but there are two things to mention: > > > > 1) keywords are used which are not mentioned in the upstream extlinux > > documentation > > 2) keywords from the bootloader spec don't work at all > > If you have a look at the code (in "cmd/pxe.c"), the following > keywords are implemented: > > 864 /* > 865 * Keywords recognized. > 866 */ > 867 static const struct token keywords[] = { > 868 {"menu", T_MENU}, > 869 {"title", T_TITLE}, > 870 {"timeout", T_TIMEOUT}, > 871 {"default", T_DEFAULT}, > 872 {"prompt", T_PROMPT}, > 873 {"label", T_LABEL}, > 874 {"kernel", T_KERNEL}, > 875 {"linux", T_LINUX}, > 876 {"localboot", T_LOCALBOOT}, > 877 {"append", T_APPEND}, > 878 {"initrd", T_INITRD}, > 879 {"include", T_INCLUDE}, > 880 {"devicetree", T_FDT}, > 881 {"fdt", T_FDT}, > 882 {"devicetreedir", T_FDTDIR}, > 883 {"fdtdir", T_FDTDIR}, > 884 {"ontimeout", T_ONTIMEOUT,}, > 885 {"ipappend", T_IPAPPEND,}, > 886 {NULL, T_INVALID} > 887 }; > > This does not fit with your description, as you list: > > Ignoring unknown command: title > > Ignoring unknown command: version > > Ignoring unknown command: options > > Ignoring unknown command: linux > > Ignoring unknown command: devicetree > > OK, "version" and "options" are not implemented, but the other > keywords are, so you must be doing something else wrong. That's what I was saying. I suppose the handling of label and title is different, so the entry group I had below 'title' was not recognized as group of options for one entry, like it was when replacing title with label. I can write an actually working extlinux.conf file (as showed in my last mail), but that was not the question I had in the first place. > > Neither does it support multiple files (just /boot/extlinux/extlinux.conf > > works) nor the keywords specified? > > You can run the sysboot command as often with different data as you > like, so what o you mean? The U-Boot documentation in the file 'doc/README.distro' could lead to the impression as if U-Boot would support the BootLoaderSpec and even links to it: http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ That spec says basically, in my own words: "put one conf file for each boot menu item in the directory /boot/loader/entries and let it have the following format." The keywords differ from the ones used by extlinux/U-Boot, in my opinion the U-Boot documentation in 'doc/README.distro' however is not very clear about that. Back to my original question: Is U-Boot supposed to honour that Boot Loader Specification? If yes: then it does not work as specified. Is anybody working on making U- Boot comply? If no: would anybody mind changing the documentation to better reflect what U- Boot actually does and not mislead people into thinking U-Boot would be compliant to that specification (like it was the case for me)? I would send a patch if nobody objects. Greets Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
