<thejpster[m]>
the on start-up you walk from .sregion to .eregion picking up two words at a time and zero-ing them. Or I guess three words at a time and doing a memcpy.
<thejpster[m]>
s/the/then/
<AlexandrosLiarok>
I was not aware of LOADADDR, haven't really used it before.
<thejpster[m]>
putting __eitcm outside the .item output section means you can insert extra things in front of it. As that doesn't make sense here, you might as well put it inside the .item section.
<thejpster[m]>
but yes that looks about right (I am not a compliant GNU ld syntax parser, no warranty is given express or implied)
<thejpster[m]>
You can 'insert' sections into the main link.x script from your memory.x fragment if you don't want to write a whole new script
<thejpster[m]>
rp-rs does this to insert a .boot section in front of .text
<AlexandrosLiarok>
hmm it seems I get a conflicting FLASH range with .vector_table.
<AlexandrosLiarok>
for FLASH specifically.
<AlexandrosLiarok>
Do I need something like `AT> LOADADDR(.text) + SIZEOF(.text)` or similar for other sections ?
<thejpster[m]>
no the linker should just arrange all of the output sections into the region. Unless you told it not to somewhere.
<AlexandrosLiarok>
s/`/~~`/, s/`/`~~/
<AlexandrosLiarok>
s/`/<del>`/, s/`/`</del>/
flr7919174955 has joined #rust-embedded
flr7919174955 has quit [Remote host closed the connection]
<JamesMunns[m]>
If postcard-schema's `Schema` derive automatically emitted snapshot test powered by `insta`, would folks here use it? The idea would be that when you are making a postcard(-rpc) `icd` crate with your data types, you would get regression tests for "free" - if you ever change the contents, you'll get a failing snapshot test you have to approve to avoid breaking your wire formats.
<thejpster[m]>
You need ‘insert after .text’ or something.
<thejpster[m]>
Because cortex-m-rt nails the the vector table to ORIGIN(FLASH).
PeterKrull[m] has joined #rust-embedded
<PeterKrull[m]>
James Munns: hey, I have been wondering what the status is on the RawMutex/ScopedMutex/mutex-traits efforts, since it seems to have been still/stable for ~5 months. I have been playing around with the WaitQueue and WaitMap from maitake-sync in my own project, and really like what I do with those. And I believe much of embassy-sync could benefit from building on something like the maitake WaitQueue.
<JamesMunns[m]>
Yeah, no progress on it, I'm not sure exactly where we left off, but I believe it was working, just needed review + polish + release.
<JamesMunns[m]>
I've been working on postcard/postcard-rpc, so I haven't had cycles to pick it back up.
<JamesMunns[m]>
If you're interested in helping to get it released, it would definitely be appreciated, but I don't have a to-do list handy for what is left to check off.
MarcTrius[m] has joined #rust-embedded
<MarcTrius[m]>
Hi, I'm looking for some examples of using embedded-sdmmc with AVR
<PeterKrull[m]>
<JamesMunns[m]> "I think it's:..." <- I would love to help. Though it seems past you is already way ahead of us, mutex-traits is already 1.0 on crates.io 😆 and Eliza did what looks like polishing work earlier this month. So maybe the next step is for the rest of the ecosystem to start using those traits
<JamesMunns[m]>
<JamesMunns[m]> "I think it's:..." <- Oh hell yeah old James and old Eliza
<JamesMunns[m]>
<JamesMunns[m]> "I think it's:..." <- re: embassy-sync, switching everything over ran into some blockers where the embassy CI was failing. I think @danielb's work on the executor things might have caught some bugs, so it might go smoother this time?
<JamesMunns[m]>
<JamesMunns[m]> "I think it's:..." <- I attempted to wholesale replace the current embassy sync bits with maitake's primitives under the hood, and that required unwinding some code that relied on CS being re-entrant, which doesn't super fit with the scoped mutex stuff
<JamesMunns[m]>
<JamesMunns[m]> "I think it's:..." <- I guess maitake-sync probably needs a release using the new traits still? I know Eliza has talked about doing it
<JamesMunns[m]>
<JamesMunns[m]> "I think it's:..." <- I'd check, but GH is on the struggle bus 😃
<PeterKrull[m]>
JamesMunns[m]: Yeah, I'm either getting a unicorn or a 503 trying to find your PR 😬
<JamesMunns[m]>
JamesMunns[m]: I can't even load top level repos :p
<AlexandrosLiarok>
my bootloader fetches the sp from it.
<AlexandrosLiarok>
* my bootloader fetches it from the vector table when jumping.
<AlexandrosLiarok>
If I could rewrite the bootloader I would just ignore that part and rely on the firmware being built with the set-sp feature.
<thejpster[m]>
_start_start is a PROVIDE, which gives it a default value. Set it to whatever you like.
<thejpster[m]>
s/_start_start/\_stack\_start/
<AlexandrosLiarok>
Yea no it works, I got misdirected.
<AlexandrosLiarok>
If I set stack to ITCM it hard-faults after jumping from bootloader. Probably happens if I change stack in general. Maybe I forgot to disable interrupts while jumping or something.
<AlexandrosLiarok>
* or something. Nope, it happens without the bootloader as well.
<thejpster[m]>
you might need to enable ITCM in _pre_init?
<JamesMunns[m]>
<JamesMunns[m]> "I'd check, but GH is on the..." <- I checked with Eliza, she's gunna cut maitake-sync v0.2 soon, so it should be ready to use. Then long term, the hope would be to migrate embassy-sync onto `mutex-traits` and maybe merge/rework/reexport some of the data structures.
<JamesMunns[m]>
<JamesMunns[m]> "I'd check, but GH is on the..." <- for the record, "the hope" is more coming from me, not sure what the desire/plan is from other embassy maintainers.