Maintainers for embedded targets about wg HOT 32 CLOSED

I haven't spoken to the @rust-embedded/riscv team yet but if they're interested in the riscv32i-unknown-none-elf, riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, riscv64imac-unknown-none-elf, or riscv32im-unknown-none-elf targets I'm happy to add them to the same PR (or they can make their own). Similarly if there are any other targets people in the WG think we could support.

I'm happy to help with riscv32imac as that's what I have, I cannot do practical things with the others I'm afraid.

from wg.

Apparently Tier 3 targets need a maintainer too. I'm fine w/ either the msp430 team or myself being a maintainer (cc: @YuhanLiin, would you be open to maintaining it too?). I already kinda maintain it, anyway.

from wg.

This target supports interlinking with C code compiled using the TI MSP430 GCC compiler.

Yes this is correct, but I would put a caveat that cross-language LTO w/ the GCC compiler almost certainly doesn't work (b/c LLVM vs GCC's IR). I would also put a note that nightly is required for the forseeable future until at least rust-lang/rfcs#3246 and by extension rust-lang/rust#38487 are resolved. Because we're stuck on nightly, I have not felt an impetus to get rid of the build-std=core invocation (and honestly, I kinda hope at some point build-std is just stabilized and we don't need to provide libcore).

from wg.

Yeah but that's just a method in cortex-m to poke CP15, right? And if you want to use an RTOS that doesn't use HF (because stacking those registers is expensive) you will want this.

from wg.

@romancardenas, @almindor, would you mind checking the proposed rv32 file? In particular

• I've combined i, imc, and imac into one file, as they're all tier 2 targets with no existing details
• I've left im alone because it's somehow tier 3 and does have a nominal maintainer, though it might make more sense to see if we can have it promoted to tier 2 and then its platform file merged with this one
• The "building rust programs" and "cross-compilation toolchains and C code" sections are missing, any ideas here? The template has a little guidance of what to put in each section.

from wg.

@romancardenas, @almindor, would you mind checking the proposed rv32 file? In particular

• I've combined i, imc, and imac into one file, as they're all tier 2 targets with no existing details
• I've left im alone because it's somehow tier 3 and does have a nominal maintainer, though it might make more sense to see if we can have it promoted to tier 2 and then its platform file merged with this one
• The "building rust programs" and "cross-compilation toolchains and C code" sections are missing, any ideas here? The template has a little guidance of what to put in each section.

I agree with merging the targets into one file. I also think that we should pursue making the im target tier 2 if possible, I don't see a reason why that would be rejected. I think we can just copy the no_std arm target sections for the cross-compilation and building rust program sections.

FYI the riscv-rust-quickstart link 404s, I guess the link should be https://github.com/riscv-rust/riscv-rust-quickstart, but this seems to be a quickstart for the discontinued hifive boards. It might make sense to update this to something more modern (and purchasable) before adding the link here.

from wg.

@romancardenas

I'd update the riscv-rust-quickstart repo to align it with a RED-V clone for now. I have a couple of RED-V boards, so I can take a look. But we definitely need a more generic and modern template.

OK, I've re-instated the (correct) link, I guess at least it's something and hopefully it can be updated to be more useful.

Regarding cross-compilation toolchains and C code, I haven't played around with it, but I guess that we could add something like

Thanks, added.

@MabezDev

I can take care of that as I'll be adding the imafc target soon for the ESP32-P4.

Brilliant, thanks! I'll leave it as-is for this PR then, and you can merge the rv32im target to use the same platform support file at the same time?

I've pushed the latest updates and I don't think anything is missing now, so I'll bring it up at the weekly meeting tomorrow and if there are no further comments after that I'll open the PR upstream.

from wg.

I'm onboard to help maintain these targets! I don't know as much as I would like to about the thumv8m ISA though 😅

from wg.

So this is a good backstop, but honestly I'd much rather Arm was listed as the maintainer, as they are for aarch64-unknown-linux-gnu. I understand that they will already help fix issues if we tag the right people, but there's some discussion about whether they're happy to have their name actually listed.

from wg.

Equally it would be nice if the RISC-V targets were maintained by the RISC-V Foundation, or if they sponsored someone to maintain them.

from wg.

So this is a good backstop, but honestly I'd much rather Arm was listed as the maintainer, as they are for aarch64-unknown-linux-gnu. I understand that they will already help fix issues if we tag the right people, but there's some discussion about whether they're happy to have their name actually listed.

I agree that having the official makers of the stuff onboard to be co-maintainers would be better. In any case we additionally should have rewg people on board rather than outsourcing this completely without any possibility of collaboration...

from wg.

That's a fair point. We should be co-maintainers.

from wg.

Let's get the cortex-m team added now, and I'll continue to talk to Arm about this. They could be co-maintainers, or they could just have someone join the cortex-m team. Either would work.

from wg.

I haven't spoken to the @rust-embedded/riscv team yet but if they're interested in the riscv32i-unknown-none-elf, riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, riscv64imac-unknown-none-elf, or riscv32im-unknown-none-elf targets I'm happy to add them to the same PR (or they can make their own). Similarly if there are any other targets people in the WG think we could support.

I'm happy to help with riscv32imac as that's what I have, I cannot do practical things with the others I'm afraid.

Same here, I can help with RISC-V 32 targets. I currently do not have any RISC-V 64 board, but I plan to eventually work with those targets as well.

from wg.

Thanks for the responses everyone. I've started to put together a branch with the relevant details.

Please could you check the relevant files, let me know if anything is missing or wrong, if there's any more details you think should be present, or any other links or docs:

