Aw: Re: Re: distro_boot vs. env-based bootmenu

[Jonas Karlman]

Hi Frank,
On 2023-06-30 19:51, Frank Wunderlich wrote:
> Hi Jonas
> 
> sorry for the delay. i came back to this and tried your way. Thx for your information...there is no real example in the docs (or i didn't found it) for manual trigger the extlinux-boot, so your information helps a lot.
> 
>> Gesendet: Sonntag, 30. April 2023 um 19:40 Uhr
>> Von: "Jonas Karlman" <jonas at kwiboo.se>
>> An: "Frank Wunderlich" <frank-w at public-files.de>, "Simon Glass" <sjg at chromium.org>
>> Cc: "U-Boot Mailing List" <u-boot at lists.denx.de>, "Heinrich Schuchardt" <heinrich.schuchardt at canonical.com>, "Ilias Apalodimas" <ilias.apalodimas at linaro.org>
>> Betreff: Re: Aw: Re: distro_boot vs. env-based bootmenu
>>
>> Hi Frank,
>>
>> On 2023-04-30 15:25, Frank Wunderlich wrote:
>>> Hi
>>>
>>> I tried to find out why distroboot is enabled (i have not set it in my defconfig) and i think this is why:
>>>
>>>   │ Symbol: DISTRO_DEFAULTS [=y]                                            │  
>>>   │ Type  : bool                                                            │  
>>>   │ Prompt: Select defaults suitable for booting general purpose Linux dist │  
>>>   │   Location:                                                             │  
>>>   │ (3) -> Boot options                                                     │  
>>>   │   Defined at boot/Kconfig:833                                           │  
>>>   │   Selects: BOOT_DEFAULTS [=y] && AUTO_COMPLETE [=y] && CMDLINE_EDITING  │  
>>>   │   Implied by [y]:                                                       │  
>>>   │   - ARCH_ROCKCHIP [=y] && <choice> && !ROCKCHIP_RK3399 [=n]
>>>
>>> as far as i see you've got a response from Jonas about this option and he changed Kconfig file to BOOTSTD_DEFAULTS
>>>
>>> as i have not used BOOTSTD_DEFAULTS before, what needs to be changed to have it working?
>>
>> Please update to latest master branch, rk356x is not fully working
>> with v2023.04 or earlier, especially BOOTSTD without extra CONFIGs.
>>
>> With latest master branch CONFIG_BOOTSTD_DEFAULTS=y should be set by
>> default for all ARCH_ROCKCHIP. And should work very similar to if you
>> used to have "run distro_bootcmd" as your bootcmd.
> 
> As i use builtin-environment there is no distro_bootcmd which i can run.
>  
>> It is still unclear what script/bootcmd you are trying to use, or if
>> you used to have "run distro_bootcmd" as a fallback. Replacing
>> "run distro_bootcmd" with "bootflow scan -lb" or "bootflow scan"
>> could work as such fallback option.
> 
> but with "bootflow scan -lb" it works except 1 thing: old bootchain looked in config directory for the files (kernel+fdt) whereas new way looks in root of partition and now needs additional extlinux prefix.

This could be related to an issue that was fixed in v2023.07-rc5:

  bootstd: Fix relative path use in extlinux bootmeth

See https://source.denx.de/u-boot/u-boot/-/commit/a7e4dffcd8c582bf4344548270d2fc7ac6c0f9ec

If not then please provide more details, in case this is a bug.

> 
> and yes i want distroboot as fallback...
> 
> is there a way to avoid this to hold the file compatible?

The intent is that the new standard boot should be as compatible as
possible as the old script based distro boot, depending on you boot
script.

If you use any of the script part that the old distro boot provided you
will have to adjust your boot script, e.g. replace "run distro_bootcmd"
with "bootflow scan -lb" or "bootflow scan", and modify boot_targets and
bootmeths to control boot order.

See https://u-boot.readthedocs.io/en/latest/develop/bootstd.html#controlling-ordering

> 
> why i use the environment bootmenu? i do a bit more in the menuitems (and before) e.g. loading a uEnv.txt to override some options
> and for testing. have bootargs only defined once, have testkernels with initrd and some special stuff with asking for user input
> (list kernels from mmc/tftp/... and let user choose which kernel/fdt/initrd/...). Such things are imho not possible with extlinux 
> way.

I think there are some limited menu handling with standard boot, it may
depend on a working video driver, something that RK356x does not have.

Regards,
Jonas

> 
> currently only bpi-r2pro uses extlinux boot and the other 3 boards using the builtin environment bootmenu. So to keep all boards nearly same i want to have the same for r2pro but allow users with extlinux still using this.
> 
>>> basicly my Plan is to script the bootup via env in script with a bootmenu (default entry + additional ones which can be 
>>> changed by an env.txt file), but i do not want to break existing setups (using extlinux/*.conf behaviour) and no additional
>>> bootmenu-entries.
>>
>> The "distro" bootmeth described at the documentation you linked to will
>> looks for a file called extlinux/extlinux.conf.
>>
>> Is there a special reason why you need to use a custom bootmenu script
>> and are moving from distro-boot (extlinux-config files)?
>>
>>>
>>> is there any documentation describing the "Standard boot"?
>>>
>>> i found this, but it looks like the "old" distro-boot...or is is same from users PoV?
>>>
>>> https://u-boot.readthedocs.io/en/latest/develop/bootstd.html>>>
>> This is the documentation for standard boot.
>>
>> I recommend you try out the commands bootdev, bootflow and bootmeth with
>> CONFIG_BOOTSTD_FULL=y to get a better handling on how it would work on
>> your device and how you can use them in your script.
>>
>> Regards,
>> Jonas
> 
> regards Frank
>