Vagrant Cascadian writes: > 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. As far as I know, the opensbi support in visionfive2 was added later, so the opensbi configuration needs to be modified, and later other boards should be able to use the generic version of opensbi. > > 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? The disadvantage of this is that cuirass can't see on-the-fly opensbi, and if the hidden input takes a long time to compile, it will affect the compilation time of the package. So I split opensbi-for-visionfive2 in the v2 patchset. > > Thoughts? > > > That aside, looks good to me. :) > > Thanks! > > live well, > vagrant