<jotthyr[m]>
Hello, anybody can help me with my rpi 2040 and embassy-rp? I cannot flash using bootsel, I tried to run command "cargo run --release" and I get Error: "entry point is not in mapped part of file". Anyone have encountered this issue before?
<JamesMunns[m]>
Did you copy from some kind of template? Usually that error means an issue with the linker script, so you might be missing thememory.x, or the build.rs
<JamesMunns[m]>
it looks like a bug in the tool because it counts 0-36 instead of 1-37
<JamesMunns[m]>
it looks like it flashed right
<JamesMunns[m]>
(like, just the debugging output is wrong, the tool is probably fine)
<jotthyr[m]>
Ok, I see
<jotthyr[m]>
yeah, it works like a charm! I was just confused by not blinking led 25 but in rpi pico WH this is no longer connected as onboard led (probably) but now on another pin it works
<JamesMunns[m]>
The LED is attached to the wifi chip on the pico Ws
socrates1298 has joined #rust-embedded
pcs38 has quit [Quit: leaving]
mkj[m] has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
socrates1298 has quit [Ping timeout: 252 seconds]
<thejpster[m]>
Every version of embedded-sdmmc has a data corruption bug. It appears when modifying file contents using a read-modify-write on a block where you are modifying the bytes the start of the block.
<thejpster[m]>
It's pretty bad, so should I yank every existing version? Doing so would avoid surprises, but also be very annoying for any project that only ever reads or creates files without randomly modifying them.
<thejpster[m]>
* the bytes at the start
<thejpster[m]>
`f.seek(1); f.write(&[0]);` works fine but `f.seek(0)` or `f.seek(512);` followed by `f.write(&[0]);` will zero out the other 510 bytes in the affected block.
<thejpster[m]>
`f.seek(1); f.write(&[0xCC; 511])` is also fine.
<diondokter[m]>
How likely is it to hit this in production code? If very likely, then I wouldn't yank. People will probably have seen it already.
<diondokter[m]>
But when unlikely, it might have been missed and it'll be very surprising. Maybe then you should yank
<thejpster[m]>
any write of a length that isn't a multiple of 512 bytes and that isn't at the end of the file, will corrupt the file.
<thejpster[m]>
but I have no idea who is using the crate, or for what.
<thejpster[m]>
ooh, maybe I can get someone to make a CVE.
<diondokter[m]>
Ah, then I wouldn't yank. Any new user isn't gonna use an old version anyways.
<diondokter[m]>
But that's just my opinion :)
<thejpster[m]>
I guess I could put out the fix as a minor change, then it will get picked up by anyone who hasn't locked the package.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
I wouldn't yank unless you also planned to publish a backport for every semver-compatible line, and even then I wouldn't bother I don't think
<adamgreig[m]>
but "serious bug" is just "release a new version" imo
<thejpster[m]>
fair. I will at least go and edit the github release notes.
<thejpster[m]>
I'm proposing an alternative fix to the one in https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/189 - can I get a second pair of eyes on it to check I'm fixing this correctly? The issue was around failing to read the existing block contents when writing to the start of a block (failing to notice that you might not be writing the whole block, and hence zeroing out the last part of the block).
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
uuuuuuugh, release management is hard
<Ralph[m]>
<thejpster[m]> "ooh, maybe I can get someone..." <- if the CVE is too much hassle you can also create a RUSTSEC advisory (it'll get picked up by GitHub, so all users with repos on GH will start getting this in their notifications): https://github.com/RustSec/advisory-db
<Ralph[m]>
(but then i guess you're well aware of this and i'm not telling you anything new... just throwing it out there for the rare chance that you might not have thought of it)
<thejpster[m]>
hmm, these do seem to be for security issues though, not bugs that are only triggered by the programmer (rather than an attacker)
<Ralph[m]>
they also have "unmaintained" and i think i've seen other things there as well. or you do it like the linux kernel: they just say that all bugs might be used as a security issue somehow and started being very generous with issuing CVEs ;)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
or we follow the wise words of Greg Kroah-Hartman of linux kernel fame ;)
sroemer has quit [Quit: WeeChat 4.5.2]
realroot[m]1 has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
It can be a problem with Public traits/types, for example if your Hal imementa embedded-hal 1.0 and a driver uses 0.2 it won't work
<dirbaio[m]>
But in most cases it has zero impact, each Lib uses its own version of the thing internally and everything works. (or maybe increased code size at worst)
<rafael[m]>
okay, got it, thx!
<rafael[m]>
dirbaio[m]: in that case it will not even compile, no way of not noticing that 🙂
<dirbaio[m]>
Exactly :p
<dirbaio[m]>
I don't like this lint ;(
<dirbaio[m]>
I've already got a few people asking to remove eh0.2 support in embassy due to it
<dirbaio[m]>
Just to silence the lint
<dirbaio[m]>
It makes no sense, there's no downside in keeping eh0.2
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
I hope that lint allows excluding specific crates cause that seems to be very broad in coverage
<rafael[m]>
I must admit i just now used clippy for the first time. It is a blast, so many things I learned from it. Just this and some typecasting stuff and future_not_send need to be suppressed.
<rafael[m]>
dirbaio[m]: that is a little over the top just for a warning... and a ton of work for many people.