<ian_rees[m]>
linker question: is there a downside to a firmware having "-C", "link-arg=-Tdefmt.x", in the Cargo rustflags, when defmt is not used?
<ian_rees[m]>
I'd like to add feature-gated defmt support to HAL examples, ideally without the end user needing to fiddle with .cargo/config.toml
ello has quit [Ping timeout: 265 seconds]
ello has joined #rust-embedded
<ian_rees[m]>
ah, sorry that was a dumb question: if there's not a linker script defmt.x , the build errors out
sroemer_ has quit [Ping timeout: 252 seconds]
ello has quit [Read error: Connection reset by peer]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
ello has joined #rust-embedded
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
stgl has joined #rust-embedded
cinemaSundays has joined #rust-embedded
cinemaSundays has quit [Quit: Connection closed for inactivity]
ello has quit [Ping timeout: 252 seconds]
ello has joined #rust-embedded
ello has quit [Ping timeout: 265 seconds]
ello has joined #rust-embedded
<bartmassey[m]>
Not dumb. I also really want feature-gated rustflags for a project we are working on. Cargo should maybe figure out a better plan for this kind of stuff.
<GuineaWheek[m]>
cargo is kinda kludgy for embedded ngl
<GuineaWheek[m]>
there are a lot of things in cargo that would make embedded way easier if they could be feature-configurable
<GuineaWheek[m]>
but i think cargo development is too scared to make a build system that ends up like some atrocity like gradle
ello has quit [Ping timeout: 248 seconds]
<chrysn[m]>
<thejpster[m]> "Tock, Ariel, Linux, Zephyr - all..." <- We do have some 1:1 contacts, and some individual overlaps in each others' channels (I'm occasionally reading up on the MnemOS room, and I don't know how often he's really there, but a colleague from the RIOT project has his Zephyr kite visibly behind his desk :-) ).
<chrysn[m]>
Not sure if a team is the right tool, whether a Matrix channel is, or anything else.
<chrysn[m]>
s/Not sure if a team is the right tool, whether a Matrix channel is, or anything else./More communication would be good; not sure if a team is the right tool, whether a Matrix channel is, or anything else./
<chrysn[m]>
(Context: Once more I've updated a crate that has write implementations for a gazillion CBOR writers and their versions, and with an embedded-io 1.0 it'd be way easier to ask them to pretty please just accept any impl embedded_io::Write.)
pcs38 has joined #rust-embedded
Kaspar[m] has joined #rust-embedded
<Kaspar[m]>
<GuineaWheek[m]> "cargo is kinda kludgy for..." <- Yeah ... In Ariel OS, we wrap Cargo in [laze](https://laze-build.org), to handle all the different target hardware needs. `--target`, runner, all the different linker options, `PROBE_RS_CHIP`, target-specific features & dependencies, ... With plain cargo it is really difficult to keep track of all of that, especially in distributed development settings.
<diondokter[m]>
I don't think there's a way to override this in cortex-m-rt, right?
<M9names[m]>
you can always patch the file before you program it
<diondokter[m]>
Hmmm yeah, that's possible. But then it's a two-step process which can't be done in cargo alone
<diondokter[m]>
We may need to do that anyways though since there's some CRC support too we'd like to use
<JamesMunns[m]>
You might be able to PROVIDE the value in the table from the linker? not sure
<diondokter[m]>
Not sure, cortex-m-rt already fully defines it and sets it to 0
<diondokter[m]>
Unless the linker can override that again...
<M9names[m]>
what sort of data is it shoving into those vectors?
<diondokter[m]>
Image length, image type and 'offsetToCertificateBlockInBytes'
<JamesMunns[m]>
ohhh, it's in the base exception part of the table, not the normal interrupt part of the table, got it
<diondokter[m]>
Basically they saw reserved and thought "free realestate!"
<diondokter[m]>
JamesMunns[m]: Yes
<diondokter[m]>
s/realestate/real-estate/
<M9names[m]>
how do you know the image length before you've compiled? or is it the limit of image length?
<diondokter[m]>
Then another later vector is the load address
<diondokter[m]>
M9names[m]: That could just be populated by `_etext` of whatever the symbol is for the end of text
<M9names[m]>
i have 1 other messed up solution to this problem: you have a flash algo that calculates it and replaces the value on the fly while programming
<diondokter[m]>
Or I guess _etext - _stext
<diondokter[m]>
M9names[m]: Ha, well that is properly cursed. I like it :P
<M9names[m]>
please don't like it too much, probe-rs --verify disagrees with my methods
<diondokter[m]>
But you're right, this might just need to be a two-step solution sadly. Likely can't do the CRC at link-time anywyas
<diondokter[m]>
s/anywyas/anyways/
<diondokter[m]>
If only Cargo had a post-build.rs
<M9names[m]>
i wish it weren't, it's always painful when you need to do this.
<M9names[m]>
> If only Cargo had a post-build.rs
<M9names[m]>
or maybe... probe-rs could grow a --prerun? 😈
<diondokter[m]>
I'm already happy with the new(-ish?) --preverify flag
<diondokter[m]>
So much saved flashing
<danielb[m]>
so nice to hear it wasn't wasted work
<danielb[m]>
probe-rs probably shouldn't do much image manipulation, though, it's not its job :)
<diondokter[m]>
Just do something cursed like providing hooks and lua scripting :P
<diondokter[m]>
/sarcasm
<danielb[m]>
you're just trying to give me nightmares I think
<danielb[m]>
to be fair probe-rs does some image manipulation for esp32, we even prepend a complete bootloader - which is something I really want to remove. but if the thing you want to do is somewhat standard-ish, you can introduce a new image format that does the transformation
<diondokter[m]>
Yeah no I agree probe-rs shouldn't do anything here. Also from a reproducibility pov
<adamgreig[m]>
having probe-rs append a crc would be pretty cool though...
<diondokter[m]>
adamgreig[m]: Yeah, but it's full of technicalities...
<diondokter[m]>
Where should the CRC be stored? How many bits? Which regions should be included in the CRC?
<diondokter[m]>
* bits? Which polynomial? Which regions should
<adamgreig[m]>
and what crc, how long, what params...
<adamgreig[m]>
but all things you could have a decent guess at tbh
<adamgreig[m]>
bzip2 crc32 stored in the four bytes after the end of text, containing the whole text region,
<adamgreig[m]>
for sure some sort of hook would be a more general way to do it though
<diondokter[m]>
Ok but, that wouldn't work for me because the built-in bootloader expects something else
<adamgreig[m]>
oh yea, it's not helpful for your thing
<adamgreig[m]>
having the crc at the end is nice if the firmware wants to check its own validity but not so helpful for a bootloader that needs to know the length or where it can find the length
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has joined #rust-embedded
<Noah[m]>
Hmm that actually sounds like a dope thing to have!
<Noah[m]>
would be cool if you could tell the linker even how to do this
<adamgreig[m]>
Yea ideally the linker could be told via a linker script
<adamgreig[m]>
A lot of commercial embedded tool chains add things like that
<adamgreig[m]>
msp430 can make a new section that's got start and end addresses of every memory section and their checksum, so your fw can go to that table and then go through and verify everything
<adamgreig[m]>
wonder if probe-rs could use the crc for pre-verify... hard without support from the flash stubs though
<adamgreig[m]>
ideally you'd have the chip compute a fresh crc over the range you're about to program and compare it, must be way faster than sending all the flash contents over the debug link, but...
<danielb[m]>
I think Verify has been designed with flash encryption in mind
<danielb[m]>
if you can CRC arbitrary ranges, you can effectively read back encrypted flash
<JamesMunns[m]>
my $0.02: We should absolutely have a tool that does this, we should absolutely not put it in cursed custom linker script stuff lol
<danielb[m]>
or if not encrypted, then readout protected
<JamesMunns[m]>
We should make a toml file or cli args that describes the action, if it's probe-rs doing it :D
<danielb[m]>
aand somehow do it in a way that a hypothetical gdb load implementation will understand it
<Noah[m]>
danielb[m]: we can implement load however we want :)
<adamgreig[m]>
danielb[m]: aah neat
<adamgreig[m]>
from my rough understanding don't you have to send all the desired flash contents to the chip for that cmsis thing and then the chip compares? didn't know there could be a way to only send/receive a crc
<danielb[m]>
what?
<danielb[m]>
you need to send down the flash contents, and the chip tells you whether it matches
<danielb[m]>
my conjecture is that this is done to prevent reading back things you shouldn't be able to
<adamgreig[m]>
yea
<adamgreig[m]>
but imagine if you could just send down a crc of the flash contents
<adamgreig[m]>
and then the chip computes its own crc onboard and tells you if they matched
<adamgreig[m]>
presumably a lot more time is spent sending flash contents over the wire than reading them on-chip, so it could be a lot faster
<adamgreig[m]>
but it's not a cmsis function so we don't have algorithms for it and it would probably differ a lot chip-to-chip, so it doesn't sound like something that could easily be done
<danielb[m]>
you don't really want false positives though
<adamgreig[m]>
1 in 4-billion odds with a crc32, or go nuts and use a crc64
<JamesMunns[m]>
danielb[m]: does it make you verify the WHOLE flash?
<JamesMunns[m]>
because if not, then can't you brute force one byte at a time with readout protection enabled?
<danielb[m]>
okay my experience with custom flash algo additions is that nobody implements them
<danielb[m]>
we don't have --verify working on RP2040 because nobody implemented it
<JamesMunns[m]>
:D
<danielb[m]>
we don't have it working on chips with external flash because nobody implements what's needed
<danielb[m]>
so we can dream up a CRC checker but it will exist for at most three chips
<adamgreig[m]>
yea, I agree, it's not practical for that reason
<adamgreig[m]>
but would be so fast
<danielb[m]>
and how would you CRC-check encrypted flash?
<JamesMunns[m]>
have the flash algo load the private key from the otp area, use it to decode the external flash, and provide the CRC back? but if you have the ability to execute a flash algo then there's basically no point to encrypted flash?
<danielb[m]>
hmm that's a good point for me to double-check in esp-land
<JamesMunns[m]>
Like, maybe for development time, but if you care enough to encrypt flash I'd imagine you'd also burn the swd/jtag fuses
<JamesMunns[m]>
like, flash algos are the definition of "arbitrary code execution"
astennumero[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
<adamgreig[m]> "ideally you'd have the chip..." <- segger has this as an option, can confirm that it is much faster
<M9names[m]>
Certainly would be a good choice for slow debug probes
<danielb[m]>
well if someone wants to implement it, I won't say no
<Koen[m]>
Oh, but no TLS for no-std environments :/
<Koen[m]>
* no TLS *verification* for no-std
<joelsa[m]>
Ah thank you, this looks really ergonomic and is what I was looking for
<thejpster[m]>
<diondokter[m]> "If only Cargo had a post-build..." <- For Neotron OS, I wrote an xtask (that I called `nbuild`) which manages the build for me. I have to build the OS, the applications, a disk image containing and application, and then a final UF2 or binary files containing the OS and the disk image.
<thejpster[m]>
Maybe there should be a library for making it easier to write a build-wrangling xtask.
<diondokter[m]>
Yeah I worked for a client once that used xtask. It worked... but it wasn't pretty
mabez[m] has joined #rust-embedded
<mabez[m]>
`xtask` works pretty well for us in esp-hal. We do need to refactor the xtask itself a bit though, after year or so of adding new features organically it could do with a bit of a clean up :D.
<mabez[m]>
A library that took care of the build parts (including building docs etc) in particular would be really nice, we have quite a bit of boiler plate for handling invoking cargo etc which probably isn't esp specific at all
<mabez[m]>
Another problem (which again could be resolved with a shared library, or a common interface) is that people know cargo, but xtask always different depending on the project, which adds a bit of friction to contributing
<JamesMunns[m]>
<diondokter[m]> "Yeah I worked for a client..." <- I think there's an art to xtask, I've seen really useful ones, and ones that ended up being really clunky :p
<JamesMunns[m]>
JamesMunns[m]: (same as any tooling, really)
KenMatsui[m] has joined #rust-embedded
<KenMatsui[m]>
<thejpster[m]> "> <@kenmatsui1:matrix.org> Hi..." <- May I know how?
<thejpster[m]>
You can't use ptr::read_volatile and ptr::write_volatile for MMIO because LLVM sometimes picks a non-obvious assembly instruction and the Hypervisor was relying on looking at the machine code to work out which register the OS was trying to read or write.
<thejpster[m]>
(I guess, you can't in an OS running on a hypervisor that traps MMIO accesses)
<thejpster[m]>
s/looking at the machine code/looking at the exception syndrome register/
<diondokter[m]>
Last RustNL unconf Amanieu said they wanted to create a new `mmio_read` and `mmio_write` for this.
<thejpster[m]>
or ... you could write manual assembly routines for all the primitive integers and use those to do reads and writes
<diondokter[m]>
Well yeah. But then you need to fork everything to make it work with that
mkj[m] has joined #rust-embedded
<mkj[m]>
<thejpster[m]> "You can't use ptr::read_volatil..." <- from a fairly uninformed perspective, does the hypervisor need to be cleverer at reading machine code?
<thejpster[m]>
we're currently trying to work out if we can avoid having both derive-mmio and safe-mmio as they appear to (now, with this PR) trying to do the same job. That is, give you access to fields without creating references.
<thejpster[m]>
<mkj[m]> "from a fairly uninformed..." <- the hypervisor is relying in the processor reporting details about the failed instruction and (reading notes) arguably it's a bug in the AArch64 ISA, but we are where we are, and we need to teach LLVM to use instructions for MMIO that the processor handles correctly.
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<dirbaio[m]>
oooo mmio with rawasm
<dirbaio[m]>
s/rawasm/raw asm/
<dirbaio[m]>
I think you have to tell it it clobbers mem? I gave that a try a while ago and found it made it generate worse code, because that prevents reordering with any mem access, not just othermmio/volatile accesses.
<dirbaio[m]>
s/othermmio/other mmio/
<dirbaio[m]>
and also it can't generate stuff like ldr r0, [r1, #4]
<dirbaio[m]>
so I think the real fix would have to be adding "mmio read/write" ops to llvm, you can't emulate them yourself with asm without losing perf :(
AshconMohseninia has quit [Quit: Idle timeout reached: 172800s]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
<thejpster[m]>
well the most correct answer is fix the AArch64 ISA, but that isn't happening, so the second correct answer is to fix LLVM.
<thejpster[m]>
whether that will happen or not, who knows
<thejpster[m]>
I hope the project's embedded working group will have opinions about what the compiler does when used for embedded things
cr1901_ is now known as cr1901
<dirbaio[m]>
yeah...
<dirbaio[m]>
the problem is volatile's semantics are "lol who knows"
<dirbaio[m]>
so "fixing" them is probably controversial because you might argue they weren't intended for mmio in the first place ;D
<dirbaio[m]>
vs if you add first-class support for "MMIO memory access" then fixing that should be uncontroversial
<dirbaio[m]>
dunno
posborne[m] has quit [Quit: Idle timeout reached: 172800s]
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]>
thejpster: Is there a reason the undefined/abort/prefetch handler in cortex-ar use an asm default handler instead of a (user-provided) C default handler similarly to the IRQ handler? I just had a sample program where a division by zero was performed. I think my program is probably in some exception handler, but I can not pause/step anymore.
<RobinMueller[m]>
* was performed (accidentaly). I
pcs38 has quit [Quit: leaving]
<thejpster[m]>
they didn't have stacks set up so there wasn't much I could do. Also I was worried that stacking all the registers like you do for an interrupt handler might damage some state you need to work out *why* you'd aborted or hit a UDF. So I let the user write their own.
<thejpster[m]>
If there's a standard set of things to do, and we could hand them a structure containing details about why the fault occurred, that would be a nice to have.
<thejpster[m]>
My debug scripts set a breakpoint on every exception vector, so I can easily see if I trip one.
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
pcs38 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
cr1901_ is now known as cr1901
ejpcmac[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
<ian_rees[m]>
<bartmassey[m]> "Not dumb. I also really want..." <- t-moe: unfortunately there doesn't seem to be a way to cause build.rs to be run when features change. It's a neat idea though, and has me wondering if I could make build.rs generate an empty defmt.x that gets overwritten by whatever defmt magic creates the linker file later on? Will tinker with this more later