05:19 <re_irc> <chrysn (@chrysn:matrix.org)> As faern mentioned firmware updates: Has anyone implemented any part of SUIT in embedded Rust yet? It'd be a well-vetted data format and security mechanism on top of any platform specific OTA, but I've neither found anything in a direct crates.io search nor in dependents of COSE crates.

05:20 <re_irc> <chrysn (@chrysn:matrix.org)> (SUIT as in RFC9124 and the follow-up yet-unfinished documents such as suit-manifest (https://www.ietf.org/archive/id/draft-ietf-suit-manifest-19.html))

05:26 <re_irc> <MathiasKoch> While not implementing SUIT, i think i have a lot of overlap in the OTA part here: https://github.com/BlackbirdHQ/rustot (intended to target AWS IoT OTA)

05:27 <re_irc> <MathiasKoch> Without any further knowledge of SUIT, other than skimming the RFC you just linked

05:28 <re_irc> <MathiasKoch> After reading further, probably not. It looks like SUIT is not the actual OTA process?

05:30 <re_irc> <chrysn (@chrysn:matrix.org)> SUIT is the manifest format; it can be implemented on any transport without depending on the transport's security properties. (Like, same data could go over CoAP, MQTT or just a USB stick).

05:31 <re_irc> <MathiasKoch> Ahh, cool 👍️

06:58 <re_irc> <lulf> SUIT looks like something that would suit (hah) drogue iot, I didn't know about that RFC. Instead invented our own CBOR based protocol 🤪

07:03 <re_irc> <chrysn (@chrysn:matrix.org)> Quite frankly I saw this as an opportunity to plug this to a crowd which I hoped would like it ;-)

07:13 <re_irc> <MathiasKoch> I would absolutely consider changing my manifest format in rustot as well, if a SUIT crate was available :p

07:17 <re_irc> <MathiasKoch> Currently we just went with the format they used in freertos, but there is no actual reason for choosing that, apart from having to invent one myself

07:23 <re_irc> <chrysn (@chrysn:matrix.org)> I've seen people from ARM/mbed, Microsoft, Nordic and RIOT during the SUIT development discussion list, but nobody from FreeRTOS was around. Let's hope that no features of their format were missed out.

07:26 <re_irc> <MathiasKoch> FreeRTOS would today be AWS, but as they are not on your list either it probably comes down to the same :p

07:26 <re_irc> Quickly glancing over SUIT, I don't see anything that shouldn't be implementable on top of the AWS managed OTA service either.

13:41 <re_irc> <thejpster> Woot!

13:41 <re_irc> https://doc.rust-lang.org/core/ffi/index.html

13:42 <re_irc> <thejpster> Rust 1.64 is out now :)

13:42 <re_irc> https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html

13:43 <re_irc> <thejpster> Can finally get rid of this nonsense: https://github.com/nrf-rs/nrfxlib-sys/blob/develop/src/lib.rs#L6

13:43 <re_irc> It makes bindgen for embedded rust so much nicer.

13:47 <re_irc> <James Munns> Posted about the Final Friday Showcase, retweets (and submissions!) appreciated: https://twitter.com/rustembedded/status/1572945559769563138

17:22 <re_irc> <dirbaio> has anyone seen this error when clicking "Run test" above a test in rust-analyzer?

17:22 <re_irc> * Executing task: cargo test --package ekv --lib -- file::tests::test_read_write --exact --nocapture

17:22 <re_irc> * The terminal process failed to launch: Path to shell executable "cargo" is not a file or a symlink.

17:22 <re_irc> <dirbaio> it started happening randomly, I don't think I changed anything :S

17:23 <re_irc> <dirbaio> cargo is "/usr/bin/cargo", I do have it in "$PATH"

17:33 <re_irc> <dirbaio> this fixes it: ""rust-analyzer.runnables.command": "/usr/bin/cargo","

17:33 <re_irc> <dirbaio> but _why??_ and why did it break?? 🤷

19:37 <re_irc> <datdenkikniet> 1.64 now ships rust-analyzer, maybe that's somehow creating some sort of collision (assuming you even updated)?

19:38 <re_irc> <datdenkikniet> * updated and it somehow was installed through rustup)?

19:38 <re_irc> <datdenkikniet> which would be strange and probably doesn't explain the issue, but 🤷

19:47 <re_irc> <SEGFAULT> how do I make gdb / openocd flash the device?

19:47 <re_irc> <SEGFAULT> (target is stm32f4)

20:05 <re_irc> <James Munns> did you use "load path/to/binary.elf"?

20:05 <re_irc> <James Munns> SEGFAULT ^

20:05 <re_irc> <SEGFAULT> let me check my gdb init file, cos the problem I am having is its not sticking after a debug session

20:06 <re_irc> <SEGFAULT> this is my openocd.gdb file: target remote :3333

20:06 <re_irc> monitor arm semihosting enable

20:06 <re_irc> detect unhandled exceptions, hard faults and panics

20:06 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/901686f04975d8aca3ada4c68b0e4c4251deb3fac13886b503f1521d72b5db69 (8 lines)

20:06 <re_irc> set print asm-demangle on

20:07 <re_irc> <SEGFAULT> this is my openocd.gdb file:

20:07 <re_irc> set print asm-demangle on

20:07 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/85075420465e50ce660f3192e2f8602cf000e955f74b4e1e4440fca51ff78e16 (9 lines)

20:07 <re_irc> target remote :3333

20:07 <re_irc> monitor arm semihosting enable

20:07 <re_irc> <James Munns> My typical gdb script usually looks like:

20:07 <re_irc> target remote :xxxx

20:07 <re_irc> monitor reset halt

20:07 <re_irc> load path/to/binary.elf

20:07 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/8b8547798a5b746e58eadc9bd19c3fec884959ea714e64ab63092c5d11f42fac (6 lines)

20:07 <re_irc> <James Munns> I dunno if "load" by itself is enough? But also I am a nub at gdb.

20:08 <re_irc> <James Munns> maybe if you provide the elf path on gdb invocation

20:08 <re_irc> <SEGFAULT> its possible I also screwed my regions up and uploaded to ram?

20:08 <re_irc> <James Munns> I mean, you can also upload to RAM with openocd

20:09 <re_irc> <SEGFAULT> where _is_ the binary that gdb loaded?

20:09 <re_irc> <James Munns> how are you invoking gdb?

20:09 <re_irc> <SEGFAULT> sorry tired, I meant to say the one that cargo spits out of build

20:10 <re_irc> <James Munns> probably "target/thumbvxxx-none-eabi-hf/(release|debug)/program-name"

20:11 <re_irc> <SEGFAULT> I am running the load command now, its taking a lot longer than I expected

20:15 <re_irc> <SEGFAULT> yea that worked

20:15 <re_irc> <SEGFAULT> load started execution which was unexpected

20:35 <re_irc> <James Munns> I can't remember, one of the debuggers (stlink? daplink?) does that. There's some inconsistencies between jlink/daplink/stlink

20:35 <re_irc> <James Munns> also between "mon reset" and "mon reset halt"

21:09 <re_irc> <SEGFAULT> it didn't work it "forgot" the firmware after being powered off for more than a few seconds

21:09 <re_irc> <James Munns> Look at your linker script?

23:17 <re_irc> <SEGFAULT> What am I looking for?

23:21 <re_irc> <James Munns> Does your "memory.x" file define the "FLASH" region in RAM or FLASH regions?