[U-Boot] U-Boot and The Boot Loader Specification

[Wolfgang Denk <wd@denx.de>]

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.

> 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.

> 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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ein weiser Herrscher kann in einem großen Land  mehr  Gutes  bewirken
als  in  einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
fug. Da weise Herrscher seltener sind als dumme, war ich schon  immer
gegen große Reiche skeptisch.                   - Herbert Rosendorfer