ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <Lachlan> dirbaio: do you know how I might put the info at a set offset before the vector table, but such that it's still included in the flash image without changing the address of the entry point?
<re_irc> <dirbaio> I don't think you can put it before the vector table, because it has to be at offset 0
<re_irc> <dirbaio> (you can move the vector table with VTOR but it's very annoying, you need a bootloader and stuff)
<re_irc> <dirbaio> my snippet above puts it right at the start of .text, which is immediately after the vector table
<re_irc> <Lachlan> Ah, interesting
<re_irc> <dirbaio> which is a known offset because the vector table is fixed size
<re_irc> <Lachlan> Technically, I do have a bootloader
<re_irc> <dirbaio> +(for a given chip)
<re_irc> <Lachlan> So I'm fine with having to change VTOR/etc (already do)
<re_irc> <dirbaio> why doesn't "after vector table, fixed offset" work for you?
<re_irc> <Lachlan> It does, that's fine too
<re_irc> <dirbaio> one advantage is you can use the same thing for including the build info _in the bootloader_ :)
<re_irc> <dirbaio> vs if you moved the vector table you'd need a "bootloader for the bootloader"
<re_irc> <Lachlan> Ah, true!
<re_irc> <dirbaio> I do that, so my devices can self-report "bootloader version, application version" :D
<re_irc> <Lachlan> dirbaio: Fancy :)
<re_irc> <James Munns> I use a pretty similar trick for building an "image header" in mnemos: https://github.com/jamesmunns/pellegrino/blob/07bcbabf09c0d80208293ff1181c727062f72375/firmware/userspace/link.x#L101-L136
<re_irc> <James Munns> I don't have a vector table in my userspace, but you could do the same immediately after the vector table.
<re_irc> <dirbaio> my bootloader doesn't even have the irq vectors hehe
<re_irc> <Lachlan> The snippet earlier on results in the linker complaining about overlapping load addresses
<re_irc> <dirbaio> Lachlan: i've copypasted and edited the entire cortex-m-rt linker script
<re_irc> <dirbaio> dunno if it's possible to do it by "extending" it instead
<re_irc> <Lachlan> Ah
<re_irc> <James Munns> I think there's some hook for "after vector table, before text"
<re_irc> <dirbaio> maybe with INSERT AFTER / INSERT BEFORE, but that stuff is super cursed
<re_irc> <James Munns> I think the rp2040 uses it
<re_irc> <dirbaio> honestly copypasting it is way easier
<Darius> if you want to put some data in a specific location can't you frob the linker map?
<Darius> that's what I've done in C to put image info (version data etc) in a fixed location that tooling can read
<re_irc> <James Munns> (mnemos' linker script is also a copy/paste/edit of cmrt)
<re_irc> <dirbaio> and linker script never changes, I wouldn't say copypasting it is "bad" or "tech debt"
* Darius reads some more
<Darius> if it complains about overlapping addresses you need to trim the other region to fit it
<re_irc> <James Munns> nah, totally reasonable
<re_irc> <James Munns> you might just have to redo it if you update your cmrt version
<re_irc> <9names (@9names:matrix.org)> James Munns: We put stuff before vector table, not after it
<re_irc> <James Munns> ah!
causal has joined #rust-embedded
<re_irc> <Lachlan> I seem to have gotten it working by pointing "_stext" to after the build_info, and putting the build_info at an address directly after the vector table
<re_irc> <Lachlan> The reason why I wanted to put it before the vector table is because that would make checking the signature of the binary in the bootloader easier
<re_irc> <dirbaio> strange
<re_irc> <dirbaio> oof, signatures:D
<re_irc> <dirbaio> * signatures :D
<re_irc> <Lachlan> yeah
<re_irc> <dirbaio> nordic's stores it all out of band to avoid that problem, and I think mcuboot uses a "trailer" instead of a header
<re_irc> <dirbaio> might be worth exploring these
<re_irc> <Lachlan> The way I have it set up now stores it out of band
<re_irc> <Lachlan> It seemed like it had the potential to be simpler if I put it all in the binary, but probably not
<re_irc> <dirbaio> dunno!
<re_irc> <dirbaio> I did get the feel nordic's was overcomplicated, so I'm storing everything inline in mine. Not doing signatures/crcs though
<re_irc> <dirbaio> +(I check it at install time, not boot time)
<re_irc> <dirbaio> like, storing out of band feels more complicated/dangerous because it can easily get "desynced" :D
<re_irc> <dirbaio> +with what's really on the firmware partition
<re_irc> <Lachlan> Exactly
<re_irc> <dirbaio> welp, have fun
<re_irc> <Lachlan> Figured out how to put it before the vector table
<re_irc> <dirbaio> make sure to align the vector table, it has to be aligned to the next higher power of 2 of its size
<re_irc> <dirbaio> which can force you to waste quite a bit of space...
<re_irc> <Lachlan> So, like 512 bytes?
<re_irc> <dirbaio> maybe? :P
<re_irc> <dirbaio> yeah perhaps it's not that much if your flash is big
<re_irc> <Lachlan> Looks like the vector table is 664 bytes, so 1k should be enough
eigenform has quit [Ping timeout: 276 seconds]
eigenform has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
gsalazar has joined #rust-embedded
aspe has joined #rust-embedded
aspe has quit [Remote host closed the connection]
<re_irc> <emilgardis> https://reviews.llvm.org/D126835
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc> <matejcik> do you know what ".rodata..Lanon....." symbols are?
<re_irc> <James Munns> I think they are variable initializers?
<re_irc> <James Munns> like if you have:
<re_irc> foo: ...,
<re_irc> let data = Something {
<re_irc> bar: ...,
<re_irc> <James Munns> that initial value is stored in rodata
explore has joined #rust-embedded
<re_irc> <thejpster> There are a couple of Rust Embedded grant awards in the list.
<re_irc> <thejpster> I got one, and jannic got one.
<re_irc> <jamwaffles> Is there a nicer way of copying a sub-slice into a buffer? I currently have this which I'm not that happy with:
<re_irc> #![no_std]
<re_irc> pub fn stuff(input: &mut [u8], lil_bit: &[u8]) -> Result<(), ()> {
<re_irc> input.get_mut(0..lil_bit.len()).ok_or_else(|| ())?.copy_from_slice(lil_bit);
<re_irc> <jamwaffles> Is there a nicer way of copying a sub-slice into a buffer? I currently have this which I'm not that happy with:
<re_irc> #![no_std]
<re_irc> pub fn stuff(buf: &mut [u8], some_data: &[u8]) -> Result<(), ()> {
<re_irc> buf.get_mut(0..some_data.len()).ok_or_else(|| ())?.copy_from_slice(some_data);
<re_irc> <jamwaffles> "some_data" is pretty much always guaranteed to be smaller than "buf"
<re_irc> <jamwaffles> thejpster: Congrats! I'm now majorly regretting not applying 🙈 I have a perfect project for it 😭
<re_irc> <James Munns> TIL you can pass a range to "get_mut"
<re_irc> buf.get_mut(0..some_data.len())
<re_irc> .and_then(|b| b.copy_from_slice(some_data))
<re_irc> <James Munns> pub fn stuff(buf: &mut [u8], some_data: &[u8]) -> Result<(), ()> {
<re_irc> .ok_or_else(|| ())
<re_irc> <jannic> jamwaffles: There will be another round of project grants in October
Amadiro_ has quit [Ping timeout: 272 seconds]
<re_irc> <jamwaffles> Ah October. I've got a chance!
<re_irc> <James Munns> it's me, I'm clippy
<re_irc> <firefrommoonlight> Lol
<re_irc> <firefrommoonlight> James Munns: IIRC clippy will push you into this approach, and even give you a copy+paste of your specific code, eg if you were doing it by indexing instead
<re_irc> <James Munns> 📎
<re_irc> <firefrommoonlight> I don't remember the and_then stuff
<re_irc> <James Munns> nope
<re_irc> <jamwaffles> I like the "and_then" solution. I still don't feel great about "copy_from_slice" panicking but it can't if it's behind a checked "get_mut" so...
<re_irc> <jamwaffles> Thank you clippy ❤️
<re_irc> <firefrommoonlight> Could you change your name here for the benefit of those who don't see this chat segment?
<re_irc> <James Munns> Chances are it'll get optimized out
<re_irc> <James Munns> you do the check in get_mut
<re_irc> <James Munns> and when the compiler smooshes it all together, that panic will likely evaporate.
<re_irc> <James Munns> (compiler is good about removing duplicate bounds checks)
inara has quit [Quit: Leaving]
<re_irc> <James Munns> At least when they are that close in proximity to each other. Still not guaranteed I guess, but should go away at basically any opt level
<re_irc> <dirbaio> yeah, just use indexing if you know the data fits. Much more readable
<re_irc> <jamwaffles> Godbolt sez... things (https://godbolt.org/z/o68fozY3W)
<re_irc> <Lachlan> My work has literally every clippy lint turned on—can be quite pedantic
<re_irc> <jamwaffles> For armv7 if I'm reading it correctly it has a panic jump, but for x64 it doesn't
<re_irc> <firefrommoonlight> Btw, if you know the size of the buffer / don't need the error checking:
<re_irc> buf[0..len].copy_from_slice(some_data);
<re_irc> pub fn stuff(buf: &mut [u8], some_data: &[u8], len: usize) {
<re_irc> }
<re_irc> <Lachlan> You’d do some_data.len() in that case
<re_irc> <firefrommoonlight> Yep, before passing it to the fn
<re_irc> <firefrommoonlight> and can error check before passing it in
inara has joined #rust-embedded
<re_irc> <firefrommoonlight> *WAIT nvm you can do it in the fn
<re_irc> <Lachlan> My point is that len is required to be the same as some_data’s length, so it’s not useful to have it as a separate argument
<re_irc> <Lachlan> yes :)
<re_irc> <firefrommoonlight> pub fn stuff(buf: &mut [u8], some_data: &[u8]) {
<re_irc> buf[0..some_data.len()].copy_from_slice(some_data);
<re_irc> }
<re_irc> <firefrommoonlight> Good catch
<re_irc> <James Munns> That's different hto
<re_irc> <James Munns> that copies the smallest subset
<re_irc> <firefrommoonlight> Since it doesn't check the len and could panic?
<re_irc> <jamwaffles> That's what I want 🙂
<re_irc> <James Munns> it wont panic, but you won't get an error on the wrong case :)
<re_irc> <firefrommoonlight> Gotcha
<re_irc> <jamwaffles> I'm building up pieces of an ethernet payload, so "buf" will always be bigger than "some_data"
<re_irc> if some_data.len() <= stuff.len() {
<re_irc> let sub = stuff.get_unchecked(0..some_data.len();
<re_irc> <James Munns> This is what the compiler sees (ish), btw:
<re_irc> // The compiler can infer this check is never false
<re_irc> <James Munns> (that's why the panic goes away)
<re_irc> <dirbaio> jamwaffles: huh strange that the panic doesn't get optimized away
<re_irc> It does if you use an "if" instead lol https://godbolt.org/z/naooPndo4
<re_irc> <jamwaffles> And it does if you remove "--target" which is very interesting
<re_irc> <Lachlan> Anyone want to make an issue on the rust repo about the missed optimization here?
<re_irc> <firefrommoonlight> dirbaio: I kind of agree here, mainly because it makes the code more language-agnostic. Ie more readable for people already familiar with C etc but not Rust
<re_irc> <firefrommoonlight> While "copy_from_slice" requires looking up docs
<re_irc> <James Munns> oh that's dumb:
<re_irc> <James Munns> (it should have been "map", not "and_then", btw)
<re_irc> <dirbaio> firefrommoonlight: I meant indexing to slice the buf, then "copy_from_slice" into it.. How'd you copy without "copy_from_slice"? :D
<re_irc> <firefrommoonlight> pub fn stuff(buf: &mut [u8], some_data: &[u8]) {
<re_irc> buf[0..some_data.len()].copy_from_slice(some_data);
<re_irc> for i in 0..some_data.len() {
<re_irc> buf[i] = some_data[i];
<re_irc> <dirbaio> ah, a "for" lol
<re_irc> <firefrommoonlight> (Could panic if you don't know the lens)
<re_irc> <firefrommoonlight> pub fn stuff(buf: &mut [u8], some_data: &[u8]) {
<re_irc> for i in 0..some_data.len() {
<re_irc> }
<re_irc> }
<re_irc> buf[i] = some_data[i];
<re_irc> <firefrommoonlight> This is a more universal approach IMO, but James objects
<re_irc> <jamwaffles> This is quite far down this application's stack so I could certainly panic, but I'd prefer to make it fallible for now, even if I can make it simpler later
<re_irc> <jamwaffles> And this app is a Rust replacement for a C incumbent so the less readable it is for C devs the better 😉
<re_irc> <firefrommoonlight> lol. I think about this stuff because I've been doing a lot of C->Rust translation
<re_irc> <dirbaio> "copy_from_slice" optimizes better though, thanks to doing a single bounds check upfront https://godbolt.org/z/s6sqGWKd6
<re_irc> <firefrommoonlight> Oh neat. Concrete adv
<re_irc> <James Munns> hello yes I am a C programmer and all I know is "memcpy":
<re_irc> pub fn stuff3(buf: &mut [u8], some_data: &[u8]) -> Result<(), ()> {
<re_irc> if buf.len() >= some_data.len() {
<re_irc> unsafe { core::ptr::copy_nonoverlapping(some_data.as_ptr(), buf.as_mut_ptr(), some_data.len()); }
<re_irc> <James Munns> (this optimizes to the same as dirbaio's if statement
<re_irc> <James Munns> https://godbolt.org/z/3xxn7Paxc
<re_irc> <jamwaffles> Gnarly
<re_irc> <jamwaffles> I think I'll go for "it's ok" for now and optimise it down to the wire later 😉
<re_irc> <James Munns> (copy from slice is basically just copy_nonoverlapping with a check the lens are equal anyway)
<re_irc> <Lachlan> James Munns: Imagine how bad this would be if rust had move constructors
<re_irc> <James Munns> I am blissfully unaware
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <James Munns> (I spent 10 years trying unsuccessfully to learn C++)
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc> <adamgreig> hi room! meeting time again, agenda is https://hackmd.io/fnRopLZWQ2emoDVRNbMKFA, please add anything you'd like to announce or discuss!
<re_irc> <adamgreig> it's been another quiet week so may be a fairly brief meeting
<re_irc> <adamgreig> ok, let's start! I don't have any announcements for this week, anyone else?
<re_irc> <therealprof> Grants maybe? 😉
<re_irc> <newam> I saw something about the 2040 in those grants :D
<re_irc> <James Munns> I got one (announcement)!
<re_irc> <James Munns> Postcard has alpha releases for 1.0! https://crates.io/crates/postcard
<re_irc> <adamgreig> ooh, is there a link for the grants?
<re_irc> <James Munns> Most of the breaking changes for the wire format there, and I'd love for everyone to try it!
<re_irc> <James Munns> I'll be shipping the "real" 1.0 by monday (the 20th) at the LATEST, so if you could take it for a spin and report any bugs, I'd appreciate it!
<re_irc> <thejpster> Jannic got a grant for RP2040 work and Debian/Rust work. I got one to make 30 Neotron boards.
<re_irc> <therealprof> And some adamgreig is listed as mentor. 😉
<re_irc> <adamgreig> not a mentor, just helped review!
<re_irc> <James Munns> Also, there is a written wire format spec now, feel free to give it a read and let me know if you find anything confusing! https://postcard.jamesmunns.com/
<re_irc> <adamgreig> or am I also a mentor now 😬
<re_irc> <James Munns> (working on the "alpha.3" release right now, fixing some known bugs, should be out in the next few hours, but don't wait!)
<re_irc> <James Munns> (that's all, thanks!)
<re_irc> <therealprof> Oh, only an expert advisor. Never mind then...
bjc` has joined #rust-embedded
<re_irc> <therealprof> 😁
VShell has joined #rust-embedded
<re_irc> <adamgreig> thanks James Munns, nice work!
<re_irc> <adamgreig> and congrats thejpster and jannic on the grants :D
<re_irc> <James Munns> (oh, and I'm also working on getting the "cobs" crate to 1.0 as well, if you have any desires/bugs with _that_, lemme know too :D)
<re_irc> <James Munns> (no more "postcard-cobs v0.1.5-pre" :D
<re_irc> <adamgreig> for once I don't think I actually have anything else to discuss, no updates on cortex-m or embedded-hal afaik
vancz_ has joined #rust-embedded
<re_irc> <adamgreig> anyone else have anything we need to talk about this week?
starblue has quit [*.net *.split]
bjc has quit [*.net *.split]
vancz has quit [*.net *.split]
Shell has quit [*.net *.split]
<re_irc> <James Munns> 🦗
<re_irc> <adamgreig> a quiet week! I usually check all the rust-embedded github notifications since last week but barely any this time around
starblue has joined #rust-embedded
<re_irc> <adamgreig> I'll need to throw some bikeshed bombs into the mix this week :P
<re_irc> <therealprof> Yeah, tons of non-embedded stuff to do I'm afraid.
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
<cr1901> Crap. I missed the meeting b/c I was distracted ._.
<re_irc> <adamgreig> wasn't much to miss this week!
<re_irc> <firefrommoonlight> Thoughts on stm32 PAC rel?
<re_irc> <firefrommoonlight> Eg fix certain G0 variants
<re_irc> <adamgreig> sorry, that's long overdue, "yes"
sknebel_ has joined #rust-embedded
agg has quit [*.net *.split]
sknebel has quit [*.net *.split]
agg has joined #rust-embedded
sknebel_ is now known as sknebel
VShell is now known as Shell
<re_irc> <Lachlan> Does anyone know why the HASH processor on the stm32h7 isn't exposed in the rust pac for it?
<re_irc> <dirbaio> which chip?
<re_irc> <Lachlan> stm32H743IIT6
<re_irc> <Lachlan> I didn't expect it in the hal, but I was surprised to see it wasn't in the pac either
<re_irc> <dirbaio> it doesn't have HASH
<re_irc> <Lachlan> The datasheet I'm looking at says it does
<re_irc> <dirbaio> they "merge" multiple chips in the RMs, a RM documenting a peripheral doesn't mean all matching chips have it
<re_irc> <Lachlan> Ah, I see
<re_irc> <Lachlan> That's frustrating, I would up the reference manual would say which chips have it and which don't
<re_irc> <Lachlan> * hope
<re_irc> <dirbaio> yeah they usually do..
<re_irc> <dirbaio> for 100% accurate info you have to check the datasheets, which are more granular
<re_irc> <dirbaio> (or the C headers or stm32cubemx)
<re_irc> <dirbaio> yeah they usually do.. not in this case it seems :(
<re_irc> <Lachlan> Well, thank you for the help
<re_irc> <dirbaio> or on the website
<re_irc> <dirbaio> * the website sometimes gives clues about the part numbering
<re_irc> <dirbaio> h743 = no crypto, h753 = crypto
<re_irc> <Lachlan> Ah, interesting
<re_irc> <Lachlan> Huh
<re_irc> <Lachlan> I'll complain to one of our EEs about that