[Buildroot] toolchain-bare-metal-buildroot

[Buildroot] toolchain-bare-metal-buildroot

[Frager, Neal via buildroot]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Thomas, Arnout,

I am continuing the work on the toolchain-bare-metal-buildroot, and I have
encountered a snag where I am hoping you can come up with a brilliant idea
to resolve.

In addition to needing multiple bare-metal toolchains, the versal gen2 products
need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
configuration.  Just using the riscv32 tuple is not sufficient.

Since the architecture tuples come as a list, do you have any ideas for
how we can handle architectures that have many options beyond just the
tuple, such as ARM and RISC-V?  Any additional variables we make will
also need to be a list.

Do you have any ideas for a clean way to handle this?  Perhaps arch
specific configs that we can apply in the config loop should the tuple
match the corresponding option?

Thanks for any ideas!

Best regards,
Neal Frager
AMD

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] toolchain-bare-metal-buildroot

[Thomas Petazzoni via buildroot]

Hello,

On Thu, 27 Feb 2025 12:58:34 +0000
"Frager, Neal" <neal.frager@amd.com> wrote:

> I am continuing the work on the toolchain-bare-metal-buildroot, and I have
> encountered a snag where I am hoping you can come up with a brilliant idea
> to resolve.
> 
> In addition to needing multiple bare-metal toolchains, the versal gen2 products
> need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
> configuration.  Just using the riscv32 tuple is not sufficient.
> 
> Since the architecture tuples come as a list, do you have any ideas for
> how we can handle architectures that have many options beyond just the
> tuple, such as ARM and RISC-V?  Any additional variables we make will
> also need to be a list.
> 
> Do you have any ideas for a clean way to handle this?  Perhaps arch
> specific configs that we can apply in the config loop should the tuple
> match the corresponding option?

I really don't have a good suggestion here unfortunately. This is
another area where a kconfig-based configuration system is showing its
limits IMO.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] toolchain-bare-metal-buildroot

[Arnout Vandecappelle via buildroot]

  Hi Neal,

On 27/02/2025 13:58, Frager, Neal wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]

  You know that buildroot@buildroot.org is in Cc, right? :-)


> Hi Thomas, Arnout,
> 
> I am continuing the work on the toolchain-bare-metal-buildroot, and I have
> encountered a snag where I am hoping you can come up with a brilliant idea
> to resolve.
> 
> In addition to needing multiple bare-metal toolchains, the versal gen2 products
> need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
> configuration.  Just using the riscv32 tuple is not sufficient.
> 
> Since the architecture tuples come as a list, do you have any ideas for
> how we can handle architectures that have many options beyond just the
> tuple, such as ARM and RISC-V?  Any additional variables we make will
> also need to be a list.

  When all else fails, we can resort to hacks :-)

  The target tuple components can only contain letters, digits and underscore, 
en they are separated with dashes. That leaves us with a lot of characters that 
we can use to add something extra that can be stripped off and treated 
differently. For example, OpenEmbedded uses ; in URLs to give additional 
information (like the download method or the hash). And URLs themselves have ? 
and & to add GET data. So we can use one of these to have additional data, like

riscv32-buildroot-none-elf?with-arch=rv32imc&enable-initfini-array

(not convincend if ?& or ; or something else is better; also I'm not sure if 
it's better to include the -- or not).

  It is obviously super ugly, but I can't think of anything better.

  Regards,
  Arnout


> Do you have any ideas for a clean way to handle this?  Perhaps arch
> specific configs that we can apply in the config loop should the tuple
> match the corresponding option?
> 
> Thanks for any ideas!
> 
> Best regards,
> Neal Frager
> AMD
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] toolchain-bare-metal-buildroot

[Frager, Neal via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 2531 bytes --]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Arnout,


> [AMD Official Use Only - AMD Internal Distribution Only]

>  You know that buildroot@buildroot.org is in Cc, right? :-)

Yes, I included the community on purpose.
Nothing in my email is "internal only".

Since my original email was not sent from git,
AMD IT added this lovely footnote...

> Hi Thomas, Arnout,
>
> I am continuing the work on the toolchain-bare-metal-buildroot, and I have
> encountered a snag where I am hoping you can come up with a brilliant idea
> to resolve.
>
> In addition to needing multiple bare-metal toolchains, the versal gen2 products
> need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
> configuration.  Just using the riscv32 tuple is not sufficient.
>
> Since the architecture tuples come as a list, do you have any ideas for
> how we can handle architectures that have many options beyond just the
> tuple, such as ARM and RISC-V?  Any additional variables we make will
> also need to be a list.

>  When all else fails, we can resort to hacks :-)

  > The target tuple components can only contain letters, digits and underscore,
> en they are separated with dashes. That leaves us with a lot of characters that
> we can use to add something extra that can be stripped off and treated
> differently. For example, OpenEmbedded uses ; in URLs to give additional
> information (like the download method or the hash). And URLs themselves have ?
> and & to add GET data. So we can use one of these to have additional data, like

> riscv32-buildroot-none-elf?with-arch=rv32imc&enable-initfini-array

