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

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

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