ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
dreamcat4 has quit [Quit: Connection closed for inactivity]
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
alefir has quit [Ping timeout: 250 seconds]
emerent_ has joined #rust-embedded
emerent has quit [Killed ( (Nickname regained by services))]
Guest2 has joined #rust-embedded
<re_irc> <dngrs (spookyvision@github)> hopefully not too offtopic ... I'm trying to figure out the meaning of various letters in flash memory, so e.g. GD25Q64BSIG - I got this far: GD=Gigadevice, Q=?QSPI?, 64=Mbit ... and that the part number is probably fake anyway since it's not listed by Gigadevice %) how to approach this in general?
<re_irc> <ryan-summers> Part number specifications and meaning are typically outlined in the device datasheet
<re_irc> <dngrs (spookyvision@github)> ah so there's one per family?
<re_irc> <K900> It's impossible to know
<re_irc> <K900> There is no convention
<re_irc> <dngrs (spookyvision@github)> found some Winbond data sheets, let's see what they say
<re_irc> <dngrs (spookyvision@github)> K900: ok great, thx :D
<re_irc> <K900> Any vendor that claims to have a convention has at least three parts that violate said convention
<re_irc> <Max Muravyev> Hey,
<re_irc> The thing is I wanna make it with clang and libc++.
<re_irc> I install libs:
<re_irc> I'm trying to compile cpp subproject under rust using cross-compilation to aarch64-linux-gnu-g++.
<re_irc> <ryan-summers> From that device family datasheet ^
<re_irc> <dngrs (spookyvision@github)> thx!
<re_irc> <ryan-summers> But yeah, the convention is usually only valid for the given part family, and even then, may have deviations
<re_irc> <Max Muravyev> * ring with clang and libc++ tools. Their github page
<re_irc> <adamgreig> It is common for 25Q to be qspi flash across many manufacturers, but it's just a convention
<re_irc> <adamgreig> Like 25C before it and also most 2* memories
<re_irc> <Max Muravyev> +Also, ring was tested with clang only with qemu-based compilation.
<re_irc> <dngrs (spookyvision@github)> aye
<re_irc> <Max Muravyev> * compilation, not cargo.
<re_irc> <Max Muravyev> * "apt-get install gcc-multilib g++-multilib clang libc++-dev"
<re_irc> I'm trying to compile cpp subproject under rust using cross-compilation to aarch64-linux-gnu-g++.
<re_irc> I install libs:
<re_irc> <Max Muravyev> Hey,
<re_irc> The thing is I wanna make it with clang and libc++.
<re_irc> I'm trying to compile cpp subproject under rust using cross-compilation to aarch64-linux-gnu-g++.
<re_irc> <Max Muravyev> Hey,
<re_irc> I install libs:
<re_irc> The thing is I wanna make it with clang and libc++.
<re_irc> <Max Muravyev> * installed
<re_irc> <Max Muravyev> * "clang" and "libc++".
<re_irc> I'm trying to compile cpp subproject under rust using cross-compilation to aarch64-linux-gnu-g++.
<re_irc> <Max Muravyev> Hey,
<re_irc> I installed libs:
<re_irc> The thing is I wanna make it with "clang" and "libc++".
<re_irc> <Max Muravyev> * from "arm64" to "aarch64-linux-gnu-g++".
<re_irc> <Max Muravyev> * "ring"
<re_irc> <Max Muravyev> * "ring"
<re_irc> <Max Muravyev> +Thanks!
<re_irc> <luojia65> Should we release `riscv` crate version 0.7.1? It's nearly half a year before last release, and there are more features on master branch
<re_irc> <luojia65> Or it maybe more appropriate to release after finishing some items on to do list
<re_irc> <d3zd3z> I'd asked this question over on, and someone recommended I ping here.
<re_irc> <d3zd3z> I am a maintainer for MCUboot, a C MCU bootloader project. I am interested in working on a Rust bootloader and have a few questions about things, esp HAL support.
<re_irc> <d3zd3z> So far, the boards I've looked at don't have support for the flash controllers. Generally, this is kind of tricky, since it is usually necessary to mask interrupts, and execute out of RAM during flash operations.
<re_irc> <d3zd3z> I was wondering if anyone has looked into this yet, or if I'm breaking new ground here.
<re_irc> <d3zd3z> Typically, in something like Zephyr, a small piece of code will be copied to RAM, and the code will jump to that to perform the flash operations.
<re_irc> <jessebraham> We're looking into re-writing the flasher stub for the Espressif chips in Rust coming soon, but unfortunately have not yet started on it.
<re_irc> <jessebraham> That's about the closest we've come to the conversation haha
<re_irc> <pinealservo> I think the probe-rs folks have probably thought about it to some degree, but it's been a while since I was following things at that level.
<re_irc> <Lachlan Sneff> Has anyone managed to get probe-run ported to an embedded system? Maybe not the way to go, but seems like a clever way to make a board that can flash basically anything else
<re_irc> <Lachlan Sneff> Or probe-rs rather
<re_irc> <lulf> Lachlan Sneff: like ? Or maybe I'm misunderstanding the question
<re_irc> <Lachlan Sneff> Oh, that’s pretty much it yep
<re_irc> <d3zd3z> I think I'll probably start, then, with trying to get HAL support on one of the boards I have. The NRF flash controller is pretty simple, so maybe that is a good place to start (but will require me to figure out how to run code from RAM).
<re_irc> <jannic> I don't think hs-probe contains probe-rs, it's just a probe which is compatible. (And has a rust firmware.)
<re_irc> <lulf> ah, didn't know that
<re_irc> <lulf> d3zd3z: I recently worked on a bootloader for nrf (and eventually stm32) here
<re_irc> <d3zd3z> lulf What did you end up doing to be able to use the flash controller while the code was running from flash?
<re_irc> <lulf> d3zd3z: nothing (it just worked0
<re_irc> <lulf> * worked)
<re_irc> <d3zd3z> Interesting, I wonder if you're just getting lucky and the code stays resident in cache.
<re_irc> <lulf> d3zd3z: my impression is that it should just work as long as you're not reflashing the code your executing, but I don't know much about these things
<re_irc> <lulf> d3zd3z: the flash driver seems to wait until flash is not busy before doing any operation, maybe that is what makes it work 🤷
<re_irc> <d3zd3z> It probably depends on the specific CPU. Maybe I misread the NRF52 data sheet. I know that the NXP LPC52S69 definitely can't fetch instructions while doing flash programming. Maybe it is unique to that device.
<re_irc> <Noah> Well I would guess that's just the LPC that sucks :D
<re_irc> <d3zd3z> The NXP C Hal is the one where I first noticed the trick of moving the code to RAM.
<re_irc> <Noah> Basically any device doing FW upgrades in the loop has to have that capability
<re_irc> <d3zd3z> Or use tricks.
<re_irc> <Noah> Maybe you cannot write the same Sector. But I would assume different sectors work
<re_irc> <Noah> Well sure, but that is something many devices do. Idk
<re_irc> <d3zd3z> I'm guessing it varies. I seem to remember seeing an ST device that divided the flash into several large banks, and you could write in a different bank than you were executing from.
<re_irc> <Noah> Lachlan Sneff: I think what you want is what the "blackmagicprobe"does. but I don't like the concept much as it's a hassle to get new devices in and you are constrained to no_std :)
<re_irc> <Noah> d3zd3z: yep :) Nordic is kind of very advanced in terms of useability.
Guest2 has quit [Ping timeout: 256 seconds]
<re_irc> <Noah> So it might be they can do it and others not :)
<re_irc> <Eivind Bergem> I've done in-application programming to flash on an NXP LPC54628. If I remember correctly, it had to be a different sector. So not all LPCs suck :P
<re_irc> <adamgreig> d3zd3z: a few people have written various bootloaders in rust, eg i wrote way back when (so it might not be the best thing to look at for modern rust!)
<re_irc> <adamgreig> as i'm sure you know from mcuboot there's as many different ways of doing this as there are microcontrollers, in my case the main firmware reboots into the bootloader which has a network stack and receives new firmware image other ethernet, writing it over the top of the first application, and then boots into it
<re_irc> <d3zd3z> One of the goals of MCUboot is to try and unify the diversity of bootloaders. Not sure how well it has done that in it's space, but we do have quite a few users.
<re_irc> <adamgreig> i've certainly heard a bunch about it!
<re_irc> I am new to Rust and would definitely like to learn more, I already made a very simple game/webapp with rust to learn a bit about the language. However I am more interested in learning rust for low-level and cryptography.
<re_irc> <aktaboot> Hello fellow Rustaceans,
<re_irc> I came here looking for guidance, shed light on my lost soul please. :)
<re_irc> Any projects/ressources that were very instructive to you that you would recommend ?
<re_irc> <disasm> luojia65: It's a good idea to release a new version, you can prepare a PR for this to speedup things. However, one of the unreleased changes is technically a breaking change, so next version is more like 0.8.0.