<BenPye[m]>
<danielb[m]> "80% of my build times are in..." <- Is that just setting codegen units to 1?
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
kvark[m] has joined #rust-embedded
<kvark[m]>
Hi All!
<kvark[m]>
Any pointers to start? It looks like most code in riscv-rust org is focused on hifive boards?
<kvark[m]>
I want to play with Rust on bare metal of Milk-V.
sajattack[m] has joined #rust-embedded
<sajattack[m]>
closest thing I can think of is oreboot but it supports visionfive and nezha only. I think milk-v might be similar hardware to visionfive2 though? https://github.com/oreboot/oreboot
<sajattack[m]>
risc-v rust-embedded seems a bit like a niche of a niche to me and it shows. I haven't seen anyone really champion it. A few notable contributors but yeah just hasn't reached critical mass imo
<sajattack[m]>
assuming we're talking about milk-v mars - you could try hacking the visionfive2 port of oreboot until it can run code beyond a bootloader, but it would be a pretty advanced-level project
<kvark[m]>
cool, thanks for the hint!
<sajattack[m]>
the more powerful the board, the harder it is to bring up all it's peripherals
<sajattack[m]>
all the external memories and clocks and such
<kvark[m]>
hopefully it's a gradual development process - I don't need all the peripherals to boot :)
<sajattack[m]>
yeah kinda
<sajattack[m]>
you need clocks and memory before you can do much else
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
Guest7221 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
hifi has quit [Ping timeout: 240 seconds]
hifi has joined #rust-embedded
<danielb[m]>
<BenPye[m]> "Is that just setting codegen..." <- and fat LTO
hifi has quit [Ping timeout: 248 seconds]
Lumpio- has quit [Ping timeout: 255 seconds]
hifi has joined #rust-embedded
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
<sajattack[m]> "risc-v rust-embedded seems a bit..." <- I mean Espressif seem to be very committed to RISC-V+Rust
<dngrsspookyvisio>
but that doesn't help with Milk-V…
hifi has quit [Ping timeout: 272 seconds]
Lumpio- has joined #rust-embedded
hifi has joined #rust-embedded
JonathanDickinso has joined #rust-embedded
<JonathanDickinso>
Even the C community is struggling with Milk-V. Their documentation isn't great and they don't seem to want to do much about it, totally scared me off the platform.
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
I got upstream linux + uboot working on jh7110. Still a struggle with all the peripherals. Latest status is that I got ethernet working reliably
<ruabmbua[m]>
(there is some sort of upstream support, but it did not actually work for me like it is right now)
<ruabmbua[m]>
At least with the visionfive2 I can recommend not using the vendor provided boot images with their uboot. Its totally screwed, e.g. one of the boot scripts does some crazy things like patching device trees on disk in very weird ways (which does not work), instead of using upstream uboot functionality for it
<ruabmbua[m]>
The chip is very disappointing b.t.w. Not sure if there is something wrong, but there is a large difference in responsiveness compared even to a raspberry pi 3. My current theory is, that the sdcard / emmc speed is so bad, that it affects system performance.
Guest7221 has left #rust-embedded [Error from remote client]
<ruabmbua[m]>
-> I use u-boot for booting my rust kernel I am currently toying with. If anyone else is interested, I can publish my network booting setup for visionfive2, which allows me to recompile, and just reset the board to directly boot it via network.
<ruabmbua[m]>
I also have some patches for u-boot to unlock jtag access to the correct pins with the pinmuxer
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Guest7221 has joined #rust-embedded
<BenPye[m]>
<ruabmbua[m]> "The chip is very disappointing b..." <- Have you tried using M2 storage instead? I have a VisionFive 2 board that I haven’t got around to playing with
<ruabmbua[m]>
Not yet, was too lazy to disassemble my external usb SSD thing to salvage for SSD.
<ruabmbua[m]>
But I do not actually want to run nvme, I want to use the included emmc, it should be fast enough
<adamgreig[m]>
dfu-tool keeps threatening to stop working with raw images so maybe your version is new enough to have done it
<adamgreig[m]>
you can use dfu-tool to create a dfuse file
<FlixtheNewbie[m]>
What is a raw image? That seems overly complex: I have a binary, I want to put it on the flash memory: why do I have to do these shenanigans
<adamgreig[m]>
hi @room , weekly meeting time again! agenda is https://hackmd.io/wrGgeYXaStOJcUf2BcPgkA, please add anything you have to announce and we'll start in a few mins
<adamgreig[m]>
what you have is a "raw image"
<adamgreig[m]>
but for DFU people usually bundle it into something that also knows "where in flash do i need to be programmed" and "what chip am i being programmed to"
<adamgreig[m]>
because some end user a million miles away might be using this image with some other tool, so it's more convenient
<FlixtheNewbie[m]>
Yeah, but I know what I'm doing, I don't need that
<adamgreig[m]>
it's not optimised for "i'm the developed and flashing my latest code", because ideally you have a debug probe in that case, instead of using the bootloader
<FlixtheNewbie[m]>
Oh, I see
<adamgreig[m]>
s/developed/developer/
<adamgreig[m]>
but it sounds like you can maybe just use --dfuse-address to tell it the address?
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
adamgreig[m]: oh god its been another week
<adamgreig[m]>
check my example incantation in that link, maybe it will work
<adamgreig[m]>
JamesMunns[m]: i knowwwwwwwww
<adamgreig[m]>
i'm still at work this week too 🥲
<adamgreig[m]>
worse, the technicians' secret biscuit stash is empty so i can't even steal a biscuit to keep me going
<adamgreig[m]>
ok, let's start!
<adamgreig[m]>
one quick announcement, svdtools 0.3.4 is was released this week
<adamgreig[m]>
any other announcements from anyone?
<adamgreig[m]>
OK, let's move on and if you have anything to announce just shout
<adamgreig[m]>
first up, quick check if anyone's seen any issues with the anti-spam bot?
<adamgreig[m]>
please do report them if you spot anything, I don't think it's had to ban anyone recently though
<adamgreig[m]>
next up, I made a PR to add a new "libs" team for our various embedded libraries, since they aren't really covered by HAL, tools, or the arch-specific teams: https://github.com/rust-embedded/wg/pull/707
<adamgreig[m]>
we actually already have a majority approval vote, along with a couple of volunteers to help out, but I was hoping to see dirbaio approve it too as the first volunteer otherwise it feels a bit coercive :P
<adamgreig[m]>
I'm not sure if he's around atm though, so in the meantime does anyone else have anything they want to say about the libs team?
<adamgreig[m]>
I've heard back from japaric about potentially moving volatile-register and heapless, so hopefully we can get both of those across fairly soon once the libs team is established
<adamgreig[m]>
if no one has any issues with it I'll merge it after the meeting
<adamgreig[m]>
next up, the rust target maintainers thing, https://github.com/rust-embedded/wg/issues/704, I think is now also ready to submit upstream, so if you're on the riscv/msp430/cortex-m teams please give it a final look over if you can and then I'll submit it
<therealprof[m]>
adamgreig[m]: Why wait if the merge is just a button push away? 😉
<adamgreig[m]>
we discussed this idea last week: split the InterruptNumber trait out of cortex-m, since PACs depend on it and that makes it very very hard to ever do breaking changes to cortex-m, since you can't have multiple versions in your build tree
<adamgreig[m]>
the PR adds a new crate with just the InterruptNumber trait, and the current version of cortex-m in master (0.8 to-be) changes to use it without re-exporting
<adamgreig[m]>
but the idea is to have a new 0.7 series release that just re-exports this trait, so that PACs could immediately start to update to it and still work with cortex-m 0.7's NVIC
<adamgreig[m]>
thejpster asks if that's a breaking change, though, and I'm not sure... you can't ever have more than one version of cortex-m in your build tree, and a patch release can be pulled in by cargo as soon as the new PAC requires it, so I don't think you can ever have the old cortex_m::InterruptNumber and the new cortex_m_interrupt_number::InterruptNumber together in a way that causes problems?
<adamgreig[m]>
I had a related thought, which is we should maybe yank the single breaking change in cortex-m's master branch to a new branch, "0.8" or "next" or just an open PR, and have master be 0.7 again, at least until we're closer to actually releasing 0.8
<adamgreig[m]>
but that's somewhat distinct from the interrupt-number trait crate
<dirbaio[m]>
o/
<dirbaio[m]>
sorry I was afk
<adamgreig[m]>
o/
<dirbaio[m]>
team PR approved
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Would you recommend us to do the same for riscv? (The riscv-interrupt crate thing)
<adamgreig[m]>
I think it probably makes sense for the same reasons, yea
<adamgreig[m]>
you could wait a week and check we don't run into some unforeseen issue on c-m
<romancardenas[m]>
Great, we'll do
<adamgreig[m]>
I feel we should be able to release c-m-i-n, update svd2rust and other PACs to implement it instead of c-m 0.7's version, then... when someone updates their PAC and not their c-m they find they can't enable interrupts because the PAC doesn't impl old c-m's InterruptNumber, but if they "cargo update" it will work again, or they update c-m and not the PAC (this is more likely when the PACs are slow to update), and then the PAC should
<adamgreig[m]>
end up implementing the re-exported trait from the new c-m 0.7 release and work ok?
<therealprof[m]>
Not sure why the interrupt number crate is necessary but I guess you have your reasons.
<adamgreig[m]>
needs testing I guess
<adamgreig[m]>
therealprof: the motivation is that right now, all PACs depend on cortex-m 0.7 to implement this trait, so if we release cortex-m 0.8, no one can update to it until their PAC updates, because you can't have 0.7 and 0.8 together (except if we do another semver hack release of 0.7, which gets more and more painful every time and is prone to bugs)
<adamgreig[m]>
but typically your HAL depends on the PAC too, so you're stuck waiting for the PAC and HAL to update to 0.8 before your application can update, and in the meantime maybe some other crate you use wants c-m 0.8 and you're stuck
<adamgreig[m]>
but this is an artificial problem: the PAC only depends on a stable and unchanged trait from c-m, there's no reason it couldn't work on c-m 0.8
<adamgreig[m]>
by splitting it out, the PACs can remove all dependency on cortex-m, so we're in turn hopefully freer to issue breaking releases
<adamgreig[m]>
...is the thinking.
<adamgreig[m]>
we could also not do this, and when we do eventually release a new c-m 0.8 or 1.0 or whatever, it just takes a while for PACs to update before people can start using it; not the end of the world either
<therealprof[m]>
adamgreig[m]: Gotcha, makes sense. Thanks for the explanation.
<adamgreig[m]>
yea, I think we'd simultaneously have svd2rust not re-export the core peripherals, which users can get from cortex-m directly anyway, for the same reason
<adamgreig[m]>
it might also be possible to not require the dependency on cortex-m-rt either which would be nice
<adamgreig[m]>
maybe we can do a quick test before releasing c-m-i-n to double check how the PACs will handle it when one or the other is newer/older
<adamgreig[m]>
ok, I think that's everything I had for this meeting, anyone else want to discuss anything?
<romancardenas[m]>
Just curious, any plans for e-h 1?
<adamgreig[m]>
good question! I'm not sure actually, anyone from the hal team have any thoughts?
<adamgreig[m]>
I guess ideally we should at least look over the various 1.0-rc.1 impls and drivers and check there haven't been any major issues
<jannic[m]>
Nothing to discuss, but I wanted to mention that EuroRust was great, and a lot of people I talked to mentioned embedded rust.
<adamgreig[m]>
nice! I'm sad I couldn't make it...
<adamgreig[m]>
ok, let's finish the meeting there for today then, thanks everyone!
<cr1901>
Well so much for me being at the meeting (sorry, meatspace thing right as the meeting started)
<Jonathan[m]1>
What is recommended for a new project? svd2rust, chiptool, raltool?
<dngrsspookyvisio>
Usually "an existing HAL"... depends on your kind of project I guess
inara has quit [Quit: Leaving]
waveguide[m] has joined #rust-embedded
<waveguide[m]>
<Jonathan[m]1> "What is recommended for a new..." <- Depends on what you are wanting to generate MMIO like regmap code for, svd2rust has been around the longest but... generates code that uses references (questionable) and takes a long time to compile generally, raltool is a fork of chiptool that was made to better match what an older python tool generated
<Jonathan[m]1>
It's completely new (I'm looking at Xilinx FPGA), I'm building the cpu crate, runtime, pac and hal so I'm free to use whatever I want. Downside is I don't know what is available!
<FlixtheNewbie[m]>
<adamgreig[m]> "but it sounds like you can maybe..." <- Yes, it works. Basically, I just had to provide the address of the flash memory: `sudo dfu-util -s 0x08000000 --device 0483:df11 --alt 0 --download ./app.bin --reset`
<FlixtheNewbie[m]>
It's funny how embedded is a different world. I've been a senior developer for years, but I feel like I've just begun to develop now.
<JamesMunns[m]>
I think adamgreig has a *thing* for that (assuming you are doing a riscv processor), it's probably RAL based
<JamesMunns[m]>
JamesMunns[m]: (responding to Jonathan)
<Jonathan[m]1>
I'm looking at Cortex-R5... only things I found are 5 years old
<JamesMunns[m]>
Ah, are you using a hard-ip core, or instantiating a soft-ip core?
<Jonathan[m]1>
Hard-ip
<waveguide[m]>
Jonathan[m]1: so the way most of this has been done so far is a hand written core peripheral crate (cortex_m) and then the soc peripherals are mapped from an svd file to rust code using one of the tools. You could directly do mappings with chiptool though from yaml for things like the core arm peripherals
<JamesMunns[m]>
Gotcha! yeah, I saw some folks working on Cortex-R a while back, nothing more recent.
<JamesMunns[m]>
I *might* remember thejpster talking about Cortex-R cores recently? But maybe only in a "is anyone using this" kind of way.
<Jonathan[m]1>
My goal is to use Linux on the A-53 to start a rust firmware on the Cortex-R5
<Jonathan[m]1>
And then use something like OpenAMP (I've seen rust rewrite) to communicate with the Linux controller
<Jonathan[m]1>
But for the PAC/HAL, I was going for svd2rust, but found chiptool/raltool that look more recent, so I'm wondering if "they would be recommanded over svd2rust" for something without legacy
<waveguide[m]>
svd2rust isn't legacy and is widely used, as is chiptool at this point. The pros/cons mostly come down to the use of references by svd2rust (questionable semantics, given registers are volatile), and the compile time involved. It's up to you, the hal creator. You could hand write everything if you wanted, there's no definitive answer around it
<waveguide[m]>
the closest to how you'd write it in C is probably what raltool does, defines offsets/masks/etc and you use some macros to read/write/update
<Jonathan[m]1>
What is raltool about then? I saw it is forked from chiptool and is faster...
<waveguide[m]>
right, nothing to compile when its effectively equivalent to #define SOME_REG_X 0x0000
<Jonathan[m]1>
Ok, thanks, I will play with them with that information, it's very helpful
<waveguide[m]>
so if you have a lot of peripherals, it makes good sense and avoids having rustc do much work just to get you a register map
inara has joined #rust-embedded
<waveguide[m]>
where as the other tools generate function wrappers/closure wrappers for things like SomeReg and you want to update a bit, it might generate set_en_bit(&mut self) wrapper
<waveguide[m]>
take a look, its worth looking at the various pac crates and how they are setup
<waveguide[m]>
and what the trade offs are
<Jonathan[m]1>
Ok thanks! The chip is huge, probably bigger than most Cortex-M chip, but most of it will be controlled by Linux and not exposed to the Cortex-R5
<thejpster[m]>
<Jonathan[m]1> "My goal is to use Linux on the A..." <- I did this with the M4 on a Beaglebone Black. It’s online somewhere.
<adamgreig[m]>
lol, sigh, the "update readme" pr conflicted with the "new libs team" pr, stopping the latter merging until rebased, which dismissed all the reviews
<GrantM11235[m]>
<ruabmbua[m]> "-> I use u-boot for booting my..." <- I would be very interested to see this! I recently got a allwinner f1c200s board (armv5 with 64MB of dram) to play around with, and it uses u-boot
<adamgreig[m]>
thanks dirbaio, welcome to the libs team!
<BenPye[m]>
<waveguide[m]> "svd2rust isn't legacy and is..." <- It looks like the answer is no, but do either chiptool or raltool allow you to have two different 'modes' for a set of registers? The MCU I'm currently playing with has a USB peripheral that does both device and host, I ended up hacking the svd to make the USB device mode more usable, but it would be nice if I could have some way to generate a set of registers for both device and
<BenPye[m]>
host
<adamgreig[m]>
usually they will emit aliasing register definitions, or alias fields on the same register
<adamgreig[m]>
at least, that's what I did for stm32ral which I guess is the python tool that would eventually inspire raltool, and svd2rust does a similar thing with aliased fields
<waveguide[m]>
some work would be needed probably to have either the register block or a subset of it have aliased registers and fields
<BenPye[m]>
Oh huh, it didn't even occur to me that that was legal in an svd... The vendor provided definition is particularly terrible and just merges both host and device register names
notgull has joined #rust-embedded
<waveguide[m]>
@dirbaio:matrix.org: would probably know best how chiptools IR deals with it, if it bothers doing anything special
<dirbaio[m]>
yea you can just make overlapping regs
<BenPye[m]>
Yeah I just saw that, I guess it does rule raltool out - but this part is simple enough that I'm not really worried about the compile time difference
<waveguide[m]>
mostly that's probably because of the way the codegen part works in this case
<waveguide[m]>
You could probably carefully craft a device and host RegisterBlock with raltool, and point them at the same IP address