<re_irc>
<nihal.pasham> > Okay cool. I’m mostly curious if it’s been tested on production hardware yet.
<re_irc>
Yes it is. It's being used to boot "mcus" and "sbcs" by a few teams in the company I work for
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest6598
emerent_ is now known as emerent
Guest6598 has quit [Ping timeout: 272 seconds]
<re_irc>
<nihal.pasham> > Im looking for a bootloader that doesn’t require that the mcu be reset to switch to new firmware
<re_irc>
I agree with James Munns: on the consulting part. However, one caveat - implying it's possible or saying yes (always) can result in setting the wrong expectations
<re_irc>
Although, rustBoot doesn't support this for the reason that it's focused on security i.e.
<re_irc>
- rustBoot is always divergent (i.e. never returns once it's done)
<re_irc>
Note: only interested people should apply, click and drop a message let's get started
<re_irc>
<nihal.pasham> +sometimes
<re_irc>
<nihal.pasham> > Im looking for a bootloader that doesn’t require that the mcu be reset to switch to new firmware
<re_irc>
I agree with James Munns: on the consulting part. However, one caveat - implying it's possible or saying yes (always) can sometimes result in setting the wrong expectations
<re_irc>
Although, rustBoot doesn't support this for the reason that it's focused on security i.e.
<re_irc>
- rustBoot is always divergent (i.e. never returns once it's done)
<re_irc>
<James Munns> Agree with you Nihal, there's some finesse in saying "yes" in a way that makes it clear that "any choice other than no is unreasonable". And sometimes the answer really is no, but more often I find engineers saying "no" when it is undesirable/unreasonable, rather than truly impossible
<re_irc>
<James Munns> (I find being choosy with your hard "no"s makes them better listened to when you do have to use them. Again, it also takes having the correct relationship/pull to make sure people hear what you are actually saying, not what they want to hear, i.e. just the "yes" part and not the "but" part, this is typically easier as an external consultant than a junior team member, for complicated/political reasons)
<re_irc>
<James Munns> People are complicated systems, teams even more so, and companies even more so :p
<re_irc>
<nihal.pasham> > "any choice other than no is unreasonable". And sometimes the answer really is no, but more often I find engineers saying "no" when it is undesirable/unreasonable, rather than truly impossible
<re_irc>
> I started of as a persales-engineer and this is one of the trickiest things I've had to learn. But been there. done that.
<re_irc>
<James Munns> We probably need a separate "consulting war stories" room at this point :D
fabic has joined #rust-embedded
<re_irc>
<nihal.pasham> ->
<re_irc>
<9names (@9names:matrix.org)> Looks like the embedded ctctf video is up.
<re_irc>
<diondokter> Oh wait, that value might be a bit further than I thought it was... That probably already multiplied with the WORD_SIZE, which is 4...
<re_irc>
But that's also incorrect. It should be 0x2000
<re_irc>
<diondokter> Thanks for being a rubber duck everyone! :P
<re_irc>
<diondokter> Ok, yup, that's an nrf-hal bug
<re_irc>
<ryan-summers> Happy to help! 🦆
aspe has joined #rust-embedded
aspe has quit [Client Quit]
<re_irc>
<James Munns> (just a guess)
<re_irc>
<Mehmet Ali> the root one has this that I don't have
<re_irc>
[alias]
<re_irc>
xtask = 'run -p xtask --'
<re_irc>
<Mehmet Ali> I think this springs up only for the nightly.
<re_irc>
<Mehmet Ali> And the blog/repo is for stable
<re_irc>
<Mehmet Ali> Cargo looks at the test crate's Cargo.toml and can't find a bin or a lib
<re_irc>
<Mehmet Ali> Maybe I can put "[[test]]" in the Cargo.toml?
<re_irc>
<Mehmet Ali> Couldn't make this work
dc740 has joined #rust-embedded
<re_irc>
<Mehmet Ali> Added this to ./.cargo/config.toml but same.
<re_irc>
<Mehmet Ali> kebab-case is fine for the folder structure right?
dc740 has quit [Remote host closed the connection]
<re_irc>
<williamskim> I'll help 10 people on how to earn $20,000 within 72 hours but you will pay me 10% of your profit when you receive it.
<re_irc>
Note: only interested people should apply, drop a message let's get started
<re_irc>
<Mehmet Ali> this was my bad. I had named the folder as src/ then tests/.
dc740 has joined #rust-embedded
<re_irc>
<thalesfragoso> Hmm, I just realized that under strict provenance we would probably need to manually patch all DMA address registers to have a type of say "*mut ()" instead of the bare "u32".
<re_irc>
cc dirbaio for opinions
<re_irc>
<dirbaio> converting ptr->int with ".expose_addr()" wouldn't be enough?
<re_irc>
<thalesfragoso> dirbaio: Hmm, what is that ?
dc740 has quit [Remote host closed the connection]
<re_irc>
<thalesfragoso> Oh, found it
<re_irc>
<thalesfragoso> It has this on the docs:
<re_irc>
> Using this method means that code is not following Strict Provenance rules.
<cr1901>
Maybe worth bring up to the lang group working on it?
<re_irc>
<dirbaio> under strict provenance, volatile-writing a pointer to a register means the hardware is free to write to that pointer?
<cr1901>
thalesfragoso: I'm not actually sure what the problem w/ DMA and provenance is. Could you elaborate?
<re_irc>
<thalesfragoso> dirbaio: Well, I would expect that writing the pointer to an "outside address" would be enough to rust realize that it escaped
<re_irc>
<dirbaio> hmhmmmhmhmh
<re_irc>
<thalesfragoso> cr1901: Basically, pointers have provenance, giving the integer representation of a pointer to "someone" doesn't give access to that memory location, and the compiler would be free to optimize around that
<re_irc>
<adamgreig> yea, I feel like so long as you make it clear the address has escaped it's no different from an FFI call
<cr1901>
Well, if you initially have the pointer, convert it to an int, I was under the impression that that's sufficient to give "someone" access to that memory location from compiler POV
<re_irc>
<thalesfragoso> cr1901: Not according to strict provenance rules
<re_irc>
<thalesfragoso> In that issue libc (glibc?) asks for a pointer as an integer
<cr1901>
what if you convert said int back to a pointer?
<re_irc>
<thalesfragoso> cr1901: You can convert it, but not read nor write
<cr1901>
I could've sworn provenance had "something to say" about casting from pointer and still having access to the memory
<cr1901>
ahhh well, guess I'll have to reread Ralf's blog post
<re_irc>
<adamgreig> thalesfragoso: in that case you pass an integer and the libc uses it as a pointer, which is bad, but the point is if you pass a _pointer_ to FFI it escapes, the same as if you call expose on it, and that's what the DMA op would need
<cr1901>
dirbaio: When you say "under strict provenance, volatile-writing a pointer to a register means the hardware is free to write to that pointer?" 1/2
<re_irc>
<adamgreig> so yea, you're right in that the DMA method in a HAL should take a *mut () or should otherwise arrange for escaping
<re_irc>
<dirbaio> I think "expose" would be correct
<cr1901>
does "the hardware" mean "the CPU" or "the DMA engine"?
<re_irc>
<dirbaio> but it's "stronger" than needed, so it could prevent optimizations
<re_irc>
<dirbaio> because if you "expose", then at every "from_exposed_addr" the compiler will take into account hte new ptr could alias to the previously exposed memory
<re_irc>
<thalesfragoso> cr1901: I think this strict provenance stuff is all kinda of experimental, and it's just trying to be very strict to conform with everything
<re_irc>
<James Munns> IIRC gankra has talked about MMIO, unsure about DMA
<re_irc>
<James Munns> Lokathor has chatted with her about it, I've seen a couple times.
<re_irc>
<James Munns> (in the context of strict provenance)
<re_irc>
<dirbaio> I think "exposing" is not "forever" though? it's just for the duration where stacked borrows would say the original ptr is valid (?)
<re_irc>
<dirbaio> so it's not that bad maybe (?)
<re_irc>
<thalesfragoso> dirbaio: I guess it's an escape hatch from the compiler point of view, but if the compiler would follow it strictly, then it wouldn't work
<re_irc>
<thalesfragoso> adamgreig: Yep, I think changing the register type to "*mut ()" would be enough
<re_irc>
<dirbaio> how does DMA work in CHERI machines?? 🤣😱
<re_irc>
<thalesfragoso> adamgreig: Why don't they mention expose on the solutions though ?
<re_irc>
<thalesfragoso> As I see, expose doesn't follow strict provenance
<re_irc>
<thalesfragoso> It's actually on its docs
<re_irc>
<thalesfragoso> adamgreig: I actually meant the pac should have the register type as "*mut ()"
<cr1901>
>thte new ptr could alias to the previously exposed memory <-- does this only apply for missed optimizations for reads (since shared XOR mutable except in a cell)?
<re_irc>
<thalesfragoso> > Using expose_addr or from_exposed_addr (or the equivalent as casts) means that code is not following Strict Provenance rules. The goal of the Strict Provenance experiment is to determine whether it is possible to use Rust without expose_addr and from_exposed_addr.
<re_irc>
<thalesfragoso> Ok, so this escape hatch would kinda work, but they're researching to see if it's possible to just not have them
<re_irc>
<thalesfragoso> Which I think we can live without it for DMA, right ?
<re_irc>
<thalesfragoso> Just involves some manual work...
<re_irc>
<firefrommoonlight> Subjective API question: Would you mark read and write functions to internal flash memory "unsafe" ? Reasoning to do that would be if you write over internal program memory, bad things/UB (likely program failing to run) will happen
<re_irc>
<firefrommoonlight> Or should that be assumed by default lol
<re_irc>
<firefrommoonlight> *Probably just mark "write" and "erase"; not "read"