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

[Frager, Neal]

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.

> 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.

> 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?

Even if we add the option to use a pre-built microblaze toolchain, I would still like to include the option we have developed in buildroot to build and control everything within buildroot itself.  It is true that the build time is longer, but many users like the option of building the toolchains they use and would be willing to pay the build time price to have this option.  From my view, adding a pre-built toolchain option should not be "instead of" offering the option to build a toolchain, but should instead be an option in "addition to" building a toolchain.  Basically, following the same concept as using the buildroot internal toolchain or supplying an external one for the main Linux toolchain.

What are your thoughts?

Best regards,
Neal Frager
AMD