El vie, 19-10-2018 a las 12:12 +0200, Wolfgang Denk escribió:
Dear Alexander,
In message 118460556.a0Y5euKZZ7@ada you wrote:
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.
Well, what confuses me here is that you cleanly show error messages for example for title, linux, and devicetree, even though these should be recognized as valid keywords.
I think there are sublte imcompatibilities in your config file (and/or bugs in the code). See also this comment (same file):
440 * A note on the pxe file parser. 441 * 442 * We're parsing files that use syslinux grammar, which has a few quirks. 443 * String literals must be recognized based on context - there is no 444 * quoting or escaping support. There's also nothing to explicitly indicate 445 * when a label section completes. We deal with that by ending a label 446 * section whenever we see a line that doesn't include. 447 * 448 * As with the syslinux family, this same file format could be reused in the 449 * future for non pxe purposes. The only action it takes during parsing that 450 * would throw this off is handling of include files. It assumes we're using 451 * pxe, and does a tftp download of a file listed as an include file in the 452 * middle of the parsing operation. That could be handled by refactoring it to 453 * take a 'include file getter' function.
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.
I'm adding Dennis on Cc: who submitted the doc; I hope he has a better understanding of the state of things.
Sorry for the slow response, I have been travelling, currently u-boot does not support the boot loader spec, it was a goal that no-one found the time to solve, the main issue being how to we traverse the directories to parse all the snippets.
Is U-Boot supposed to honour that Boot Loader Specification?
I think it should, if possible.
If yes: then it does not work as specified. Is anybody working on making U- Boot comply?
None that I know of.
There is no one working on it, I should remove the link to BootLoaderSpec
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.
Can we not do it the other way round, and fix the code that it improves and conforms (better) to the spec?
We could, I have not yet found a way to solve the problems. It would be nice to solve them
Dennis
Best regards,
Wolfgang Denk