<FrreJacques[m]>
No clue, but are you sure you need to comment out the Tlink.x line?
<thejpster[m]>
If it’s an open source project, can you post the repo link? It’s hard to read such big blocks of text.
<thejpster[m]>
If it’s not open source, you’ll need professional support from one of any number of Rust consultancies.
<thejpster[m]>
(But also, your .cargo/config is wrong - I’m pretty sure the riscv-rt crate requires you to pass both -Tlink.x and -Tmemory.x to the linker )
M9names[m] has joined #rust-embedded
<M9names[m]>
the official riscv-rt doesn't - it includes link.x inside device.x (which is roughly equivalent to the above memory.x)
<M9names[m]>
s/doesn/examples don/
cinemaSundays has joined #rust-embedded
jiande20205 has joined #rust-embedded
jiande2020 has quit [Ping timeout: 252 seconds]
jiande20205 is now known as jiande2020
<thejpster[m]>
Why is it so different to cortex-m-rt? There’s no reason to make them different.
<JamesMunns[m]>
I'm guessing that it's due to the fact that interrupts are fairly different on riscv, and you need HAL-level flexibility to deal with that.
<JamesMunns[m]>
I'd defer to more active risc-v devs tho
<JamesMunns[m]>
* on riscv (edit: specifically that there is no "one true interrupt controller" in risc-v,, * , unlike cortex-m), and you
<thejpster[m]>
But the names of the linker scripts and how they are included though?
<JamesMunns[m]>
I'm definitely guessing, so take that for what it's worth.
<thejpster[m]>
I've only written one RISC-V interrupt controller driver, but I was able to make it work exactly like Cortex-M, modulo the riscv-rt crate at the time used interrupt! instead of #[interrupt].
<JamesMunns[m]>
btw/mostly unrelated, good thread on bluesky for how to get started with the ch32v003, a 10¢ risc-v MCU:
<M9names[m]>
<thejpster[m]> "Why is it so different to cortex..." <- you could say the same about all the different hals, you know?
<M9names[m]>
there's no overlap between the folks who wrote riscv-rt and cortex-m-rt, there's been no pressure to make them the same so they diverge.
<thejpster[m]>
yeah, but this is the embedded devices working group. It's kind of here to prevent divergence.
<thejpster[m]>
although I accept I am in a very very small overlap in the venn diagram
cinemaSundays has quit [Quit: Connection closed for inactivity]
cr1901 has quit [Ping timeout: 252 seconds]
pbsds3 has joined #rust-embedded
<whitequark[cis]1>
i think it results in better development tools if you actively try to avoid divergence
<whitequark[cis]1>
i have a similar situation with FPGAs in Amaranth; we currently support six vendors (xilinx, altera, lattice, siliconblue, gowin, quicklogic) and the APIs are unified completely or almost completely across all. this took a significant amount of design work and even more testing work; i believe that nobody really ever tried to do it on such a scale
<whitequark[cis]1>
but the problem is that if you want to try to avoid this as a development principle you need some of a vanishingly small number of people with very broad development experience and also the time to painstakingly test it all
<whitequark[cis]1>
so i don't know what the answer is, honestly. telling people to install 5 other toolchains if they want to add a feature to xilinx is... certainly something i could ask for
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k_ is now known as m5zs7k
Socke has joined #rust-embedded
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
How do you do a memory clobber in rust?
<jason-kairos[m]>
(sometimes you see asm :::memory with a bunch of special characters in gcc, but rust uses LLVM)
<jason-kairos[m]>
* memory clobber / memroy barrier in rust?
<jason-kairos[m]>
* memory clobber / memory barrier in rust?
<jason-kairos[m]>
I'm measuring the number of clock cycles something takes, and rust I think is doing things out of order
<JamesMunns[m]>
in asm or in rust?
<JamesMunns[m]>
in rust you can use core::sync::atomic::fence or core::sync::atomic::compiler_fence
<jason-kairos[m]>
rust
<JamesMunns[m]>
or you can use core::hint::black_box
<jason-kairos[m]>
Is black box the same is `(&foo as *const Foo).read_volatile();` ?
<JamesMunns[m]>
not really, because reading "normal" memory as volatile isn't super well defined
<JamesMunns[m]>
but black box is the recommended "best effort to inhibit clever optimizations" to use.
<jason-kairos[m]>
If I explicitly add asm::nop(); or asm!("nop"); instruction can they be optimized away? (I have a situation where they have seemingly disappeared from the disassembly)
<dirbaio[m]>
they shouldn't get optimized away,no
<dirbaio[m]>
(unless the compiler can prove the spot where the asm! is is unreachable, I think?)
<JamesMunns[m]>
(and just disassemble actual_main doesn't work?)
<JamesMunns[m]>
(or put a breakpoint on actual main, and split the panes there so you can step by asm or lines? layout split I think?)
Lumpio- has joined #rust-embedded
<jason-kairos[m]>
GDB's behavior seems to change depending on weather or not it is connected to a debug probe over TCP. odd...
<jason-kairos[m]>
I can disassemble other functions, but not that specific one unless I call tar ext :61234
<jason-kairos[m]>
(ie. connect to the jtag probe using gdb extended remote protocol)
<JamesMunns[m]>
I don't use gdb 99.9% of the time, the UX is... whatever that is :D
<JamesMunns[m]>
Maybe some day we'll get an interactive frontend for native probe-rs.
<jason-kairos[m]>
Everything uses gdb as the backend so far as I can tell, and this behavior would show in a gui
<jason-kairos[m]>
the only reason why I use gdb directly is because gdb is so broken, and GUIs don't handle weird gdb errors
<JamesMunns[m]>
afaik the vscode probe-rs plugin uses the DAP protocol instead of gdb? but honestly I haven't used it and not sure if it can do asm step debugging.
<jason-kairos[m]>
if I could use LLVM's debugger, I'd gladly take the jump (but I never got it to work)
<jason-kairos[m]>
isn't probe-rs's stepping is broken
<jason-kairos[m]>
it only steps single instructions
<JamesMunns[m]>
(those are unrelated but both are neat)
<adamgreig[m]>
that was a fun blog post!
<adamgreig[m]>
drink if you guessed correctly who would be at fault in the end lol
<adamgreig[m]>
ok, first agenda point is from bartmassey about the team list on the rust website; the wg-embedded team list just hasn't been kept up-to-date as the set of all the sub-teams, so that needs updating and should resolve that issue, I'll try and get that sorted tonight
<adamgreig[m]>
second is the embedded-hal-bus that dirbaio mentioned; is anyone interested in putting together a PR for the 0.3 release?
Nate[m]1 has joined #rust-embedded
<Nate[m]1>
This is more of a general nvim/rust-analyzer question, but, I'm trying to get rid of the no crate test error in my config and am having a hard time finding the api docs to configure it. Any help pointing me in the right direction would be awesome
<JamesMunns[m]>
I've never set up embedded-hal-bus, but I'm at a PC, let me try to hack out a release PR now
<adamgreig[m]>
I was going to say I think the point is to help ensure we've not overflowed flash, but it's not clear this really helps with that at all
<adamgreig[m]>
_stext goes immediately after the vector table in flash in the normal setup, so something has gone badly wrong if that's no longer inside flash
<adamgreig[m]>
however, for the standard linker script _stext should always be inside flash, so I don't think it's ever an issue? you'd have to change the linker script anyway
<JamesMunns[m]>
I've also just made the "FLASH" be in RAM before
<JamesMunns[m]>
(you can just lie to the linker like that)_
<JamesMunns[m]>
* (you can just lie to the linker like that)
<adamgreig[m]>
that's fine, but not what the issue is asking about since they want to load from flash into ram at startup (whereas your setup only works when loaded from some other bootloader/debugger right?)
<JamesMunns[m]>
ahh, yes, correct
<adamgreig[m]>
i.e. you don't hit the error, I think? because your stext is still inside "FLASH"
<adamgreig[m]>
but to hit the error they must change the linker script itself, so I think fair to just say remove the assertion in that case
<adamgreig[m]>
then next is https://github.com/rust-embedded/cortex-m/issues/575 about why #[exception] doesn't allow extern "C" fn. I think this is just an oversight on the list of allowed attributes. if anything the ABI should probably always be C...
<adamgreig[m]>
I suppose because we enforce a specific signature the ABI doesn't actually matter, and no one has needed extern "C" before because it's just useful right now to avoid the compiler warning about naked functions....
<JamesMunns[m]>
do we accept #[naked] actually as well?
<JamesMunns[m]>
I thought that did weird things, but I forget the details
<jannic[m]>
https://github.com/rust-embedded/cortex-m/pull/421 "pre_init and entry are called from our asm.S via bl __pre_init and bl main, exception and interrupt handlers are called directly by the CPU; in either case there's no issue with calling a naked function."
<adamgreig[m]>
who wrote that 🤔
<adamgreig[m]>
well, still not sure why they're not getting a warning on it, but I can't see why it wouldn't be fine to have extern "C" for these. in fact the functions our macros actually emit are also extern "C" as you might expect
<adamgreig[m]>
s/it/pre_init/, s//`/, s//`/
<adamgreig[m]>
yea, weird, pre_init is one of the few we don't turn into extern C anyway
<adamgreig[m]>
well, I think the short answer is "naked/extern interacts with the macros in confusing ways"
<JamesMunns[m]>
one escape hatch is just changing the export name to the symbol right? Or do we declare that as private?
<adamgreig[m]>
yea, it's fine to not use the macro and just make your own function with the right export name
<adamgreig[m]>
one issue is the exception macro generally makes a wrapper for your function anyway so depending on what you try and achieve with naked it might not do what you want
<adamgreig[m]>
perhaps pre_init is OK because even though it's not extern C it doesn't have any arguments, whereas hardfault w/ the fault into does
<adamgreig[m]>
hmm... though they have trampoline=false, so... dunno
<JamesMunns[m]>
Maybe we just document the escape hatch better?
<adamgreig[m]>
yea... I think this should work too though
<adamgreig[m]>
I'll look into it a bit more later, it might be simple enough to allow extern C but probably need to think about what a naked attribute would do with the new naked fns
<adamgreig[m]>
the current implementation reads the PRIMASK register and then ANDs the bottom bit, PM, which is 0/1 depending on whether interrupts are enabled or not
<adamgreig[m]>
the remaining bits of PRIMASK are RESERVED in ARMv6/7/8
<adamgreig[m]>
the suggested new implementation doesn't bother masking primask, it just reads the whole thing and writes it back
<JamesMunns[m]>
do we have to persist the reserved bits?
<adamgreig[m]>
the reserved bits are RES0 in newer arch ref mans
<JamesMunns[m]>
like could we just read as bool, write bool as u32?
<JamesMunns[m]>
ah, I bet casting to bool would probably do masking still tho
<JamesMunns[m]>
because in rust bool must be 0/1, not 0/any
<adamgreig[m]>
SBZP: If software has read the field since the core implementing the field was last reset and initialized, it must preserve the value of the field by writing the value that it previously read from the field. Otherwise, it must write the field as all 0s.
<JamesMunns[m]>
drat
<adamgreig[m]>
"If software writes a value to the field that is not a value previously read for the field and is not all 0s, it must expect an unpredictable result."
<adamgreig[m]>
but in this case... we read the whole register, save it, and later write it all back
<adamgreig[m]>
so it seems it's allowed
<JamesMunns[m]>
yeah, I mean for the breaking change from bool to u32?
<JamesMunns[m]>
or maybe I misread
<jannic[m]>
In theory something in the critical section might read PRIMASK again, get other bit values, and then release call would write older values back. In practice: Very unlikely :-)
<adamgreig[m]>
even if it does, that doesn't seem like a problem
<adamgreig[m]>
James Munns: it changes the critical-section feature from bool to u32 but I don't think that's a breaking change. it also changes the api for the primask register which _is_ a breaking change but I think not necessary
<jannic[m]>
Depends if "writing the value that it previously read" implies that it must be the most recent value read. But I guess if that was meant, it would have been written more clearly.
<adamgreig[m]>
yea..
<adamgreig[m]>
it seems like on all current cortex-m cores the bits are unused anyway but always writing back a value you read since startup seems legit
<adamgreig[m]>
and this does shave a bunch of instructions off the critical section routine, which is pretty nice
<adamgreig[m]>
especially if they can work out how to get the linker to turn the exit into a single instruction instead of a branch
<JamesMunns[m]>
(I gotta run right at the hour, https://github.com/rust-embedded/embedded-hal/pull/644 is up, I think I got it all, if there are any HAL people around we do need to push a tag for the existing v0.2, otherwise should be good to go)
<adamgreig[m]>
thanks!
<adamgreig[m]>
I think we're pretty well done, did anyone else have anything to discuss?
<JamesMunns[m]>
Oh, they are about to fully kill #[start], once they figure out how to make CI green :D
<SirWoodyHackswel>
.oO( Is the embedded-hal-bus a long or short bus? )
<dirbaio[m]>
shorter than the universal cereal bus, that's for sure
<SirWoodyHackswel>
Just don't tell Tony the Tiger:tm:
<danielb[m]>
<JamesMunns[m]> "small postcard-rpc release, v0.1..." <- wow that issue is such a facepalm of epic proportions, that pointers over C FFI should need an extra_unsafe keyword to make sure you understand what the recipient does with it
<dirbaio[m]>
there's a reason I rewrote (parts of) libmodem in rust 🙈
<SirWoodyHackswel>
30+ years of software development... and I'm still learning scary new things
n_vl[m] has joined #rust-embedded
<n_vl[m]>
🤣, that invalid pointer to the stack reminds me of my uni days
cinemaSundays has quit [Quit: Connection closed for inactivity]
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
I ran into this issue when trying out zig...and that's how I learned zig is not for me LOL
<therealprof[m]>
<i509vcb[m]> "I still love the phrase "modem..." <- Not quite sure why people only have a single SIM at hand. They used to be prohibitively expensive, especially if you needed something "special" like non-CGNAT (those were sometimes called IoT or before that M2M SIMs) but nowadays it's like 2€: Even elaborating about whether to do it or not costs more than just buying it..
<dirbaio[m]>
you get jailed based on IMEI as well, not just IMSI/ICCID
<therealprof[m]>
So I guess those things don't have virtual IMEIs then?
<dirbaio[m]>
not nrf91, no :(
<SirWoodyHackswel>
IMEI = rnd(MAX(u64)); ;)
<therealprof[m]>
And only single SIM interface? Is that eSIM, iSIM or USIM? I guess the latter...
<therealprof[m]>
I haven't seen IMEI blocking yet, but if you get SIMs from different (physical) operators, that should work.
<dirbaio[m]>
physical sim
<dirbaio[m]>
or newer firmwares have a "softsim" feature that just passes the APDUs to the application core :D
<dirbaio[m]>
that qualifies as "iSIM" I guess
<therealprof[m]>
Probably. Or maybe they have a special term for that. I thought an iSIM is always a fixed SIM, either provided by a dedicated secure element or sometimes a USIM glues in place.
<therealprof[m]>
s/glues/glued/
<SirWoodyHackswel>
iSIM, iRACK, and iRAN are all trademarks of Apple Corp. ;)