<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 30, 2024 at 3:15 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <<a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jan,<br>
<br>
On 1/29/24 19:41, <a href="mailto:Jan.Sommer@dlr.de" target="_blank">Jan.Sommer@dlr.de</a> wrote:<br>
> Hi everyone,<br>
> <br>
> As mentioned in the other Rust thread, I am working on an initial Rust port for RTEMS.<br>
> The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.<br>
> Where I am not completely sure, is how to name the new target for Rust (see here the current list:<a href="https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3" rel="noreferrer" target="_blank">https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3</a>).<br>
> The Rust ARM targets usually have the instruction set version and ABI as part of the name, e.g. armv7a-none-eabihf.<br>
> In RTEMS the arm-rtems6-gcc covers all supported ARM versions and different ABIs (i.e. hard-float or soft-float) collectively.<br>
> <br>
> So, for the Zynq and similar BSPs this would yield for the Rust target something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).<br>
> Similarly, for other ARM BSPs additional Rust targets would need to be added. Which might add up to quite a  number of Rust targets over time.<br>
> Is this fine or do you see another solution?<br>
Just to make sure I understand your question correct:<br>
You want to push the RTEMS support you have developed (changes to Rust <br>
libraries, test framework, ability to have a main() in the Rust code for <br>
RTEMS etc.) to the official Rust repository - so that it is available to <br>
everyone through the Rust nightly builds?<br>
<br>
If this is so, then your question would be primarily a question to the <br>
Rust folks because it is their repository which would possibly receive <br>
many different entries for (similar?) RTEMS BSPs?<br>
<br>
As far as I understand this, the steps for an RTEMS developer would be:<br>
<br>
1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.<br>
2) Build RTEMS (kernel) for the right (RTEMS) BSP<br>
3) Install the Rust compiler and its tools<br>
4) Create a Rust project<br>
5) Fine tune some Rust configuration files in that project.<br>
    Here the "armv7a-rtems6-eabihf" or something fitting the BSP would<br>
    be used in a config file. The point is, it must be for the processor<br>
    and BSP which matches the RTEMS tools and BSP selected in steps 1)<br>
    and 2)<br>
6) Make changes to the sample Rust code generated in the project<br>
    or write the Rust code desired.<br>
7) Load the nightly build of the Rust compiler.<br>
    (The nightly is only needed as long as your code has not entered the<br>
    stable build).<br>
8) Compile the Rust program code with the Rust nightly compiler.<br>
9) Link the Rust binary with the RTEMS libraries into a single<br>
    executable (using a linker build by the RTEMS tools).<br>
<br>
Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the <br>
naming convention of the Rust community:<br>
     <a href="https://docs.rust-embedded.org/embedonomicon/custom-target.html" rel="noreferrer" target="_blank">https://docs.rust-embedded.org/embedonomicon/custom-target.html</a><br>
According to this file, the part `eabi` is for bare metal. Would this be <br>
correct when it is based on RTEMS? For example, a Linux target would be <br>
"x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.<br></blockquote><div><br></div><div>This is the more correct target name. We have worked hard for GCC, binutils,</div><div>etc. to not have any BSP specific knowledge. They know about processor </div><div>architectures and processor variations (e.g. core models) within each family.</div><div>GCC may include shortcuts with SoC names as arguments but those just </div><div>map to the proper arguments for the CPU core on the SoC. There is no </div><div>implication of device support of any kind, much less a full BSP.</div><div><br></div><div>Is there no notion of multilib in the Rust tooling? </div></div></div></blockquote><div><br></div><div>I should have also mentioned that the bare metal nature of the *-eabi nature</div><div>as Frank noted has implications. It selects different configurations of support</div><div>libraries which I assume Rust is layered on. The *-rtems* tool target enables</div><div>the multithread safety and RTEMS awareness in various libraries. We may use</div><div>the same object format as the bare metal target but the library build configurations</div><div>are quite different. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
By the way, section "Adding a new target" of<br>
    <a href="https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html" rel="noreferrer" target="_blank">https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html</a><br>
points to an example:<br>
    <a href="https://github.com/rust-lang/rust/pull/94872" rel="noreferrer" target="_blank">https://github.com/rust-lang/rust/pull/94872</a><br>
and that person discussed that triple name here:<br>
<br>
<a href="https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets" rel="noreferrer" target="_blank">https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets</a><br>
<br>
Greetings,<br>
Frank<br>
> <br>
> Cheers,<br>
> <br>
> <br>
>      Jan<br>
> <br>
> Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)<br>
> German Aerospace Center<br>
> Institute for Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany<br>
> <br>
> Jan Sommer<br>
> Telephone +49 531 295-2494 | Telefax 0531 295-2767 |<a href="mailto:jan.sommer@dlr.de" target="_blank">jan.sommer@dlr.de</a><br>
> DLR.de/SC<br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
<br>
-- <br>
embedded brains GmbH & Co. KG<br>
Herr Frank KÜHNDEL<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:frank.kuehndel@embedded-brains.de" target="_blank">frank.kuehndel@embedded-brains.de</a><br>
phone:  +49-89-18 94 741 - 23<br>
mobile: +49-176-15 22 06 - 11<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRA 117265<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
</blockquote></div></div>