> (not convincend if ?& or ; or something else is better; also I'm not sure if
> it's better to include the -- or not).

>  It is obviously super ugly, but I can't think of anything better.

Thank you for this idea!

At the moment, I will keep this as a backup "if all else fails"
solution.  I am still working internally to see if we can
update the asufw application such that a standard
riscv32-buildroot-elf toolchain can do the job.

I hope to do it this way, so we can keep as many ugly
hacks out of Buildroot as we can...

Thanks again for your help!

Best regards,
Neal Frager
AMD


> Do you have any ideas for a clean way to handle this?  Perhaps arch
> specific configs that we can apply in the config loop should the tuple
> match the corresponding option?
>
> Thanks for any ideas!
>
> Best regards,
> Neal Frager
> AMD
>


[-- Attachment #1.2: Type: text/html, Size: 4759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] toolchain-bare-metal-buildroot

[Frager, Neal via buildroot]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Arnout, Thomas,

> [AMD Official Use Only - AMD Internal Distribution Only]

>  You know that buildroot@buildroot.org is in Cc, right? :-)


> Hi Thomas, Arnout,
>
> I am continuing the work on the toolchain-bare-metal-buildroot, and I have
> encountered a snag where I am hoping you can come up with a brilliant idea
> to resolve.
>
> In addition to needing multiple bare-metal toolchains, the versal gen2 products
> need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
> configuration.  Just using the riscv32 tuple is not sufficient.
>
> Since the architecture tuples come as a list, do you have any ideas for
> how we can handle architectures that have many options beyond just the
> tuple, such as ARM and RISC-V?  Any additional variables we make will
> also need to be a list.

>  When all else fails, we can resort to hacks :-)

>  The target tuple components can only contain letters, digits and underscore,
> en they are separated with dashes. That leaves us with a lot of characters that
> we can use to add something extra that can be stripped off and treated
> differently. For example, OpenEmbedded uses ; in URLs to give additional
> information (like the download method or the hash). And URLs themselves have ?
> and & to add GET data. So we can use one of these to have additional data, like

> riscv32-buildroot-none-elf?with-arch=rv32imc&enable-initfini-array

> (not convincend if ?& or ; or something else is better; also I'm not sure if
> it's better to include the -- or not).

>  It is obviously super ugly, but I can't think of anything better.

I wanted to come back to this topic, as I identified a simple solution to the
riscv32 bare-metal toolchain problem which only comes with the negative of
significantly longer build time.

If we --enable-multilib, then gcc and newlib will build all the riscv32
library variants.  While this takes longer to build, it would be much
simpler to implement as it is an easy switch from --disable-multilib to
--enable-multilib.  I have confirmed that I am able to build the
versal_2ve_2vm asufw application by enabling multilib and changing nothing
else.

Since the AMD toolchain is already a multilib toolchain (since we support
soft cores which could be virtually any riscv variant), the asufw already
has a Makefile designed for a multilib toolchain as you can see below.

https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/asufw/src/Makefile

What do you think of adding a config option to the bare-metal toolchain that
enables multilib?  It would be simple for me to implement this, and then users
could choose whether enabling multilib is worth paying for with extended build
time.

Similar to BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH, my idea is the option
would be BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_MULTILIB which would be a boolean
used by binutils-bare-metal, gcc-bare-metal and newlib-bare-metal.

What do you think?

Best regards,
Neal Frager
AMD
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] toolchain-bare-metal-buildroot

[Frager, Neal via buildroot]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Arnout, Thomas,

I am re-sending this email with Arnout's new email address.

> Hi Thomas, Arnout,
>
> I am continuing the work on the toolchain-bare-metal-buildroot, and I have
> encountered a snag where I am hoping you can come up with a brilliant idea
> to resolve.
>
> In addition to needing multiple bare-metal toolchains, the versal gen2 products
> need the riscv32 toolchain to have "--with-arch=rv32imc" included in the
> configuration.  Just using the riscv32 tuple is not sufficient.
>
> Since the architecture tuples come as a list, do you have any ideas for
> how we can handle architectures that have many options beyond just the
> tuple, such as ARM and RISC-V?  Any additional variables we make will
> also need to be a list.

>  When all else fails, we can resort to hacks :-)

>  The target tuple components can only contain letters, digits and underscore,
> en they are separated with dashes. That leaves us with a lot of characters that
> we can use to add something extra that can be stripped off and treated
> differently. For example, OpenEmbedded uses ; in URLs to give additional
> information (like the download method or the hash). And URLs themselves have ?
> and & to add GET data. So we can use one of these to have additional data, like

> riscv32-buildroot-none-elf?with-arch=rv32imc&enable-initfini-array

> (not convincend if ?& or ; or something else is better; also I'm not sure if
> it's better to include the -- or not).

>  It is obviously super ugly, but I can't think of anything better.

I wanted to come back to this topic, as I identified a simple solution to the
riscv32 bare-metal toolchain problem which only comes with the negative of
significantly longer build time.

If we --enable-multilib, then gcc and newlib will build all the riscv32
library variants.  While this takes longer to build, it would be much
simpler to implement as it is an easy switch from --disable-multilib to
--enable-multilib.  I have confirmed that I am able to build the
versal_2ve_2vm asufw application by enabling multilib and changing nothing
else.

Since the AMD toolchain is already a multilib toolchain (since we support
soft cores which could be virtually any riscv variant), the asufw already
has a Makefile designed for a multilib toolchain as you can see below.

https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_apps/asufw/src/Makefile

What do you think of adding a config option to the bare-metal toolchain that
enables multilib?  It would be simple for me to implement this, and then users
could choose whether enabling multilib is worth paying for with extended build
time.

Similar to BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_ARCH, my idea is the option
would be BR2_TOOLCHAIN_BARE_METAL_BUILDROOT_MULTILIB which would be a boolean
used by binutils-bare-metal, gcc-bare-metal and newlib-bare-metal.

What do you think?

Best regards,
Neal Frager
AMD
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot