<re_irc>
<@ubik:matrix.org> adamgreig: yeah, that's what I thought of, but I was wondering whether there's some magic 🪄 I could use to make it in a more transparent way
<re_irc>
<@ubik:matrix.org> Fuck, there's a console editor which has clippy
<re_irc>
<@david-boles:matrix.org> Hi folks, are there any good examples I could look at for how to set up a project to build for a bootloader? I'm targeting mcuboot so I need to be able to add a header and trailer to what would normally be flashed, which are both dependent on the built binary. I'm also hoping to get away with a minimum of manually installed dependencies.
<re_irc>
<@david-boles:matrix.org> My main problem at the moment is just amending the built ELF file. I was hoping to use the llvm-objcopy provided by the rust toolchain and exposed by cardo-binutils but it seems to be missing both the `--change-section-address` (for use with `--add-section`) and `--update-section` options that my default objcopy has. The `object` crate maybe seems like the right way to go but their demo for (presumably)...
<re_irc>
<@david-boles:matrix.org> So far what I do have working is an [xtask](https://github.com/matklad/cargo-xtask) subproject based on cargo-embed which builds and then finds the binary as well as linker scripts that create the blank sections I need to fill.
<re_irc>
<@david-boles:matrix.org> (this is for cortex-m, an nrf52832)
<re_irc>
<@korken89:matrix.org> david-boles:matrix.org: Convert to bin and pad the binary?
<re_irc>
<@korken89:matrix.org> We do that in a bootloader we have with a few lines of Python
<re_irc>
<@david-boles:matrix.org> Yeah, that's definitely the easiest option. I was hoping to generate a single artifact that kept all the debug info too
<re_irc>
<@david-boles:matrix.org> Hoping to integrate with probe-rs' vscode plugin and eventually cargo-embed. I don't think they're set up to support that atm
<re_irc>
<@korken89:matrix.org> We had 2 things there, 1 bin we generated for the bootloader to be happy
<re_irc>
<@korken89:matrix.org> But we kept the elf around for debugging
<re_irc>
<@korken89:matrix.org> So you load symbols from the ELF, use the bin for flashing
<re_irc>
<@david-boles:matrix.org> Totally, just trying to get that smooth all-in-one experience :) Doesn't look like separate files for debug symbols are supported from what I can see: https://probe.rs/docs/tools/vscode/
<re_irc>
<@david-boles:matrix.org> And I'm mostly annoyed because it seems like it *should* be easy to do
<re_irc>
<@korken89:matrix.org> Nah it's a special special usecase
<re_irc>
<@korken89:matrix.org> But adding a parameter for it should not be that hard
<re_irc>
<@korken89:matrix.org> You can check in the probe-rs chat how to fix it maybe
<re_irc>
<@david-boles:matrix.org> Well, it would be easy if llvm-objcopy supported all the options that gcc's does :)
<re_irc>
<@david-boles:matrix.org> I'll probably try digging into `object` but your way does sound like the path of least resistance. Thanks for the advice!
<re_irc>
<@korken89:matrix.org> Why not use gcc objcopy?
<re_irc>
<@david-boles:matrix.org> > I'm also hoping to get away with a minimum of manually installed dependencies.
<re_irc>
<@david-boles:matrix.org> Mostly making life difficult for myself
jackneilll has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> :D
<re_irc>
<@korken89:matrix.org> Here I'm writing xtasks that install all the crap for me :D
<re_irc>
<@korken89:matrix.org> download a GCC toolchain in the bg? Sure!
<re_irc>
<@david-boles:matrix.org> Ha! Could do that... But then I'd have to spin up Windows to test it
jackneill has quit [Ping timeout: 240 seconds]
<re_irc>
<@korken89:matrix.org> :)
<re_irc>
<@korken89:matrix.org> Generally generating headers and footers and merging has not been straight forward, so if you write a nice tool - ping me ;)
<re_irc>
<@david-boles:matrix.org> Will do :)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fooker has quit [Quit: WeeChat 3.3]
fooker has joined #rust-embedded
<re_irc>
<@9names:matrix.org> david-boles:matrix.org: Why does that that require Windows?
<re_irc>
<@adamgreig:matrix.org> david-boles: why do you need to change section addresses? could you just update your memory.x so the elf is generated suitable for the bootloader memory map to start with?
<re_irc>
<@9names:matrix.org> i think it's the "which are both dependent on the built binary" section of the story that is load bearing here
<re_irc>
<@dirbaio:matrix.org> probably a crc or signature, there's no way to get the normal build process to do these, you need to do them in a postprocessing step
<re_irc>
<@dirbaio:matrix.org> sometimes it helps to still add the sections with the right addrs etc in the main build. with "dummy" data, so the postprocessing step is just patching them in place
<re_irc>
<@dirbaio:matrix.org> so it's easier to do with a few lines of python/rust without requiring gcc objcopy
<re_irc>
<@adamgreig:matrix.org> yea, that's what I mean
<re_irc>
<@adamgreig:matrix.org> instead of needing --add-section and --change-section-address, set up memory.x to add the relevant sections in advance
<re_irc>
<@adamgreig:matrix.org> agreed you still need to munge the binary afterwards to write the correct crc
<re_irc>
<@adamgreig:matrix.org> but should make elf and/or bin manipulation pretty easy hopefully
<re_irc>
<@dirbaio:matrix.org> with `object` you can easily read all .text data to calc signatures, then with [file_range](https://docs.rs/object/latest/object/read/trait.ObjectSection.html#tymethod.file_range) you can get where the "bootloader header" section is on file, then reopen the file as raw bytes and patch it in there
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar has joined #rust-embedded
GenTooMan has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> recommendation for firmware/crate I can flash onto an mcu so it behaves as an "example" I2C peripheral? (just sends some kind of data, I don't much care what - I want to write an I2C driver and don't have any peripheral speaking it)
<re_irc>
<@thejpster:matrix.org> ithinuel wrote one for the RP2040 I think
<re_irc>
<@thejpster:matrix.org> I got removed from the repo because it uses embassy, which isn't published, and it blocked us publishing our crate to crates.io
<re_irc>
<@ithinuel:matrix.org> Note that only the controller part requires embassy. The peripheral (/slave) does not, so you can build a small app that'll act as an i2c peripheral.
<re_irc>
<@thejpster:matrix.org> (note to self, we should have an 'experimental' bucket alongside the crates with interesting but unpubilshable examples)
<re_irc>
<@dirbaio:matrix.org> embassy-traits won't get published because the plan is to use embedded-hal async support from day one
<re_irc>
<@matoushybl:matrix.org> I suppose there is no trait for it because it cannot be described using one as it is basically a weird state machine implemented differently by vendors. Async functions could in theory describe it, but there are different protocols that could behave differently.
<re_irc>
<@ithinuel:matrix.org> For what it's worth, on the RP2040, I didn't try to describe the state machine but the event on the bus.
<re_irc>
<@ithinuel:matrix.org> This should be fairly generic and future proof if/when RPI releases new MCU.
gsalazar has quit [Ping timeout: 256 seconds]
xnor has joined #rust-embedded
<cr1901>
How does svd2rust 0.20.0 (or above) decide whether a register will have a safe of unsafe bits() function?
<cr1901>
i.e. what SVD fields does svd2rust look at for the entire register?
<re_irc>
<@henkkuli:matrix.org> TLDR: If the register contains only a single field and all values are valid, the bits method is safe. Otherwise it is unsafe
Amadiro has quit [Remote host closed the connection]
<cr1901>
Okay, I was trying to tell svd2rust at the _register_ level (i.e. not field level) that "all bits are used and all bit patterns are safe."
<cr1901>
I wanted to avoid svd2rust from generating a redundant register field that covers the entire register, and use bits() instead
<cr1901>
But that's okay, I'll keep things the way they are
<re_irc>
<@henkkuli:matrix.org> I'm not sure there is a way not to generate a field, though I'm in no way an expert in the internals of svd2rust. I just happened to spot that piece of code yesterday when skimming through the codebase.
<re_irc>
<@henkkuli:matrix.org> On that note, I actually came here for a svd2rust question of my own: Does there exist a svd2rust-generated PAC crate with custom code. Or is this something that is not supported? I'm trying to implement a custom trait on some registers to provide extra methods on them.
<re_irc>
<@adamgreig:matrix.org> you can add anything you want to what svd2rust generates (for example the stm32-rs PACs put the svd2rust files in modules to support multiple chips per crate), but not sure about adding traits on specific registers
<re_irc>
<@adamgreig:matrix.org> there was some talk about this for rp2040's atomic access recently... maybe in #rp-rs:matrix.org
<re_irc>
<@adamgreig:matrix.org> ah...
<cr1901>
I'm not worrying about it for now, tbh
<re_irc>
<@adamgreig:matrix.org> it was us ;)
<re_irc>
<@adamgreig:matrix.org> I think the idea of having svd2rust apply some tag to some selected registers somehow could work, then you can impl a trait thereafter, but afaik it doesn't currently have anything built in to make this easy
<re_irc>
<@adamgreig:matrix.org> I wonder if you could just do it for all registers though or what
<re_irc>
<@henkkuli:matrix.org> Yeah, it was us :D I was looking for examples on how to move forward with this
<re_irc>
<@henkkuli:matrix.org> I have a very crude POC for implementing marker traits on some registers and I'm now trying to implement the PAC side of the thing
<re_irc>
<@adamgreig:matrix.org> I wonder if you could just add some impl blocks to generic.rs
<re_irc>
<@adamgreig:matrix.org> (pass -g to svd2rust to have it write a separate generic.rs which contains the Reg type definition and methods)
<re_irc>
<@adamgreig:matrix.org> and then just modify that generic.rs in your PAC
<re_irc>
<@henkkuli:matrix.org> I'll check how it works with `form`. But that might work. The only downside is that any updates to svd2rust's generic.rs would need to be ported manually
<re_irc>
<@adamgreig:matrix.org> sure, but it's probably not hard, just a single impl block
<cr1901>
Well, this wasn't that fun to do, but the msp430 crates are update. Just gonna do a few tests before I start releasing them in a few days.
<re_irc>
<@henkkuli:matrix.org> adamgreig: OK, I think I'll just add `generic_extension.rs` at the root of the project and then concatenate that with the `generic.rs` generated by svd2rust. At least it compiles
<re_irc>
<@david-boles:matrix.org> adamgreig: Unfortunately `--update-section` also isn't available so objcopy doesn't work for patching existing sections either. Looks like object is the way to go.
<re_irc>
<@david-boles:matrix.org> dirbaio: Ah, I like that much better than rewriting the entire file. Thanks!
<re_irc>
<@adamgreig:matrix.org> room meeting time again! agenda is https://hackmd.io/vPTd5YmHSsytrmz-CmuJog, please add anything you'd like to discuss, and we'll start in 5min
<re_irc>
<@adamgreig:matrix.org> I don't have any announcements this week, anyone got anything?
<cr1901>
I've been test driving bare-metal 1.0.0, which AFAIK cortex-m isn't using yet
<re_irc>
<@adamgreig:matrix.org> actually, svd2rust 0.21 is out now, that's worth mentioning!
<re_irc>
<@adamgreig:matrix.org> especially if anyone in cortex-m team could look over it (and thanks thejpster for doing so already)
<re_irc>
<@adamgreig:matrix.org> this should also start to unlock doing more and better tests in c-m including newam's HIL stuff
<re_irc>
<@adamgreig:matrix.org> if dirbaio's around, I was wondering about moving cortex-m to using critical-section, assuming it shouldn't go in bare-metal itself
<re_irc>
<@adamgreig:matrix.org> possibly including adopting the critical-section crate in the wg
<re_irc>
<@therealprof:matrix.org> Do you intend to keep the hundreds of commits?
<re_irc>
<@adamgreig:matrix.org> yea? that's the whole history of it, so you get to keep it when looking at files/blame/etc
<re_irc>
<@adamgreig:matrix.org> I could do a version where we just copy the files with no git history if there's a reason for that
<re_irc>
<@newam:matrix.org> 583 commits isn't a ton, I would say the benefits outweigh the clutter.
<re_irc>
<@adamgreig:matrix.org> this way also means github will accurately reflect contributors and stuff
<re_irc>
<@therealprof:matrix.org> Fair points. It feels a bit weird chronologically but I have no other objections.
<re_irc>
<@adamgreig:matrix.org> the commits should all appear as from the correct times and authors and so forth I think
<re_irc>
<@newam:matrix.org> The committer will be changed to you I think, but the author field should still be intact.
<re_irc>
<@adamgreig:matrix.org> I don't think that's happened in this case (I didn't rebase the commits), and github currently seems to show just the original author in the PR view
<re_irc>
<@therealprof:matrix.org> They do but the actual order of the commits is not chronological, I like being able to browse through the last commits to get recent history but in this case I'd have to skip 500 or so.
<re_irc>
<@adamgreig:matrix.org> oh, in the overall commits view for the repo?
<re_irc>
<@chrysn:matrix.org> therealprof:matrix.org: If the tree is put in in a merge, there is no actual order of the commits.
<re_irc>
<@adamgreig:matrix.org> I would have thought that would still be sorted by time
<re_irc>
<@adamgreig:matrix.org> I see for the semihosting crates we did just do a single commit that adds the new files, but for a larger crate like c-m-rt especially it seems worth keeping the history and contributors
<re_irc>
<@therealprof:matrix.org> How is crates structure done to not create conflicts with RTIC?
<re_irc>
<@adamgreig:matrix.org> RTIC?
<re_irc>
<@therealprof:matrix.org> (sorry, can't see any forrest for all the wood)
<re_irc>
<@adamgreig:matrix.org> (by the way, `git log` will also show the commits in a chronological sense, it doesn't have 500 c-m-rt commits on top of all the c-m commits)
<re_irc>
<@therealprof:matrix.org> Right, I just double checked that.
<re_irc>
<@therealprof:matrix.org> RTIC relies on cortex-m, right?
<re_irc>
<@adamgreig:matrix.org> why might RTIC be affected?
<re_irc>
<@therealprof:matrix.org> Because it uses the cortex-m stuff but not cortex-m-rt.
<re_irc>
<@adamgreig:matrix.org> the PR just moves the repositories, there's still two separate crates
<re_irc>
<@therealprof:matrix.org> If they're in the same crate, how's that handled.
<re_irc>
<@adamgreig:matrix.org> same as cortex-m-semihosting and panic-semihosting
<re_irc>
<@newam:matrix.org> The advantage to being in the same repository is that is prevents a dependency cycle when using cortex-m-rt to do HIL testing
<re_irc>
<@adamgreig:matrix.org> the cortex-m-rt stuff is all in the cortex-m-rt directory, which is a member of the top-level workspace and a crate in its own right, still published and depend-upon separately
<re_irc>
<@therealprof:matrix.org> Ah, I thought the idea was to be able to use the cortex-m primitives directly but if they're in separate crates in the same repository?
<re_irc>
<@adamgreig:matrix.org> yep, at this point the only change is for our own logistics and testing, there's no visible difference to end users
<re_irc>
<@adamgreig:matrix.org> fewer repositories to configure and administer (and corresponding ci/bors/etc), share things like xtask/assembly generation (not yet implemented), and crucially cortex-m tests can depend on the repo's own cortex-m-rt for executable tests
<re_irc>
<@adamgreig:matrix.org> but what's on crates.io doesn't change
<re_irc>
<@therealprof:matrix.org> Makes sense.
<re_irc>
<@adamgreig:matrix.org> it does also mean in the future we could start to refactor how the crates relate to each other so that perhaps end users do only need to depend on cortex-m or we can more easily split cortex-m up into separate bits
<re_irc>
<@therealprof:matrix.org> Thanks for the walkthrough... Again, forest vs trees. 😉
<re_irc>
<@adamgreig:matrix.org> but none of those changes are in this PR or immediately planned
<re_irc>
<@adamgreig:matrix.org> np!
<re_irc>
<@adamgreig:matrix.org> ok, next up on the agenda is about critical-section... we've talked about this briefly before but while we're pondering cortex-m 0.8 stuff I wonder if now would be a good time for it
<cr1901>
Glad I get to watch you talk this out and I just steal the decisions you make :P
<re_irc>
<@adamgreig:matrix.org> cortex-m's interrupt::free causes lots of different people various problems, and it seems like using critical-section (as in https://crates.io/crates/critical-section) we could probably keep all the ease-of-use for people happy with interrupt::free while stopping it from breaking the world for other users
<re_irc>
<@adamgreig:matrix.org> I'm curious whether it should be put into bare_metal and used by cortex-m from there, or just used directly in cortex-m itself, and also whether the wg should possibly adopt the crate and push it as the best way to interoperate critical sections
<re_irc>
<@adamgreig:matrix.org> and perhaps write some more documentation for it :P
<re_irc>
<@adamgreig:matrix.org> (it's currently dirbaio's crate, to be clear)
<re_irc>
<@therealprof:matrix.org> What's the difference between `critical-section` and our CS?
<re_irc>
<@therealprof:matrix.org> Seeing this for the first time just now.
<re_irc>
<@adamgreig:matrix.org> the basic principle in critical-section is that there's an `extern Rust` method called `_critical_section_acquire()` / release, and that gets called by anyone wanting a CS
<re_irc>
<@adamgreig:matrix.org> then, _someone_ provides those methods somewhere in your application (once only)
<re_irc>
<@adamgreig:matrix.org> on a standard cortex-m system, they just map to our existing interrupt::free (i.e., cpsid, and then maybe cpsie if it was enabled before)
<re_irc>
<@adamgreig:matrix.org> on nrf with softdevice, it can leave the softdevice interrupts running, to stop it from totally breaking softdevice
<re_irc>
<@adamgreig:matrix.org> on an RTOS, it can enter an RTOS-provided critical section for this application/thread/whatever is useful
<re_irc>
<@therealprof:matrix.org> Interesting.
<re_irc>
<@adamgreig:matrix.org> in unprivileged user code, it might not be implemented if the application just isn't allowed to enter a CS, then you get a linker error instead of the current totally unsound behaviour
<re_irc>
<@adamgreig:matrix.org> (currently the cpsid instruction will silently do nothing, then proceed thinking it's got interrupts off)
<re_irc>
<@adamgreig:matrix.org> there's probably some fine details to resolve, including questions about inlineability/performance if you need to make all these function calls for every critical section, and what invariants exactly a "critical section" implementation must uphold
<re_irc>
<@adamgreig:matrix.org> it might be we still want an unsafe "classic" CS in cortex-m for more performance-sensitive use-cases too
<re_irc>
<@adamgreig:matrix.org> but it's a problem we need to fix in cortex-m eventually, and this basically makes it more or less end-user-configurable like a panic handler
<re_irc>
<@therealprof:matrix.org> Doesn't sound too shabby.
<re_irc>
<@adamgreig:matrix.org> (but typically you'd expect it to be configured for you without user intervention, maybe with a default feature)
<re_irc>
<@adamgreig:matrix.org> as a bonus it works out the box on risc-v, std, wasm, etc too
<cr1901>
adamgreig: I have some numbers if/when you want to see
<re_irc>
<@adamgreig:matrix.org> cr1901: thanks! could you share after meeting?
<cr1901>
Will do
<re_irc>
<@adamgreig:matrix.org> OK, I guess that's all I wanted to say about c-s at the moment, let's see what it looks like in c-m for 0.8 I guess
<re_irc>
<@adamgreig:matrix.org> talking of 0.8, the other thing is to make an alpha release sometime, which I guess can happen without any thoughts of semver hacks yet, though they might want to come before we actually release it
<re_irc>
<@chrysn:matrix.org> Thanks for the pointer to critical-section, sounds well doable in RIOT as an RTOS example (though I might ask for a larger token type, but that should be doable with features).
<re_irc>
<@adamgreig:matrix.org> yea, I noticed the token size too, I wonder if there'd be any actual cost in bumping it to a u16 or even u32
<re_irc>
<@adamgreig:matrix.org> (maybe on 16-bit platforms...)
<re_irc>
<@chrysn:matrix.org> It could be feature-driven -- the user doesn't specify a feature, but whoever provides the c-s backend will depend on it and select the right type through a feature.
<cr1901>
I try to avoid u32s when possible :P
<re_irc>
<@adamgreig:matrix.org> chrysn, yea, a feature could work
<re_irc>
<@drtobbe:matrix.org> personally, i consider critical sections very hardware-specific. couldn't that abstraction lead to false assumptions?
<re_irc>
<@adamgreig:matrix.org> yep, so we'll need to document what the conditions are for an implementation, for sure
<re_irc>
<@newam:matrix.org> mutually exclusive features sadly :/
<re_irc>
<@newam:matrix.org> I don't have any better suggestions though.
<re_irc>
<@adamgreig:matrix.org> not as worried about mutually exclusive features when only one crate can possibly provide the no-mangle'd functions anyway
<re_irc>
<@newam:matrix.org> Good point
<re_irc>
<@adamgreig:matrix.org> got a few more agenda items to mention before we run out of time, we can come back to the cortex-m stuff after:
<re_irc>
<@adamgreig:matrix.org> first up is that the cross RFC is effectively approved now, so I anticipate making it happen in the next few days barring any last minute objections or concerns
<re_irc>
<@adamgreig:matrix.org> so I think it would be nice to link to those from the book front pages (in a table with space for other languages too I guess)
<re_irc>
<@eldruin:matrix.org> definitely
<re_irc>
<@adamgreig:matrix.org> if anyone would like to do that it should be an easy PR
<re_irc>
<@therealprof:matrix.org> adamgreig: thejpster is already getting nervous... 😉
<re_irc>
<@adamgreig:matrix.org> ok, and finally I'll turn the floor over the embedded-hal team, any PRs to discuss this week?
<re_irc>
<@therealprof:matrix.org> adamgreig: Excellent, training material...
<re_irc>
<@adamgreig:matrix.org> I think there was a lot of HAL PRs merged after last meeting
<re_irc>
<@eldruin:matrix.org> embedded-hal-async is now in a subfolder
<re_irc>
<@dirbaio:matrix.org> I did some ping spam and some got merged 🙈
<re_irc>
<@eldruin:matrix.org> delay is already in
<re_irc>
<@eldruin:matrix.org> exactly, dirbaio added prs for several traits and the discussions are ongoing
<re_irc>
<@eldruin:matrix.org> there is also a new draft for managed CS
<re_irc>
<@eldruin:matrix.org> which has some relevance for the spi trait shuffle discussion
<re_irc>
<@eldruin:matrix.org> lots of discussion going on in the PRs
<re_irc>
<@eldruin:matrix.org> I do not have anything specific to discuss right now
<re_irc>
<@dirbaio:matrix.org> is there any outstanding concern with that, or can we merge it?
<re_irc>
<@eldruin:matrix.org> we already merged the error type unification which was the only discussion item so I think that is good to go now
<re_irc>
<@eldruin:matrix.org> may need some rebase though
<re_irc>
<@therealprof:matrix.org> Fine with me.
<re_irc>
<@dirbaio:matrix.org> rebased
<re_irc>
<@chrysn:matrix.org> I liked the separation, but it's also really verbose, to little practical benefit (didn't run into any case where one couldn't be implemented).
<re_irc>
<@eldruin:matrix.org> merge in process...
<re_irc>
<@dirbaio:matrix.org> <3
<re_irc>
<@dirbaio:matrix.org> then I guess the async equivalent is OK too? :D
<re_irc>
<@adamgreig:matrix.org> yea, that's one of the issues I was referring to
<re_irc>
<@adamgreig:matrix.org> I mean, it wouldn't change the underlying reality of unpriv code not being able to enter a CS, but it would stop cortex-m being totally unsound out of the box in that situation
<re_irc>
<@adamgreig:matrix.org> (well, assuming we implement it suitably.... the current version of critical-section will call interrupt::disable on all cortex-m platforms by default, which _would_ have the same problem)
<re_irc>
<@chrysn:matrix.org> For c-s to be of any help here, the c-m interrupt:free would need to go away or be replaced with c-s's free (and then provide the functions again), right?
<re_irc>
<@adamgreig:matrix.org> yes, c-m::interrupt::free would call/be replaced by c-s::with
<re_irc>
<@chrysn:matrix.org> And then user code would not enable that old implementation, but basically receive one that's a static error
<re_irc>
<@chrysn:matrix.org> (user code in user mode)
<re_irc>
<@adamgreig:matrix.org> right.
<re_irc>
<@adamgreig:matrix.org> I don't think we can detect that at build time
<re_irc>
<@adamgreig:matrix.org> but if the runtime crate for your user-mode thing sets things up, it will either get to implement its own CS or otherwise cause a build error when you try to build code that uses a CS
<re_irc>
<@chrysn:matrix.org> Well, c-m would might grow a feature that says "I'm building this to be run in privileged mode"
<re_irc>
<@adamgreig:matrix.org> _probably_ I'd have cortex-m-rt enable the default cortex-m implementation in c-s, so that just using c-m alone doesn't do it
<re_irc>
<@chrysn:matrix.org> Or even c-m-rt would define it
<re_irc>
<@adamgreig:matrix.org> (and still leave a way for other crates to disable it even when using c-m-rt)
<re_irc>
<@chrysn:matrix.org> yes :-)
<re_irc>
<@adamgreig:matrix.org> but at least most users on c-m-rt are priv-mode no-OS and want the default cpsid/cpsie
<re_irc>
<@chrysn:matrix.org> But the softdevice is weird already :-)
<re_irc>
<@adamgreig:matrix.org> whereas ideally the c-m crate is usable from inside an rtos or other abstraction that shouldn't be able to call interrupt::free
<re_irc>
<@adamgreig:matrix.org> (its use of the peripherals singleton is another problem that needs addressing)
<re_irc>
<@adamgreig:matrix.org> cr1901: hmm, I wonder where the debug mode difference is coming from, there's so little changed in bare-metal 0.2->1.0...
<cr1901>
Who knows? Even r0 was about 1000 bytes of code in debug mode
<re_irc>
<@dirbaio:matrix.org> adamgreig: yeah, it bugs me that it's still "incorrect by default", I was thinking of making it have no impl by default, and have the user explicitly enable the cpsid/cpsie impl...
<re_irc>
<@dirbaio:matrix.org> but that'd be annoying
<re_irc>
<@adamgreig:matrix.org> Yea. Maybe disabled by default but cortex-m-rt enables it by default
<re_irc>
<@adamgreig:matrix.org> For cortex-m anyway, and maybe riscv
<re_irc>
<@dirbaio:matrix.org> then someone forgets default-features=false when depending on cmrt and then you're stuck :P
<re_irc>
<@dirbaio:matrix.org> hmm but "if you're using cmrt you're in privileged mode" is an interesting assumption
<re_irc>
<@dirbaio:matrix.org> probably always true..? if you're writing some rtos app the app image format is usually different (?)
<re_irc>
<@dirbaio:matrix.org> except for the softdevice lol
<re_irc>
<@chrysn:matrix.org> you could still have code you start in unprivileged mode in the same binary
<re_irc>
<@chrysn:matrix.org> (we do some of this in RIOT, not with unprivileged mode because all code runs on the same level, but at least with the MPU)
<re_irc>
<@dirbaio:matrix.org> oof do people really do that?
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: Make it a negative feature like it currently is in c-s?
<re_irc>
<@chrysn:matrix.org> but then you WOULD PROBABLY (as in RFC6919) also define a way for that code to use something CS-ish, and things conflict.
<re_irc>
<@dirbaio:matrix.org> adamgreig: custom-impl is technically not a negative feature, it's "gimme the macro to supply my own"
<re_irc>
<@chrysn:matrix.org> dirbaio:matrix.org: well the default assumption in riot is that you're building a monolithic application, and the MPU is merely used to prevent some common errors
<re_irc>
<@adamgreig:matrix.org> Ok but with it you don't get the default impl, and without it you do, soooo
<re_irc>
<@adamgreig:matrix.org> It could be the same in c-m-rt is all :p
<re_irc>
<@yuhanliin:matrix.org> cr1901: I added you as contributor for `panic-msp430`. Should I also make a new release?