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

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

[Alexander Dahl]

Hei hei,

while setting up U-Boot for a new board, I read doc/README.distro and tried to 
follow it for making things smooth with standard distributions. The document 
mentions the so called "Boot Loader Specification" [1] as follows:

> This is roughly
> as specified at:
> 
> http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> 
> ... with the exceptions that the BootLoaderSpec document:

I played with the extlinux.conf format snippets from the U-Boot docs. Upstream 
extlinux docs are not really helpful, especially not for options regarding dtb 
files. And I tried a config based on the Boot Loader Spec:

	Scanning mmc 2:1...
	Found /boot/extlinux/extlinux.conf
	Retrieving file: /boot/extlinux/extlinux.conf
	366 bytes read in 268 ms (1000 Bytes/s)
	Ignoring unknown command: title
	Ignoring unknown command: version
	Ignoring unknown command: options
	Ignoring unknown command: linux
	Ignoring unknown command: devicetree

Am I right, U-Boot does not support that spec at all? Files are in different 
positions, and the keywords are all different? If so, then the U-Boot 
documentation is misleading (and people will be frustrated to follow the hints 
given in there).

Are there any plans to support that specification or is anybody working on 
that? If not, would a patch be okay to reword that part of the documentation?

Greets
Alex

[1] recent version here: https://systemd.io/BOOT_LOADER_SPECIFICATION

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

[Wolfgang Denk]

Dear Alexander,

In message <2092760.TlMJupW03t@ada> you wrote:
> 
> I played with the extlinux.conf format snippets from the U-Boot docs. Upstream 
> extlinux docs are not really helpful, especially not for options regarding dtb 
> files. And I tried a config based on the Boot Loader Spec:
> 
> 	Scanning mmc 2:1...
> 	Found /boot/extlinux/extlinux.conf
> 	Retrieving file: /boot/extlinux/extlinux.conf
> 	366 bytes read in 268 ms (1000 Bytes/s)
> 	Ignoring unknown command: title
> 	Ignoring unknown command: version
> 	Ignoring unknown command: options
> 	Ignoring unknown command: linux
> 	Ignoring unknown command: devicetree
> 
> Am I right, U-Boot does not support that spec at all? Files are in different 
> positions, and the keywords are all different? If so, then the U-Boot 
> documentation is misleading (and people will be frustrated to follow the hints 
> given in there).

It would definitely help if you tell us which actual command
(sequence) you used to get this output, and what the exact content
of this extlinux.conf was.

Without such information, we cannot even guess what you did.

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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

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

[Alexander Dahl]

Hello,

Am Freitag, 19. Oktober 2018, 08:53:15 CEST schrieb Wolfgang Denk:
> In message <2092760.TlMJupW03t@ada> you wrote:
> > I played with the extlinux.conf format snippets from the U-Boot docs.
> > Upstream extlinux docs are not really helpful, especially not for options
> > regarding dtb> 
> > files. And I tried a config based on the Boot Loader Spec:
> > 	Scanning mmc 2:1...
> > 	Found /boot/extlinux/extlinux.conf
> > 	Retrieving file: /boot/extlinux/extlinux.conf
> > 	366 bytes read in 268 ms (1000 Bytes/s)
> > 	Ignoring unknown command: title
> > 	Ignoring unknown command: version
> > 	Ignoring unknown command: options
> > 	Ignoring unknown command: linux
> > 	Ignoring unknown command: devicetree
> > 
> > Am I right, U-Boot does not support that spec at all? Files are in
> > different positions, and the keywords are all different? If so, then the
> > U-Boot documentation is misleading (and people will be frustrated to
> > follow the hints given in there).
> 
> It would definitely help if you tell us which actual command
> (sequence) you used to get this output, and what the exact content
> of this extlinux.conf was.

Okay first the content of /boot/extlinux/extlinux.conf from the root 
filesystem, which does not work (of course without additional linebreaks from 
my mail client):

title          PTXdist
version                4.9.133
options                mtdparts=gpmi-nand:8M(fcb),7M(reserved)ro,512k(env1),
512k(env2),-(fs) ubi.mtd=fs console=ttymxc0,115200 rootwait rw root=/dev/
mmcblk0p1
linux          /boot/zImage
devicetree     /boot/imx6dl-ttcore.dtb

As you might guess, I use ptxdist for building the BSP for an i.MX6 based 
platform. Currently everything is on a SD-Card and the system can boot from 
that card, if I load kernel image and dtb manually in U-Boot (or use another 
extlinux.conf).

> Without such information, we cannot even guess what you did.

I was basically following the instructions from doc/README.distro so I read 
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ as mentioned in 
section "Boot Configuration Files" and set CONFIG_DISTRO_DEFAULTS=y and added 
the following to the board configuration header file in include/configs/

