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

[Wolfgang Denk]

Dear Alexander,

In message <18120382.ptJS9iqsuP at 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.]