00:03 <re_irc> <@whitequark:matrix.org> _stares at probe-run_

00:03 <re_irc> <@whitequark:matrix.org> fn analyze_vector_table(core: &mut Core) -> anyhow::Result<(u32, u32)> {

00:03 <re_irc> let stack_start = core.read_core_reg::<u32>(SP)?;

00:03 <re_irc> I do not think that does what it says it does.

00:03 <re_irc> let reset_address = cortexm::set_thumb_bit(core.read_core_reg::<u32>(PC)?);

00:05 <re_irc> <@whitequark:matrix.org> (I checked, it was like that in the very first commit that introduced either the name or the code)

00:06 <re_irc> <@jamesmunns:beeper.com> just because it's getting the measured pc/sp instead of the values from the actual code image/vector table?

00:06 <re_irc> <@whitequark:matrix.org> yes

00:06 <re_irc> <@jamesmunns:beeper.com> I think they halt on start before reading that?

00:07 <re_irc> <@jamesmunns:beeper.com> "get values that normally live in the vector table"? :p

00:07 <re_irc> <@whitequark:matrix.org> I implemented most of https://github.com/knurling-rs/probe-run/issues/354 and this is the one place where there are issues still

00:08 <re_irc> <@whitequark:matrix.org> it doesn't make much of a difference one way or another in the current implementation, largely by a series of coincidences

00:09 <re_irc> <@jamesmunns:beeper.com> Yeah, I don't know all of the decisions that went into that. I wonder what rtt-host does. I think it might actually scan for the rtt block? But if you're attaching (and promise that the elf is what is currently running), I dunno why you wouldn't just pull those values from the elf

00:10 <re_irc> <@whitequark:matrix.org> no idea! I think it may predate elf analysis

00:10 <re_irc> <@whitequark:matrix.org> in any case I'll just fix it up to do what it says on the tin

00:11 <re_irc> <@jamesmunns:beeper.com> Maybe! probe-run always used the elf tho to store the interned data, and I think (maybe later?) get line numbers from debuginfo

00:11 <re_irc> <@whitequark:matrix.org> ahh huh

00:11 <re_irc> <@jamesmunns:beeper.com> : Either way, they'll probably appreciate that :D

00:12 <re_irc> <@whitequark:matrix.org> oh I forgot probe-rs has its own channel

00:14 <re_irc> <@adamgreig:matrix.org> (though note that probe-run isn't a probe-rs project)

00:15 <re_irc> <@whitequark:matrix.org> oh right.

00:15 <re_irc> <@adamgreig:matrix.org> "probe-rs-cli run" is, though, heh

00:15 <re_irc> <@whitequark:matrix.org> : _stares_ so it actually _feeds the reset vector read from hardware_ *into the elf parser*

00:15 <re_irc> <@whitequark:matrix.org> _*after throwing out the reset vector it got from the elf*_

00:16 <re_irc> <@jamesmunns:beeper.com> thats certainly a thing to do

00:16 <re_irc> <@adamgreig:matrix.org> (at first, probe-rs was mostly a library plus cargo-flash/cargo-embed, knurling wrote probe-run using probe-rs, it was a great idea and became very widely used, probe-rs has more recently added "probe-rs-cli run" which does some of the same things in a different way, I guess)

00:16 <re_irc> <@adamgreig:matrix.org> (the "probe-rs-cli" binary was today renamed to just "probe-rs", too)

02:00 <re_irc> <@whitequark:matrix.org> https://github.com/knurling-rs/probe-run/pull/414

02:02 <re_irc> <@whitequark:matrix.org> ... wait, i could have been using cargo embed all this time ? oops

05:26 <re_irc> <@thejpster:matrix.org> : How do you know which four bytes of the ELF are the reset vector?

06:13 <re_irc> <@diondokter:matrix.org> : https://github.com/tweedegolf/stackdump/blob/master/trace/src/platform/cortex_m/mod.rs#L172

06:13 <re_irc> This is what I do in stackdump. You just get the vector table section from the name. This works because everyone uses cortex-m-rt (in Rust and on cortex m)

07:42 <Guest62> hello guys, did someone wrtie RISC-V RTOS in Rust already?

07:48 <re_irc> <@burrbull:matrix.org> https://github.com/rtic-rs/rtic/pull/733

08:15 <re_irc> <@pollyglot:pyjam.as> what does the "x lines y" reactions by heisenbridge mean?

08:16 <re_irc> <@pollyglot:pyjam.as> also Hi 👋

08:16 <re_irc> <@k900:conduit.0upti.me> It means it copied the long post to the IRC side

08:17 <re_irc> <@pollyglot:pyjam.as> doesn't it do that with every message?

08:17 <re_irc> <@pollyglot:pyjam.as> I'm viewing this from the Matrix side

08:17 <re_irc> <@k900:conduit.0upti.me> It does that, but longer messages are broken up into more than one on IRC

08:18 <re_irc> <@k900:conduit.0upti.me> I'm not sure why this is considered important information

08:18 <re_irc> <@k900:conduit.0upti.me> But it marks those specially

08:18 <re_irc> <@pollyglot:pyjam.as> oh okay

08:18 <re_irc> <@pollyglot:pyjam.as> thanks!

08:20 <re_irc> <@osten_music:matrix.org> Hey, I'm wondering if the flash (read, write, erase) implementations for various microcontrollers has been standardized with traits?

09:24 <re_irc> <@dirbaio:matrix.org> : https://github.com/rust-embedded-community/embedded-storage

10:04 <re_irc> <@romancardenas:matrix.org> Is there any mechanism to force atomic-polyfill to use the critical-section emulation even if I'm using a riscv32imac target?

10:08 <re_irc> <@dirbaio:matrix.org> no ( :

10:08 <re_irc> <@dirbaio:matrix.org> * :(

10:09 <re_irc> <@dirbaio:matrix.org> why do you need it?

10:10 <re_irc> <@romancardenas:matrix.org> because I'm facing a lot of problems with my board and compare exchange functions

10:11 <re_irc> <@romancardenas:matrix.org> I don't know why but load stores work OK and compare_exchange etc. cause exceptions

10:11 <re_irc> <@dirbaio:matrix.org> which chip is it? perhaps itps -imc and not -imac?

10:11 <re_irc> <@romancardenas:matrix.org> I discussed this with the RTIC folks and seems a bug in the rustc codegen

10:11 <re_irc> <@dirbaio:matrix.org> * it's

10:12 <re_irc> <@romancardenas:matrix.org> It is an FE310g002, so it is imac

10:12 <re_irc> <@dirbaio:matrix.org> O_o

10:12 <re_irc> <@romancardenas:matrix.org> I tried to change the target to imc but the e310x-hal crate uses atomics so... I'm doomed

10:12 <re_irc> <@dirbaio:matrix.org> well, you can still run -imc code on an -imac chip if you don't trust the CAS instruction implementation (either silicon's or rustc's)

10:13 <re_irc> <@dirbaio:matrix.org> : oh, oog

10:13 <re_irc> <@dirbaio:matrix.org> * oof

10:13 <re_irc> <@romancardenas:matrix.org> I'll try to do a crappy fork of atomic-polyfill and add a feature to skip the build cfgs

10:13 <re_irc> <@dirbaio:matrix.org> if it uses only atomic load/store and not CAS you can force-enable these on -imc with these flags https://github.com/knurling-rs/defmt/pull/707#issuecomment-1488035240

10:14 <re_irc> <@dirbaio:matrix.org> -imc can do load/store fine, rustc should make these available in "core::sync::atomic" like it does in thumbv6m but it doesn't. see https://github.com/rust-lang/rust/issues/99668

10:15 <re_irc> <@dirbaio:matrix.org> these flags force-enable them

10:15 <re_irc> <@romancardenas:matrix.org> I'll take a look, thanks!

10:15 <re_irc> <@dirbaio:matrix.org> if e310x-hal uses CAS then... good luck 😓

10:16 <re_irc> <@dirbaio:matrix.org> : is there an issue for this?

10:16 <re_irc> <@dirbaio:matrix.org> * a rustc

10:16 <re_irc> <@dirbaio:matrix.org> if these things don't get reported they won't get fixed...

10:17 <re_irc> <@romancardenas:matrix.org> I opened it a while ago: https://github.com/rust-lang/rust/issues/110857

10:22 <re_irc> error[E0432]: unresolved import `core::sync::atomic::AtomicU32`

10:22 <re_irc> <@romancardenas:matrix.org> Whit those rustc flags I get the following error:

10:23 <re_irc> <@romancardenas:matrix.org> The "e310x-hal" crate imports "AtomicU32" and it seems that the flags are not enough...

10:26 <re_irc> <@dirbaio:matrix.org> huh, not sure then. Perhaps they're outdated or something

10:26 <re_irc> I haven't personally tried them...

10:26 <re_irc> <@dirbaio:matrix.org> perhaps you need build-std

10:42 <re_irc> <@romancardenas:matrix.org> I ended up doing the polyfill hack

10:42 <re_irc> <@romancardenas:matrix.org> Would you be interested on this feature ?

10:42 <re_irc> <@romancardenas:matrix.org> I can open a PR if so

10:56 <re_irc> <@romancardenas:matrix.org> In case someone wants to take a look: https://github.com/embassy-rs/atomic-polyfill/pull/25

10:58 <re_irc> <@9names:matrix.org> do you know which instructions it's generating for the compare exchange?

10:59 <re_irc> <@romancardenas:matrix.org> Nope, and I don't think I know how to check that. Could you provide me some pointers to do that?

11:01 <re_irc> something like

11:01 <re_irc> cargo objdump --release -- --disassemble

11:01 <re_irc> <@9names:matrix.org> sure! usually i would use cargo-binutils' objdump to get that info out.

11:02 <re_irc> <@9names:matrix.org> if you don't already have cargo binutils:

11:02 <re_irc> cargo install cargo-binutils

11:02 <re_irc> rustup component add llvm-tools-preview

11:08 <re_irc> <@romancardenas:matrix.org> Thanks, I'll take a look!

11:16 <re_irc> <@9names:matrix.org> I'll be asleep soon, so here's the spoiler of what I'm guessing _might_ be the cause (from the chip reference manual):

11:16 <re_irc> > The E31 core supports the RISC‑V standard Atomic (A) extension on the DTIM and the peripheral memory region. Atomic memory operations to regions that do not support them generate an

11:16 <re_irc> > access exception precisely at the core. The load-reserved and store-conditional instructions are only supported on cached regions, hence generate an access exception on DTIM and other uncached memory regions.

11:16 <re_irc> <@9names:matrix.org> this is definitely better than the case for bl602, where they had atomic operations but didn't have any atomic memory regions 🙃

11:19 <re_irc> <@romancardenas:matrix.org> Ooops, it definitely sounds like that's the problem

11:26 <re_irc> <@whitequark:matrix.org> : the ones loaded at the beginning of flash? the code in probe-run already made the assumption that the IVT is located there, at least

11:27 <re_irc> <@whitequark:matrix.org> (I would say "the ones mapped at 0x0" but I think probe-run also specifically assumes flash is being used rather than SRAM)

11:30 <re_irc> <@dirbaio:matrix.org> probably easier to look for the ".vector_table" section?

11:30 <re_irc> <@diondokter:matrix.org> I think that is what happens yes

11:31 <re_irc> <@dirbaio:matrix.org> no, it currently flashes the elf, then reset-and-halts the core, and then _reads_ PC and SP from it

11:31 <re_irc> <@diondokter:matrix.org> Oh ah

11:31 <re_irc> <@diondokter:matrix.org> It used to do it though :)

11:31 <re_irc> <@diondokter:matrix.org> At least for the stacktrace

11:31 <re_irc> <@dirbaio:matrix.org> yeah, I don't understand why it was changed

11:32 <re_irc> <@dirbaio:matrix.org> git history doesn't have much clues

11:32 <re_irc> <@dirbaio:matrix.org> it breaks if your ELF is not the very first thing that runs at boot (bootroms, bootloaders, softdevice...)

11:32 <re_irc> <@dirbaio:matrix.org> because it gives the bootloader's reset vector, not your ELF's

11:32 <re_irc> <@dirbaio:matrix.org> 🤷

11:32 <re_irc> <@diondokter:matrix.org> Been working fine with our bootloader though...

11:33 <re_irc> <@dirbaio:matrix.org> this is what caused probe-run 0.3.8 to break (was broken for lots of people for ~1mo until 0.3.9 was released)

11:34 <re_irc> <@dirbaio:matrix.org> 0.3.9 added some checks to make it not explode if the reset vector doesn't point to inside the ELF

11:34 <re_irc> <@dirbaio:matrix.org> but it's still using the wrong reset vector 🤷

12:05 <re_irc> <@romancardenas:matrix.org> : Found the following atomic instructions:

12:05 <re_irc> lr.w.aqa4, (a1)

12:05 <re_irc> sc.w.rla5, a5, (a1)

12:05 <re_irc> The atomic variables are part of a static struct, so probably they're not on a cached region...

12:05 <re_irc> ...

12:14 <re_irc> <@jamesmunns:beeper.com> : has a PR open that changes this, I believe, there was some discussion last night

12:16 <re_irc> <@jamesmunns:beeper.com> https://github.com/knurling-rs/probe-run/pull/414/files#diff-42cb6807ad74b3e201c5a7ca98b911c5fa08380e942be6e4ac5807f8377f87fcL67-L80

12:24 <re_irc> <@jamesmunns:beeper.com> (I could see "halt and read" as a fallback option if the elf doesn't have that section, but I'm not sure if anything else would work reasonably if you are missing debuginfo)

12:24 <re_irc> <@onsdag:matrix.org> : This is very specific to Espressif RISC-Vs since they’ve got sort of a different interrupt handling mechanism. I do have the CLIC in the back of my mind though, and I know is working on a software emulation to make RTIC work on virtually any RISC-V (although it doesn’t take full advantage of the hardware acceleration part of the framework, the runtime guarantees still hold)

12:25 <re_irc> <@onsdag:matrix.org> +of the CLIC

12:26 <re_irc> <@onsdag:matrix.org> : Dunno why the quote disappeared but that was pertaining this

14:58 <re_irc> <@fork027:matrix.org> Hey all, trying to get through the discovery package with the mirco:bit board, and getting stuck with gdb. I have an older mac OS not supported by homebrew, and don't know how to proceed without gdb. any advice?

14:58 <re_irc> I've gotten minicom to open, but not in connection to any specific project or file, it opens a generic terminal regardless of the path fed to the command.

23:05 <re_irc> <@pacarito:mozilla.org> Is there an updated version of https://docs.rust-embedded.org/book/intro/index.html , buecause my Debian system is missing some of the packages referenced there.

23:05 <re_irc> <@pacarito:mozilla.org> +?

23:05 <re_irc> <@pacarito:mozilla.org> * because

23:11 <re_irc> <@adamgreig:matrix.org> which packages in particular? that's the latest version but it may need updating

23:15 <re_irc> <@pacarito:mozilla.org> "db-arm-none-eabi openocd qemu-system-arm"

23:17 <re_irc> <@adamgreig:matrix.org> for debian that page suggests gdb-multiarch which I think you should have?

23:17 <re_irc> <@adamgreig:matrix.org> and afaik openocd and qemu-system-arm are still around