Guest7221 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<paulyoung[m]>
<ryan-summers[m]> "I'd be very surprised if USB-C..." <- Hi. What I meant was, I’m pretty sure the device I’m trying to build an adapter for won’t be able to power the adapter.
<paulyoung[m]>
<ryan-summers[m]> "Also also, you don't have to..." <- I don’t have any control over the device I’m targeting and the serial interface is the only way to communicate with it.
<paulyoung[m]>
<Lumpio[m]> "You have a pre-existing device..." <- Yes, that sounds right.
<paulyoung[m]>
<Lumpio[m]> "That would also explain it not..." <- Exactly. A PC is normally the host and I’m trying to build an adapter to avoid needing to go through a PC.
<paulyoung[m]>
<ryan-summers[m]> "But also, STM32 and RPI devices..." <- Thanks
<paulyoung[m]>
<paulyoung[m]> "Yes, that sounds right." <- Maybe I could replace the feather in the Adafruit guide with this https://www.adafruit.com/product/5723
crabbedhaloablut has joined #rust-embedded
<paulyoung[m]>
paulyoung[m]: It seems like this being a host is really a hack and might not be suitable
sknebel has quit [Server closed connection]
sknebel has joined #rust-embedded
<paulyoung[m]>
<paulyoung[m]> "It seems like this being a..." <- Appreciate any recommendations.
<paulyoung[m]>
<paulyoung[m]> "Appreciate any recommendations." <- STM32F4 looks like it can be host, so maybe this could work.
<adamgreig[m]>
@room meeting time again! agenda is https://hackmd.io/Pn3jt6VoQlWXvKpWnipPKA, please add anything you have to announce or discuss and we'll start in a few mins
<therealprof[m]>
Trying Cinny right now. ;)
johngigantic[m] has joined #rust-embedded
<johngigantic[m]>
Lurkin' around 👀
<adamgreig[m]>
ok, let's start! one quick announcement, embedded-alloc 0.5.1 is out, with the Allocator trait implemented
<adamgreig[m]>
any other announcements from anyone?
<jessebraham[m]>
Just a quick bit from me, if that's okay!
<adamgreig[m]>
go for it
<jessebraham[m]>
I will be volunteering for some number of teams in the Embedded Workgroup, definitely RISC-V because that's related to work but unsure on others. If there are teams which are desperately in need of help please let me know. Was thinking of maybe the triage team, too.
<jessebraham[m]>
I will go through the formal application process and all that, just wanted some feedback on where help is most needed first
zagura has quit [Server closed connection]
zagura has joined #rust-embedded
<jessebraham[m]>
(This can be answered later, too. No need to hold up the meeting 😅 )
<thejpster[m]>
Note for all: Please consider putting yourself forward for the Mod team. It needs more people.
<adamgreig[m]>
that's the rust-lang mod team, to be clear
<thejpster[m]>
Yes
Guest7221 has left #rust-embedded [Error from remote client]
<adamgreig[m]>
jessebraham: ah cool! the triage team is essentially moribund so if you were interested in helping there I'm sure there's a lot of really beneficial triaging to do
<jessebraham[m]>
Yeah sounds good, I'm sure I can help out there!
<therealprof[m]>
jessebraham[m]: We don't really have formal application processes. ;)
<adamgreig[m]>
well, we do have a process, at least :P
<jessebraham[m]>
Submit a PR adding my name* 😉
<adamgreig[m]>
RustNL is a conference happening probably in the week may 6-10 2024, the organisers are considering having a couple days either before or after for embedded rust people to get together and work on stuff, primarily aimed at working on whatever topics rewg think are worth working on
<adamgreig[m]>
it doesn't have to be wg members, but I wanted to gauge if many people would be interested in attending such a thing
<adamgreig[m]>
uh, it's in amsterdam, I should have said
<JamesMunns[m]>
Very interested! I wanted to go last year and it didn't work out, so +1 from me.
<JamesMunns[m]>
(this year? whatever)
<adamgreig[m]>
ideally looking for 10-15 people from here, plus expect a few engineers from sponsor companies, and probably some of us could get some sponsorship for flights etc
<adamgreig[m]>
something like the oxidize impl days from 2019 👴
<thejpster[m]>
I’m up for it
<thejpster[m]>
Where should people register interest? I suspect more bums than seats.
<JamesMunns[m]>
adamgreig[m]: also happy to discuss throwing some sponsor money in if its needed to get folks there. I'm not a big company, but I can pitch in :)
<dirbaio[m]>
my bum's interested too :D
jannic[m] has joined #rust-embedded
<jannic[m]>
I'm interested but don't know yet if I'll have time in May.
<jessebraham[m]>
I can discuss the possibility of Espressif sending somebody internally, is there a link or something with some more info on this?
<therealprof[m]>
jessebraham[m]: Not yet.
<adamgreig[m]>
I don't think there's any more information yet, this is just a very informal straw poll to check there's enough interest to make further plans
<jessebraham[m]>
Okay, no worries
<jessebraham[m]>
Gotcha, well tentative +1 then :p
andresovela[m] has joined #rust-embedded
<andresovela[m]>
I might be able to join too
<adamgreig[m]>
cool, I make that 8ish already, so I think probably fair to say we could muster 10-15 :P
<adamgreig[m]>
I'll report back if I get any more details
<therealprof[m]>
I have no doubt we will find at the very list 10 bums...
<mabez[m]>
+1 from me too :)
Noah[m] has joined #rust-embedded
<Noah[m]>
+1 for sure :)
<Noah[m]>
* sure :) (happy to pay myself)
<JamesMunns[m]>
fwiw, oxidize in-person events were ~100ish attendees, a couple of years back, and we've grown since then. I think we got together 20+ people for the impl days? Maybe more
<therealprof[m]>
s/list/least/
<JamesMunns[m]>
I think it'll be one of those "if everyone is coming, then everyone is coming" sort of deals :)
<Noah[m]>
Which reminds me, I rearlly have to organize the probe-rs retreat
<adamgreig[m]>
yep! I think the 10-15 limit is to account for a few people from sponsors and then only having so much space beyond that, rather than being pessimistic about how many people might turn up, but perhaps it's worth seeing if we could have a bigger space even if most people couldn't be sponsored
<therealprof[m]>
Venue size is a problem, so we can't overdo it.
<adamgreig[m]>
cool, besides that there's only some leftover things from last week, does anyone have any other topics they wanted to discuss first?
<JamesMunns[m]>
let me suggest and then withdraw __sexceptions, despite being consistent with e.g. __stext.
<adamgreig[m]>
lmao
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
I have a question for you guys regarding linker scripts: Is anyone else also just overwriting the linker script from the various crates (cortex-m etc...), and just using a custom one for every project? For me the current setup rarely ever worked out.
<adamgreig[m]>
I don't think I've ever had to replace the c-m-rt linker script
<adamgreig[m]>
you can add new sections in your memory.x which covers all my various linker crime needs
<JamesMunns[m]>
ruabmbua[m]: I have done this temporarily, but only to test or do something hacky for a little bit
<adamgreig[m]>
what MCUs are you using?
<adamgreig[m]>
some require more special handling
<ruabmbua[m]>
mostly stm32`s and various risc-v stuff
<adamgreig[m]>
for stm32 I don't think you should ever really need to replace the c-m-rt one, what sort of changes are you making?
<ruabmbua[m]>
But I have special needs with safety, ecc, dual partition etc...
<JamesMunns[m]>
Yeah, it's always there as an option, embedded always needs some escape hatch. It would be good to open an issue to capture why though, in case it could potentially be supported.
<adamgreig[m]>
the memory.x snippet you provide gets wholesale included into the c-m-rt linker script, so it can add sections, insert them in various places, change where the stack starts, that sort of thing, which has usually been enough to cover funny flash partitions, bootloaders, ecc ram, dtcm/itcm/ccm etc
<JamesMunns[m]>
That said, I think we have generally said "support the 95% of reasonable cases, otherwise give you good docs + a good template for whatever cursed things need to be done"
<ruabmbua[m]>
I can probably do that. Its just that with the first project I did it and kept copying it ^^
<adamgreig[m]>
if you can find something you needed that's not possible with the default linker script, it would be worth either discussing here or opening an issue and we can see if it can support it, for sure
<ruabmbua[m]>
I also like to do a lot of tricks with linker scripts (e.g. to automatically build a table of drivers, so that I do not have to have a file where every driver is registered)
<adamgreig[m]>
like James Munns says, the goal is to cover the majority of common use cases and then you can always use entirely your own if need be, but I would have expected for most stm32 projects at least the c-m-rt one is fine
<JamesMunns[m]>
(or document how you COULD do it without changes! it is surprisingly flexible I've found)
<adamgreig[m]>
if you're already comfortable writing linker scripts and it's how you like to engage with the toolchain I don't think there's any problem always using your own, anyway
<adamgreig[m]>
it's something that people coming to embedded often find extremely esoteric and confusing and poorly documented and liable to make terrible errors, but if you've spent years in the linker mines already, it's not really a problem to use your own I think...
<adamgreig[m]>
still I am grateful to not have to copy the last project's linker script into every new project 😆
<JamesMunns[m]>
Any objections to saying "general consensus is rename it to something reasonable, include in the next breaking change" re: the symbol name?
<therealprof[m]>
Can one find gold in the linker mines?
<adamgreig[m]>
I don't think it's "include in next breaking change"
<adamgreig[m]>
I'd just release it as 0.7.4
<adamgreig[m]>
well
<adamgreig[m]>
I probably wouldn't bother cutting a release for it specifically, even? dunno
<adamgreig[m]>
it changes nothing except lowers confusion to someone reading the linker script, and they're probably reading it on github anyway, so....
<therealprof[m]>
adamgreig[m]: Aren't there cursed versioning tricks we'd have to work around?
<adamgreig[m]>
not for c-m-rt afaik
<adamgreig[m]>
PACs depend on c-m-rt 0.7, so 0.7.4 would be fine
<adamgreig[m]>
releasing 0.8 is where the pain begins
<adamgreig[m]>
ok, next up is to continue the end of the discussion last week about the new cortex-m-interrupt-number crate, in particular ideas for a name that captures that it's also where we'd document the required interface PACs for cortex-m should implement
<adamgreig[m]>
probably just cortex-m-pac-interface lol
<dirbaio[m]>
cortex-m-abi? :P
<adamgreig[m]>
it's more like an API...
<dirbaio[m]>
cortex-m-software-interface-standard
<adamgreig[m]>
💀
<ruabmbua[m]>
this sounds very german ^^
<dirbaio[m]>
CMSIS for short
<dirbaio[m]>
🤣
<thejpster[m]>
cortex-m-pac-interface, or cmpi, is fine by me
<therealprof[m]>
I was about to point that out. 😅
<thejpster[m]>
allows for cortex-m-pac and cortex-m-hal when we finally sort that stuff out
<therealprof[m]>
cortex-m-sis ... gives us the option to add a cmsis-m-bro later...
<therealprof[m]>
s/cmsis/cortex/
<ruabmbua[m]>
I am in favor of not using any shorthand names.
<adamgreig[m]>
they can hang out with the sadly deprecated nb
<dirbaio[m]>
oh it's deprecated already? yay
<adamgreig[m]>
ok, let's say cortex-m-pac-interface for now, I'll update the PR and draft some updated doc text
<therealprof[m]>
ruabmbua[m]: The point is: it needs to have a name but the name itself is not actually important.
<dirbaio[m]>
cortex-m-vectors
<ruabmbua[m]>
Well if one reads the name and then has an idea what it could be based on that, it will help any newbies browsing the source code
<dirbaio[m]>
cortex-m-core
<adamgreig[m]>
dirbaio[m]: oh sorry I don't think it's "officially" deprecated. I won't interfere with HAL team business :P
<dirbaio[m]>
(I was joking)
<therealprof[m]>
ruabmbua[m]: Or do the opposite: imply importance -- which is exactly my concern here...
<adamgreig[m]>
the main other thing on the list is deprecating mutex-trait, which I think is just waiting for an rfc now
<adamgreig[m]>
anything else anyone wanted to discuss?
<adamgreig[m]>
so the book has a chapter on tooling that's all about gdb and openocd and such
<AdamHott[m]>
yes, I saw that and looked at probe.rs
<adamgreig[m]>
it should really be updated to talk primarily about probe-rs and what people actually use these days
<AdamHott[m]>
ok, sounds great!
<adamgreig[m]>
Adam Hott volunteered to help out, but I think could probably use some pointers on what topics to include?
<andresovela[m]>
I wanted to bring up something, I saw a few weeks ago that some crate/crates were “donated” to the embedded community for maintenance, any chance Ferrous Systems would be willing to “donate” defmt? Perhaps flip-link too?
<therealprof[m]>
Okay, I was worried for a bit... We're not talking about probe.rs documentation but about changing our documentation to use probe.rs instead. 😅
<JamesMunns[m]>
misc note, I think we could really use some "flashy" examples of "did you know you can do this without pain in embedded rust?", like "look how easy setting up a project is", or "look how easy it is to use rtt/defmt". This is both a probe-rs and rust thing
<thejpster[m]>
but you can't do it in a HAL agnostic way
<thejpster[m]>
The HALs have good examples
<adamgreig[m]>
doesn't need to be HAL agnostic
<JamesMunns[m]>
like for people just looking to dip their toes in or decide IF they want to dip their toes in, some good promo of why the grass is greener.
<adamgreig[m]>
just some examples on the first page of the book for one or two mcus showing how slick and nice things can be
<thejpster[m]>
the REWG has traditionally been HAL agnostic
<adamgreig[m]>
has it? the disco book was all f3 and such
<dirbaio[m]>
The discovery book is definitely not Hal agnostic
<adamgreig[m]>
and then micro:bit
<thejpster[m]>
although I suppose there is/was the Discovery book
<JamesMunns[m]>
I've always REALLY appreciated how instructive a GIF or similar is - rust-analyzer used that very effectively.
<adamgreig[m]>
I don't think we'd be saying "use this hal!", we just want some concise collected examples of how nice things can be
<dirbaio[m]>
(and it's using an unmaintained hal but taht's another story 🤣)
<thejpster[m]>
apart from the Discovery book, the REWG has tried quite hard to be HAL agnostic
<adamgreig[m]>
and also, no problem saying "this hal exists", that's what the awesome-embedded-rust list is for
<thejpster[m]>
but there's perhaps room for an edited version of the AWEL
<thejpster[m]>
as long as there's a clear process for a HAL to volunteer up a demo project for inclusion
<JamesMunns[m]>
https://www.sublimetext.com/ is also another of my long-term good examples for "look, this is easy and it is cool, you don't even have to read"
<AdamHott[m]>
I'm pretty green to embedded Rust, if I threw some unlisted YouTube videos of me working through a couple examples of probe.rs and rtt, would anyone watch for accuracy?
<AdamHott[m]>
No worries either way
<JamesMunns[m]>
AdamHott[m]: happy to review, also discuss some nice tooling that might help for screen recording and making a web-friendly animation/video (mostly OBS + ffmpeg)
<thejpster[m]>
very happy for people to film themselves working through that
<Noah[m]>
AdamHott[m]: yeah, absolutely, shoot :)
<AdamHott[m]>
Thanks James!
<thejpster[m]>
(although it needs changing from probe-run to probe-rs or cargo-flash)
<AdamHott[m]>
Thanks Noah!
<Noah[m]>
well, you are doing part of the work I always wanted to do but never managed ;)
<thejpster[m]>
this discussion also touches upon the "project shape" questions being discussed over on Zulip.
<AdamHott[m]>
Ok let me go through some examples and do some recordings, and I'll send them
<JamesMunns[m]>
Noah[m]: There's a huge benefit to watching someone else's workflow. You learn a ton just asking "wait how did you do that?!?!"
<thejpster[m]>
there is a piece of work which is "make the thing" and there is a piece of work which is "tell people about the thing"
<thejpster[m]>
the project does not currently know if it should only do the former, or if it should do both
<thejpster[m]>
James Munns: which is why Why Rust? and Why Ferrocene? both have live coding sessions in the middle
<AdamHott[m]>
once I get a handle on how to do it, I'll be happy to work with anyone to get the tooling page updated
<AdamHott[m]>
I'm very excited about embedded Rust
<Noah[m]>
AdamHott[m]: I am revamping the probe-rs webpage, happy about all feedback possible :)
<JamesMunns[m]>
Also: being relatively fresh is a very good thing! It means you don't take things for granted that some else that is even newer to it would also appreciate
<Noah[m]>
I suck at writing docs
<ruabmbua[m]>
Noah: if you are behind probe-rs docs I have to disagree
<AdamHott[m]>
Happy to work with you!
<Noah[m]>
ruabmbua[m]: Which part, but I guess in large part I am ^^
<ruabmbua[m]>
I think its pretty ok. And having its own website was probably the reason why I got interested
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Please add me as a +1 on RustNL if that's a thing: I'm working closely with Henk Oordt on stuff and would love an excuse to travel to NL and talk embedded.
<bartmassey[m]>
Sorry to have had to miss the meeting.
<bartmassey[m]>
Also let me know if I can help somehow with the efforts on doc and teaching materials.
<ruabmbua[m]>
* got interested in the first place. (I know its stupid, but nice graphics and stuff actually do matter)
<AdamHott[m]>
ok everyone, I have to run!
<AdamHott[m]>
Noah James Munns I'll be in touch!
<jannic[m]>
It's not stupid. For me it's not primarily the nice graphics, but the impression that someone does care. Often a good sign that other properties of a project are also handled well.
<JamesMunns[m]>
100% not stupid
<JamesMunns[m]>
if you've got 30s to make a point, then a clear gif probably goes further than clear text, IMO.
<thejpster[m]>
back to the topic above, did anyone take an action to fix the Rust Embedded book?
<ruabmbua[m]>
I think the problem is mostly the attention span we have nowadays. I regulary browse the webs for interesting new stuff. Sometimes I skip reading too fast and totally miss a gem. But if its a gem + has a nice website the chances are way higher
<ruabmbua[m]>
* way higher for me to actually try it
<Noah[m]>
<ruabmbua[m]> "I think its pretty ok. And..." <- my opinion exactly :) that's why I invest time in it even if it's worthless to most people :)
<adamgreig[m]>
thejpster: yea, Adam Hott volunteered to help out on it
<thejpster[m]>
ok, cool, missed that bit
<thejpster[m]>
<andresovela[m]> "I wanted to bring up something..." <- Those crates are not owned by Ferrous, they are owned by the Knurling project. And I don't think any have been donated - instead probe-run was deprecated in favour of binaries from probe-rs, which is the library that probe-run was using.
<adamgreig[m]>
I think they were referring to heapless and volatile-register
<thejpster[m]>
The Knurling project receives sponsorship money which it spends on developer time to keep the crates up to date. I'm not sure where you'd propose to send them to where they'd get more support than they currently get?
<thejpster[m]>
OK, those projects were Jorge's personal property.
<adamgreig[m]>
yea, I don't think there's been any suggestion that knurling or ferrous had transferred any projects to the wg
<adamgreig[m]>
right, that's all for the meeting, thanks everyone!
<thejpster[m]>
> <@andresovela:matrix.org> I wanted to bring up something, I saw a few weeks ago that some crate/crates were “donated” to the embedded community for maintenance, any chance Ferrous Systems would be willing to “donate” defmt? Perhaps flip-link too?
<thejpster[m]>
* The defmt crates are not owned by Ferrous, they are owned by the Knurling project. And I don't think any have been donated - instead probe-run was deprecated in favour of binaries from probe-rs, which is the library that probe-run was using.
<jessebraham[m]>
Oh! Also, new bare-metal HALs for Espressif chips are out too, new minor release plus a quick little subsequent patch. Lots of new features, lots of breaking changes, good times 😁 Check out the release notes for more info:
<dirbaio[m]>
imo defmt development has indeed slowed down a bit in the last 1-2 years, though
<danielb[m]>
dirbaio[m]: I don't mind not bumping msrv with great regularity tbh
<dirbaio[m]>
Lol
<andresovela[m]>
Yeah the reason I brought it up it's because I see defmt as one of the central pieces of the embedded rust ecosystem, and I have gotten the feeling that it's become a bit abandoned
<thejpster[m]>
I use it all the time and I wasn't really aware of anything lacking? (and for full disclosure, I work at Ferrous)
<andresovela[m]>
But I understand that it's its own entity and all that, I don't wanna overstep any lines, I was just saying :)
<thejpster[m]>
are they just trying to make cortex-m look bad?
<ruabmbua[m]>
not everyone follows the recommended rust semver policy of never getting to 1.0
<ruabmbua[m]>
(obviously joking)
<jessebraham[m]>
Commitment is hard 😉
<andresovela[m]>
thejpster[m]: It's not that there's something lacking, but rather that at least I find that there are a lot of paper cuts that could be improved
<andresovela[m]>
For example, I personally dislike a lot the fact that logs with "location" are printed in two lines
<andresovela[m]>
There were a few attempts at fixing this by introducing --verbose, --with-location, flags to probe-run, probe-rs
<mabez[m]>
thejpster[m]: The only thing I often reach for is some kind of `#[ignore]` attribute to allow deriving `Format` when one field can't be automatically derived, I'm bored of manually deriving `Format` now :D
<mabez[m]>
s/deriving/writing/
<andresovela[m]>
I implemented a way to customize the log output and I have a PR open to document the feature for about a month now
<M9names[m]>
ruabmbua[m]: Saying you're releasing 1.0 soon means you get stuck on 0.2 for 3 more years and you rip out a bunch of functionality because it has to be perfect.
<M9names[m]>
(also obviously joking but with more 🌶️)
lulf[m] has joined #rust-embedded
<lulf[m]>
<adamgreig[m]> "I don't think there's any more..." <- I'm interested too
<thejpster[m]>
andresovela: in defmt or in probe-run?
<andresovela[m]>
defmt
<ruabmbua[m]>
M9names[m]: > <@9names:matrix.org> Saying you're releasing 1.0 soon means you get stuck on 0.2 for 3 more years and you rip out a bunch of functionality because it has to be perfect.
<ruabmbua[m]>
> (also obviously joking but with more 🌶️)
<ruabmbua[m]>
I call it the 1.0 stigma
<thejpster[m]>
I see it.
<thejpster[m]>
I think the issue is that our dedicated knurling employee just took a few months sabbatical to finish his university studies.
<thejpster[m]>
I have raised the issue internally.
<andresovela[m]>
Cool thanks :)
<Noah[m]>
<thejpster[m]> "I use it all the time and I wasn..." <- Not using it myself, so cannot judge, but from what I observe I don't think anyone believes it's lacking, on the contrary, it's amazing! I think people are more refering to PR reviews/merges. Again, observing from the sideline and I don't always merge in probe-rs timely either :D
<thejpster[m]>
yeah, that's fair. We were pushing Ferrocene out of the door.
TimHilt[m]1 has quit [Quit: Idle timeout reached: 172800s]
<waveguide[m]>
Is there a way to use dyn without Box<T> in embedded, to say have something like [dyn SomeTrait; 4] where the actual object implementing the trait may vary in size?
<waveguide[m]>
* Is there a way to use dyn without Box\<T> with no_std, to say have something like \[dyn SomeTrait; 4\] where the actual object implementing the trait may vary in size?
<waveguide[m]>
can it be as simple as a reference? &dyn SomeTrait?
euphemism[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
`&mut dyn SomeTrait` is roughly equivalent to `Box<dyn SomeTrait>`
<dirbaio[m]>
except of course you need to allocate the data somewhere it'll live long enough, you don't get the convenience of Box
<dirbaio[m]>
sometimes putting it on the stack works
<dirbaio[m]>
otherwise you can put it in a `static`. [static_cell](https://crates.io/crates/static_cell) helps with this. It allows you to get a `&'static mut dyn SomeTrait`, which you can now pass around as if it was owned (no lifetime param required!)
<dirbaio[m]>
of course you can only initialize it once, so it works best for something created once at program startup that live forever
<ruabmbua[m]>
Make sure you update the firmware of your raspberry pi. I had some troubles because of that with a different bare metal project
<johngigantic[m]>
Huh. It's new & out of the box, would that be an issue?
<ruabmbua[m]>
Yes
<ruabmbua[m]>
especially the 4b stock firmware had some pretty bad problems out of the box
<ruabmbua[m]>
-> like not booting in 75% of tries from sd card
<ruabmbua[m]>
Idk if they update it for newer ones from factory
<johngigantic[m]>
Wowza
<ruabmbua[m]>
You can also try your program in qemu, it should have a raspberry pi board mode. Not sure if it supports the 4, but pretty sure it does 2 & 3
<johngigantic[m]>
Yeah, I have been doing so, but the hardware connection is the issue. RPi 4 isn’t supported in qemu, but the earlier sections of the tutorial have you emulate the architecture-agnostic stuff early on before touching the board
<johngigantic[m]>
It’s just frustrating that I follow the tutorial pretty closely and get nothing
<ruabmbua[m]>
What bootloader are you using? And how do you create the sdcard image?
<ruabmbua[m]>
Not familiar with your specific tutorial, but with embedded linux / uboot in general
<ruabmbua[m]>
There is a SPI flash on the board which contains even earlier boot code
<ruabmbua[m]>
for raspbian you do not need a monitor you can enable ssh in some file in the boot partition by mounting it after flashing the sd card
<ruabmbua[m]>
Also forget how to do that ^^
<johngigantic[m]>
Ok. It feels a little like a rabbit hole, but I'll give it a go. Thanks
<johngigantic[m]>
Especially because I'll have to learn german 😉
<ruabmbua[m]>
unfortunately thats how it is. For embedded going application processor instead of microcontroller is a bit of pain.
<ruabmbua[m]>
Raspberry pi is much better than e.g. the last thing I did. The vendor provided a complete mess of a bootloader + kernel, and almost 0 documentation.
<ruabmbua[m]>
Had to reverse engineer their buggy crap and port it to upstream uboot
<ruabmbua[m]>
johngigantic[m]: sry I am from austria, and I usually do not notice when I switch languages XD
<ruabmbua[m]>
their is probably a english version of the page
<ruabmbua[m]>
johngigantic: when you create the partition table for your sdcard, make sure to make it mbr not gpt. I do not know if the rpi firmware supports gpt, but I am sure it supports dos/mbr (looking at my rpi4 server)
<ruabmbua[m]>
obviously you do not need the other two partitions at first. And it might also be a good idea to limit the size of the fat32 boot partition.
<johngigantic[m]>
Ok, gotcha - might be the boot partition size. Let me try that
<ruabmbua[m]>
I have to go now, I hope you can fix your problem!
<johngigantic[m]>
Thank you!
Guest7221 has joined #rust-embedded
neceve has quit [Ping timeout: 258 seconds]
ello has quit [Server closed connection]
ello has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]