[bug#70892] [PATCH 4/6] gnu: Add u-boot-starfive-visionfive2.

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]

On 2024-05-12, Zheng Junjie wrote:
> diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
> index cfe8046731..1d52e961fd 100644
> --- a/gnu/packages/bootloaders.scm
> +++ b/gnu/packages/bootloaders.scm
...
> @@ -1343,6 +1344,36 @@ (define-public u-boot-sifive-unmatched
>         (modify-inputs (package-inputs base)
>           (append opensbi-generic))))))
>  
> +(define-public u-boot-starfive-visionfive2
> +  (let ((opensbi (package
> +                   (inherit opensbi-generic)
> +                   (arguments
> +                    (substitute-keyword-arguments
> +                        (package-arguments opensbi-generic)
> +                      ((#:make-flags flags)
> +                       `(cons* "FW_TEXT_START=0x40000000"
> +                               "FW_OPTIONS=0"
> +                               ,flags))))))
> +        (base (make-u-boot-package "starfive_visionfive2" "riscv64-linux-gnu")))

I would not want to block this patch on this, but...

Curious about the advantages and disadvantages of making this an
on-the-fly opensbi package variant... as so far I think most u-boot
packages just pull in inputs of other packages
(e.g. arm-trusted-firmware-*) rather than modifying them as part of the
u-boot-* package.

If this seems to be a good approach overall, maybe we should switch more
packages to use this approach ... or if there are significant downsides,
perhaps this patch series should just create another opensbi variant and
add it to inputs or whatever?

Thoughts?


That aside, looks good to me. :)

Thanks!

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]