Re: [PATCH v4 13/33] bootstd: Add the bootstd uclass and core implementation

Simon Glass
2022-03-12T17:59:22Z

Hi Ilias,

On Sat, 12 Mar 2022 at 07:35, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> +
> > +/* For now, bind the boormethod device if none are found in the devicetree */
> > +int dm_scan_other(bool pre_reloc_only)
> > +{
> > + struct udevice *bootstd;
> > + int ret;
> > +
> > + /* These are not needed before relocation */
> > + if (!(gd->flags & GD_FLG_RELOC))
> > + return 0;
> > +
> > + /* Create a bootstd device if needed */
> > + uclass_find_first_device(UCLASS_BOOTSTD, &bootstd);
> > + if (!bootstd) {
> > + ret = device_bind_driver(gd->dm_root, "bootstd_drv", "bootstd",
> > + &bootstd);
> > + if (ret)
> > + return log_msg_ret("bootstd", ret);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct udevice_id bootstd_ids[] = {
> > + { .compatible = "u-boot,boot-std" },
> > + { }
> > +};
> > +
> > +U_BOOT_DRIVER(bootstd_drv) = {
> > + .id = UCLASS_BOOTSTD,
> > + .name = "bootstd_drv",
> > + .of_to_plat = bootstd_of_to_plat,
> > + .probe = bootstd_probe,
> > + .remove = bootstd_remove,
> > + .of_match = bootstd_ids,
> > + .priv_auto = sizeof(struct bootstd_priv),
> > +};
> > +
> > +UCLASS_DRIVER(bootstd) = {
> > + .id = UCLASS_BOOTSTD,
> > + .name = "bootstd",
> > +#if CONFIG_IS_ENABLED(OF_REAL)
> > + .post_bind = dm_scan_fdt_dev,
> > +#endif
> > +};
> > diff --git a/doc/device-tree-bindings/bootstd.txt b/doc/device-tree-bindings/bootstd.txt
> > new file mode 100644
> > index 0000000000..f048b9dd32
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/bootstd.txt
> > @@ -0,0 +1,28 @@
> > +U-Boot standard boot device (bootstd)
> > +=====================================
> > +
> > +This is the controlling device for U-Boot standard boot, providing a way to
> > +boot operating systems in a way that can be controlled by distros.
>
> A bit more info on how this can be controlled by distros would be helpful.
> What are you expecting from distros here? Most of the current installers
> (at least on x86 and armv8) set the Boot0000 to SHIM and assume the
> efibootmgr will take care of that.

Well then it would use the bootmgr bootmeth, which is included in this
series. Most of the code here is related to moving on from the current
scripts.

> > +
> > +Required properties:
> > +
> > +compatible: "u-boot,boot-std"
>
> This needs to end up on every board controldtb? Or is there another way of
> defining those nodes?

No, this node is optional.

>
> > +
> > +Optional properties:
> > +
> > +filename-prefixes:
> > + List of strings, each a directory to search for bootflow files
> > +
> > +bootdev-order:
> > + List of bootdevs to check for bootflows, each a bootdev label (the media
> > + uclass followed by the numeric sequence number of the media device)
> > +
> > +
> > +Example:
> > +
> > + bootstd {
> > + compatible = "u-boot,boot-std";
> > +
> > + filename-prefixes = "/", "/boot/";
> > + bootdev-order = "mmc2", "mmc1";
> > + };
>
> [...]

Regards,
Simon