• MSP430
• RV32
  • I've combined i, imc, and imac into one file, as they're all tier 2 targets with no existing details
  • I've left im alone because it's somehow tier 3 and does have a nominal maintainer, though it might make more sense to see if we can have it promoted to tier 2 and then its platform file merged with this one
  • The "building rust programs" and "cross-compilation toolchains and C code" sections are missing, any ideas here? The template has a little guidance of what to put in each section.
• thumbv6
• thumbv7
• thumbv8
  • I merged baseline and mainline as I expect the details will be the same for them and we've merged all the v7 targets together too.

Feel free to leave comments here or open a PR against my branch, once we're happy with it I'll submit it as a PR to rust-lang/rust#116004

from wg.

thumbv8m.main-none-eabi points to thumbv8m.main-none-eabihf

but

thumbv7em-none-eabihf points to thumbv7m-none-eabi

We should probably have the 'lowest' target as the one that gets the file and then have the others point at it? Doesn't make a big difference though.

from wg.

The -eabihf target enables the hardware FPU and uses the hard-float ABI.

I would add:

If you want to use the FPU with the soft-float ABI, you can use the -eabi' target, but add extra RUSTFLAGSlike-mcpu=+vfp` (I made that up).

from wg.

The thumbv8m file says:

This target supports C code. Use the thumbv6m-none-eabi triple in LLVM. If interlinking with C or C++, you may need to use arm-none-eabi-gcc as a linker instead of the built-in LLD.

That's probably the wrong LLVM target? Also s/the built-in LLD/the default rust-lld linker/.

from wg.

Maybe in the thumbv6m-none-eabi target file we could point them at atomic-polyfill?

Also I think my notes above apply to the thumbv7m target file too; but I really liked the Floating Point section so maybe copy that to the thumbv8 file?

from wg.

Thanks @cr1901, @jonathanpallant, I've made those changes and pushed, except:

If you want to use the FPU with the soft-float ABI, you can use the -eabi' target, but add extra RUSTFLAGSlike-mcpu=+vfp` (I made that up).

Happy to add this but not sure what the right incantation is and don't have time to test it tonight, does anyone know?

from wg.

I guess we can add it later.

from wg.

Thinking about it more, I think it would be more involved than just the config flag - you'd cause rust to generate FPU instructions, but cortex-m-rt uses the "hf" in the target to know to enable the FPU at boot, so you'd also need to manually enable the FPU. Perhaps advanced enough to leave out of the target support for the time being.

from wg.

@cr1901 I've fallen off embedded Rust lately, so I'm not really the right person for maintenance duty.

from wg.

I also think that we should pursue making the im target tier 2 if possible, I don't see a reason why that would be rejected. I think we can just copy the no_std arm target sections for the cross-compilation and building rust program sections.

I like the idea but don't know anything about practically doing it in rust-lang/rust, do you think that should wait until after these target changes are merged (assuming it needs some sort of signoff or changes to what gets distributed via rustup etc)?

from wg.

FYI the riscv-rust-quickstart link 404s, I guess the link should be https://github.com/riscv-rust/riscv-rust-quickstart, but this seems to be a quickstart for the discontinued hifive boards. It might make sense to update this to something more modern (and purchasable) before adding the link here.

The red-v clone is still available though I suspect it'll be out of circulation soon as well. The quickstart was started when hifive1 was essentially the only board around, situation is quite different now but ironically I don't have any of the newer ones :D

from wg.

@romancardenas, @almindor, would you mind checking the proposed rv32 file? In particular

• I've combined i, imc, and imac into one file, as they're all tier 2 targets with no existing details
• I've left im alone because it's somehow tier 3 and does have a nominal maintainer, though it might make more sense to see if we can have it promoted to tier 2 and then its platform file merged with this one
• The "building rust programs" and "cross-compilation toolchains and C code" sections are missing, any ideas here? The template has a little guidance of what to put in each section.

LGTM apart from the quickstart link as mentioned by @MabezDev

from wg.

Thanks! I've removed the quickstart link for now.

The final thing is the missing "building rust programs" and "cross-compilation toolchains and C code" for riscv32, any ideas there?

from wg.

Looks good to me!!

I'd update the riscv-rust-quickstart repo to align it with a RED-V clone for now. I have a couple of RED-V boards, so I can take a look. But we definitely need a more generic and modern template.

Regarding cross-compilation toolchains and C code, I haven't played around with it, but I guess that we could add something like:

This target supports C code. If interlinking with C or C++, you may need to use riscv64-unknown-elf-gcc as a linker instead of rust-lld.

from wg.

I like the idea but don't know anything about practically doing it in rust-lang/rust, do you think that should wait until after these target changes are merged (assuming it needs some sort of signoff or changes to what gets distributed via rustup etc)?

I can take care of that as I'll be adding the imafc target soon for the ESP32-P4.

from wg.

@cr1901 I've fallen off embedded Rust lately, so I'm not really the right person for maintenance duty.

@YuhanLiin Okay, no problem. I can take care of things. I've also been on a bit of a break from writing Rust, embedded or otherwise. My priority right now is to just ensure that MSP430 doesn't break e.g. AT2XT until I have the bandwidth to make a bunch of small improvements in a large batch (such as "it's now agreed that volatile references need to be replaced with pointer accesses, even though in the short term nothing is going to break").

from wg.

As far as I can tell the goal of this ticket has been reached and the teams are listed as maintainers of their architectures in https://github.com/rust-lang/rust/tree/master/src/doc/rustc/src/platform-support/
Can we close this ticket?

from wg.

Thanks, yep! It's not the route we first planned but you're right, all the goals have been reached so this can be closed.

from wg.