Re: [Buildroot] [PATCH v3 1/6] package/binutils-bare-metal: new package

[Luca Ceresoli via buildroot <buildroot@buildroot.org>]

Hi Neal, Peter,

On Sun, 1 Oct 2023 16:11:23 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:

> Hello Peter,
> 
>  >>> Is this ok for both of you?  
>  >>
>  >> I'm OK with the whole approach, except for the sentence "I do not  >> believe there is currently any organized effort to upstream any of  >> these patches"... which is probably already clear to the recipients  >> of this message, and thus is not going to be solved in this thread,  >> however I just want to be sure my position is clear. I'd also like to  >> stress that I appreciate a lot the work you are doing to properly  >> support the pmufw in Buildroot. Thanks!
>  >>
>  >> Luca  
> 
>  > Your position is very clear.  And I can assure you that both Ibai and I agree with it.  
> 
>  > It would be much better if all of these binutils and gcc patches for  > microblaze go upstream, and both Ibai and I have pushed for it  > internally at AMD / Xilinx.  
> 
>  > The only thing I can say is that change is always possible.
>  > Yesterday, we could not build a zynqmp pmufw, versal plm or versal  > psmfw in buildroot.  Today, we have submitted a solution to change  > that.  
> 
>  > Tomorrow (figurative meaning the future), we hope to get all these  > binutils and gcc patches upstream, so the upstream toolchain matches  > the AMD Xilinx distributed toolchain.  
> 
>  > One step at a time.  
> 
> > Sure! Sorry, I am somewhat late to the review game here. I wonder how this fits with Luca's zynqmp-pmufw-builder?  
> 
> From my view, we can continue maintaining Luca's zynqmp-pmufw-builder in parallel.  Buildroot will still offer the option to accept a pre-built pmufw binary without needing to build a microblaze toolchain, so if users prefer to build the pmufw outside of buildroot (to have a faster buildroot build perhaps), this capability will still be available.

As Neal wrote, if/when Buildroot will be able to build a pmufw on its
own (with the proposed approach, or a downloaded toolchain, or
both), zynqmp-pmufw-builder can continue existing even though the use
cases for it will be reduced. I have no plan to stop maintaining it for
the foreseeable future.

> > E.G. today the setup is that the pmufw is built outside Buildroot and we just point the u-boot package to where it can fetch the prebuilt firmware binary - This is nice in the sense that it is fast and simple, but makes is somewhat annoying to make modifications to the firmware.  
> 
> > This series instead goes to the other extreme, E.G. we build the entire microblaze toolchain from scratch and then use it to build the firmware and use it in the u-boot package - This is nice because it is all in Buildroot and we have it all under control, but also brings quite some build time overhead for building the toolchain before building the  
> (small) toolchain. You can naturally "solve" it by using two defconfigs, E.G. one that builds the pmufw and another that uses the prebuilt one, but it isn't very handy either.

I think the approach taken here by Neal and Ibai is valuable,
especially as it would allow Buildroot defconfigs to be self-standing.
Additionally it is already proving useful as it prompted "the
community" (mostly Neal -- thanks about that) to upstream patches
needed to support Microblaze in binutils and gcc, that are currently
downstream.

> > Would an in between option not be more interesting, E.G. use (or  
> download) a prebuilt microblaze toolchain and use that to build the firmware? That would still give the flexibility to easily tweak the firmware, but not the overhead of building the toolchain every time?
> 
> > I guess the problems with that are what to do about the meta-xilinx patches and where/who wants to host a prebuilt one?  
> 
> This is a good point.  As for the meta-xilinx patches, Ibai and I have started going through them and have even started upstreaming a few.  The majority of the meta-xilinx patches are actually for enabling 64-bit microblaze support, which is not available in the upstream gnu binutils or gcc.  Since we do not need 64-bit microblaze for the zynqmp pmufw or the versal plm and psmfw applications, we can easily skip these patches.
> 
> Our current objective is to get all microblaze 32-bit bug fix and feature support patches (such as the barrel shift instructions used by the pmufw) upstreamed.  Since this appears to be a small subset of the overall meta-xilinx patches, we hope to be able to enable the use of the upstream gnu binutils and gcc, so that the meta-xilinx patches will no longer be needed for our use case of building the zynqmp pmufw, versal plm and versal psmfw applications.
> 
> However, in order to achieve what you are asking for, we would still need someone to host a pre-built microblaze compiler somewhere, if we would want to go this route.  At the moment, it is not in the AMD Xilinx plan to host the toolchains somewhere outside of a Petalinux or Vitis download.
> 
> If the upstream toolchain included all the necessary meta-xilinx patches, could bootlin potentially host a pre-built toolchain somewhere?

I fyou are thinking about toolchains.bootlin.com, I am not the
maintainer of those toolchains but I think the idea is to only have
Linux toolchains there, not bare metal ones, thus newlib is not
supported. Also I'm pretty sure downstream feature patches are
absolutely not welcome there.

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot