<diondokter[m]>
The nRF54H20 seems like a giant PITA
<diondokter[m]>
Also, congrats, you get to run a proprietary management engine on your chip now!
<JamesMunns[m]>
diondokter[m]: tbh the softdevice has always been that, just multiplexed on the same core :p
<JamesMunns[m]>
at least you get a more consistent dotted line?
<diondokter[m]>
That's true. Still, I don't like the direction they're taking. Their nRF52 was always nice and simple. But nowadays they're putting so much more in their SDK. Usually also not well documented
<diondokter[m]>
Note that softdevice was optional. This seems not optional
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #rust-embedded
mathu_ has joined #rust-embedded
diondokter[m] has quit [*.net *.split]
dirbaio[m] has quit [*.net *.split]
Curid[m] has quit [*.net *.split]
stgl has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
mathu has quit [*.net *.split]
diondokter[m] has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
Curid[m] has joined #rust-embedded
stgl has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
dirbaio[m] has quit [*.net *.split]
Curid[m] has quit [*.net *.split]
diondokter[m] has quit [*.net *.split]
stgl has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
dirbaio[m] has joined #rust-embedded
diondokter[m] has joined #rust-embedded
Curid[m] has joined #rust-embedded
stgl has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
diagprov has quit [Quit: Connection closed for inactivity]
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 264 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
tiwalun[m] has joined #rust-embedded
<tiwalun[m]>
<diondokter[m]> "That's true. Still, I don't like..." <- The nRF54L is probably more interesting for you if you like the nRF52. That one is much closer in architecture. On the nRF54H there is no way around running the nordic provided firmware, that is part of the whole secure boot thing there.
<diondokter[m]>
Yeah I know the 54L will be a thing. I'm just... I just don't like the direction they're taking. I don't like the nRF53, the nRF7002 is awful and now the nRF54H seems very annoying too at the least
<ryan-summers[m]>
Hmm that seems odd indeed that you'd be getting something that doesn't align with your datasheet. Is this bread-boarded or on a PCB?
<link445645[m]>
bread board
<ryan-summers[m]>
I'd double check the wiring. I think those pins are internally pulled-up, so if your wire isn't making good electrical contact it'll register as 3V3
<link445645[m]>
i bought 2, maybe i try the other one before going down a huge rabbit hole
<link445645[m]>
ok thanks a lot!
<ryan-summers[m]>
Actually it says they must be externally biased, so if they're not connected, they could float and give you an inconsistent address
<link445645[m]>
the adress is stable afaik
<ryan-summers[m]>
Yeah but it's a bit of a craps shoot if it's not electrically connected
<ryan-summers[m]>
* electrically connected. It can be stable for a while and then flip if you put your hand near it etc.
<JamesMunns[m]>
Does it latch on powerup too? you might need to power cycle to reset the addr
<link445645[m]>
JamesMunns[m]: mh not sure how to check this
<JamesMunns[m]>
power the whole board down, power it back up, see if the address is the same?
<link445645[m]>
ah
<link445645[m]>
i tried with my second mcp23017 now, it is also at adress 33 😅😅
<link445645[m]>
very strange, i will investigate more after dinner 😜
<link445645[m]>
<JamesMunns[m]> "Does it latch on powerup too..." <- ok i did that a few times, sometimes it can't find the adress anymoer
<JamesMunns[m]>
that sounds like your wiring might be a little funky :)
<link445645[m]>
ok, i redid it a few times over, ill try it again with different wires haha
<link445645[m]>
s/haha/and different breadboard/
<link445645[m]>
thanks for the help so far ))
<ryan-summers[m]>
Yeah some of those quick connect wires can actually be internally broken and its hard to see
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
Just heading home, might be a minute or two late to the meeting, seeya all in a bit
dandels has joined #rust-embedded
<JamesMunns[m]>
so hows everyone doing this week?
<JamesMunns[m]>
I'm here for some pleasantries before Adam makes it home :D
<adamhott[m]>
doing great!
<diondokter[m]>
Busy with blog writing haha
<adamhott[m]>
how are you?
<JamesMunns[m]>
good! bad sleep schedule and busy, but working on some cool things I'm excited for
<cr1901>
I wrote a MOD player
<dirbaio[m]>
sup
<dirbaio[m]>
fighting thr nrf91 here :D
<dirbaio[m]>
s/thr/the/
<cr1901>
Partially inspired by thejpster[m] telling me it's not _that_ bad
<diondokter[m]>
dirbaio[m]: Boy do I know that feeling
<Henk[m]>
Quite good actually, apart from the fact that it seems to have been raining over here for at least the last three years
<diondokter[m]>
dirbaio[m]: For nrf91?
<dirbaio[m]>
yep
<diondokter[m]>
Oh, continued with breaking article 5 of the nordic license I hear? :D
<dirbaio[m]>
i'm not reversing the lib, i'm just staring at the silicon real hard until it tells me the protocol
<diondokter[m]>
Ah right, of course!
<dirbaio[m]>
intimidating angry look
<JamesMunns[m]>
dirbaio, the binwhisperer
<dirbaio[m]>
but uh
<dirbaio[m]>
there's ... tradeoffs of doing it this way
<dirbaio[m]>
obviously using the undocumented protocol is a downside
<dirbaio[m]>
and i'm going for just "raw socket, gimme ip packets" to hook it up to embassy-net, which means more flash/ram use because it's "wasting" the stack inside the modem
<adamgreig[m]>
wheww, sorry everyone, took way longer than usual to get home
<dirbaio[m]>
wiring up the full tcp/udp/tls/whatever apis is quite a bit more effort
<adamgreig[m]>
@room belated meeting time! we'll start in just a min, quickly putting together agenda, but please add anything you'd like to announce or discuss!
<dirbaio[m]>
but for this use case the entire firmware is written on embassy-net and shared between many products
<dirbaio[m]>
I already tried abstracting the network stack out in the past (with some embedded-nal-like thing) for simcom modems and it didn't end well
<JamesMunns[m]>
Nothing to announce, but there is a leadership council meeting this week, and having some private chats about EWG and Rust Project stuff
<dirbaio[m]>
generics everywhere and much less flexibility
<JamesMunns[m]>
As always, lemme know if there's anything you want me to take TO the council meeting, otherwise I'll maybe have an update next meeting
<Henk[m]>
The idea is to port each chapter and then update the structure of the index a bit
<Henk[m]>
The whole gdb setup is feeling kinda antique, and the GDB stub of probe-rs is not that great (intentionally, it turns out)
<Henk[m]>
So I'm thinking of also replacing that stuff with the probe-rs vscode extension. But that may be a bit much for now
<adamgreig[m]>
maybe it would make sense to replace it with rtt-based logging of the things being inspected?
<adamgreig[m]>
at the time it was written, it was very standard to be using gdb or similar to manually inspect registers and jump around code line by line, so it made a lot of sense to have it in the discovery book
<JamesMunns[m]>
(preferably defmt-rtt)
<Henk[m]>
You would think, but the GDB setup is nice in the sense that it does show really wel what's going on
<adamgreig[m]>
but in the years since, I think it's fair to say many rust users reach for that as a very last resort, and the more typical debugging experience is probably centred around realtime logging with rtt (and defmt, yea) or similar?
<Henk[m]>
Which, in my experience with the old book, is pretty insitghtful
<adamgreig[m]>
I don't actually use vscode so I still reach for gdb when the situation really calls for it but it feels like it's been a while
<adamgreig[m]>
yea, that's fair, you'll have a better insight into what's useful for actually teaching
<Henk[m]>
adamgreig[m]: I know, me too,but I'd like to optimize for educational value
<adamgreig[m]>
yep, that makes sense
<Henk[m]>
It's a balance between showing the internals and teaching people the tech they should work with later
<Henk[m]>
Anyway, I'm gonna stick with GDB for now
<adamgreig[m]>
I think you can do a certain amount of inspecting the value of registers and such by just printing them, but it's not quite the same as stopping execution and going through it line by line or instruction by instruction
<Henk[m]>
Yeah it's kinda nice to see the values of registers change and LEDs light up at the same moment
<Henk[m]>
I really love blinking LEDs ;)
<adamhott[m]>
I went through the rewrite of the registers chapter that Henk did using gdb, and it was pretty cool to see everything update on the fly
<adamhott[m]>
Nothing to add at this time, comments or feedback from anyone on the PRs would be great!
<adamgreig[m]>
sounds good, thanks for the update!
<adamgreig[m]>
last week we had a blitz on a lot of old wg issues, how did people find that? should we plan to do it again in a few weeks/months to work through some of the rest and/or the embedded-hal ones?
<JamesMunns[m]>
Probably could do with one more "bulk filter" pass, then maybe "actually discuss the remains"
<JamesMunns[m]>
there were a couple that got identified as worth discussing, and some that were worth just keeping around
andar1an[m] has joined #rust-embedded
<andar1an[m]>
Are there any popular crates listed in the book?
<andar1an[m]>
I dk if rpi-hal or whatever it was called would be an example
<JamesMunns[m]>
so, IMO:
<JamesMunns[m]>
* in 2-4 weeks: do one more "aim to close the old ones still left" working meeting pass
<JamesMunns[m]>
* in >2-4 weeks: maybe pick one open issue at a time to start discussion?
<jannic[m]>
What I'd also love to have is some way to easily mark issues that can probably be closed. It happens quite regularly that I, while looking for something specific, stumble over tickets that are completely outdated. But I have no idea how that could work.
<adamgreig[m]>
would it work to just bring them up at the next meeting?
<adamgreig[m]>
we could have a label but the process of actually checking the label and discussing it might not work out as well...
<adamgreig[m]>
thanks for setting it up, I thought the spreadsheet worked well
<JamesMunns[m]>
there are labels and stuff there, I also did a quick find and replace to take the issue number and turn it into a link
newam[m] has joined #rust-embedded
<newam[m]>
I can spend some time this weekend to triage cortex-m issues. Though only the surface level ones, the deeply technical ones take a lot of time to grok
<jannic[m]>
adamgreig[m]: Maybe? Feels a bit strange to bother all of you with random tickets.
<adamgreig[m]>
newam: yea, hopefully there's a bunch of old/expired/surface-level ones that can be fairly quickly cleaned up which would make it easier to see the more serious ones
<adamgreig[m]>
jannic: I guess that or leave a comment on the issue along the lines of "looks like this can be closed" and someone from that team should see the comment and could close it?
<jannic[m]>
That could work. Something searchable would be nice.
<andar1an[m]>
May I ask what the Discovery book is?
<Henk[m]>
JamesMunns[m]: It's a book written for people who know a bit of Rust and want to tip their toes in embedded
<andar1an[m]>
Awesome-sauce. Is there a way to virtually represent a micro-controller for programming? I found rustlings to be wonderful and wonder if that could be implemented so
<Henk[m]>
We're currntely in a meeting, but we're happy to answer you questions on the discovery book in ~30 mins!
<rmsyn[m]>
definitely, I read the backlog from a few meetings ago, and saw that there was some consensus on making panicking functions fallible instead
<dirbaio[m]>
I don't understand riscv#212. "exception-safe" doesn't mean "must not panic", it means "if there's an unwind due to a panic, it should leave stuff in a state where invariants are not violated"
<rmsyn[m]>
in some cases, yes. I think some CSRs are machine checked, others are like the one you quoted where we're doing the checks in-library
<dirbaio[m]>
and it's not very relevant for embedded where you typically use panic=abort so there's no unwind at all
<rmsyn[m]>
@dirbaio, maybe the terminology I used is wrong, I mean "do not panic". especially when it is completely avoidable
<JamesMunns[m]>
dirbaio[m]: (we do need to check for re-entrancy tho, even in panic-abort)
<adamgreig[m]>
the issue itself phrases it as though panicking could cause soundness issues if e.g. a safe function panics when called by an unsafe function that didn't expect it
<adamgreig[m]>
but that should not generally be an issue
<rmsyn[m]>
@dirbaio I don't want bare-metal code I'm writing to just blow up without giving me any context. it's a terrible developer experience
<dirbaio[m]>
you get the panic message, how is that terrible experiencE?
<dirbaio[m]>
s/experiencE/experience/
<rmsyn[m]>
you don't if you don't have logging in a panic handler
<JamesMunns[m]>
(I gotta run, have a great week y'all)
<dirbaio[m]>
having to spam .unwrap() everywhere is worse experience
<adamgreig[m]>
if you don't have logging then what are you going to do with the Error/None return?
<rmsyn[m]>
then don't spam unwrap and properly handle errors :)
<dirbaio[m]>
rmsyn[m]: there's your problem then, you should have it
<rmsyn[m]>
and what if the panics are in your logging code?
<JamesMunns[m]>
(fwiw I prefer having checked options, and have the panicking variants be wrappers of that - I'm pro riscv providing the option and not forcing panic-immediate-abort)
<adamgreig[m]>
it makes sense to have fallible functions where the caller can do something useful about it, but panic is widely used for assertions where it indicates an unrecoverable error or program bug etc
<dirbaio[m]>
panic-never is infeasible at scale
<dirbaio[m]>
if your firmware is big enough, it WILL have panic codepaths
<dirbaio[m]>
* panic codepaths that the compiler is incapable of optimizing out, even if they're legit unreachable
<rmsyn[m]>
ok, I'm not suggesting we enforce `panic-never`, more that in every place it is feasible to be fallible, we should
<rmsyn[m]>
panics all over the place feels lazy to me
<dirbaio[m]>
how'd you handle an error returned from hpm()
<dirbaio[m]>
s//`/, s//`?/
<dirbaio[m]>
especially if you're writing code like let x = hpm(0) where you know for sure it's in bounds?
<dirbaio[m]>
you'd just .unwrap() it
<rmsyn[m]>
unwrap_or_default exists
<JamesMunns[m]>
I should be gone, but there's a lot of "lazy" and "infeasible" being thrown around, quick request to be specific about what you are/aren't saying and please all keep the discussion productive :)
<adamhott[m]>
I have to head out, goodnight!
<dirbaio[m]>
unwrap_or_default is worse, it'll silently convert an out of bounds index into bad data
<dirbaio[m]>
as a programmer if you really think that index can't be out of bounds you'd .unwrap()
<dirbaio[m]>
so if you're ever wrong you notice
<rmsyn[m]>
but you just said you "know" its in bounds
<rmsyn[m]>
quit moving goal posts
<jannic[m]>
Doesn't it heavily depend on the actual use case? Especially in embedded? Sometimes it's better to just abort instead of trying to continue after an error. And sometimes you don't want an error in a non-critical code path to stop the whole device.
<adamgreig[m]>
yea, I think it's very typical and useful to assert on things like parameter preconditions
<rmsyn[m]>
there are plenty of ways to bubble up errors, and return sane defaults on error
<adamgreig[m]>
if your function docs say "must call with x<10", returning a Result<T, ErrorYouCalledWithXMoreThanTen> is not especially useful
<adamgreig[m]>
but perhaps this is my C brain worms :P
<rmsyn[m]>
it's very typical but how much harder is it to make the function fallible, and bubble up a contextualized error
<dirbaio[m]>
if you *know* 100% sure it's in bounds IMO `hpm(0).unwrap()` is better than `hpm(0).unwrap_or_default()`. It conveys better the intent, it tells the reader that the error there can really never happen.
<dirbaio[m]>
if you *think* the index is always in bounds then IMO `hpm(i).unwrap()` is better than `hpm(i).unwrap_or_default()`, again. It conveys better the intent, and if you happen to be wrong you notice instead of your program silently misbehaving.
<dirbaio[m]>
same with hpm(i).unwrap() vs hpm(i)?.
<adamgreig[m]>
rmsyn: it's not obvious to me that it's better for every assert to be a fallible function instead though, especially for parameter checking
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
rmsyn[m]: It's very easy to make the function fallible, but very difficult and annoying to bubble up the error
<adamgreig[m]>
alas
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
..or even better use bounded types :)
<adamgreig[m]>
there's a compromise available in having panicking foo() and fallible try_foo(), but that seems like it would get pretty annoying if used everywhere
<Henk[m]>
I gotta take off, thanks all!
<dirbaio[m]>
and if you're writing a lib, what would the user of the lib do with such a a "oops should never happen" error? they can't handle it. retrying would fail again, informing the user is not actionable either
<dirbaio[m]>
so you're going through the effort (and extra flash usage for the extra code) of bubbling up errors, for nothing
<dirbaio[m]>
"oops should never happen" programming errors should be panics.
<rmsyn[m]>
dirbaio at least they have a context of "you have an error condition that should never happen, and here is where it's happening". instead of "your program just blew up, good luck chump"
<adamgreig[m]>
but if you panic you do get a location, and an error message
<adamgreig[m]>
if you don't, you won't be getting it from the fallible function returning a result either
<dirbaio[m]>
with proper panic logging you do get the error condition and the location
<jannic[m]>
I wouldn't want my car to panic if the connection to its speedometer is broken. But an entry in the car's error log would be nice.
<adamgreig[m]>
yea, but "connection to speedometer" isn't a "should never happen, panic" error
<adamgreig[m]>
we even have fallible functions for turning a gpio high, it's not like there's an aversion to the concept :P
<rmsyn[m]>
ok, idk there has been a lot of effort from the Linux Rust developers to get more fallible functions into the core library, so I don't think it's for nothing
<adamgreig[m]>
interesting, what for? just alloc stuff?
<dirbaio[m]>
"speedometer replied with i2c NAK" is definitely something you should handle and not panic.
<dirbaio[m]>
"speedometer driver tried to use I2C5 but the chip only has 4 I2Cs" is a programmer error that should panic.
<adamgreig[m]>
for alloc, in std rust it makes reasonable sense to panic on alloc failure because it "shoudln't happen" on a modern OS and there's nothing the program can do about it really
<adamgreig[m]>
but in linux kernelspace you really do want to handle allocation failure usefully, which is one friction point linux-for-rust has had and is why they're pushing a lot of fallible allocation APIs
<adamgreig[m]>
I've gotta run in a minute too
<cr1901>
(So yes, fallible versions should exist, there are cases where panics are truly undesirable. But honestly, I can live w/ panics as long as the format strings are taken out :P)
<AlexandrosLiarok>
If you are a library you often don't have the context needed to know if the error can be handled or not
<rmsyn[m]>
alright, thank you all for the discussion. I'd like to continue it either next week, or in the relevant GitHub issues
<adamgreig[m]>
I think the point that's missing from the issue is that there is a cost and downside associated with having only fallible functions for everything, and it's not unsound/a memory safety issue despite that being hinted at in the issue; it's a library API decision with tradeoffs
<dirbaio[m]>
there's advantages of panicking even. if you panic as early as possible you get the stack trace that led to the panic. if you bubble up errors you get an "hpm() index out of bounds" in your top-level code with no idea where it's coming from.
<adamgreig[m]>
I worry without more specific examples people might have very different types of functions and checks in mind, too, so it might be good to look at a few specific methods in riscv to think about
<adamgreig[m]>
definitely lots of methods should be fallible, but I'm not personally convinced yet that nothing in the whole library should be allowed to panic
<andar1an[m]>
Could you bubble an error with unwrap_or_else instead of default?
<adamgreig[m]>
but that is definitely a defensible view some people have, so it's worth discussing
<rmsyn[m]>
I think bubbling up errors will be even more helpful when the `Error trait in core` becomes stable, since you will then also get all the unwind data
<adamgreig[m]>
I don't think that will give unwind data in our embedded environments, will it?
<dirbaio[m]>
you won't get unwind data with error-in-core
<adamgreig[m]>
unwinding is a separate concern
<dirbaio[m]>
it needs alloc and libunwind and debuginfo
<rmsyn[m]>
I can look through the riscv library, specifically for examples of "good panic / bad panic"
<jannic[m]>
Perhaps a nice rule of thumb would be that panics should be avoidable by the caller? So any panic should be caused by a mistake the caller made, not by some outside event the caller can't directly influence?
<adamgreig[m]>
that could be nice. if the function says "panics if x>10" the caller can always check themselves x<=10 if they're unsure, for example
<andar1an[m]>
same burnt sushi as ripgrep?
<jannic[m]>
Allocating memory is a nice example, the caller can't (easily & reliably) avoid OOM situations, so alloc-like functions shouldn't panic.
<GrantM11235[m]>
andar1an[m]: Yup
<rmsyn[m]>
yeah, my main issue with the panic handler is that I had logging setup in the panic handler, but the panic happened before logging peripherals were setup
<adamgreig[m]>
for an architecture crate I could imagine there are still some situations where all you can usefully do is panic even if the caller didn't make a mistake, but I don't have specific examples
<rmsyn[m]>
so, it left me with having to guess at where the error was coming from
<adamgreig[m]>
ok, I really have to run, thanks everyone! see you next week
AtleoS has quit [Ping timeout: 264 seconds]
<dirbaio[m]>
probe-rs or gdb could've got you a stack trace
<rmsyn[m]>
bye :wave: thanks for the meeting
AtleoS has joined #rust-embedded
<andar1an[m]>
Can I ask about the Discovery book now?
<rmsyn[m]>
dirbaio: yeah, and I am not sure whether bubbled errors or the panic would have been easier to debug. I've had issues getting probe-rs to work with the particular board I'm working on
<jannic[m]>
adamgreig[m]: Sure, that's why I said "rule of thumb".
<adamgreig[m]>
andar1an: please, go ahead
<andar1an[m]>
So with wasm one of the biggest issues I had with rust when diving in was understanding what crates were in a good state for use. Fastly did something nice which I discovered after where they had a list of like supported crates. I know rust has tier lists for support with hardware, and was wondering if there would be some form of indicating crate maturity or stability in the Discovery book
<andar1an[m]>
I have also been intrigued by what Oxide Computer company has done by not having a bios/uefi, and I often wonder about that and embedded
<JamesMunns[m]>
<andar1an[m]> "I have also been intrigued by..." <- Their rtos, hubris, is public and documented: https://hubris.oxide.computer/
<andar1an[m]>
Amazing! I didn't know Hubris was an OS. The root of trust is based on a chip at the very core i believe, so I imagine that either some hat or add on may be needed for a sbc or some device
<andar1an[m]>
Will definitely check that out more deeply now, thank you!
<andar1an[m]>
That blog post helped there. The Repo states things like operating environment, and message-passing kernel which I didn't correlate with an OS without the blog haha
<TomB[m]>
* like setup from what I can tell with lilos
<TomB[m]>
* <del>they</del> Cliff Biffle also has an embassy like setup from what I can tell with lilos https://github.com/cbiffle/lilos
<TomB[m]>
hubris is neat I guess, though if you are going to go full stack swapping with mpu protection tock does a nice job and provides a sensible syscall like setup
<TomB[m]>
* stack swapping tasks/threads with mpu
<dirbaio[m]>
they're for different use cases
<TomB[m]>
that's what they claim for sure, but tock is a lot more widely useful, being asil-d certified in oxidos, and was used in a similar root of trust (opentitan) use case
<TomB[m]>
not saying either isn't cool, but arguably tockos is easier to get and try
<andar1an[m]>
tock is reference to a secure embedded os?
<andar1an[m]>
2 of my docketed tinker projects have to do with e-ink display system and agritech projects like what bifarm does (their growos is interesting and it would be cool to see something like that in oss). Will be fun to dive into the different use cases eventually.
<andar1an[m]>
so cool. Rust embedded is on fire haha
<andar1an[m]>
seems like tock supports riscv too
<thejpster[m]>
AIUI TockOS is more aimed at running mutually untrusted applications that you don’t know about at kernel build time, but Hubris is more for “I’ve got these five tasks - compile me a kernel to run exactly that”
<andar1an[m]>
There was an OS research project I liked to follow called Thesus was along that second line
<andar1an[m]>
Definitely like that for agri applications
<thejpster[m]>
And OxidOS is aiming for ASIL-D but I don’t think they are there yet.
<andar1an[m]>
tablet may be more suited to tock
<TomB[m]>
thejpster[m]: I'd argue one is a superset of the other and embodies all the properties of the other, tock doesn't have a dynamic elf loader like zephyr does now last i checked, all the tasks needed to be bundled into the image when I last looked
<TomB[m]>
* i checked from what I recall, all
<TomB[m]>
* i checked. From what I recall, all
<thejpster[m]>
Right but I think you could ship with two tasks and OTA update to add a third in its own flash slot and Tock would just work it out.
<thejpster[m]>
Although PIC/PIE is still broken in Rust on Arm last I checked, so you do have to link knowing which slot you are going in to.
<TomB[m]>
yes, because its not a real elf loader :-)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<thejpster[m]>
Not all elf loaders relocate! Like mine doesn’t. But I see what you mean - sending an ELF OTA and relocating it at flash time is one solution.
<TomB[m]>
fair enough!
<thejpster[m]>
But the better solution is fixing LLVM so the code can just run from any address. Maybe that’s ROPI and RWPI rather than PIC.
<TomB[m]>
pic/pie also has a small cost as I understand it in terms of performance no? like some register gets taken up with the elf offset
<thejpster[m]>
RWPI requires you to set R9 as your base register IIRC. And it crashes the linker.
<andar1an[m]>
(quietly looks up ROPI and RWPI) haha
<TomB[m]>
right, vs doing the relocations and linking where you can get what looks just like a statically linked elf running
<TomB[m]>
the only downside I've seen is PC local instructions might require a jump table
<TomB[m]>
* the only downside I've seen is PC local instructions might require a jump table be generated
<TomB[m]>
linux does that I believe for armv7a, I did it for zephyr with -mlong-calls to just avoid the pc local bl[x] ops, and it just worked easy peasy
<andar1an[m]>
Sorry, no bueno. What are ROPI and RWPI not as acronyms?
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
andar1an[m]: its about position independent code - e.g your pointer addresses have a fixed mapping or no
<vollbrecht[m]>
s/no/not/
<thejpster[m]>
PIC is about load time relocation. ROPI is about doing everything PC relative.