ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
_whitelogger has joined #rust-embedded
MayaRodriguez[m4 has joined #rust-embedded
<MayaRodriguez[m4> Get in touch with this platform for greatness you’ll definitely thank me later
ℹ️❤️
👇🏻👇🏻👇🏻
MayaRodriguez[m4 has left #rust-embedded [#rust-embedded]
EthanWu[m] has joined #rust-embedded
<EthanWu[m]> an update: implemented bidirectional asynchronous typed ipc for amp landed on amp e.g. stm32mp257f-dk, feel free to try it on: https://crates.io/crates/consortium-ipc-transport-memory.
<i509vcb[m]> no message deletions of spam?
<EthanWu[m]> two weeks ago I said I made it embassy on stm32mp257f-dk with defmt, promised to open-source later.
<EthanWu[m]> hardware validated
<EthanWu[m]> not a cliche: dont anticipate all llm code to be slop. last mile uio worked helped by llm refactor.
cr1901 has quit [Ping timeout: 250 seconds]
cr1901 has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has joined #rust-embedded
bandini has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.7.2]
rom4ik has quit [Quit: bye]
rom4ik has joined #rust-embedded
rom4ik has quit [Client Quit]
rom4ik has joined #rust-embedded
rainbyte_ has joined #rust-embedded
rainbyte has quit [Ping timeout: 256 seconds]
sroemer has joined #rust-embedded
rainbyte_ has quit [Ping timeout: 264 seconds]
rainbyte has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.7.2]
gkoebel has quit [Read error: Connection reset by peer]
gkoebel has joined #rust-embedded
gkoebel has quit [Read error: Connection reset by peer]
gkoebel has joined #rust-embedded
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
gkoebel has quit [Ping timeout: 276 seconds]
gkoebel has joined #rust-embedded
gkoebel has joined #rust-embedded
gkoebel has quit [Changing host]
<thejpster[m]> has anyone ever done SEGGER RTT out of secure state on a TrustZone enabled chip?
<thejpster[m]> because I'm trying to and seeing nothing
diondokter[m] has joined #rust-embedded
<diondokter[m]> Well, secure state is the default. So yes, I have
<diondokter[m]> Which chip?
<thejpster[m]> it's only the default if you set some sticky bit to enable it. Otherwise they boot in nonsecure state by default.
<thejpster[m]> STM32U5A5
<diondokter[m]> Oh? Then STM is different from all other chips I've used
<thejpster[m]> if SRAM is stil at 0x2000_0000 on STM32, then it's definitely nonsecure state. Secure SRAM lives at 0x3000_0000.
<diondokter[m]> The nRFs and NXPs all start in secure state
<thejpster[m]> huh
<diondokter[m]> What's the address the debugger uses to access the RTT buffer?
<thejpster[m]> https://github.com/42-technology-ltd/nrf9160-demo notes that the SPM boots in secure state, then bootloads the app in nonsecure state
<thejpster[m]> my RTT buffer is at 300001a8, in secure SRAM
<diondokter[m]> Sure. The chips boots secure into whatever software is there. In that case the SPM
<diondokter[m]> thejpster[m]: Maybe try the nonsecure alias?
<thejpster[m]> but probe-rs gets the address from the symbol table?
<diondokter[m]> thejpster[m]: Btw, people have figured out how to use the modem from the secure state: https://github.com/diondokter/nrf-modem#secure-and-nonsecure-operation
<diondokter[m]> thejpster[m]: Just to try, set your memory.x to use the non-secure alias
<diondokter[m]> Maybe that doesn't work on STM though
<thejpster[m]> huh
<thejpster[m]> I didn't expect that to work, but it did
<diondokter[m]> So, often (chip settings dependent), the secure side can access anything in the non-secure alias just fine.
<diondokter[m]> But debugger access is different again and so 🤷‍♂️
<diondokter[m]> It's all cursed
<thejpster[m]> it begs the question why there are two aliases
<thejpster[m]> I bet I couldn't execute a ram func from 0x2000_0000
<diondokter[m]> Well, the non-secure can't access anything with a secure alias. And regions can be turned off in the non-secure alias
<diondokter[m]> Not sure!
<thejpster[m]> nope, it ran a ram func just fine
<diondokter[m]> Secure accessing non-secure data is a feature. How otherwise would a secure enclave encrypt a byte slice?
<diondokter[m]> It's the other way around that's protected
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<thejpster[m]> cool, well ThreadX is running in Secure State without issue
<thejpster[m]> but now I see
<thejpster[m]> > warning: linker stderr: rust-lld: address (0xc000258) of section .text is not a multiple of alignment (16)
<thejpster[m]> Is this new cargo now printing linker warnings by default?
<diondokter[m]> Yes
<diondokter[m]> Was changed in the most recent update I think
<thejpster[m]> I'm using a fairly normal cortex-m-rt linker script
<thejpster[m]> 0c000040 g O .vector_table 00000218 __INTERRUPTS
<thejpster[m]> 0c000258 g .text 00000000 __stext
bandini has quit [Quit: WeeChat 4.9.4]
ouilemur has quit [Quit: WeeChat 4.9.4]
<az1[m]> Yeah RA is (mostly) secure / ns callable by default.
<az1[m]> <diondokter[m]> Secure accessing non-secure data is a feature. How otherwise would a secure enclave encrypt a byte slice?...
<az1[m]> Maybe it's chip dependent? I've run into errors trying to get secure access of non-secure data (and some stuff here is NS only like ethernet DMA).
ouilemur has joined #rust-embedded
<diondokter[m]> az1[m]: It is! IIRC the NXP chips I've used do allow it except when you set some extra vendor bits
sroemer has quit [Quit: WeeChat 4.7.2]
<diondokter[m]> The biggest issue with trustzone is how it left so many things up to the vendor
<az1[m]> diondokter[m]: Yeah… I think on the RA chips "without" an SAU it doesn't matter but on the chips with an SAU (what Renesas calls their v2 implementation) it does.
<az1[m]> Yep, plenty of opportunity for creativity.
<az1[m]> Plus there's also trustzone privileges if you're feeling extra feisty.
<az1[m]> Actually, scratch that. There's seven different ways on this MCU that a register can respond to security context lol.
gkoebel has quit [Quit: gkoebel]
glitchy has quit [Remote host closed the connection]
<az1[m]> Welp the Baochip boards shipped.
glitchy has joined #rust-embedded
glitchy has quit [Max SendQ exceeded]
glitchy has joined #rust-embedded
reto[m] has joined #rust-embedded
<reto[m]> And arrived, got mine today:)
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
glitchy has quit [Max SendQ exceeded]
glitchy has joined #rust-embedded
arrubin has joined #rust-embedded
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
Noah[m]1 has joined #rust-embedded
<Noah[m]1> <dirbaio[m]> and "homies" and "bro" is an interesting choice of words to talk to a group of 3.8k people you don't know personally
<Noah[m]1> yo bro you not down with the homies?
<Noah[m]1> sorry, couldn't resist, somehow this popped up on my screen now and I was chuckling
<dirbaio[m]> u not have enough aura
<DnielBuga[m]> sadge mate, real L attitude
<Noah[m]1> rare W boiiis
<dirbaio[m]> lit
<Noah[m]1> I really have to resist to not keep this going :D
dinkelhacker has quit [Server closed connection]
dinkelhacker has joined #rust-embedded
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
gkoebel has joined #rust-embedded
gkoebel has quit [Client Quit]
gkoebel has joined #rust-embedded
gkoebel has quit [Client Quit]
gkoebel has joined #rust-embedded
gkoebel has quit [Read error: Connection reset by peer]
majors has quit [Server closed connection]
majors has joined #rust-embedded