<diondokter[m]>
<danielb[m]> "the sad part is that the forum..." <- Ugh, I know! I checked a week ago and still nothing changed in the docs
<diondokter[m]>
Yeah, we had two devices, both with their own non-exchangable esims
<Darius>
interesting read, pretty annoying so much of the nRF stuff is closed source though :(
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
<adamgreig[m]> "drink if you guessed correctly..." <- I read the word IPC and saw the signature of nrf_send and got flashbacks from stm32-eth, I was sure it would be a missing DMB somewhere, specially after they started playing with black_box.
<thalesfragoso[m]>
Although it wasn't it, I would recommend double checking to see if it's necessary.
<adamgreig[m]>
oh man, i hadn't even considered the dma-likeness of cross-core ipc
<adamgreig[m]>
i was just gunning for "the vendor c code did something stupid"
<adamgreig[m]>
stm32 ethernet drivers are such a barrel of fun
<thalesfragoso[m]>
Since they have a specific peripheral for IPC, you might not need the DMB itself, but you might need a compiler fence
<adamgreig[m]>
remember the "by default the counter interrupt is enabled, you'll hit this after sending 2^31 packets and it will probably hardlock your system unless you have an irq set to clear the specific flag"
<thalesfragoso[m]>
adamgreig[m]: Last time I checked they still have that bug in the C driver, even though there's a very old thread with the solution in their forum.
<adamgreig[m]>
i think all my contributions to chibios are stm32 ethernet fixes, either dma barriers or that interrupt thing or something else
<adamgreig[m]>
hah
<adamgreig[m]>
i think the latest HAL for like the h7 was ok but the older ones weren't updated or something? what a footgun
<JamesMunns[m]>
could be worse, could be whatever that bug was that oxide found with the corrupted vlan thing
<adamgreig[m]>
every rtos and hal has to rediscover this, including the vendor code
<JamesMunns[m]>
adamgreig[m]: oh yeah, bugs that would never show up in dev and always show up in prod, love it
<thalesfragoso[m]>
* Last time I checked they still had that bug in the C driver, even though there's a very old thread with the solution in their forum.
<adamgreig[m]>
bugs that show up in prod as "after weeks/months/ years, it hangs"
<adamgreig[m]>
"no further evidence your honour"
<JamesMunns[m]>
JamesMunns[m]: ive worked at places where we always initialized rolling timers with some value like 0xFF00_0000 or similar, so you'd see rollovers regularly
<JamesMunns[m]>
(like within a few minutes of boot, usually)
<adamgreig[m]>
yea, see, there's a bit in the register to initialise it to a hundred packets below the rollover to test this
<adamgreig[m]>
but it's not set by default of course, whereas the interrupt is
<JamesMunns[m]>
lol
<JamesMunns[m]>
I still think c-m-rt should default to reset on hardfault, not halt
<JamesMunns[m]>
(for exactly this reason)
<adamgreig[m]>
so you have to know this counter even exists (who bothers looking in the station keeping statistics part of the register map for the MAC?), notice it has an interrupt associated with it, realise it's enabled by default, and understand that if it occurs you have to clear it specifically
<adamgreig[m]>
brutal
<adamgreig[m]>
hmm yea maybe, idk. there are probably a lot of times when that's no good and/or confusing and hard to debug too
<JamesMunns[m]>
yeah, also fair
<adamgreig[m]>
i think most applications should have a specifically chosen hardfault handler
<JamesMunns[m]>
no one size fits all :p
<i509vcb[m]>
No idea why "unusual defaults" was the answer there
<JamesMunns[m]>
i509vcb[m]: whatcha mean?
<adamgreig[m]>
i509vcb[m]: for this stm32 ethernet, it's 100% synopsys' fault
<JamesMunns[m]>
(ah, the eth, not cmrt)
<adamgreig[m]>
they wrote the MAC and set the defaults and made these incredibly abnormal interrupts
<adamgreig[m]>
the whole peripheral feels alien compared to the ST in-house stuff
<i509vcb[m]>
ah yes sounds just like external IP
<adamgreig[m]>
they are also responsible for the "memory must be accessed exclusively by half-words" USB peripherals
<adamgreig[m]>
and the "time triggered CAN support! errata: time triggered CAN is not available"
<JamesMunns[m]>
at least when atmel duct taped the eth peripheral from the PIC family, it was from a pic32 so the word width was right
<adamgreig[m]>
ST should have let their own engineers make the IP, I think they'd have had a nice time
<JamesMunns[m]>
* PIC family onto the SAM line, it
<i509vcb[m]>
For a more desktopish platform, I've heard for Apple Macs on Linux the drivers for the synopsys usb 3 IP with just the right combo of the display controller, USB-C PD stack and alt mode is a hellish mess
<dirbaio[m]>
synopsys is also responsible for the "lol otg corrupts stuff unless you access regs in the exact order their driver does"
<i509vcb[m]>
i509vcb[m]: Part of this is how Apple basically designed the hardware to have a single driver managing this, but Linux's rigid system for "a usb driver", "a usb-c driver", "a display controller" collapses
<adamgreig[m]>
Henk newam sirhcel I'm updating the wg-embedded team list because you were on the relevant sub-team but hadn't been added to the main list, but to do so you need an email address associated with your details on the repo (eg https://github.com/rust-lang/team/blob/master/people/adamgreig.toml), is there an email address you're happy to use here?
<adamgreig[m]>
there is an option to make it private, or I can also leave you off that main list - it's different because it also builds the mailing list address list, so team CI fails without emails for everyone in wg-embedded
<adamgreig[m]>
making it private seems quite complicated and I've never done it before, though
newam[m] has joined #rust-embedded
<newam[m]>
Yeah, mine is `alex` Àt `thinglab.org`
<newam[m]>
Sorry for the weird formatting. Have had bad experiences with plaintext adresses getting picked up by spambots.
<adamgreig[m]>
it would go in plain text into the toml file in that repo
<newam[m]>
Yeah that's fine. Never had a problem with it on GitHub
<adamgreig[m]>
cool, thanks
DaltonCaron[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has joined #rust-embedded
<M9names[m]>
<JamesMunns[m]> "evergreen list: http://www.efton..." <- I just spent a large chunk of time to find out the RNG peripheral generates seed+clock errors if you use breakpoint debugging. I thought I'd implemented it wrong the whole time.
<M9names[m]>
Not my favourite part of the job.
<thejpster[m]>
“So it's Jonathan's fault?”
<thejpster[m]>
NGL you had me worried for a moment
<thejpster[m]>
Seeing as the Cortex-R team is empty and your crate is empty, and I am writing a lot of Cortex-R examples lately - I thought I’d write one.
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
<adamgreig[m]> "Henk newam sirhcel I'm updating..." <- Yes, i‘m fine with using christian.meusel@posteo.de here.
Henk[m] has joined #rust-embedded
<Henk[m]>
<adamgreig[m]> "Henk newam sirhcel I'm updating..." <- Sure, let’s go with hd’at’oordt.dev
bitts[m] has joined #rust-embedded
<bitts[m]>
<thejpster[m]> "Seeing as the Cortex-R team is..." <- Not directly related, but sort of. From working with pacs generated with svd2rust, I am used to the RegisterBlocks and their write/modify syntax, but I noticed that e.g. aarch64-cpu use tock registers. Is one of the two solutions the direction the community is heading towards, or are both considered equal alternatives? (And what are you planning on using?)
<thejpster[m]>
<bitts[m]> "Not directly related, but sort..." <- I have never seen an SVD file for a Cortex-R part, and the Armv7-R architecture doesn't define any standard peripherals (unlike Armv7-M et al), so really cortex-r is just going to be some freestanding functions for turning interrupts on and off. cortex-m-rt will just be a little bit of machine code to get the stack pointer initialised and .data and .bss initialised. Maybe
<thejpster[m]>
cortex-m-rt will also let you set an IRQ and a FIQ handler. That's about it.
<JamesMunns[m]>
<diondokter[m]> "Whoops, I think someone at..." <- I wonder if they'll just fix it with docs, or by making that one specific function copy the config
<adamgreig[m]>
hah
<adamgreig[m]>
we fixed the one bug, are you happy now???
<JamesMunns[m]>
It's not even that their code is wrong, they just didn't make their invariants clear
<diondokter[m]>
Yeah, putting it in the docs is 'good enough'
<adamgreig[m]>
sadly there is no way to fix this class of bugs in general 😌
<JamesMunns[m]>
like you said, if they said "the configuration must be stored for the static lifetime", it'd have been fine
<JamesMunns[m]>
* like you said, if they said "the configuration must be stored for the static lifetime", it would have been fine
<diondokter[m]>
But there's no reason the user should hold on to the static. They've got a bunch of statics in their lib anyways
<JamesMunns[m]>
adamgreig[m]: "no way to fix this, says only language where this happens often"
<diondokter[m]>
Someone on the embedded reddit rightfully pointed out that doing binary blob like this with Rust would not entirely fix it because it'd need to use the stable C ABI anyways
<JamesMunns[m]>
yeah, I mean I agree with you on a design perspective, but an API can still be "awkward but safe"
<JamesMunns[m]>
yeah, you'd still need a SAFETY comment that says this
<diondokter[m]>
Yeah
cinemaSundays has quit [Quit: Connection closed for inactivity]
<M9names[m]>
I don't agree. If I were shipping a binary blob with the intention of using it from rust, I would also ship it with the necessary rust wrappers so the unsafe would not be exposed to users.
<JamesMunns[m]>
yeah, you don' have to Just ship the -sys crate for it
<JamesMunns[m]>
* you don't have
<JamesMunns[m]>
you definitely could ship a much nicer non-sys wrapper crate
<JamesMunns[m]>
(tho the -sys crate SHOULD have the safety invariants documented!)
<diondokter[m]>
Is it already a thing where you can have non-unsafe extern fns?
<JamesMunns[m]>
tbh if I were doing that, I'd probably write a "fake" rust signature right in the comments
<JamesMunns[m]>
I've never made a Rust binary blob intentionally tho, I guess :p
<JamesMunns[m]>
at least not intended to be consumed by Rust? I've made a rust staticlib for C code, but it was all within the same project
wassasin[m] has joined #rust-embedded
<wassasin[m]>
I was the one who just bumped the nrfxlib binary in the -sys crate to the one which is no longer compatible, so technically I introduced the problem.
<JamesMunns[m]>
wassasin[m]: hindsight is 20/20, I'm sure it seemed reasonable at the time :D
<wassasin[m]>
Trying to double check now, but this was a while ago :')
<thejpster[m]>
uuuuuuuuugh, guess who fell over the "if you specify a target-cpu, maximal features are enabled, even the FPU, even on a soft-float target" 'bug'
<diondokter[m]>
JamesMunns[m]: There's also no mention in any changelog about the contract change
<JamesMunns[m]>
do we even know if the old versions did copy? or were we just luckier back then on what ended up kept on the stack?
<thejpster[m]>
it would be against the licence terms to find out by inspecting the binary
<thejpster[m]>
if you break the licence, you're commiting copyright crimes by using the library
<JamesMunns[m]>
Doesn't seem to have stopped TG, who admitted to as much in writing :D
<wassasin[m]>
We checked the DWARF thats emitted by nrfxlib and the stuff they stored in the older version did not depend on the memory being in the same place
<thejpster[m]>
YoU wOuLdN't DisSaSsEmBlE a LiBrArY
<diondokter[m]>
I spoke to a Nordic engineer once and he said that such a license is BS and no one can hold you accountable
<JamesMunns[m]>
> In the European Union, reverse engineering is permitted – under the verdict of the Court of Justice issued in 2012 – for creating computer programs with operation analogous to the original program.
<diondokter[m]>
Fun when licenses prohibit runnin objdump on your own project :P
<diondokter[m]>
s/runnin/running/
<JamesMunns[m]>
Still, not a lawyer, even if you're right, proving that in court isn't always pleasant
<JamesMunns[m]>
Ruling happened in the UK, while part of the EU, so maybe it is still well established case law in both places. Not so sure for our non-EU friends
<thejpster[m]>
`2147488430 is not in [-2147483648, 2147483647]` is better written as `8000_12AE is not in [-0x8000_0000 0x7FFF_FFFF]`. And it's right, it's not.
<thejpster[m]>
So the question is, why did the compiler emit object code that is attempting to jump over 2 GiB across the address space when all of your code should be in the same region.
<JamesMunns[m]>
I wonder if something is being implicitly placed at 0x0000_0000?
<dngrs[m]>
<thejpster[m]> "`2147488430 is not in [-21474836..." <- what kind of notation is `8000_12AE`?
<JamesMunns[m]>
dngrs[m]: hex, in the style of rust literals?
<dngrs[m]>
JamesMunns[m]: my rustc doesn't accept it
<JamesMunns[m]>
I mean, it would 0x8000_12AE in Rust
<JamesMunns[m]>
Giving a little grace to JP for not having perfectly parsable literals in a chat message
<dngrs[m]>
ah, it's just hex then. I thought AE would be some kind of suffix like 1e6 or something. Guess I'm just very used to lower case hex literals so I didn't get it
<JamesMunns[m]>
s//be `/, s//`/
<dngrs[m]>
JamesMunns[m]: I wasn't trying to be confrontational, I literally didn't understand the notation
<JamesMunns[m]>
all good :D
<JamesMunns[m]>
I actually had to impl "radix guessing" for a repl/cli for a client
<JamesMunns[m]>
I ended up supporting both `0xAB` and `ABh` for things, mostly because you had to enter an array of bytes (and `0x12 0x34 0x56 0x78 ...` was slightly more annoying than `12h 34h 56h 78h`, and the datasheet for that thing used the "h" suffix, so the techs were more familiar with it
<JamesMunns[m]>
I guess my point is "guessing at encodings is hard" :D
<jannic[m]>
And btw, a quick workaround that also seems to work is building with --release. I guess with that, the offending symbols get optimized away before they reach the linker.
<thejpster[m]>
yeah, putting .eh_frame not into a region will probably generate a sufficiently large jump
<JamesMunns[m]>
love linker UX of "instead of erroring when something is ambiguous, we'll just guess and put it somewhere, this will definitely work out great"
<jason-kairos[m]>
Why can't rust's linker be nicer?
<jason-kairos[m]>
Surely linker file syntax and error messages could contain "black magic"
<jason-kairos[m]>
*less "black magic"
<jason-kairos[m]>
* could contain less "black magic"
kenny has quit [Quit: WeeChat 4.5.1]
<JamesMunns[m]>
mostly because there is no rust linker
<JamesMunns[m]>
just the system linker
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
rafael[m] has quit [Quit: Idle timeout reached: 172800s]
Jubilee[m] has joined #rust-embedded
<Jubilee[m]>
<JamesMunns[m]> "love linker UX of "instead of..." <- every now and then someone asks "can't we rely on the linker emitting an error in that situation?" and I just kinda laugh.
<jason-kairos[m]>
Sounds like it's just bad software
<jason-kairos[m]>
Folks laughed at the idea of nicer error messages in rust, but I the work paid off
<jason-kairos[m]>
s/I//
<jason-kairos[m]>
* Sounds like it's just bad software
<jason-kairos[m]>
Folks laughed at the idea of nicer error messages in rust, but the work quickly paid off
<thejpster[m]>
You’re very welcome to write one
<JamesMunns[m]>
We just need to get rui314 excited about Rust
<JamesMunns[m]>
they've already written two, how hard could a third be
<Jubilee[m]>
jason-kairos: unfortunately, people rely on the way linkers misbehave, and linkers aren't really a language, so they have different problems than a programming language.
<Jubilee[m]>
I don't believe you could truly realize the benefits of a ground-up rewritten linker with ergonomics and actual errors in mind without compiler support.
<jason-kairos[m]>
I don't follow - rust has shaped LLVM internals quite a bit as far as I can tell
<jason-kairos[m]>
A rust linker wouldn't necessarily do what a system linker would do.
<jason-kairos[m]>
* would do. Or would it?
<jason-kairos[m]>
Oh, I think you are saying, "it's not really feasible unless it were to be an officially sanctioned project of the rust compiler team"
<jason-kairos[m]>
There are many decades of Rust ahead, over that timespan it seems doable
<Jubilee[m]>
<jason-kairos[m]> "Oh, I think you are saying, "it..." <- Not quite.
<Jubilee[m]>
Rust supports less than all of C, yet is compatible with it. It was carefully designed to be relatively coherent on its own terms, without needing C to validate its existence, yet remaining compatible with C's worldview in the parts where C can make sense to anyone.
<Jubilee[m]>
Well,
<whitequark[cis]1>
<thejpster[m]> "You’re very welcome to write one" <- i would but i'm already maintaining too much stuff
<Jubilee[m]>
I suppose a few Standardese-Knowers understand C on the level that makes sense of the part of C that don't make sense.
<Jubilee[m]>
but you get what I mean.
<whitequark[cis]1>
the hardest part of building a linker is conforming to people's expectations of "what a linker should obviously do", I think
<whitequark[cis]1>
'cause they're not, when taken as a whole, even coherent or something you can go somewhere to read
<Jubilee[m]>
right.
<whitequark[cis]1>
it's just like, beliefs, of varying reasonability, floating in people's heads
<Jubilee[m]>
Rust is not compatible with C, it is compatible with an ideological version of C. Or a pragmatic version, if you prefer? A version of C that happens to intersect with the C that people actually use. Mostly.
<Jubilee[m]>
Likewise a novel linker would need to pick its own version of Whatever the Fuck You Call The Sea Of Linker Behaviors.
<Jubilee[m]>
And rationalize it.
<whitequark[cis]1>
i wonder if you could like... avoid writing a linker but write a thing that loads all the dependencies, checks them for compatibility, and errors out if it's not there
<whitequark[cis]1>
it could be stricter than a linker, and allow a fallback of "just not running it" for all the people who need some obscure behavior it's not even clear if anybody intentionally added
<whitequark[cis]1>
so you could incrementally define a reasonable subset of linker behavior you could properly verify, without breaking everyone's workflows outright
<Jubilee[m]>
well, we added static analysis tools to C and, yk
<whitequark[cis]1>
i do k
<whitequark[cis]1>
it's exchanging one type of pain for another
<whitequark[cis]1>
i don't know where the tradeoff is better, it's just what i think i would try prototyping
<whitequark[cis]1>
actually, here's an idea for where we could constructively begin: start a shared repo of all the linker errors we want to improve
<Jubilee[m]>
I think "just" writing a linker at some point might be easier.
<Jubilee[m]>
that would be an idea.
<whitequark[cis]1>
with reproducers that create an environment for the error, cause it, and document what we want to see instead
<whitequark[cis]1>
Jubilee[m]: it's possible but a good linker (especially for Rust) needs to be really fast and that's an ordeal of its own that i feel like there may just not be enough people to complete in addition to really good error messages
<whitequark[cis]1>
nobody really ever tried making a linker with really good error messages, as far as i know! it's novel research
<petekubiak[m]>
<whitequark[cis]1> "also, what's up with linker..." <- I've gotta say, there's nothing that makes me feel like a wizard messing with dark arcane magicks quite as much as when I have to write/edit linker scripts