/*  PHYS_ADDR is 0x10000000 for i.MX6S,
 *  Kernel doc recommends to put dtb at 128 MiB, zImage above 32 MiB,
 *  but below 128 MiB. So we put them there and scriptaddr after dtb.
 *  We don't strictly need ramdisk_addr_r, but just set it to some
 *  reasonable value according to doc/README.distro …
 *  This should not collide with U-Boot which places itself at the
 *  lowest 8k and something around 8 MB at the top of the memory, the
 *  board currently has 512 MiB.    */
#define MEM_LAYOUT_ENV_SETTINGS \
        "kernel_addr_r=0x12000000\0" \
        "fdt_addr_r=0x18000000\0" \
        "scriptaddr=0x18100000\0" \
        "pxefile_addr_r=0x18200000\0" \
        "ramdisk_addr_r=0x18300000\0"

#define BOOT_TARGET_DEVICES(func) \
        func(MMC, mmc, 0) \
        func(MMC, mmc, 1) \
        func(MMC, mmc, 2) \
        func(UBIFS, ubifs, 0) \
        func(USB, usb, 0)

#ifndef CONFIG_SPL_BUILD
#include <config_distro_defaults.h>
#include <config_distro_bootcmd.h>
#endif

So in U-Boot env the following is set (this is populated by U-Boot itself by 
default, I removed non interesting lines and added some linebreaks):

boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} $
{prefix}${script}; source ${scriptaddr}

boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any $
{scriptaddr} ${prefix}extlinux/extlinux.conf

boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 mmc1 mmc2 ubifs0 usb0 
bootcmd=run distro_bootcmd
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_mmc2=setenv devnum 2; run mmc_boot
bootcmd_ubifs0=setenv devnum 0; run ubifs_boot
bootcmd_usb0=setenv devnum 0; run usb_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run 
scan_dev_for_boot_part; fi
pxefile_addr_r=0x18200000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; 
for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run 
scan_dev_for_scripts; done;

scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env 
exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do 
if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run 
scan_dev_for_boot; fi; done

scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} $
{prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/
extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi

scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} $
{devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script 
${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; 
done


What happens is what I wrote in the first mail. extlinux.conf is found and 
'sysboot' fails because it ignores all the keywords.

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

So, although the idea to have a config file in the Linux filesystem an let the 
distribution set things in it, might be the same as in the Boot Loader 
Specification, my impression is, U-Boot does not follow the specification. 
Neither does it support multiple files (just /boot/extlinux/extlinux.conf 
works) nor the keywords specified?

An extlinux.conf that works is this:

label   PTXdist
  kernel    /boot/zImage
  fdtdir    /boot
  append    mtdparts=gpmi-nand:8M(fcb),7M(reserved)ro,512k(env1),512k(env2),-
(UBI) ubi.mtd=UBI console=ttymxc0,115200 rootwait rw root=/dev/mmcblk0p1

I have to add, I currently still use U-Boot 2016.09, but I did a thorough 
research in master and the responsible code in cmd/pxe.c did not change from a 
functional point of view since 2016.09.

Greets
Alex

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

[Wolfgang Denk]

Dear Alexander,

In message <18120382.ptJS9iqsuP@ada> you wrote:
>
> Okay first the content of /boot/extlinux/extlinux.conf from the root 
> filesystem, which does not work (of course without additional linebreaks from 
> my mail client):

Thanks.

> 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
:-)

> So in U-Boot env the following is set (this is populated by U-Boot itself by 
> default, I removed non interesting lines and added some linebreaks):
> 
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} $
> {prefix}${script}; source ${scriptaddr}

This would expect a "script", or rather a text blob containing
U-Boot commands.

> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any $
> {scriptaddr} ${prefix}extlinux/extlinux.conf

This would run the "sysboot" command:
	sysboot - command to get and boot from syslinux files",
        sysboot [-p] <interface> <dev[:part]> <ext2|fat|any> [addr] [filename]
            - load and parse syslinux menu file 'filename' from ext2, fat
              or any filesystem on 'dev' on 'interface' to address 'addr'

OK, these are your environment settings...

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

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

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

> I have to add, I currently still use U-Boot 2016.09, but I did a thorough 
> research in master and the responsible code in cmd/pxe.c did not change from a 
> functional point of view since 2016.09.

That does not appear to make a difference in terms of the supported
keywords.

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
Mike's Law: For a lumber company employing two men and a cut-off saw,
the marginal product of labor for any number  of  additional  workers
equals  zero  until the acquisition of another cut-off saw. Let's not
even consider a chainsaw.
- Mike Dennison [You could always  schedule the saw, though - ed.]

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

[Alexander Dahl]

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] U-Boot and The Boot Loader Specification

[Wolfgang Denk]

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

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

[Dennis Gilmore]

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
>